Shipping code is easy; shipping code without hurting users is the real craft.

Every application changes over time. Developers fix bugs, add features, patch security holes, and upgrade libraries. Each change eventually needs to reach the servers where real users are connecting. The moment a new version replaces an old one is called a release or a rollout, and it is one of the riskiest moments in the life of any system.

A deployment strategy is simply the plan for how the old version is swapped for the new one. The plan answers questions such as: do we stop everything first or replace gradually? How many copies can be missing at the same time? How do we know the new copy is healthy? What happens if it is not? Without a clear plan, releases become stressful events that people schedule for midnight and dread.

What Kubernetes gives you out of the box

Kubernetes has a built-in object called a Deployment that manages the lifecycle of stateless application copies. Inside a Deployment there is a setting called the strategy, and it accepts exactly two types: RollingUpdate and Recreate. If you do not choose, Kubernetes picks RollingUpdate for you. Other popular approaches such as blue-green and canary releases are built on top of Kubernetes using extra objects or tools, and we will touch on them later in this guide.

Four objects work together every time a rollout happens.

Before comparing strategies, it helps to be clear about the objects involved. A rollout is not magic; it is a conversation between a small number of Kubernetes components, each with a narrow job. Once you know who does what, the behaviour of both strategies becomes easy to predict.

Why the Service matters for rollouts

A Service keeps a list of pod addresses that are ready to receive traffic. When a pod becomes ready it is added to the list, and when it is terminating or unhealthy it is removed. This list is what makes zero-downtime rollouts possible, because the Service quietly shifts traffic away from old pods and toward new ones. If your Service or its health checks are misconfigured, no strategy can save you from dropped requests.

The Deployment never touches pods directly; it manages ReplicaSets, and ReplicaSets manage pods.

When you create a Deployment, it creates one ReplicaSet, and that ReplicaSet creates the pods. The pods carry a special label containing a hash of the pod template, so each ReplicaSet can recognise which pods belong to it. This hash is the fingerprint of a version. Two pods with different fingerprints are considered different versions, even if they look almost the same.

What counts as a new version

Only changes to the pod template trigger a rollout. The pod template includes the container image, environment variables, resource requests, probes, volumes, and labels on the pod. Changing the number of replicas does not create a new version; it simply scales the current ReplicaSet up or down. This distinction surprises many beginners who expect any edit to cause a restart.

flowchart TD
    D[Deployment
desired state and strategy] --> RS1[Old ReplicaSet
version 1 pods]
    D --> RS2[New ReplicaSet
version 2 pods]
    RS1 --> P1[Pod v1]
    RS1 --> P2[Pod v1]
    RS2 --> P3[Pod v2]
    RS2 --> P4[Pod v2]
    S[Service] -.routes to ready pods.-> P1
    S -.-> P3
        

The diagram shows the heart of every rollout. During an update, the Deployment holds two ReplicaSets at the same time: the old one that is shrinking and the new one that is growing. The strategy decides how quickly and in what order these two counts change. After a successful rollout, the old ReplicaSet remains with zero pods, kept as a history record so that a rollback is quick.

The reconciliation loop

The Deployment controller runs a continuous loop. It observes the current number of pods in each ReplicaSet, compares them to the numbers allowed by the strategy, and adjusts the replica counts of the ReplicaSets. It does not command pods to start or stop. It only edits numbers on ReplicaSets, and the ReplicaSet controllers do the actual creating and deleting. This layered design keeps each component simple and makes the whole system resilient to restarts of any single controller.

Stop everything, then start everything: the simplest possible release.

With the Recreate strategy, Kubernetes first scales the old ReplicaSet down to zero pods. It waits until those pods are fully gone. Only then does it scale the new ReplicaSet up to the desired number. At no point do the old and new versions run at the same time.

What you gain

The greatest gift of Recreate is certainty. Since only one version runs at any moment, you never have to worry about two versions disagreeing about data formats, message shapes, or database structure. You also never need spare cluster capacity for extra pods, because the old ones disappear before the new ones appear. Some workloads simply cannot tolerate two copies running at once, and for them Recreate is the natural fit.

What you pay

