ReplicaSet resources are Kubernetes controllers that help you run multiple pod replicas at a given time. They provide horizontal scaling for your container workloads, forming the basic building block of a horizontal scale set for your containers, a group of similar containers tied together to run as a unit.
ReplicaSet resources define the number of pod replicas to run at a given time. The Kubernetes controller then tries to maintain the replicas and recreates a pod if it goes down.
You should never use ReplicaSet resources on their own, but instead, they should act as a backend to a Deployment resource.
For understanding, however, let’s look at an example. To access the resources for this section, cd into the following:
$ cd ~/modern-devops/ch6/deployments/
The ReplicaSet resource manifest, nginx-replica-set.yaml, looks like this:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: nginx
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
The resource manifest includes apiVersion and kind, as with any other resource. It also contains a metadata section that defines the resource’s name and labels attributes, similar to any other Kubernetes resource.
The spec section contains the following attributes:
- replicas: This defines the number of pod replicas matched by the selector to run at a given time.
- selector: This defines the basis on which theReplicaSet resource will include pods.
- selector.matchLabels: This defines labels and their values to select pods. Therefore,
the ReplicaSet resource will select any pod with the app: nginx label.
- template: This is an optional section that you can use to define the pod template. This section’s contents are very similar to defining a pod, except it lacks the name attribute, as the ReplicaSet resource will generate dynamic names for pods. If you don’t include this section, the ReplicaSet resource will still try to acquire existing pods with matching labels. However, it cannot create new pods because of the missing template. Therefore, it is best practice to specify a template for a ReplicaSet resource.
Let’s go ahead and apply this manifest to see what we get:
$ kubectl apply -f nginx-replica-set.yaml
Now, let’s run the following command to list the ReplicaSet resources:
$ kubectl get replicaset
NAME
DESIRED CURRENT READY AGE
nginx 3
3
0
9s
Right—so, we see that there are three desired replicas. Currently, 3 replicas are running, but 0 are ready. Let’s wait for a while and then rerun the following command:
$ kubectl get replicaset
NAME
DESIRED
CURRENT READY AGE
nginx 3
3
3
1m10s
And now, we see 3 ready pods that are awaiting a connection. Now, let’s list the pods and see what the
ReplicaSet resource has done behind the scenes using the following command:
| $ kubectl get | pod | |||
| NAME | READY | STATUS | RESTARTS | AGE |
| nginx-6qr9j | 1/1 | Running | 0 | 1m32s |
| nginx-7hkqv | 1/1 | Running | 0 | 1m32s |
| nginx-9kvkj | 1/1 | Running | 0 | 1m32s |
There are three nginx pods, each with a name that starts with nginx but ends with a random hash. The ReplicaSet resource has appended a random hash to generate unique pods at the end of the ReplicaSet resource name. Yes—the name of every resource of a particular kind in Kubernetes should be unique.
Let’s go ahead and use the following command to delete one of the pods from the ReplicaSet resource and see what we get:
$ kubectl delete pod nginx-9kvkj && kubectl get pod
| pod “nginx-9kvkj” deleted | ||||
| NAME | READY | STATUS | RESTARTS | AGE |
| nginx-6qr9j | 1/1 | Running | 0 | 8m34s |
| nginx-7hkqv | 1/1 | Running | 0 | 8m34s |
| nginx-9xbdf | 1/1 | Running | 0 | 5s |
We see that even though we deleted the nginx-9kvkj pod, the ReplicaSet resource has replaced it with a new pod, nginx-9xbdf. That is how ReplicaSet resources work.
You can delete a ReplicaSet resource just like any other Kubernetes resource. You can run the kubectl delete replicaset <ReplicaSet name> command for an imperative approach or use kubectl delete -f <manifest_file> for a declarative approach.
Let’s use the former approach and delete the ReplicaSet resource by using the following command:
$ kubectl delete replicaset nginx
Let’s check whether the ReplicaSet resource has been deleted by running the following command:
$ kubectl get replicaset
No resources found in default namespace.
We don’t have anything in the default namespace. This means thatthe ReplicaSet resource is deleted.
As we discussed, ReplicaSet resources should not be used on their own but should instead be the backend of Deployment resources. Let’s now look at Kubernetes Deployment resources.
