7: Kubernetes Deployment Strategies and Rollouts: A Comprehensive Guide with Examples

When working with Kubernetes, managing application updates and deployments is crucial for ensuring stability and availability. Kubernetes provides several deployment strategies to suit different use cases, environments, and requirements. This blog will cover these strategies in detail, including examples, commands, and common troubleshooting steps.

---

Deployment Strategies in Kubernetes

Kubernetes offers multiple deployment strategies to manage application updates. Each has unique advantages and trade-offs:

1. Recreate Strategy

• Concept: The existing application pods (e.g., version 1) are terminated before starting the new application pods (e.g., version 2).

• Usage: Best suited for development environments where downtime is acceptable.

• Trade-offs: Causes downtime since the old version stops before the new version starts.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: Recreate
  template:
    spec:
      containers:
        - name: app-container
          image: my-app:v2

This approach leads to downtime while switching versions.

---

2. Rolling Update (Ramped Deployment)

• Concept: Gradually replaces old pods with new pods while maintaining service availability.

• Usage: The default strategy in Kubernetes, suitable for production environments.

• Trade-offs: Avoids downtime but might cause version conflicts during the transition phase.

• Command:

    kubectl apply -f deployment.yaml
  

Example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
        - name: app-container
          image: my-app:v2

• Details:

  • maxUnavailable: The number of pods that can be unavailable during the update.

  • maxSurge: The number of additional pods created during the update.

---

3. Blue/Green Deployment

• Concept: Maintains two environments, "blue" (current version) and "green" (new version). Once the new version is verified, traffic is switched to it.

• Usage: Ideal for scenarios needing rapid rollback.

• Trade-offs: Requires double compute resources, increasing costs.

Example:

# Update service to point to the green deployment
kubectl set selector service/my-app version=green

Details:

• The current version (blue) continues to serve traffic.

• The new version (green) is deployed alongside, and labels are used to switch traffic.

---

4. Canary Deployment

• Concept: Deploys the new version to a subset of users for testing, gradually increasing traffic.

• Usage: Effective for feature validation or incremental testing.

• Trade-offs: Requires traffic management tools (e.g., HAProxy, Istio, or Linkerd).

Example Using Service Mesh:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app.example.com
  http:
    - route:
        - destination:
            host: my-app
            subset: v1
          weight: 90
        - destination:
            host: my-app
            subset: v2
          weight: 10

---

5. A/B Testing

• Concept: Similar to canary, but users are split into groups based on specific characteristics (e.g., location, device type) for feature testing.

• Usage: Useful for testing user experiences or feedback.

• Example:

  • Use tools like NGINX ingress or Istio to route traffic conditionally.

Example:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app-ab
spec:
  hosts:
    - my-app.example.com
  http:
    - match:
        - headers:
            user-group:
              exact: test-group
      route:
        - destination:
            host: my-app
            subset: v2
    - route:
        - destination:
            host: my-app
            subset: v1

---

Managing Deployment Rollouts in Kubernetes

Checking Rollout History

Kubernetes maintains a history of deployments. You can view the rollout history and annotate changes for better tracking.

Common Commands:

• View history:

    kubectl rollout history deployment/my-app
  

• Add change-cause annotation:

    kubectl annotate deployment.apps my-app kubernetes.io/change-cause="Updated to v2"
  

• Record changes automatically:

    kubectl apply -f deployment.yaml --record=true
  

Rollbacks

Rollback to a previous version if needed:

• Rollback to the last version:

    kubectl rollout undo deployment/my-app
  

• Rollback to a specific revision:

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

Setting Revision History Limit

To avoid managing excessive replicasets:

• Add the revisionHistoryLimit field in your deployment:

    spec:
      revisionHistoryLimit: 5
  

---

Key Insights and Best Practices

1. Imperative vs. Declarative Updates:
   Use declarative YAML configurations over imperative commands for better traceability.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deploy
  annotations:
    kubernetes.io/change-cause: "version 1"
spec:
  replicas: 10
  selector:
     matchLabels:
        app: hello-world
  minReadySeconds: 10
  strategy:
     type: RollingUpdate
     rollingUpdate:
        maxUnavailable: 1
        maxSurge: 1
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-pod
        image: lovelearnlinux/webserver:v1
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 100m
            memory: 128Mi
          requests:
            cpu: 50m
            memory: 100Mi

  annotations:
    kubernetes.io/change-cause: "version 1"

1. ReplicaSet Metadata:
   In rolling updates, while pods are deleted, the old replicaset's metadata persists unless manually cleaned.

2. Zero Downtime Deployment:
   To achieve true ZDD, combine rolling updates with health checks and liveness probes.

---