CKAD Ep 2: Deployments, Rollouts & Canary Releases

TL;DR (Quick Summary)

#

• Create Deployment: kubectl create deployment web-api --image=nginx:1.25 --replicas=3
• Update Image: kubectl set image deployment/web-api nginx=nginx:1.26-alpine --record
• Check Status: kubectl rollout status deployment/web-api
• Rollback: kubectl rollout undo deployment/web-api --to-revision=1
• Helm Release: helm upgrade --install web-app ./my-chart --set image.tag=v2.0

1. Rolling Update Workflow

#

graph TD
    subgraph DeploymentV1 ["1. Initial State (v1.0)"]
        RS1["ReplicaSet v1 (3 Pods)"]
    end

    subgraph RollingProgress ["2. Rolling Update in Progress"]
        RS1_A["ReplicaSet v1 (1 Pod)"]
        RS2_A["ReplicaSet v2 (2 Pods)"]
    end

    subgraph DeploymentV2 ["3. Final State (v2.0)"]
        RS2["ReplicaSet v2 (3 Pods)"]
    end

    DeploymentV1 --> RollingProgress --> DeploymentV2

2. CKAD Terminal Hands-on Scenarios

#

Scenario A: Create & Scale Deployment

#

Create a Deployment named frontend running image nginx:1.24 with 4 replicas in namespace production.

kubectl create namespace production
kubectl create deployment frontend --image=nginx:1.24 --replicas=4 -n production

Scenario B: Rolling Update with MaxSurge & MaxUnavailable

#

Modify the Deployment to set maxSurge: 25% and maxUnavailable: 0 (guaranteeing zero downtime during updates), then update image to nginx:1.25-alpine.

patch-strategy.yaml:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0

Apply patch and update image imperatively:

kubectl patch deployment frontend -n production --patch-file patch-strategy.yaml
kubectl set image deployment/frontend nginx=nginx:1.25-alpine -n production --record

Monitor rollout in real-time:

kubectl rollout status deployment/frontend -n production

Scenario C: Rollout History & Emergency Undo

#

Inspect deployment revision history and undo the last rollout to revert back to revision 1:

kubectl rollout history deployment/frontend -n production
kubectl rollout undo deployment/frontend -n production --to-revision=1

3. Canary Deployment Strategy (Traffic Splitting)

#

A Canary Deployment involves routing a small percentage of user traffic to a new version (v2) while keeping the stable version (v1) active.

graph TD
    Service["Service: app-service
(selector: app=my-app)"]
    Service -->|90% Traffic| PodV1["Deployment v1 Pods
(app=my-app, track=stable)"]
    Service -->|10% Traffic| PodV2["Deployment v2 Pods
(app=my-app, track=canary)"]

• Both Deployments share the common label app=my-app.
• The Service selector targets app=my-app.
• By running 9 replicas of v1 and 1 replica of v2, traffic is split 90/10 at Layer 4.

4. Helm Package Management for CKAD

#

Helm is the package manager for Kubernetes.

# Add repo & update
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Install/Upgrade release
helm upgrade --install my-release bitnami/nginx --set service.type=ClusterIP

# List releases & rollback
helm list
helm rollback my-release 1

Summary & Next Steps

#

In this episode, we covered:

• Imperative Deployment creation and scaling.
• Rolling updates, maxSurge/maxUnavailable parameters, and emergency rollbacks.
• Canary deployments via label selectors.
• Helm package installation and rollbacks.

In CKAD Episode 3: ConfigMaps, Secrets & Security Contexts, we will configure environment variables, secret mounts, and container security contexts!