A deployment strategy controls how risk reaches users. Kubernetes Deployments provide reliable rolling updates and rollback primitives, while blue-green and canary releases add traffic-management patterns around those primitives.

The best strategy depends on compatibility, traffic control, capacity and failure detection. This guide compares the main options and shows the safeguards required for a production rollout that can stop or reverse before a small defect becomes a full outage.

What you will learn

  • RollingUpdate is the default Deployment strategy and balances availability with extra capacity.
  • Readiness, graceful shutdown and rollout progress are essential for zero-downtime claims.
  • Blue-green favors fast switch and rollback but requires parallel capacity and data compatibility.
  • Canary reduces blast radius only when metrics and automated stop conditions are trustworthy.

Rolling updates

A RollingUpdate gradually replaces old Pods with new ones. maxUnavailable controls how much desired capacity may be unavailable; maxSurge controls temporary extra Pods. Values can be counts or percentages.

Use readiness probes so new replicas receive traffic only when prepared. Add minReadySeconds when a new Pod must remain healthy before being considered available, and configure progressDeadlineSeconds to expose stalled rollouts.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 25%
minReadySeconds: 15
progressDeadlineSeconds: 600

Recreate strategy

Recreate terminates existing Pods before creating the new version. It is simple but intentionally introduces unavailability for ordinary stateless services.

Use it only when old and new versions cannot coexist or the workload allows downtime. Communicate maintenance, verify data safety and avoid presenting Recreate as a zero-downtime pattern.

Blue-green releases

Blue-green runs two complete environments. A Service or routing layer sends production traffic to the active color, then switches to the candidate after validation. Rollback can be a route change while the previous version remains healthy.

The cost is duplicate capacity and operational complexity. Database changes must support both versions during the overlap. Test background jobs, consumers and singleton processes so two colors do not perform conflicting work.

Canary releases

A canary sends a small portion of traffic or a selected cohort to the new version. Increase exposure only after latency, errors, saturation and business signals remain acceptable.

Replica counts alone do not guarantee precise traffic percentages because connection behavior and routing can be uneven. Use a controller, service mesh or Gateway implementation when weighted routing and automated analysis are required.

Database compatibility

Application rollback is easy only when data changes remain backward compatible. Use expand-and-contract migrations: add compatible structures, deploy readers and writers, migrate data, then remove old structures in a later release.

Do not bundle destructive schema changes with the first application rollout. Make migrations observable, bounded and recoverable. Backups are not a substitute for a tested compatibility plan.

Observe, pause and roll back

Watch Deployment conditions, unavailable replicas, probe failures, errors and user-facing indicators. A successful kubectl rollout status proves controller progress, not business correctness.

Record the image digest and configuration for each revision. Define automatic pause or rollback thresholds, and make sure rollback does not reintroduce incompatible configuration or database assumptions.

kubectl rollout status deployment/api -n production
kubectl rollout history deployment/api -n production
kubectl rollout undo deployment/api -n production

Production checklist

  • Use immutable image tags or digests and record provenance.
  • Configure readiness, resources and graceful termination.
  • Set maxUnavailable, maxSurge and progress deadlines deliberately.
  • Keep database changes compatible across overlapping versions.
  • Monitor technical and business signals during rollout.
  • Test pause, rollback and emergency access before production.

Frequently asked questions

Which strategy is best for most stateless services?

A well-configured rolling update is usually the simplest reliable default. Use canary or blue-green when risk and traffic-control requirements justify the complexity.

Does maxUnavailable zero guarantee zero downtime?

No. The application still needs enough replicas, accurate readiness, graceful shutdown, healthy dependencies and spare capacity.

Can Kubernetes do canary by itself?

You can run separate Deployments, but precise weighted traffic and automated analysis usually require an ingress, Gateway, mesh or rollout controller.

Continue learning Kubernetes

Official Kubernetes references