Zero-Downtime Deploy & Rollback

🔥 Vibe Prompt

"Design a K8s zero-downtime deployment strategy with RollingUpdate, Readiness Probe, and rollback."

apiVersion: apps/v1
kind: Deployment
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0  # Keep all pods running during update
  template:
    spec:
      containers:
      - name: app
        readinessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 20

Rollback Commands

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

🔥 Vibe Prompt

"Create a GitHub Actions workflow that auto-rollbacks on deployment failure and sends a Slack notification."

Chapter Summary

• Understand core concepts and principles
• Master implementation methods and techniques
• Familiar with common issues and solutions
• Able to apply in real projects

Further Reading

• Official documentation and API references
• Open source examples on GitHub
• Technical books and online courses
• Community discussions and tech blogs

Implementation Example

Basic Example

# This section provides a complete implementation example

Steps

1. Setup: Configure development environment
2. Data: Prepare required data
3. Implementation: Build core functionality
4. Testing: Verify correctness
5. Optimization: Improve performance

Common Errors

| Error Type | Cause | Solution | |------------|-------|----------| | Compilation | Syntax | Check code syntax | | Runtime | Environment | Verify dependencies installed | | Logic | Algorithm | Step-by-step debugging | | Performance | Efficiency | Use profilers |

Code Example

import sys

def main():
    print("Hello, World!")

if __name__ == "__main__":
    main()

References

• Official documentation
• API reference
• Open source examples
• Community discussions

Deployment Strategies

| Strategy | Description | Zero Downtime | Rollback | Complexity | |----------|-------------|--------------|----------|------------| | Rolling Update | Replace instances gradually | ✅ Yes | ✅ Yes | Low | | Blue/Green | Two identical environments, switch traffic | ✅ Yes | ✅ Instant | Medium | | Canary | Gradual traffic shift to new version | ✅ Yes | ✅ Fast | High | | Recreate | Kill all, then start new | ❌ No | ⚠️ Manual | Low | | Shadow | Mirror traffic to new version without serving | ✅ Yes | ✅ No impact | Very High |

Blue/Green Deployment

# Simplified blue/green deploy script
BLUE_URL="https://blue.myapp.com"
GREEN_URL="https://green.myapp.com"
ACTIVE=$(cat /deploy/active.txt)  # "blue" or "green"

if [ "$ACTIVE" = "blue" ]; then
  # Deploy to green
  docker compose -f docker-compose.green.yml up -d
  # Wait for health check
  curl --retry 10 --retry-delay 5 $GREEN_URL/health
  # Switch traffic
  ln -sf /etc/nginx/sites/green.conf /etc/nginx/sites-enabled/myapp.conf
  nginx -s reload
  # Stop blue
  docker compose -f docker-compose.blue.yml down
  echo "green" > /deploy/active.txt
else
  # Deploy to blue
  docker compose -f docker-compose.blue.yml up -d
  curl --retry 10 --retry-delay 5 $BLUE_URL/health
  ln -sf /etc/nginx/sites/blue.conf /etc/nginx/sites-enabled/myapp.conf
  nginx -s reload
  docker compose -f docker-compose.green.yml down
  echo "blue" > /deploy/active.txt
fi

Health Check Verification

      - name: Verify deployment
        run: |
          # Wait for the new version to be healthy
          for i in $(seq 1 30); do
            STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://myapp.com/health)
            if [ "$STATUS" = "200" ]; then
              echo "Deployment verified successfully"
              exit 0
            fi
            echo "Attempt $i: Health check returned $STATUS, waiting..."
            sleep 10
          done
          echo "Deployment verification failed after 30 attempts"
          exit 1

Automated Rollback

      - name: Deploy
        id: deploy
        run: |
          ./deploy.sh
      
      - name: Verify deployment
        run: |
          ./verify-health.sh
      
      - name: Rollback on failure
        if: failure()
        run: |
          echo "Deployment failed! Rolling back..."
          ./rollback.sh

Rollback Script

#!/bin/bash
# rollback.sh

PREVIOUS_VERSION=$(cat /deploy/previous-version.txt)

echo "Rolling back to version $PREVIOUS_VERSION..."

# Revert Docker image tag
sed -i "s|image: myapp:.*|image: myapp:$PREVIOUS_VERSION|" docker-compose.yml

# Redeploy
docker compose up -d

# Verify
curl --retry 10 --retry-delay 5 https://myapp.com/health

echo "Rollback to $PREVIOUS_VERSION completed"

Summary

Choose the deployment strategy based on your risk tolerance and complexity budget. Blue/Green gives instant rollback. Rolling update is simplest. Always verify with health checks and automate rollback on failure.

Key takeaways:

• Blue/Green: two environments, instant switch, instant rollback
• Rolling update: gradual replacement, simple, built into K8s
• Canary: gradual traffic shift, safe for high-traffic apps
• Health checks verify deployment succeeded
• Automated rollback on failed verification
• Always keep the previous version ready for rollback
• Test rollback procedure regularly

What's Next: Full Pipeline

The next chapter builds a complete CI/CD pipeline combining everything.