Update and Rollback Deployment in Kubernetes

When you create a deployment it triggers a rollout a new rollout creates a new deployment revision. In the future, when the application is upgraded meaning when the container version is updated to a new one a new rollout is triggered and a new deployment. This helps us keep track of the changes made to our deployment and enables us to roll back to a previous version of deployment if necessary

Rollout command

$ kubectl rollout status deployment nginx-deployment
deployment "nginx-deployment" successfully rolled out

By default ‘rollout status’ will watch the status of the latest rollout until it’s done.

$ kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>

Deployment Strategy

There are two types of deployment strategies.

1. recreate strategy: Imagine, you have three replicas of the application instance deployed. One way to upgrade these to a newer version is to destroy all of these and then create a newer version of application instances. First, destroy the three running instances and then deploy three new instances of the new application version. The problem with this that during the period after the older version is down and before a newer version is up the application is down and inaccessible to users. This strategy is known as the recreate strategy and this is not the default deployment strategy.

2. rolling update strategy: we do not destroy all of the running applications at once. Instead, we take down the older version and bring up a newer version one by one This way the application never goes down and the upgrade is seamless. If you do not specify a strategy while creating the deployment it will assume it to be a rolling update.

How exactly do you update the deployment.

When I say update it could be different things such as updating the application version by updating the version of docker containers used updating their labels or updating the number of replicas etc. Since we already have a deployment definition file it is easy for us to modify these files. Once we make the necessary changes we run the kubectl apply command to apply the changes. A new rollout is triggered and a new revision of the deployment is created.

Update

Edited image version

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      name: nginx-pod
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx-container
          image: nginx:1.7.1
          ports:
            - containerPort: 80
              protocol: TCP

$ kubectl apply -f nginx-deployment.yaml --record
deployment.apps/nginx-deployment configured

$ kubectl rollout history deployment nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
2         <none>
3         kubectl apply --filename=nginx-deployment.yaml --record=true

$ kubectl rollout status deployment apple-deployment
deployment "apple-deployment" successfully rolled out

The old replicaSets are down and the new replicaSets are running

$ kubectl get replicaset
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-5b4596cf84   3         3         3       74m
nginx-deployment-747d496675   0         0         0       10m

Rollback

$ kubectl rollout undo deployment nginx-deployment --to-revision=2
deployment.apps/nginx-deployment rolled back
$ kubectl rollout history deployment  nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
3         kubectl apply --filename=nginx-deployment.yaml --record=true
4         <none>
$ kubectl get replicaset
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-5b4596cf84   0         0         0       80m
nginx-deployment-747d496675   3         3         3       16m

The older replicaSets are running.