Deployments

Rollout Strategies: Rolling Update vs. Blue-Green

Rolling Update

Kubernetes' default strategy for Deployments. It replaces old Pods with new ones incrementally, ensuring zero downtime and minimal disruption. You can control the update behavior using maxUnavailable and maxSurge:

Example:

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

• maxUnavailable: Maximum number of Pods that can be unavailable during the update.
• maxSurge: Maximum number of additional Pods that can be created during the update.

To monitor a rollout:

kubectl rollout status deployment/nginx-deployment

Blue-Green Deployment

A strategy where two identical environments (blue and green) are maintained. Traffic is switched from the old (blue) to the new (green) version after validation. This requires: - A load balancer or ingress controller to route traffic. - Separate Deployments and Services for each environment.

Example Setup:

1. Blue Environment (Initial Version):

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-blue
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-blue
     template:
       metadata:
         labels:
           app: nginx-blue
       spec:
         containers:
         - name: nginx
           image: nginx:1.21
           ports:
           - containerPort: 80
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx-blue
   spec:
     selector:
       app: nginx-blue
     ports:
     - protocol: TCP
       port: 80
       targetPort: 80
   

2. Green Environment (New Version):

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-green
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: nginx-green
     template:
       metadata:
         labels:
           app: nginx-green
       spec:
         containers:
         - name: nginx
           image: nginx:1.22
           ports:
           - containerPort: 80
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx-green
   spec:
     selector:
       app: nginx-green
     ports:
     - protocol: TCP
       port: 80
       targetPort: 80
   

3. Traffic Routing (Ingress Example):

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: nginx-ingress
     annotations:
       nginx.ingress.kubernetes.io/canary: "true"
       nginx.ingress.kubernetes.io/canary-weight: "50"
   spec:
     rules:
     - http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: nginx-blue
               port:
                 number: 80
   

Workflow: 1. Deploy the green environment using kubectl apply -f green-deployment.yaml. 2. Validate the new version in the green environment. 3. Update the ingress controller to route traffic to the green environment (e.g., adjust canary weight or switch backend service). 4. Decommission the blue environment after confirming stability.

---

Rollback and Rollout Management

If an update fails, you can roll back to a previous revision using kubectl rollout undo:

kubectl rollout undo deployment/nginx-deployment

To revert to a specific revision:

kubectl rollout undo deployment/nginx-deployment --to-revision=4

Check the rollout history:

kubectl rollout history deployment/nginx-deployment

Canary Deployments are another strategy, where traffic is gradually shifted to a new version. This is often implemented using tools like Istio or Kubernetes' built-in canary features.