Dissecting Kubernetes Deployments

Summary

Kubernetes Deployments provide declarative updates for Pods and ReplicaSets, enabling application versions to roll out gradually rather than restarting every Pod at once. The Deployment controller uses informers and triggers for Deployment, ReplicaSet, and Pod events, then synchronizes state by creating ReplicaSets and scaling old and new sets according to replica counts, max surge, and available Pods. During a rolling update, it waits for new Pods to respond before terminating old ones; progress deadlines help detect stalled rollouts, including crash loops. After completion, old ReplicaSets are cleaned up but a configured number is retained for rollback, which requires changing image tags rather than continually using :latest. The post also shows a Go informer that watches Deployment creation and update events and explains that the trigger-based design supports custom controllers.

Takeaways

1. 1

   A rolling update creates a new ReplicaSet and scales it up while scaling the old ReplicaSet down, using replica counts, max surge, and Pod availability to control the transition.

2. 2

   ProgressDeadlineSeconds can mark a Deployment as failed when progress stops, including when Pods repeatedly crash before becoming available.

3. 3

   Rollback depends on retaining older ReplicaSets with distinct Pod templates; repeatedly using the :latest image tag does not provide a meaningful rollback target.