The native Kubernetes Deployment Objects support the Rolling Update strategy, which provides a basic guarantee during an update, as well as limitations:
- Few controls over the speed of the rollout.
- Inability to control traffic flow to the new version.
- Readiness probes are unsuitable for deeper, stress, or one-time checks.
- No ability to check external metrics to verify an update.
- No ability to automatically abort and roll back the update.
For the reasons above, in a complex production environment, this Rolling Update could be risky because it doesn't provide control over the blast radius, may roll out too aggressively, and there is no rollback automation in case of failure.