A standalone Pod is not suitable for production use — if it crashes, it stays crashed; if the node it's running on fails, it's gone permanently; you can't run multiple copies for availability or performance. ReplicaSets solve the first problem: they are the controller that ensures a specified number of Pod replicas are always running. If a Pod dies, the ReplicaSet controller immediately creates a replacement. If a node fails, the ReplicaSet creates replacements on surviving nodes. Deployments solve the second and third problems: they manage ReplicaSets and add the ability to declaratively update the Pod template (change the container image, add environment variables), track the update history, and roll back to a previous version. The Deployment is the standard way to deploy stateless applications to Kubernetes — it is the workload resource you will use for 90% of application deployments.
35 minintermediate
ReplicaSets and Deployments
Analogy🏏Cricket
🏏 Think of it like cricket: A well-run cricket board has distinct departments with clear responsibilities: the selection committee chooses players, the grounds department prepares venues, the scheduling department assigns matches to grounds, the operations department manages logistics, and the referees enforce the rules. No department does another's job, and all communication flows through the central secretariat. Just as the ICC's effectiveness comes from each department having a clear mandate and working through a central coordination system, Kubernetes' reliability comes from each component (API server, scheduler, controller manager, etcd, kubelet, kube-proxy) having a single responsibility and communicating only through the API server as the central hub. The insight is that this architecture makes the system resilient: a failure in the scheduling department doesn't stop ongoing matches, just as a failing scheduler doesn't kill running Pods.
Lesson 6 of 24
0% complete