Kubernetes Deployment Strategies: Rolling, Blue-Green, Canary, and Recreate Compared

Overview

A deployment strategy is the operating pattern used to replace one application version with another. Kubernetes provides several primitives for this work, but the right choice depends on more than the Deployment manifest. Traffic routing, readiness checks, observability, database compatibility, rollback procedures, and the cost of running additional capacity all influence the result.

The four common Kubernetes deployment strategies are:

• Rolling deployment: Kubernetes gradually replaces old Pods with new Pods while keeping the application available. It is the usual starting point for stateless services.
• Blue-green deployment: Two complete application environments are maintained. Traffic serves the blue environment while the green environment is deployed and tested, then routing changes to green.
• Canary deployment: A controlled portion of traffic or users reaches the new version before the release expands. The team evaluates behavior between steps.
• Recreate deployment: The old version is stopped before the new version starts. This can simplify version transitions but normally creates an availability gap.

There is no universally best Kubernetes deployment strategy. Rolling deployments usually minimize extra capacity, while blue-green deployments make switching versions relatively direct. Canary releases limit initial exposure but require traffic control and useful telemetry. Recreate is straightforward when downtime is acceptable or when two versions cannot safely run at the same time.

Before selecting a pattern, review the Kubernetes Deployment Checklist for image, configuration, readiness, security, and production-operation considerations. For GitOps teams, Argo CD can apply the desired state, while progressive delivery controllers and service-mesh or ingress capabilities can help implement staged traffic changes. Argo CD itself is a delivery and synchronization tool; the traffic analysis and promotion behavior may require additional components.

How to estimate

Use a small decision model rather than choosing by convention. Estimate each strategy across five dimensions: exposure, rollback time, temporary capacity, traffic-control complexity, and validation quality.

1. Estimate exposure. Ask how much user traffic can encounter the new version before someone can stop the release. For rolling deployment, exposure grows as new Pods become ready. For canary deployment, begin with the planned canary share and promotion stages. For blue-green, exposure may remain near zero until the traffic switch, followed by a rapid transition. Recreate has no overlap, but all users may experience an outage during the replacement.

2. Estimate rollback time. Break rollback into detection, decision, routing or rollout action, readiness, and stabilization. A useful approximation is:

rollback time = detection time + operator decision time + control-plane action time + readiness time + verification time

Blue-green can make the version switch operationally simple when both environments remain healthy. A rolling rollback can be efficient when the old image and configuration are still available, but it may take time to replace Pods again. A canary rollback can be fast if the traffic controller supports a clear abort action. In every case, test the actual procedure rather than relying on a theoretical command sequence.

3. Estimate temporary capacity. Count the old and new replicas that may run simultaneously. A simple capacity estimate is:

temporary capacity = new-version replicas running alongside old-version replicas × average resource request per replica × overlap duration

For a rough compute comparison, use requested CPU or memory and the duration of overlap. This is not a cloud bill; it is a planning measure. Actual cost also depends on node packing, autoscaling behavior, storage, network traffic, and the pricing model of the infrastructure.

4. Estimate operational complexity. List the controls needed to implement and observe the release: Services, Ingress or Gateway routing, labels, analysis checks, metrics, logs, traces, alerts, manual approvals, and cleanup. A strategy that appears inexpensive can become costly to operate if the team cannot tell whether the new version is healthy.

5. Estimate validation confidence. Define the signals that must remain within an acceptable range before promotion. Examples include error rate, latency, saturation, queue depth, successful business operations, and application-specific checks. The Observability Stack Guide can help organize the metrics, logs, traces, and incident signals needed for this assessment.

Inputs and assumptions

Record the following inputs in the release plan. Keeping them explicit makes the estimate repeatable when traffic, replica counts, or infrastructure assumptions change.

• Replica count: The normal number of Pods for the old and new versions, including autoscaling limits.
• Resource requests: CPU and memory requested by each Pod. Use requests for scheduling and capacity planning; do not treat them as a complete measure of actual consumption.
• Overlap duration: The expected time that old and new versions run together, including startup, image pulls, readiness checks, analysis, and rollback reserve.
• Traffic model: Whether traffic is distributed by Service, Ingress, Gateway, service mesh, a feature flag, a queue consumer assignment, or another mechanism.
• Health signals: The measurements used to approve, pause, or abort the release. Include both technical and user-facing signals where possible.
• Compatibility constraints: Database schema changes, message formats, caches, persistent volumes, external APIs, and jobs that may prevent two versions from operating together.
• Recovery assumptions: The previous image, configuration, manifests, and routing rules remain available, and the team has permission to change them during an incident.

