Kubernetes for Beginners: The Power Duo of Deployments and ReplicaSets - Managing Stateless Applications Made Easy

In the previous post, we got acquainted with Pods, the most basic deployment unit in Kubernetes. However, manually managing Pods will quickly become inadequate when your application needs to scale, self-heal when there is a failure, or when you want to update to a new version. That's where Deployments and ReplicaSets appear as reliable "managers" to help you solve these problems.

Problems with manual Pod management:

Imagine you create a few Pods to run your web app. What if:

• Traffic spike? You'll have to manually create more Pods to accommodate, which is time-consuming and error-prone.
• A Pod fails and stops working? Your app will be broken until you detect and recreate that Pod.
• Want to update your app to a new version? You will have to delete old Pods and create new Pods with the new version, which can cause downtime for your app.

Obviously, manually managing Pods is inefficient and not suitable for production applications.

1. ReplicaSets: Keep Your Pod Count Healthy

ReplicaSet (rs) is a Kubernetes object responsible for keeping a certain number of replicas of Pods running at all times. It ensures that there are always enough Pods to meet your requirements.

How ReplicaSet works:

• Label Selector: ReplicaSet uses a Label Selector to identify the Pods it manages. It will track Pods whose labels match its selector.
• Quantity Guarantee: If the number of Pods with the appropriate label is less than the desired number of replicas, ReplicaSet will create more Pods. If the number is more, it will delete Pods.
• Self-healing: If a Pod managed by ReplicaSet fails or is deleted (for whatever reason), ReplicaSet automatically creates a new Pod to replace it, ensuring there are always enough active Pods.

Create ReplicaSet using YAML:

Here is an example of a YAML file defining a ReplicaSet:

apiVersion: apps/v1 kind: ReplicaSet metadata: name: my-app-replicaset labels: app: my-app version: v1 spec: replicas: 3 # Muốn có 3 bản sao (Pods) chạy selector: matchLabels: app: my-app # Selector này sẽ chọn các Pods có label 'app: my-app' template: # Định nghĩa template cho các Pods mà ReplicaSet sẽ tạo metadata: labels: app: my-app version: v1 spec: containers: - name: my-app-container image: my-app:1.0

In this file:

• apiVersion: apps/v1 and kind: ReplicaSet define the resource type.
• metadata.name is the name of the ReplicaSet.
• metadata.labels are the labels assigned to the ReplicaSet.
• spec.replicas specifies the desired number of Pods (3).
• spec.selector.matchLabels defines a selector for the ReplicaSet to identify the Pods it manages (in this case, the Pods with the label app: my-app). Important: The labels in spec.template.metadata.labels must match this selector.
• spec.template defines the template for the Pods that the ReplicaSet will create. It includes metadata (labels for the Pods) and the spec (definition of the container inside the Pod).

Use kubectl to manage ReplicaSets:

After saving the above file as my-app-replicaset.yaml:

• Create ReplicaSet:

  kubectl apply -f my-app-replicaset.yaml

• View information about ReplicaSets:

  kubectl get rs # hoặc kubectl get replicasets

  You will see ReplicaSet my-app-replicaset and the number of desired Pods (DESIRED), current Pods (CURRENT), ready Pods (READY).

• View detailed information about a ReplicaSet:

  kubectl describe rs my-app-replicaset

• View the Pods that ReplicaSet is managing:

  kubectl get pods -l app=my-ap

  This command will list all Pods with label app: my-app, these are the Pods that are being managed by ReplicaSet.

Self-healing test:

1. Delete one of the Pods managed by the ReplicaSet:

   kubectl delete pod <tên-của-một-pod>

   (You can get the Pod name from the command kubectl get pods -l app=my-app).

2. Run the command kubectl get pods -l app=my-app again after a while. You will see a new Pod has been created to replace the Pod you just deleted, making sure to always have 3 Pods running as desired.

Important Note About ReplicaSets:

While ReplicaSets are useful for ensuring the number of Pods, they are not typically created directly for application management. Instead, they are typically managed by a higher-level object called a Deployment .

2. Deployments: Manage applications the "smart" way

Deployment is a Kubernetes object that provides declarative management of Pods and ReplicaSets. It allows you to describe the desired state of your application (e.g. number of replicas, application version) and Kubernetes will attempt to bring the system to that state.

Why use Deployments?

