A ReplicaSet keeps a chosen number of pod replicas in a Kubernetes cluster. Instead of creating each Pod separately, define how a Pod should be made and how many copies you want. The ReplicaSet manages those Pods as a unit and replaces missing ones—even when the desired count is just one. It does not expose them to clients; use a Service for that. section 14.1
Listing 14.1 The Kiada ReplicaSet object manifest
apiVersion: apps/v1 #1
kind: ReplicaSet #1
metadata: #1
name: kiada #2
spec:
replicas: 5 #3
selector: #4
matchLabels: #4
app: kiada #4
rel: stable #4
template: #5
metadata: #5
labels: #5
app: kiada #5
rel: stable #5
spec: #5
containers: #5
- name: kiada #5
image: luksa/kiada:0.5 #5
... #5
volumes: #5
- ... #5
This manifest shows the three essential parts together: a replica count, a label selector, and a Pod template whose labels match the selector. section 14.1.1
The `spec.replicas` field sets the desired count; omitting it defaults to one. `spec.template` defines new Pods. `spec.selector` identifies the Pods the ReplicaSet counts and manages. Selector labels must be present in the template labels, though the template may have additional labels. Kubernetes rejects a new ReplicaSet whose template does not match its selector. ReplicaSets use `apiVersion: apps/v1` and `kind: ReplicaSet`. section 14.1.1 section 14.2.2
Create, inspect, and scale
Apply a manifest with `kubectl apply -f rs.kiada.yaml`, then run `kubectl get rs kiada`. The `DESIRED`, `CURRENT`, and `READY` columns let you distinguish the requested count, the current count, and Pods reported ready. Run `kubectl get pods -l app=kiada,rel=stable` to list matching Pods. To request six, run `kubectl scale rs kiada --replicas 6`; the controller creates another Pod. Scaling down causes excess Pods to be removed. You can also change the replica count by editing and reapplying the manifest. section 14.1.1 section 14.1.2 section 14.2.1
The ReplicaSet controller runs a reconciliation loop: it compares the number of associated Pods with `spec.replicas`, then creates Pods from the template or deletes excess Pods until the counts agree. Deleting a managed Pod triggers a replacement. An existing Pod whose labels match the selector can be adopted; creating an extra matching Pod can instead lead to its deletion. Names are not what determines membership. `READY` can be lower than `CURRENT`: an unready Pod still exists and counts toward the replica total. section 14.3.1 section 14.1.2 section 14.3.2
Changing the Pod template affects Pods created afterward; it does not update existing Pods. The selector cannot be changed in place. This is why workloads that need declarative updates are usually managed through a Deployment, which uses ReplicaSets underneath. If a Deployment owns a ReplicaSet, change the Deployment’s desired replica count: its controller may undo a direct change to the owned ReplicaSet. section 14.2.2 section 14.1 section 15.1.2
Deleting a ReplicaSet normally deletes its Pods through garbage collection. To remove the ReplicaSet but keep the Pods, use `kubectl delete rs kiada --cascade=orphan`. The preserved Pods lose that owner reference and can be adopted by a new ReplicaSet with a matching selector. section 14.4 section 14.4.2
