In a production environment, the ability to update applications without interrupting service is critical. Kubernetes achieves this through the Deployment object, which acts as a high-level manager for Replica Sets and Pods. This article provides a detailed technical explanation of how Kubernetes handles application updates, the strategies it employs to maintain availability, and the mechanisms used to recover from failed deployments.

Understanding the Deployment Architecture

To understand rollouts, one must first understand the relationship between three components: the Deployment, the Replica Set, and the Pod.

• Deployment: The top-level object where you define the “desired state” (e.g., “I want 6 replicas of Nginx version 1.12”).
• Replica Set: A middle-layer controller. Its sole purpose is to ensure that the exact number of pods specified in the Deployment are running at all times.
• Pod: The smallest deployable unit containing the actual application container.

When you create a Deployment, it automatically creates a Replica Set, which in turn creates the Pods. This hierarchy is the foundation of Kubernetes’ versioning system.

Rollouts and Versioning

A rollout is the process of updating a Deployment to a new state or deploying a new version of an application. Every time a Deployment is created or updated, Kubernetes triggers a new rollout and assigns it a revision number.

Replica Sets and Revisions

To manage updates, Kubernetes uses Replica Sets. A Replica Set is a controller that ensures a specific number of identical Pods are running at any given time.

• Kubernetes uses Replica Sets to manage Pods. Each revision of a Deployment is linked to a specific Replica Set.

  • Revision 1: Created during the initial deployment.

  • Revision 2, 3, etc.: Created whenever the Deployment configuration (e.g., image version, labels, or replica count) is modified.

• Tracking: Each new rollout creates a new revision. This versioning allows administrators to track changes and revert to previous states if the new version is unstable.

Monitoring Rollouts

Administrators can monitor the progress and history of these updates using specific commands:

• Status: kubectl rollout status [deployment-name] shows whether a rollout is currently in progress or has completed.
• History: kubectl rollout history [deployment-name] lists the previous revisions of the deployment.

Deployment Strategies

Kubernetes offers two primary methods for replacing old application versions with new ones.

1. Recreate Strategy

In a Recreate strategy, Kubernetes terminates all existing Pods of the old version before creating any Pods of the new version.

• Process: All 5 replicas (for example) are destroyed $\rightarrow$ All 5 new replicas are created.
• Downside: This causes application downtime. There is a gap between the time the old version is deleted and the new version becomes ready.

2. Rolling Update Strategy (Default)

The Rolling Update strategy replaces Pods incrementally to ensure zero downtime.

• Process: Kubernetes scales up the new Replica Set and scales down the old Replica Set simultaneously, one Pod at a time.
• Upside: The application remains accessible to users throughout the entire upgrade process.

Performing Updates

Updates can be triggered by changing the deployment definition (e.g., changing the Docker image, labels, or the number of replicas). We can edit the deployment directly by using kubectl edit deployment deployment_name cinnabd or edit the yaml file and rerun the deployment by kubectl apply command.

Method A: Declarative Update (kubectl apply)

The preferred method is modifying the deployment configuration file (YAML) and running: kubectl apply -f [filename] This maintains synchronization between the configuration file and the live cluster state.

Method B: Imperative Update (kubectl set image)

The image can be updated directly via the command line: kubectl set image [resource type] [deployment-name] [container-name]=[new-image]

Ex: kubectl set image deployment frontend mywebapp=nginx:v2

Here

• deployment is the resource name. It can be like deployment, pod, statefulset etc..

• frontend is the name of the deployment.

• mywebapp is the name of the container

• nginx:v2 is the new image name.

Warning: This creates a discrepancy between the live cluster state and the local configuration file. If the configuration file is applied later, it may revert the change made by the set image command.

Error Handling and Proactive Safeguards

Kubernetes includes built-in protections to prevent total service failure during a faulty update.

The “ImagePullBackOff” Scenario

If an update is triggered with a non-existent or incorrect image version, the following occurs:

1. Partial Rollout: Kubernetes begins replacing old Pods with new ones.
2. Failure Detection: When the new Pods fail to start (status: ImagePullBackOff), Kubernetes detects the failure.
3. Proactive Stop: To prevent a total outage, Kubernetes stops terminating the remaining old, working Pods.
4. State Imbalance: You will see a discrepancy in kubectl get deployment where the “current” number of Pods may exceed the “desired” number because the old version is preserved while the new version fails to deploy.

The Rollback Mechanism

If a new version contains bugs or crashes, Kubernetes allows for a rollback, which reverts the deployment to a previous stable revision.

How Rollback Works

By executing kubectl rollout undo [deployment-name], Kubernetes reverses the rollout process:

1. The Pods in the new (faulty) Replica Set are destroyed.
2. The Pods in the previous (stable) Replica Set are scaled back up.

This restores the application to its prior functioning state rapidly.

Summary of Commands