The price is downtime. Between the moment the last old pod stops and the moment the first new pod becomes ready, no pod is available to answer requests. That gap includes image pulling, container startup, application warm-up, and the time for readiness checks to pass. For a lightweight service it may be seconds; for a heavy application with caches to load, it may be minutes.

Follow a single Recreate rollout from the moment you change the image to the moment traffic returns.

sequenceDiagram
    participant U as User
    participant DC as Deployment Controller
    participant OLD as Old ReplicaSet
    participant NEW as New ReplicaSet
    participant SVC as Service
    U->>DC: Update pod template
    DC->>OLD: Scale to 0
    OLD-->>SVC: Pods leave endpoint list
    Note over SVC: Downtime window begins
    OLD-->>DC: All old pods terminated
    DC->>NEW: Scale to desired count
    NEW-->>SVC: Pods pass readiness, join endpoints
    Note over SVC: Downtime window ends
        

Where the downtime really comes from

Downtime in a Recreate rollout is the sum of several delays: the graceful shutdown period of old pods, the scheduling time for new pods, the image pull time if the image is not cached on the node, the container start time, the application start-up and warm-up, and the readiness probe delays. You can shrink some of these, for example by using smaller images and faster start-up, but you can never reduce the total to zero. That is the fundamental nature of the strategy.

Replace pods a few at a time so the application never fully disappears.

RollingUpdate is the default strategy and the one most teams use for everyday releases. Instead of stopping everything, Kubernetes gradually creates new pods and removes old ones in small batches. At every moment during the rollout, some old pods and some new pods are serving traffic together. When the last old pod is gone, the release is complete.

Two dials control the pace

RollingUpdate exposes two settings, maxSurge and maxUnavailable. Together they define how aggressive or cautious the rollout is. One dial says how many extra pods may exist above the desired count. The other says how many pods may be missing below the desired count. We look at them closely in the next chapter, because getting these two numbers right is the difference between a smooth release and a painful one.

graph LR
    A[Start
4 old pods] --> B[Create 1 new pod
4 old, 1 new]
    B --> C[New pod ready
remove 1 old
3 old, 1 new]
    C --> D[Create another new
3 old, 2 new]
    D --> E[Repeat until done]
    E --> F[Finish
4 new pods]
        

Two small numbers that decide speed, safety, and cost.

The defaults for both are twenty-five percent. For a Deployment with ten replicas, that means up to three extra pods may be created (two and a half rounded up) and up to two pods may be unavailable (two and a half rounded down). The controller keeps the total number of pods within the upper limit and the number of ready pods above the lower limit throughout the rollout.

Common combinations and what they mean

Choosing values with real numbers

Consider a Deployment with eight replicas, each using half a CPU core. With maxSurge of two, the cluster must be able to host ten pods at the peak, so five CPU cores rather than four. If your cluster has no spare room, the surge pods will sit in a pending state, and the rollout will stall waiting for capacity. Always check that the surge fits before you rely on a high value.

On the other side, with maxUnavailable of two, your service temporarily runs on six of eight pods. If your normal traffic already uses seventy-five percent of capacity, the remaining pods will run very hot during the release. The safest choice for user-facing services is usually maxUnavailable of zero with a small surge, accepting that the rollout takes longer.

A rolling update is only as safe as the checks that decide a pod is ready.

How does Kubernetes know a new pod is healthy enough to replace an old one? It relies entirely on the probes you define. Without a readiness probe, a pod is considered ready the instant its container starts, even if the application inside is still loading. The rollout then races ahead, removes old pods, and sends users to pods that cannot answer yet.

Designing a good readiness check

A useful readiness check confirms that the application can actually do its job. It should verify that the process is listening, that essential dependencies such as the database connection are reachable, and that any required caches are loaded. However, it should not depend on every downstream service in the company, because a distant outage would then make all your pods unready and turn a small problem into a total one.

How probes affect both strategies

In a RollingUpdate, readiness decides when the controller may proceed to the next batch. A pod that never becomes ready freezes the rollout, which is exactly what you want because the old pods keep serving users. In a Recreate rollout, readiness decides when the downtime ends. A slow readiness check directly lengthens the outage, so tuning its initial delay and period carefully has real user impact.

Removing an old pod politely is as important as starting a new one.

