How to patch kubernetes existing deployment? How to roll back?

Patching a Kubernetes deployment involves making updates or changes to an existing deployment. This can be useful for various reasons, such as fixing bugs, applying security updates, introducing new features, or making configuration changes. Kubernetes provides several mechanisms to patch deployments, and the choice depends on the nature of the changes you want to make.

Here are some common methods to patch a Kubernetes deployment:

1. kubectl Patch Command:

The kubectl patch command allows you to apply changes to a resource by specifying a patch file or providing the changes directly. For example:

# Update the image of a container in a deployment
$ kubectl patch deployment my-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-container","image":"new-image:tag"}]}}}}'

2. kubectl Edit Command:

The kubectl edit command opens the resource definition in the default editor, allowing you to make changes interactively. This method is suitable for small modifications:

$ kubectl edit deployment my-deployment

3. YAML Manifest Update:

Manually update the YAML manifest file of the deployment and then apply the changes using kubectl apply:

# Make changes to the YAML file
$ vi my-deployment.yaml

# Apply changes
$ kubectl apply -f my-deployment.yaml

4. Rolling Updates:

For changes that require updating multiple replicas gradually, use rolling updates. This involves updating the deployment with a new version, and Kubernetes will automatically roll out the changes while maintaining the desired number of replicas:

# Update the image in the deployment spec
$ kubectl set image deployment/my-deployment my-container=new-image:tag

Re-Deployment vs Patching:

Re-deployment is a time-consuming process and requires a considerable window to perform. On the other hand, patching is relatively quick and efficient.

1. Bug Fixes and Improvements:
   • Patching allows you to apply bug fixes or introduce improvements to your application without downtime.
2. Security Updates:
   • In the case of security vulnerabilities, patching is essential to apply fixes promptly and secure your applications.
3. Configuration Changes:
   • Update configuration settings, environment variables, or resource limits without redeploying the entire application.
4. Rolling Updates:
   • Use rolling updates to ensure continuous availability during deployment changes. Kubernetes will gradually update pods, minimizing disruption.
5. Feature Introductions:
   • Introduce new features or functionalities to your application by patching the deployment configuration.

In Kubernetes, the changes made to a resource by patching are typically persisted in the cluster and are not lost forever. Kubernetes maintains a record of changes to resources, and this historical information can be valuable for understanding the configuration history, auditing, and troubleshooting.

Best Practices:

1. Always Use Versioned Images:
   • Specify versioned images in your deployment to avoid unexpected updates. This ensures consistency and helps prevent unintentional changes.
2. Test Changes in Staging:
   • Before applying patches to a production environment, test them in a staging or development environment to identify potential issues.
3. Monitor and Rollback:
   • Monitor the deployment after patching to catch any issues early. Be prepared to roll back changes if needed.
4. Use Declarative Configuration:
   • Store your deployment configurations in declarative YAML files. This makes it easier to track changes, share configurations, and apply updates consistently.
5. Version Control:
   • Keep your deployment configurations in version control systems like Git to track changes over time.

By adopting these practices, you can maintain the stability, reliability, and security of your applications running in Kubernetes while efficiently managing updates and changes.

How to roll back?

Each resource in Kubernetes has a resource version associated with it. When a resource is modified or patched, the resource version is incremented. This versioning system allows Kubernetes to keep track of the history of changes.

1. Use kubectl Rollout History:

You can use the kubectl rollout history command to view the history of deployments and their revisions. This provides details about when a deployment was updated, the revision number, and any annotations associated with the update.

kubectl rollout history deployment/my-deployment

2. Then use – kubectl Rollback:

If there are issues with a recent update, you can use the kubectl rollout undo command to roll back to a previous revision. This command allows you to revert to a specific revision, and the previous state is restored.

$ kubectl rollout undo deployment/my-deployment --to-revision=2

A similar syntax works on openshift as well but you need to use the oc command instead of “kubectl”