A Beginner's Guide to Kubernetes Deployments: How They Work and How to Roll Out Application Updates

Deployments in Kubernetes provide automated, reliable, and scalable processes for deploying, updating, and maintaining your applications, allowing you to focus on developing features and improving user experiences without worrying about the complexity of the underlying infrastructure.

In Kubernetes, deployments are essential configurations that define how applications should be deployed and managed. They ensure that a specified number of instances of an application, known as pods, are running and healthy at all times, automatically replacing any failed instances.

In this deeper look at Deployments, we'll cover:

• How Deployments work
• Semi-walkthrough of deploying a sample app
• Monitoring rollout status
• Rolling out updates
• Revisions and rollout history
• Debugging and troubleshooting deployments

Understanding Deployments

In simple terms, when you create a deployment, that's you telling Kubernetes exactly how you want it to roll out your application. It takes your instruction and runs with it.

In slightly more technical terms - When you create a Deployment, you declare the desired state including details like the container images, number of replicas, resource limits, etc. The Kubernetes Deployment controller then makes the current state match your desired state.

Here's what actually happens under the hood:

• The Deployment creates a ReplicaSet to spin up the requested Pods.
• Each ReplicaSet gets a unique identifier.
• The Deployment manages the ReplicaSets to ensure the right number of Pods.

So while you update the Deployment, Kubernetes handles creating, scaling and deleting ReplicaSets appropriately.

Deploying a sample app

Let's walk through deploying a simple nginx app using a Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata: # Contains metadata about the Deployment. eg Name
  name: nginx
spec: # Specifies the desired state for the Deployment
  replicas: 3 # Number of replica Pods
  selector: # Defines how the Deployment identifies which Pods it manages
    matchLabels: # Specifies the labels that the Deployment uses to select the Pods it manages
      app: nginx
  template: # Describes the Pods that will be created by this Deployment.
    metadata: # Contains labels that will be applied to the Pods 
      labels:
        app: nginx
    spec: # Specifies the container(s) that will run in the Pods created
      containers:
      - name: nginx
        image: nginx:1.14 # Specifies the Docker image to use for the container        

We can deploy this in our Kubernetes cluster using:

kubectl apply -f nginx.yaml        

This will create the Deployment along with associated ReplicaSets and Pods. We can now observe the rollout, update the Deployment, and debug issues leveraging revisions and other techniques we will discuss.

Monitoring Rollout Status

During updates, you can check the rollout status to see progress:

kubectl rollout status deployment nginx        

This will track things like:

• Old replicas terminated
• New replicas created
• Overall progress

If a rollout fails, the Deployment will show a non zero error code.

(You can press control + C on your keyboard to exit and continue this)

To validate if a deployment was successful, you can run the command below to list all deployments

kubectl get deployments        

If the Deployment is still being created, we should get an output similar to the following:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   0/3     0            0           1s        

To see the ReplicaSet created by the Deployment, run?"kubectl get rs". The output is similar to this:

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-75675f5897   3         3         3       18s        

Rolling out updates

Let's update the nginx Pods to use the?nginx:1.16.1?image instead of the?nginx:1.14.2?image.

We can do this either by editing the entire deployment using the command

kubectl edit deployment/nginx-deployment        

This opens up a text editor where you can navigate to the image section and modify.

But we are doing things the DevOps way, we want to do things in ways that can be automated and repeatable without intervention. So we use the command below instead.

kubectl set image deployment nginx-deployment nginx=nginx:1.16.1        

Revisions and rollout history

Every time the Pod template changes, Kubernetes treats it as a new revision of the deployment. Every revision creates a ReplicaSet to roll out the changes.

To put this into context, updating the container image used in the deployment or modifying the command will trigger a new revision. But scaling the Deployment does not create a revision.

Kubernetes stores the revision history of a Deployment for rollback purposes. Rollout history can be viewed with the command:

kubectl rollout history deployment nginx        

The result should look like this:

REVISION  CHANGE-CAUSE
1         kubectl apply --filename=nginx.yaml
2         kubectl set image deployment/nginx nginx=nginx:1.16        

By default, the maximum number of revision listed is 10. However this is configurable.

The number of revisions can be modified by setting the .spec.revisionHistoryLimit field in the Deployment manifest. For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  revisionHistoryLimit: 5 # retain 5 revisions
  replicas: 3
  template:
    ...        

Also, it's possible to view or revert to a previous revision of a deployment.

We can view the content of a specific revision by running the below. This will give us the complete template and other details for the revision.

kubectl rollout history deployment nginx --revision=2        

Like most application specific Kubernetes objects, revisions can also be tagged to make them mode descriptive. This is especially helpful in finding out why a particular change was made.

Revisions can be tagged with the command "kubectl annotate".

kubectl annotate deployment nginx kubernetes.io/change-cause="Upgrade to latest nginx"        

We can also rollback to a specific revision. We specify the exact revision to rollback to.

kubectl rollout undo deployment/nginx --to-revision=2        

That's all, for now.

I hope you found this insightful. To get more useful content like this, follow me?here?on Medium and connect with me on?Linkedin. Also, reshare so others can find this article. And please, drop any questions or comments in the comment section, and let's continue the conversation.