Hands-on Lab·Certified Kubernetes Administrator
ReplicaSets
Create a ReplicaSet by hand, watch it replace a deleted Pod, then create a Deployment and follow the ownership chain it builds. One command that works on the Deployment and fails on the bare ReplicaSet explains most of the difference.
Workloads Guide 25 of 103 Beginner
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 25 min
Pod and ReplicaSet name suffixes are generated. The ownership structure is not.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when you want to know what a Deployment is actually doing underneath. This matters because the ReplicaSet is the thing holding your Pod count steady, and knowing that is what explains why a deleted Pod comes back under a different name.
- writing a ReplicaSet by hand and watching it hold a Pod count on its own
- deleting a Pod and seeing the replacement arrive with a new random name
- creating a Deployment and finding the ReplicaSet it quietly made for you
- seeing why you rarely write a ReplicaSet yourself
Before you start
- The Pods guide.
- The labels and selectors guide, since a ReplicaSet finds its Pods by label and nothing else.
- A scratch namespace.
-
A ReplicaSet on its own
-
Delete a Pod and it comes back with a new name
-
What a Deployment adds, in one listing