In modern cloud-native applications, maintaining high availability during updates is crucial. Kubernetes provides a powerful mechanism called the rollout update strategy that allows you to update your application with minimal or zero downtime.

This article will explore how rollout strategies work, and how to manage them effectively in your Kubernetes deployments.

What is a Rollout Update Strategy?

The rollout update strategy (specifically the RollingUpdate strategy in Kubernetes) is a deployment approach that gradually replaces instances of your application with new ones.

Instead of stopping all pods simultaneously, Kubernetes:

1. 1. 1. Starts new pods with the updated configuration
      2. Waits for them to become healthy
      3. Then terminates the old pods
      4. Repeats this process until all pods are updated

This approach is the default strategy for Kubernetes Deployments and ensures your application remains available during the update process.

Why Use Rollout Update Strategies?

Rollout updates provide several key benefits:

• • • Minimal downtime: Your application remains available to users during updates
    • Reduced risk: If the new version fails, only a subset of pods is affected
    • Gradual rollout: You can monitor the new version’s performance before fully deploying it
    • Rollback capability: Easy to revert if something goes wrong

Configuring RollingUpdate Strategy in Deployment YAML

Here’s how to configure the rolling update strategy in a Deployment manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1      # Number of extra pods allowed during update
      maxUnavailable: 0  # Number of pods that can be unavailable during update
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.2.0
        ports:
        - containerPort: 8080

Performing a Rollout Update

1. Updating the Deployment (Triggering Rolling Update)

The most common way to perform a rollout update is by updating your deployment:

# Update the container image (will trigger rolling update)
kubectl set image deployment/my-app my-app=my-app:1.3.0

# Alternative: Edit the deployment directly
kubectl edit deployment my-app

2. Forcing a Rollout Restart Without Configuration Changes

Sometimes you need to restart pods (e.g., for configMap or secret updates) without changing the deployment spec:

# Method 1: Using kubectl rollout restart
kubectl rollout restart deployment/my-app

# Method 2: Adding an annotation (useful in CI/CD pipelines)
kubectl patch deployment my-app -p '{"spec":{"template":{"metadata":{"annotations":{"kubectl.kubernetes.io/restartedAt":"'"$(date +%Y-%m-%dT%H:%M:%S%z)"'"}}}}}'

Monitoring Rollout Status

To check the status of your rollout update:

# View rollout status
kubectl rollout status deployment/my-app

# View rollout history
kubectl rollout history deployment/my-app

# View details of a specific revision
kubectl rollout history deployment/my-app --revision=2

Handling Stuck Rollouts

Sometimes rollouts can get stuck due to various reasons (failed health checks, resource constraints, etc.). Here’s how to handle them :

1. Check Why It’s Stuck

# Describe the deployment to see events
kubectl describe deployment my-app

# Check pod status
kubectl get pods -l app=my-app

2. Cancel a Stuck Rollout

# Undo the rollout (rollback to previous version)
kubectl rollout undo deployment/my-app

# If you need to force the rollout to continue (careful with this)
kubectl rollout resume deployment/my-app

3. Advanced Troubleshooting

For more complex issues:

• • • Check resource quotas (kubectl describe quota)
    • Verify pod resource requests/limits
    • Examine readiness/liveness probe configurations
    • Check for node issues (kubectl get nodes)

Optimal Combinations of maxSurge and maxUnavailable for Kubernetes Rollouts

The ideal combination of maxSurge and maxUnavailable depends on your specific requirements for availability, rollout speed, and resource capacity. Below are detailed configurations for different scenarios.

Understanding the Interplay Between Parameters

These two parameters work together to control your rollout behavior:

Recommended Strategy Combinations

1. Maximum Availability (Zero Downtime)

strategy:
  rollingUpdate:
    maxSurge: 100%      # Double capacity during rollout
    maxUnavailable: 0   # No pods ever unavailable

2. Balanced Approach (Recommended Default)

strategy:
  rollingUpdate:
    maxSurge: 25%         # Some extra capacity
    maxUnavailable: 25%   # Some tolerance for pod churn

3. Fast Rollout (Speed Optimized)

strategy:
  rollingUpdate:
    maxSurge: 50%        # Significant extra capacity
    maxUnavailable: 50%  # Large parallel rollout

4. Large Deployment Optimization (100+ pods)

strategy:
  rollingUpdate:
    maxSurge: 10%        # Controlled extra capacity
    maxUnavailable: 10%  # Small batches

Special Case Combinations

Blue-Green Like Behavior

strategy:
  rollingUpdate:
    maxSurge: 100%     # Full duplicate set
    maxUnavailable: 0   # Maintain full capacity

Effect: Creates complete new set before deleting old (similar to blue-green but within a single deployment)

Rolling Restart Optimization

strategy:
  rollingUpdate:
    maxSurge: 1         # One extra pod at a time
    maxUnavailable: 1   # One pod down at a time

Effect: Classic rolling update with minimal resource overhead

Practical Examples

E-Commerce Checkout Service

# High availability needed
strategy:
  rollingUpdate:
    maxSurge: 50%
    maxUnavailable: 10%

Background Worker

# Can tolerate some downtime
strategy:
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 25%

Canary Deployment

# Very controlled rollout
strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Rollout Strategy vs Pod Disruption Budget: Key Differences

1. Purpose and Scope :

• • • Rollout Strategy (Deployment):
      • Controls voluntary pod replacements during deployments/updates
      • Managed through spec.strategy in Deployment resources
      • Examples: Rolling updates, recreations, blue-green deployments

• • • Pod Disruption Budget (PDB):
      • Protects against involuntary disruptions
      • Governs node drains, cluster autoscaling, admin actions
      • Separate resource (policy/v1) that works alongside Deployments

2. When Each Applies :

3. Key Technical Differences :

4. When to Use Each:

Use Rollout Strategy When:

• • • • • • You’re actively deploying new versions
          • Controlling the pace of pod replacements
          • Managing resource usage during updates

Use PDB When:

• • • • • You need to guarantee minimum available instances
        • Protecting against cluster maintenance operations
        • Preventing autoscaler from removing too many pods

5. They Can Work Together:

Example scenario:

1. 1. 1. 1. PDB ensures at least 2 pods are always available (minAvailable: 2)
         2. Rollout strategy updates pods gradually (maxUnavailable: 1)
         3. Result:

• • • • • • During updates: Deployment respects both constraints
          • During node drains: PDB prevents excessive pod termination

Best Practice:

For critical applications, use both :

# Deployment
spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

# PDB
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

This ensures protection during both voluntary updates and involuntary disruptions.