Managing Pods with ReplicaSets
The job of a ReplicaSet is to maintain a stable number of Pod copies. The term used to represents the number of Pods is replicas. The ReplicaSet controller guarantees that a specified number of identical Pods (or replicas) is running . The number of replicas is controlled by the
replicas field in the Pod resource definition.
Let's say you start with a single Pod, and you want to scale to five Pods. The single Pod is the current state in the cluster, and the five Pods is the desired state. The ReplicaSet controller uses the current and desired state and goes to create four more Pods to meet the desired state (five pods). The ReplicaSet also keeps an eye on the Pods. If you scale the Pod up or down (add a Pod replica or remove a Pod replica), the ReplicaSet does the necessary to meet the desired number of replicas. To create the Pods, the ReplicaSet uses the Pod template that's part of the resource definition.
But how does ReplicaSet know which Pods to watch and control?
To explain that, let's look at how the ReplicaSet gets defined:
apiVersion: apps/v1 kind: ReplicaSet metadata: name: hello labels: app.kubernetes.io/name: hello spec: replicas: 5 selector: matchLabels: app.kubernetes.io/name: hello template: metadata: labels: app.kubernetes.io/name: hello spec: containers: - name: hello-container image: busybox command: ['sh', '-c', 'echo Hello from my container! && sleep 3600']
Every Pod that's created by a ReplicaSet has a field called
metadata.ownerReferences. This field specifies which ReplicaSet owns the Pod. When you delete a Pod, the ReplicaSet that owns it will know about it and act accordingly (i.e., re-creates the Pod).
The ReplicaSet also uses the
selector object and
matchLabel to check for any new Pods that it might own. If there's a new Pod that matches the selector labels and it doesn't have an owner reference, or the owner is not a controller (i.e., if we manually created a pod), the ReplicaSet will take it over and start controlling it.