When a pod is told to stop, Kubernetes does not simply pull the plug. It follows a sequence: the pod is marked as terminating, it is removed from the list of Service endpoints, a pre-stop hook runs if one is defined, the container receives a termination signal, and after a grace period the container is forcibly killed if it is still running. The default grace period is thirty seconds.

sequenceDiagram
    participant C as Controller
    participant P as Old Pod
    participant E as Endpoint Update
    participant L as Load Balancers and Proxies
    C->>P: Mark terminating
    par In parallel
        C->>E: Remove pod from endpoints
        E->>L: Propagate new list
    and
        P->>P: Run pre-stop hook
    end
    P->>P: Receive termination signal
    P->>P: Finish in-flight requests
    Note over P: Grace period countdown
    P-->>C: Exit cleanly or be force-killed
        

The hidden race condition

Endpoint removal and the shutdown signal happen in parallel, not one after the other. Load balancers, ingress controllers, and node proxies need a moment to learn that the pod is gone. During that moment, new requests may still be sent to a pod that has already started shutting down. If the application exits instantly on the signal, those requests fail with connection errors, and users see brief failures during an otherwise perfect rolling update.

Practices that make termination smooth

Every rollout can be watched, paused, and reversed.

A Deployment reports its own status, and understanding those signals turns a release from a leap of faith into a supervised process. The Deployment tracks conditions such as Progressing, which says whether the rollout is moving forward, and Available, which says whether the minimum number of pods is serving. These conditions are what dashboards and pipelines read to decide if a release succeeded.

A direct comparison of the two strategies across the qualities that matter in production.

flowchart TD
    Q1{Can two versions
run together safely?} -->|No| R[Use Recreate]
    Q1 -->|Yes| Q2{Is downtime
acceptable?}
    Q2 -->|Yes and simplicity wanted| R
    Q2 -->|No| Q3{Is spare capacity
available?}
    Q3 -->|Yes| RU1[RollingUpdate
surge above zero, unavailable zero]
    Q3 -->|No| RU2[RollingUpdate
surge zero, unavailable small]
        

Real workloads and the strategy that fits them.

Situations that favour RollingUpdate

Situations that favour Recreate

The hardest part of a rolling update is not Kubernetes; it is your own software.

During a rolling update, old and new pods serve requests at the same moment, and both talk to the same database, cache, and message queues. A user might load a page from a new pod and then submit a form that lands on an old pod. If the two versions disagree about anything shared, users will see errors that are hard to reproduce and seem to vanish minutes later.

The expand and contract approach

The safest pattern for changing shared data is to do it in stages, each of which is compatible with the version before and after. First, expand: add new columns, tables, or message fields in a way that the old version simply ignores. Second, release the new version, which begins to use the new structure while still tolerating the old. Third, once the old version is completely gone, contract: remove the unused old structure in a later release.

Other shared surfaces to check

Data is not the only shared surface. Consider the format of messages placed on queues, keys and values stored in caches, the shape of API responses that other services depend on, the names of cookies and session data, and static files served by a content network. Each of these can be seen by both versions at once and must remain compatible across the overlap.

A rollout shares the cluster with everything else that is going on.

Capacity planning

RollingUpdate with a surge needs room for extra pods. If the cluster is full, surge pods stay pending and the rollout stalls without any error in the application itself. A helpful habit is to keep some headroom in the cluster, or to set the surge to zero and accept a small controlled dip in capacity for workloads that have no room to spare. Resource requests on pods should also be realistic, since inflated requests waste headroom and understated ones cause noisy neighbours.

Interaction with the Horizontal Pod Autoscaler

A Horizontal Pod Autoscaler adjusts the replica count of a Deployment based on load. During a rolling update, the autoscaler and the rollout both influence the number of pods, and this is supported by Kubernetes: the rollout proportionally distributes new replicas between old and new ReplicaSets. Still, it is wise to avoid releasing at peak traffic, because low available capacity combined with a load spike is a risky mix.

Pod Disruption Budgets

A Pod Disruption Budget states how many pods of an application may be voluntarily taken away at once, for example during node maintenance or cluster upgrades. It is an important safety net for those events. However, the pod replacement done by a Deployment rollout is governed by the strategy settings, maxSurge and maxUnavailable, and not by the budget. That means you should tune those two settings on purpose rather than relying on the budget to protect your rollouts.

