# Deployment Uses Recreate Strategy

> Flags Deployments using the Recreate strategy, where every rollout stops all pods before new ones start.

Source: https://zop.dev/integrations/kubernetes/recommendations/deployment-uses-recreate-strategy

---

## Recreate turns every deploy into downtime

The [Deployments documentation](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
defines two strategies. `RollingUpdate` is the default: by default it keeps at least 75% of the
desired pods up (25% max unavailable) and runs at most 125% (25% max surge) while it replaces
them. `Recreate` kills all existing pods before new ones are created, and for an upgrade it waits
for their removal to succeed before starting any pod of the new revision.

The gap between the last old pod stopping and the first new pod passing readiness is time with no
capacity at all, and it lasts as long as the new pods take to pull their image, start and pass
readiness. It also makes a bad release more painful, because there is no old version still serving while you notice.

## Listing Deployments on Recreate

```bash
kubectl get deployments -A -o json | jq -r '
  .items[]
  | select(.spec.strategy.type == "Recreate")
  | "\(.metadata.namespace)/\(.metadata.name) replicas=\(.spec.replicas)"'
```

## The strategy field is the whole test

ZopNight reads the Deployment's strategy as collected and fires when it is exactly `Recreate`.
The replica count does not matter: a three-replica Deployment on Recreate has the same outage on
each rollout as a single-replica one. There is no metric, threshold or window, and the finding
clears once the strategy changes. A Deployment with no reported strategy is skipped.

## Legitimate reasons to keep Recreate

The rule cannot see why Recreate was chosen, and sometimes it is the right call. Two versions of
an app that write to the same data in incompatible ways, or a singleton that must never have two
active copies, may not be safe to overlap. StatefulSets and DaemonSets have their own update
strategies and are not part of this check. Single-replica Deployments are covered separately by
[Single replica deployment](https://zop.dev/integrations/kubernetes/recommendations/single-replica-deployment),
because a rolling update of one replica still leaves little margin.

## Availability risk, no saving attached

This medium-severity reliability finding has no savings estimate. The cost is user-facing errors
during each release window.

## Moving to a rolling update

1. Confirm the app tolerates two versions running for a short time: shared schemas, queue
   consumers and file locks are the usual concerns.
2. Make sure the pods have a readiness probe, so the rollout waits for new pods to be ready before
   removing old ones.
3. Patch the strategy:
   `kubectl patch deployment <name> -p '{"spec":{"strategy":{"type":"RollingUpdate"}}}'`, then
   tune `maxSurge` and `maxUnavailable` if the 25% defaults do not suit the replica count.
4. Watch the next release with `kubectl rollout status deployment/<name>`.