Deployment rollout strategies in AKS (Azure Kubernetes Service)

A rollout is how Kubernetes updates your application (container image, config, etc.) in a Deployment without downtime. It replaces old pods with new ones gradually, based on the strategy you define.

Rolling out a new application version in AKS (Azure Kubernetes Service) must be done carefully in production to minimize downtime, avoid errors, and ensure user trust.

Default Rollout Strategy in AKS:

RollingUpdate (default)

This means:

• Kubernetes gradually replaces old pods with new ones.
• It ensures some pods are always available (high availability).
• Great for zero-downtime deployments.

🔧 Key Strategy Config in YAML:

yamlCopyEditstrategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

Key	Meaning
maxUnavailable	Max number of pods that can be unavailable during the update
maxSurge	Extra pods to launch during update for faster rollout

🔄 Other Strategy: Recreate

yamlCopyEditstrategy:
  type: Recreate

• All old pods are killed first, then new ones are created.
• Used when old and new pods cannot run together (e.g., DB schema migration).
• ⚠️ Causes downtime — not ideal for most production apps.

🧪 Rollout Commands (CLI):

📌 1. Trigger a rollout

Update something (like image):

kubectl set image deployment/my-app my-app=myimage:v2

Or apply a new YAML file:

kubectl apply -f deployment.yaml

---

📌 2. Check rollout status

kubectl rollout status deployment/my-app

Shows progress and confirms when update is complete.

---

📌 3. Roll back to previous version

kubectl rollout undo deployment/my-app

Rolls back to the previous stable version.

To see history:

kubectl rollout history deployment/my-app

📌 4. Pause & resume rollout (for staged production updates)

kubectl rollout pause deployment/my-app
# make changes, e.g., change image
kubectl set image deployment/my-app my-app=myimage:v3
kubectl rollout resume deployment/my-app

🏭 How to Do It in Production

Step-by-Step Plan:

1. Pause deployment (optional):
   • Useful if you want to control when rollout starts.
2. Push updated Docker image to ACR (Azure Container Registry) or any other registry.
3. Update Deployment with new image version: bashCopyEditkubectl set image deployment/my-app my-app=youracr.azurecr.io/my-app:v2
4. Monitor rollout: bashCopyEditkubectl rollout status deployment/my-app
5. Validate health:
   • Use kubectl get pods, kubectl logs, and/or health endpoints.
   • Consider using readiness probes to ensure pods are ready before traffic is sent.
6. If any issue → rollback immediately: bashCopyEditkubectl rollout undo deployment/my-app

Best Practices in Production

Practice	Why
Readiness & liveness probes	Prevent traffic to unstable pods
Set maxUnavailable=0	For full zero-downtime (if infra allows)
Pause/resume manually	Great for staged rollouts
Use canary or blue-green	For large-scale production (with Istio/Ingress)
Monitor with Prometheus/Grafana	Alert on failure or bad rollout

1. Recreate Strategy (Default Kubernetes Replace)

• What it does: Deletes old pods before new pods are created.
• How: Not explicitly used unless forced by setting maxSurge: 0, maxUnavailable: 100%.

✅ Pros:

• Simple and fast

❌ Cons:

• Downtime occurs
• Not suitable for production environments

🔧 Use case:

• Non-production environments
• When downtime is acceptable

---

2. Rolling Update (Default in Kubernetes)

• What it does: Gradually replaces old pods with new ones using maxSurge and maxUnavailable parameters.

🔧 Sample YAML:

yamlCopyEditstrategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%

✅ Pros:

• Zero-downtime deployment
• Safe and predictable

❌ Cons:

• Hard to roll back instantly
• Issues go unnoticed if not properly monitored

🔧 Use case:

• ✅ Recommended for stable production environments
• Works well for stateless microservices

3. Blue-Green Deployment

• What it does: Deploys new version (green) alongside old version (blue). Switch traffic to green after testing.

🔧 Requires:

• Traffic switching mechanism (e.g., Istio, Ingress Controller, Azure Front Door, App Gateway)
• Two deployments or environments

✅ Pros:

• Instant switch & rollback
• Easy testing on live environment before switching

❌ Cons:

• Doubles resource usage temporarily
• Complex traffic management setup

🔧 Use case:

• High-availability production systems
• Apps requiring real user testing before cutover

4. Canary Deployment

• What it does: Gradually shifts traffic from old to new version (e.g., 10% → 25% → 50% → 100%) while monitoring.

🔧 Tools to support:

• Service mesh (Istio, Linkerd)
• Ingress controllers (NGINX + annotations)
• GitOps tools (Argo Rollouts, Flagger with FluxCD)

✅ Pros:

• Early issue detection with minimal impact
• Fine-grained control over rollout

❌ Cons:

• Requires observability (prometheus, alerts)
• Slightly more complex setup

🔧 Use case:

• Production environments with active monitoring
• Apps with gradual confidence building needs

5. Shadow Deployment

• What it does: Deploys new version alongside, mirrors real traffic without serving it to users.

✅ Pros:

• Safe testing with production traffic
• No user impact

❌ Cons:

• Needs extra tooling
• No automatic validation of output

🔧 Use case:

• Testing AI/ML models
• Performance evaluation before go-live

🔚 Final Recommendation

For most companies with critical production environments:
✅ Use Rolling Update + Canary Rollout via Flagger or Argo Rollouts, integrated with monitoring (Prometheus/Grafana) and automated rollback on failure.