Zero Downtime Deployment Strategies for EKS

Today's users have no tolerance for downtime. When publishing a new version of your application (deploy), your service must not stop even for a second. Let's examine the strategies you can use to ensure "Zero Downtime" on Amazon EKS.

1. Rolling Update (Default)

It is the default strategy of Kubernetes Deployments.

• How it Works? Gradually shuts down old pods and opens new ones. E.g., if you have 10 pods, it shuts down 2, opens 2 new pods in v2. When these are Ready, it moves to the next 2.
• Advantage: Does not require extra resources. Easy.
• Attention: Your readinessProbe settings must be correct. Otherwise, traffic goes to new pods that are not ready yet, and errors occur.

2. Blue/Green Deployment

• How it Works? You create an exact copy of the current version (Blue) with the new version (Green). When tests are finished, you switch the Load Balancer (Service) traffic from Blue to Green at once.
• Advantage: Instant switch and instant rollback.
• Disadvantage: Doubles resource usage (cost) for a short time. Can be easily managed on EKS with tools like Argo Rollouts.

3. Canary Deployment

• How it Works? You direct a small portion of the traffic (e.g., 5%) to the new version. If the error rate does not increase, you gradually increase the traffic rate (20%, 50%, 100%).
• Advantage: Minimizes risk. Provides opportunity to test with real user traffic.
• Requirement: Requires a Service Mesh like Istio, Linkerd, or AWS App Mesh, or an advanced Ingress Controller (Gateway API).

Continuous deployment on EKS is not just a technique, it is an art. The right strategy depends on the criticality level of your application and your budget.