How to: Update strategy
[Rolling updates](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) is the default update strategy, triggered when a field in the deployment's Pod template `deployment.spec.template` is changed. A new ReplicaSet is created that creates updated Pods one after the other, and the old ReplicaSet is scaled to 0 after successful update. At some point during the update, both old version and new version of the app will be live. By default, ten old ReplicaSets will be kept, see [`deployment.spec.revisionHistoryLimit`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit)

The other type of update strategy is [Recreate](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#recreate-deployment), where all Pods are killed before new Pods are created. This is useful when you cannot have different versions of an app running simultaneously, e.g database.

- [`deploy.spec.strategy.rollingUpdate.maxUnavailable`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable): control number of Pods upgraded simultaneously
- [`deploy.spec.strategy.rollingUpdate.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge): controls the number of additional Pods, more than the specified replicas, created during update. Aim to have a higher `maxSurge` than `maxUnavailable`.

> A Deployment's rollout is only triggered if a field within the Pod template `deploy.spec.template` is changed \
> Scaling down a Deployment to 0 is another way to delete all resources, saving costs, while keeping the config for a quick scale up when required

```sh