Rolling updates and rollbacks

Replacing pods without dropping requests

A rolling update replaces pods gradually, controlled by how many extra pods may exist and how many may be missing. Those two numbers decide whether an update is fast or safe.

Graceful shutdown is where zero-downtime deploys are usually lost. A pod removed from the service still has in-flight requests, so it needs a pre-stop delay and a process that finishes work before exiting.

Deployment history makes rollback a single command. Practise it before you need it, because the first time should not be during an incident.