Zero-Downtime Deployments with Kubernetes with Examples

Ensuring system availability while deploying new features is crucial for modern applications. Kubernetes offers powerful strategies for zero-downtime deployments, enabling organizations to release updates without disrupting user experience. By employing methods like RollingUpdate, Blue-Green, and Canary deployments, combined with tools such as Argo Rollouts or Flagger for advanced traffic management, teams can achieve seamless production updates. This guide also covers techniques to handle database schema changes during these deployments.

Table of Contents

1. Deployment Strategies
   • RollingUpdate
   • Blue-Green
   • Canary
2. Using Argo Rollouts or Flagger
3. Live Traffic Shifting and Metrics-Based Promotion
4. Handling Database Schema Changes
5. Final Thoughts

Deployment Strategies

Kubernetes supports various deployment strategies to ensure that users are not impacted during updates.

RollingUpdate

RollingUpdate is Kubernetes’ default deployment strategy. It gradually replaces old Pods with new ones to ensure that the desired application state is achieved without downtime.

Configuration Example:
Define a RollingUpdate strategy in your Deployment YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1  # Maximum Pods down during the update
      maxSurge: 1        # Maximum Pods above the desired count during the update
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2

Pros:

• Default and straightforward.
• Ensures gradual rollout.

Cons:

• Rollback may impact some live users if issues arise during deployment.

Blue-Green

Blue-Green Deployment creates two environments, one active (blue) and one idle (green). Updates are made in the idle (green) environment, and once ready, traffic is switched to it.

Implementation Steps:

1. Deploy the new version to a new set of Pods (green environment).
2. Switch traffic routing to the green environment once all updates are validated.

Example with Services:

• Blue Service: Active, serving traffic.
• Green Service: Idle, being tested.

Update the service selector to switch traffic:

kubectl patch service my-service -p '{"spec":{"selector":{"app":"green"}}}'

Pros:

• Instant rollback by switching traffic back to the blue environment.
• Ideal for complex updates.

Cons:

• Costs more due to duplicated infrastructure.

Canary

Canary Deployment gradually exposes the new version to a subset of users, allowing teams to monitor its behavior and metrics before fully rolling out. This approach balances risk and feedback efficiency.

Implementation Steps:

1. Deploy the new version alongside the old version using split traffic policies.
2. Gradually route a percentage of traffic to the new version.
3. Monitor and promote based on performance metrics.

Example Traffic Split:
If 25% of traffic routes to the new version:

apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-app-v2
            weight: 25
      - pathType: ImplementationSpecific
        backend:
          service:
            name: my-app-v1
            weight: 75

Pros:

• Limits blast radius for issues.
• Provides real-world performance validation.

Cons:

• Complex release monitoring and traffic management.

Using Argo Rollouts or Flagger

Argo Rollouts

Argo Rollouts extends Kubernetes’ native capabilities to support advanced deployment strategies like Blue-Green and Canary.

Setup Example:

1. Define a Canary Rollout in rollout.yaml: apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: my-app-rollout spec: strategy: canary: steps: - setWeight: 25 - pause: duration: 1m - setWeight: 50 - pause: duration: 2m trafficRouting: nginx: stableService: my-app-stable canaryService: my-app-canary
2. Apply the rollout: kubectl apply -f rollout.yaml
3. Monitor the rollout: kubectl argo rollouts get rollout my-app-rollout -w

Flagger

Flagger automates Canary or Blue-Green deployments by integrating with service meshes like Istio or Linkerd.

Canary Deployment with Flagger:

1. Install Flagger: helm repo add flagger https://flagger.app helm install flagger flagger/flagger
2. Create a Canary custom resource: apiVersion: flagger.app/v1beta1 kind: Canary metadata: name: my-app namespace: default spec: targetRef: apiVersion: apps/v1 kind: Deployment name: my-app analysis: interval: 1m threshold: 2 metrics: - name: request-success-rate thresholdRange: min: 95

Flagger will automatically handle traffic shifting and rollback if metrics threshold is violated.

Live Traffic Shifting and Metrics-Based Promotion

Fine-grained traffic control is essential for zero-downtime deployments. Both Ingress traffic splitting and service mesh routing are effective methods.

Traffic Shifting

Perform dynamic traffic shifting by updating LoadBalancer weights or editing Kubernetes Service selectors.

Service Mesh Example (Istio):
Route traffic incrementally using Istio VirtualService:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
  - my-app.example.com
  http:
  - route:
    - destination:
        host: my-app-v1
      weight: 75
    - destination:
        host: my-app-v2
      weight: 25

Metrics-Based Promotion

Monitor key metrics, such as:

• Request Success Rate
• Error Rate
• Latency

Tools like Prometheus and Grafana can automate decision-making for promotion or rollback:

• Use PromQL queries in Prometheus alerts: sum(rate(http_requests_total{status="500"}[1m])) < 0.01

Handling Database Schema Changes

Database changes (e.g., adding columns, updating indexes) can break application functionality if not handled carefully during deployments.

Best Practices

1. Backward-Compatible Changes:
   Ensure the new database schema supports both the old and new versions of the application. For example:
   • Add a new column, without deleting old ones.
   • Deploy the new application version after verifying the schema change.
2. Phased Migrations:
   Perform schema updates in phases:
   • Phase 1: Add non-breaking changes (e.g., add columns).
   • Phase 2: Update application code to use the new schema.
   • Phase 3: Remove obsolete columns after the application updates.

Example:
Schema update for adding a created_at column:

ALTER TABLE orders ADD COLUMN created_at TIMESTAMP;

Update code in Spring Boot:

@Entity
public class Order {
    @Id
    private Long id;
    private Timestamp createdAt; // New Column
}

3. Rollback Plan:
   Prepare rollback scripts for database migrations in case of deployment failure: ALTER TABLE orders DROP COLUMN created_at;

Final Thoughts

Achieving zero-downtime deployments with Kubernetes is a strategic advantage for any modern organization. By choosing appropriate strategies like RollingUpdate, Blue-Green, or Canary, and leveraging tools like Argo Rollouts or Flagger, development teams can release updates while maintaining excellent user experience. Integrate traffic-shifting, metrics observation, and phased database migrations to further strengthen deployment processes.

Continuous improvement in deployment workflows enables faster innovation with minimized risks. Implement these techniques in your environment and unlock seamless, zero-downtime deployment capabilities!