A rollout is a moment when new code, and sometimes new permissions, enter your cluster.

Security in deployment is about making sure that what runs is what you intended, and that the release process itself cannot be abused. Because every rollout pulls an image and starts it with certain permissions, the rollout path is a natural place for attackers to try to slip something in. A careful team treats the release pipeline as part of the attack surface.

You cannot manage what you cannot see.

A healthy release process treats the rollout as an event to be observed. Two kinds of signals matter: signals from Kubernetes about the rollout mechanics, and signals from your application about user experience. A rollout can be mechanically successful and still be bad for users, so you need both.

Marking releases in your dashboards

Adding a version label to logs and metrics lets you separate the behaviour of old and new pods during the overlap. Marking each release on a dashboard timeline makes it easy to connect a change in error rate with a specific release. Many teams also configure alerts for stalled rollouts, so that a stuck release is noticed within minutes rather than discovered by a customer.

Where blue-green, canary, and other update types fit into the picture.

RollingUpdate and Recreate are the only two strategy types a Deployment understands, but teams often need more control. More advanced release patterns are built on top of Kubernetes using extra objects, traffic routers, or dedicated tools. It helps to know what they are so you can recognise when the built-in options are no longer enough.

Update strategies for other workload types

Deployments are not the only objects that roll out new versions. A StatefulSet, used for applications that need stable identity and storage, updates its pods one at a time in reverse order by default, and it offers a partition setting to stage updates. A DaemonSet, which runs one pod per node, has its own rolling update behaviour controlled by a maximum-unavailable setting. The idea is always the same: replace pods gradually, and only proceed when the previous step is healthy.

Mistakes that turn a routine release into an incident.

A checklist of habits that keep releases boring, which is the goal.

How the choice plays out in everyday engineering situations.

RollingUpdate is the default. If you do not specify a strategy, a Deployment uses RollingUpdate with a maximum surge of twenty-five percent and a maximum unavailable of twenty-five percent.

No. It makes zero downtime possible, but only when readiness probes, graceful shutdown, capacity, and version compatibility are all handled properly. Weak probes or abrupt shutdowns can still cause errors.

No. Only changes to the pod template create a new revision. Scaling simply adjusts the number of pods in the current ReplicaSet.

The most common causes are pods that cannot be scheduled because the cluster is full, images that cannot be pulled, readiness probes that never pass, and quotas that block extra pods. Cluster events usually name the cause directly.

No. After the progress deadline passes, the Deployment is marked as failed, but nothing is reverted. You or your automation must roll back or fix forward.

No. With both at zero, the controller could neither add nor remove pods, so the rollout could not progress. The configuration is rejected.

Yes. It suits workloads that must never overlap, use exclusive single-attach storage, or can tolerate a planned short outage. It is a deliberate tool, not a lazy default.

A rollback restores an earlier ReplicaSet using the same strategy that is configured. Under RollingUpdate it is gradual and safe; under Recreate it is another full stop and start.

No. They protect against voluntary evictions such as node drains. Rollout pace is controlled by the strategy settings, so those must be tuned separately.

A rolling update gradually replaces pods, and traffic spreads across them in proportion to their numbers. A canary release deliberately controls the exact share of traffic sent to the new version, usually with a traffic-splitting layer, and evaluates metrics before continuing.

Because it is a moving target. Different pods may run different code, template changes may go unnoticed, and rollbacks lose their meaning. Use unique version identifiers instead.

A deployment strategy is the plan for replacing an old version of your application with a new one. Kubernetes offers two built-in choices. RollingUpdate replaces pods gradually, keeping the application available while old and new versions briefly coexist. Recreate stops every old pod first and then starts the new ones, trading a period of downtime for perfect separation between versions. Neither is better in every case; the right choice depends on whether your users can wait and whether your software can tolerate two versions running together.

The strategy is only part of the story. Health probes, graceful shutdown, capacity headroom, data compatibility, and careful monitoring are what turn a working configuration into a safe and boring release process. When these pieces are in place, teams can release many times a day with confidence, and rollback becomes a calm, practiced routine rather than an emergency.