Managing Rolling Updates and Rollbacks in Kubernetes Deployments

Introduction

Kubernetes has become the de facto standard for managing containerized applications. With its powerful construct for deployments, you can control how updates to your application are rolled out as well as how to roll those changes back if things don’t go as planned. This tutorial will walk you through the process of managing rolling updates and rollbacks in Kubernetes.

Prerequisites

• A Kubernetes cluster
• kubectl command-line tool installed and configured to connect to your cluster
• A basic understanding of Kubernetes concepts (pods, deployments)
• A Docker image you wish to deploy

Rolling Updates

Rolling updates are the default strategy to update the running version of your application in Kubernetes with zero downtime. A rolling update slowly replaces previous pod instances with new ones with the new version.

Performing a Rolling Update

To perform a rolling update, you can either update an existing deployment’s Docker image or change its configuration.

kubectl set image deployment/myapp-deployment myapp=nginx:1.16.1 --record

This command updates the ‘myapp-deployment’ to use the ‘nginx:1.16.1’ image and records the change in the rollout history. To see the status of the rollout, use the following command:

kubectl rollout status deployment/myapp-deployment

Updating a Deployment Configuration

Another way to trigger a rolling update is by applying changes to the deployment’s YAML configuration file.

kubectl apply -f deployment.yaml

For this command to work, the ‘deployment.yaml’ must have a change, such as a new image or configuration setting.

Rollbacks

Sometimes, an update doesn’t work out, and it’s necessary to roll back to a previous stable version. Kubernetes provides a simple way to achieve this.

Checking Rollout History

First, it’s important to check the history of deployments:

kubectl rollout history deployment/myapp-deployment

This command lists the history of updates that have been done on the ‘myapp-deployment’.

Rolling Back to a Previous Revision

To roll back to a previous revision of your deployment, use the following command:

kubectl rollout undo deployment/myapp-deployment

This will roll back your deployment to the previous version. If you need to go back to a specific revision, use the ‘–to-revision’ flag like this:

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

Avoiding Disruptive Updates

It’s important to ensure that your updates don’t kill all your Pods at once. Kubernetes handles this through the ‘maxUnavailable’ and ‘maxSurge’ parameters. ‘maxUnavailable’ defines the maximum number of Pods that can be unavailable during the update process, and ‘maxSurge’ defines the maximum number of Pods that can be created over the desired number of Pods.

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

In the above example, only 1 Pod at a time will be taken down, and only 1 new Pod will be added over the desired amount at a time during the update process.

Best Practices

• Always use the ‘–record’ flag when performing rolling updates so that you can review the changes made in the deployment history.
• Monitor your application’s performance and state after a deployment. Tools like metrics-server, Grafana, and Prometheus can be indispensable in detecting and diagnosing issues.
• Consider using readiness probes and liveness probes to ensure that your service remains stable during the update.

Conclusion

Understanding rolling updates and rollbacks in Kubernetes is fundamental to managing a robust deployment system. This ability means you can continuously deliver new features and improvements with minimal downtime. Always remember to test changes and monitor deployments to prevent disruptiveness to your service.