• ReplicaSet Management: Deployment automatically creates and manages ReplicaSets for you. When you update your application version, Deployment creates a new ReplicaSet with the new version and gradually replaces the Pods of the old ReplicaSet with the Pods of the new ReplicaSet.
• Update Strategies: Deployment supports different update strategies to ensure updates are performed safely and without service disruption.
• Rollback: If something goes wrong after an update, Deployment lets you easily roll back to a previous version of the app.

Update Strategies:

Deployment provides two main update strategies, specified in the spec.strategy.type field:

• Rolling Update (default): This is the default update strategy and is recommended for most cases. It performs an incremental update of the application by replacing each Pod (or small group of Pods) of the old ReplicaSet with Pods of the new ReplicaSet. This ensures that there is always a number of Pods running during the update, minimizing or eliminating downtime.
  • maxSurge: Specifies the number of Pods that exceed the desired number of replicas that can be created during an update. The value can be an absolute number (e.g. 1) or a percentage (e.g. 25%).
  • maxUnavailable: Specifies the maximum number of Pods that will be unavailable during the update. The value can also be an absolute number or a percentage.
• Recreate: This strategy will delete all Pods of the old version before creating Pods of the new version. This will definitely cause downtime for the application during the update. Usually only used in special cases.

Rollback: If the update fails or you want to roll back to a previous version, Deployment provides a rollback mechanism to easily do this.

Create Deployment using YAML:

Here is an example of a YAML file defining a Deployment:

apiVersion: apps/v1 kind: Deployment metadata: name: my-app-deployment spec: replicas: 3 # Muốn có 3 bản sao (Pods) chạy selector: matchLabels: app: my-app # Selector này sẽ chọn các Pods có label 'app: my-app' strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 0 template: # Định nghĩa template cho các Pods mà Deployment sẽ tạo (thông qua ReplicaSet) metadata: labels: app: my-app version: v1 spec: containers: - name: my-app-container image: my-app:1.0 ports: - containerPort: 8080

Compared to ReplicaSet, Deployment has an additional spec.strategy section to define the update strategy. The spec.template section is still the same, defining the Pods that will be created. Deployment will automatically create and manage ReplicaSet based on this configuration.

Use kubectl to manage Deployments:

After saving the above file as my-app-deployment.yaml:

• Create Deployment:

  kubectl apply -f my-app-deployment.yaml

• View information about Deployments:

  kubectl get deployments

  You will see the Deployment my-app-deployment and its status (READY, UP-TO-DATE, AVAILABLE).

• View details about a Deployment:

  kubectl describe deployment my-app-deployment

• View rollout status (update):

  kubectl rollout status deployment/my-app-deployment

• View the Deployment rollout history:

  kubectl rollout history deployment/my-app-deployment

• Update the app version (change image): You can edit the my-app-deployment.yaml file and change spec.template.spec.containers[0].image to the new version (e.g. my-app:1.1) and then run:

  kubectl apply -f my-app-deployment.yaml

  Kubernetes will perform a rolling update to replace old Pods with new Pods. Monitor the process with kubectl rollout status.

• Rollback to previous version:

  kubectl rollout undo deployment/my-app-deployment

  You can also rollback to a specific revision by specifying --to-revision=<revision-number> (taken from kubectl rollout history).

Practice:

1. Create a Deployment: Use the my-app-deployment.yaml file above to create the Deployment.
2. Scale the number of replicas: Change the spec.replicas in the YAML file to 5 and run kubectl apply -f my-app-deployment.yaml. Observe the number of Pods increase using kubectl get pods.
3. Perform a rolling update: Change the image in the YAML file (for example, from my-app:1.0 to my-app:1.1) and run kubectl apply -f my-app-deployment.yaml. Monitor the update process with kubectl rollout status. Observe how old Pods are gradually replaced by new Pods.
4. Check history: Run kubectl rollout history deployment/my-app-deployment to see the history of changes to the Deployment.
5. Perform a rollback: If you want to go back to the previous version, run kubectl rollout undo deployment/my-app-deployment. Observe the rollback process using kubectl rollout status.

Conclude:

Deployments and ReplicaSets are powerful tools that help you reliably manage stateless applications on Kubernetes. ReplicaSets ensure that there are always enough Pods running, while Deployments provide declarative management, non-disruptive updates, and easy rollbacks. Understanding and mastering this “power duo” is an important step towards building scalable, self-healing applications on Kubernetes. In future posts, we will explore how Kubernetes manages stateful applications and how to provide network access to your applications via Services.