Kubernetes Rolling Updates – Verification Tutorial

This tutorial focuses on verifying successful rolling updates in Kubernetes using rollout history, status checks, and standard kubectl commands. We’ll build three examples progressively demonstrating different aspects of this process.

Example 1: Simple Rolling Update – Initial Setup and Verification

This example sets up a basic deployment, performs a rolling update, and verifies the update’s success using rollout history.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "100m"
            memory: "128Mi"
      status: {}

Steps:

1. Create the deployment manifest (`my-app-deployment.yaml`).
2. Apply the manifest: `kubectl apply -f my-app-deployment.yaml`
3. Verify the deployment: `kubectl get deployments my-app-deployment`
4. Check rollout history: `kubectl rollout history deployment my-app-deployment`
5. Observe the rolling update in progress: `kubectl rollout status deployment my-app-deployment`

You should see the replicas transitioning from 3 to 3 as the update progresses. The rollout history will show the update events.

Example 2: Introducing a Configuration Change – Rolling Update with Image Update

Now, we’ll change the application image during the rolling update and verify the update’s success with status checks.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:latest  # Initial image
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "100m"
            memory: "128Mi"
      status: {}

Steps:

1. Modify the `my-app-deployment.yaml` file to change the image to `nginx:1.25` (or another version).
2. Apply the updated manifest: `kubectl apply -f my-app-deployment.yaml`
3. Check the deployment status: `kubectl get deployments my-app-deployment -o wide`
4. Verify the rolling update: `kubectl rollout status deployment my-app-deployment`

Inspect the output of `kubectl get deployments` to confirm the image change. The `rollout status` command is key to observing the ongoing update’s status.

Example 3: Rolling Back – Handling an Incident & Verification

This example demonstrates a scenario where a problem occurs during the rolling update, and we need to rollback. It highlights the importance of monitoring rollout status.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: nginx:1.25 # Updated Image
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: "100m"
            memory: "128Mi"
      status: {}

Steps:

1. Apply the manifest: `kubectl apply -f my-app-deployment.yaml`
2. Observe the rolling update: `kubectl rollout status deployment my-app-deployment`
3. Simulate an issue (e.g., manually trigger an error in the container). This might involve a sleep command in a shell script executed inside the container or stopping the process.
4. Immediately rollback the deployment: `kubectl rollout undo deployment my-app-deployment`
5. Verify the rollback: `kubectl rollout history deployment my-app-deployment`
6. Monitor the deployment: `kubectl get deployments my-app-deployment -o wide` to confirm replicas are returning to the previous state.

The `kubectl rollout undo` command reverses the update. `rollout history` confirms the reversion. `kubectl get deployments` visually demonstrates the return to the prior version. This exemplifies a critical aspect of managing rolling updates: proactive monitoring and the ability to quickly revert to a stable state.