Database changes deserve special attention. A blue-green or canary application release does not make an incompatible schema migration safe. Prefer changes that allow the old and new application versions to coexist, and separate destructive cleanup from the release where practical. For stateful workloads, review storage behavior and failure modes in Kubernetes Storage Classes for Stateful Databases.

Also decide whether the estimate covers only application Pods or the wider platform impact. A second environment may require additional nodes, load-balancer capacity, persistent storage, secrets, certificates, test data, and observability ingestion. Include only resources that genuinely run during the overlap, but do not omit dependencies that can become the limiting factor.

Worked examples

These examples use hypothetical values to demonstrate the method, not to predict a provider bill or performance result.

Rolling deployment

Assume a service normally runs six replicas, each with a request of 0.5 vCPU. During a rolling update, the cluster temporarily runs six old replicas and two new replicas while the new Pods pass readiness checks. If that overlap lasts 10 minutes, the added planned capacity is approximately:

2 replicas × 0.5 vCPU × 10 minutes = 10 vCPU-minutes

The practical risk is gradual exposure. If readiness checks confirm only that the process is running, the rollout can proceed while the application is failing real requests. Add application-level metrics and define a pause or rollback condition. This approach is a reasonable default when versions are backward compatible and traffic can be safely shared.

Blue-green deployment

Assume the same service requires six replicas and the green environment must remain ready for 15 minutes of validation before switching traffic. If green uses the same resource requests as blue, the second environment adds six replicas during the overlap:

6 replicas × 0.5 vCPU × 15 minutes = 45 vCPU-minutes

The larger capacity requirement buys a clean environment boundary and a direct traffic decision. However, the estimate must include routing configuration, duplicated secrets or configuration, test traffic, and the time required to keep blue available for rollback. Blue-green is attractive when fast switching matters and the platform can support reliable routing changes.

Canary deployment

Suppose a canary starts with one new replica, receives a small planned share of traffic, and is evaluated for 10 minutes before promotion. The initial compute overlap is only one replica, but the main estimate is not just capacity. It includes the cost of operating analysis gates and the time needed to collect enough representative traffic.

A canary is useful when failures can be detected from request-level or business-level signals and traffic can be assigned predictably. It is less informative when the canary receives too little traffic, when users are not consistently routed to the same version where session behavior matters, or when a failure affects a shared dependency before the canary signal is visible.

Recreate deployment

Assume the service takes four minutes to terminate the old Pods, schedule the new Pods, pull images, pass readiness checks, and verify health. The direct overlap capacity may be close to zero, but the estimated availability gap is about four minutes under the stated assumptions. Recreate can be appropriate for a singleton worker, a workload with incompatible runtime requirements, or a nonproduction environment where downtime is accepted. It is a poor fit when uninterrupted service is a requirement.

When to recalculate

Recalculate the strategy and its operational estimate whenever an input changes, not only when a deployment tool changes. Revisit it when replica counts, autoscaling limits, resource requests, node capacity, traffic volume, routing rules, health checks, or release frequency changes. Revisit it before a major database migration, a change to session handling, a new external dependency, or a move from one ingress, gateway, mesh, or cloud environment to another.

Review the estimate after an incident or failed rollout. Compare the predicted detection and rollback times with what actually happened. If the team could not identify the problem, add or improve signals. If rollback was slow, preserve the previous artifact and simplify the control path. If the cluster lacked capacity, update requests, autoscaling assumptions, or the deployment budget.

For a practical next step, create a short release worksheet with the five strategy dimensions, record the assumptions, and run one controlled test in a representative environment. Confirm that readiness gates, traffic changes, alerts, rollback commands, and cleanup all work as expected. Then document the chosen pattern in the repository alongside the Kubernetes manifests or GitOps configuration. Teams comparing delivery platforms can also consult Best CI/CD Tools for Cloud-Native Teams, but the platform should support the deployment decision rather than replace it. Recalculate the worksheet when the underlying capacity, traffic, or risk assumptions change.