---
title: "Dissecting Kubernetes Deployments"
description: "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."
---

# Dissecting Kubernetes Deployments

[Heroku](https://yomu.fyi/company/heroku) · Damien Mathieu · Feb 22, 2018

**Type:** Explainer

## 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.

## Context

The post examines how Kubernetes Deployments handle gradual application rollouts internally, including the roles of Pods, ReplicaSets, controllers, informers, and event triggers.

## Approach / What changed

The Deployment controller synchronizes in response to Deployment, ReplicaSet, and Pod events, creates a new ReplicaSet for each rollout, scales old and new ReplicaSets according to rollout settings, detects stalled progress, and retains older ReplicaSets for rollback. A Go informer example demonstrates watching Deployment creation and update events.

## Takeaways

- 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.
- ProgressDeadlineSeconds can mark a Deployment as failed when progress stops, including when Pods repeatedly crash before becoming available.
- Rollback depends on retaining older ReplicaSets with distinct Pod templates; repeatedly using the :latest image tag does not provide a meaningful rollback target.

**Tags:** [Kubernetes](https://yomu.fyi/topic/kubernetes)

- Source: [Heroku](https://www.heroku.com/blog/dissecting-kubernetes-deployments)
- Source URL: https://www.heroku.com/blog/dissecting-kubernetes-deployments
- Ingested by Yomu: 2026-09-09T14:25:48.500Z

[Read original post](https://www.heroku.com/blog/dissecting-kubernetes-deployments)