Kubernetes Replicaset

Kubernetes Replicaset

---

Why we need replicaset

So far, you’ve deployed workloads by creating Pod objects directly. In a production cluster, you might need to deploy dozens or even hundreds of copies of the same Pod, so creating and managing those Pods would be difficult. Fortunately, in Kubernetes, you can automate the creation and management of Pod replicas with the ReplicaSet object.

What is the replicaset

A ReplicaSet represents a group of Pod replicas (exact copies of a Pod). Instead of creating Pods one by one, you can create a ReplicaSet object in which you specify a Pod template and the desired number of replicas, and then have Kubernetes create the Pods, as shown in the following figure.



The ReplicaSet allows you to manage the Pods as a single unit, but that’s about it. If you want to expose these Pods as one, you still need a Service object(You will learn service object later of this book). As you can see in the following figure, each set of Pods that provides a particular service usually needs both a ReplicaSet and a Service object.

The ReplicaSet’s label selector and Pod labels determine which Pods belong to the ReplicaSet. As shown in the following figure, a ReplicaSet only cares about the Pods that match its label selector and ignores the rest.

Based on the information so far, you might think that you only use a ReplicaSet if you want to create multiple copies of a Pod, but that’s not the case. Even if you only need to create a single Pod, it’s better to do it through a ReplicaSet than to create it directly, because the ReplicaSet ensures that the Pod is always there to do its job.

Imagine creating a Pod directly for an important service, and then the node running the Pod fails when you’re not there. Your service is down until you recreate the Pod. If you’d deployed the Pod via a ReplicaSet, it would automatically recreate the Pod. It’s clearly better to create Pods via a ReplicaSet than directly.

Creating a ReplicaSet

Let’s start by creating the ReplicaSet object for multiple kubia Pods. Before you create the manifest, let’s look at what fields you need to specify in the spec section.

Introducing the ReplicaSet spec

A ReplicaSet is a relatively simple object. The following table explains the three key fields you specify in the ReplicaSet’s spec section.

Field	name	Description
replicas	The desired number of replicas.	When you create the ReplicaSet object, Kubernetes creates this many Pods from the Pod template. It keeps this number of Pods until you delete the ReplicaSet.
selector	The label selector contains either a map of labels in the matchLabels subfield or a list of label selector requirements in the matchExpressions subfield.	Pods that match the label selector are considered part of this ReplicaSet.
templat	The Pod template for the ReplicaSet’s Pods.	When a new Pod needs to be created, the object is created using this template.

The selector and template fields are required, but you can omit the replicas field. If you do, a single replica is created.

Creating a ReplicaSet object manifest

Create a ReplicaSet object manifest for the kubia Pods. The following listing shows what it looks like. You can find the manifest in the file rs-kubia-ssl.yaml.

root@AlexRampUpVM-01:~# cat rs-kubia-ssl.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kubia
      rel: stable
  template:
    metadata:
      labels:
        app: kubia
        rel: stable
    spec:
      containers:
      - name: kubia
        image: luksa/kubia:1.0
        ports:
        - name: http
          containerPort: 8080
      - name: envoy
        image: luksa/kubia-ssl-proxy:1.0
        ports:
        - name: https
          containerPort: 8443
        - name: admin
          containerPort: 9901

ReplicaSets are part of the apps API group, version v1. As explained in the previous table, the replicas field specifies that this ReplicaSet should create three copies of the Pod using the template in the template field.

You’ll notice that the labels in the Pod template match those in the selector field. If they don’t, the Kubernetes API will reject the ReplicaSet because the Pods created with the template won’t count against the desired number of replicas, which would result in the creation of an infinite number of Pods.

Did you notice that there’s no Pod name in the template? That’s because the Pod names are generated from the ReplicaSet name.

The rest of the template exactly matches the manifests of the kubia Pods you created in the previous chapters. To create the ReplicaSet, you use the kubectl apply command that you’ve used many times before. The command is as follows:

root@AlexRampUpVM-01:~# kubectl apply -f rs-kubia-ssl.yaml
replicaset.apps/kubia created

Inspecting a ReplicaSet and its Pods

Check basic information about a ReplicaSet

To display basic information about the ReplicaSet you just created, use the kubectl get command like so:

root@AlexRampUpVM-01:~# kubectl get rs kubia -n default
NAME    DESIRED   CURRENT   READY   AGE
kubia   3         3         3       2m49s

The output of the command shows the desired number of replicas, the current number of replicas, and the number of replicas that are considered ready as reported by their readiness probes.

Check all the information about a ReplicaSet

To see all the information about a ReplicaSet, use the kubectl describe command:

root@AlexRampUpVM-01:~# kubectl describe rs kubia -n default

The output shows the label selector used in the ReplicaSet, the number of Pods and their status, and the full template used to create those Pods.

Listing the Pods in a ReplicaSet

Kubectl doesn’t provide a direct way to list the Pods in a ReplicaSet, but you can take the ReplicaSet’s label selector and use it in the kubectl get pods command as follows:

root@AlexRampUpVM-01:~# kubectl get po -l app=kubia,rel=stable
NAME          READY   STATUS    RESTARTS   AGE
kubia-cks7q   2/2     Running   0          3m43s
kubia-j4b7g   2/2     Running   0          3m43s
kubia-vpv2r   2/2     Running   0          3m43s

Scaling a ReplicaSet using the kubectl scale command

In the ReplicaSet, you’ve set the desired number of replicas to five, and that’s the number of Pods currently owned by the ReplicaSet. However, you can now update the ReplicaSet object to change this number. Let’s increase the number of kubia Pods to six. To do this, execute the following command:

root@AlexRampUpVM-01:~# kubectl scale rs kubia --replicas 4
replicaset.apps/kubia scaled

Now check the ReplicaSet again to confirm that it now has six Pods:

root@AlexRampUpVM-01:~# kubectl get rs kubia
NAME    DESIRED   CURRENT   READY   AGE
kubia   4         4         4       4m27s

Deleting a ReplicaSet and all associated Pods

To delete a ReplicaSet and all Pods it controls, run the following command:

root@AlexRampUpVM-01:~# kubectl delete rs kubia -n default
replicaset.apps "kubia" deleted

Summary

In this chapter, you learned that:

• A ReplicaSet represents a group of identical Pods that you manage as a unit. In the ReplicaSet, you specify a Pod template, the desired number of replicas, and a label selector.
• Almost all Kubernetes API object types have an associated controller that processes objects of that type. In each controller, a reconciliation control loop runs that constantly reconciles the actual state with the desired state.
• The ReplicaSet controller ensures that the actual number of Pods always matches the desired number specified in the ReplicaSet. When these two numbers diverge, the controller immediately reconciles them by creating or deleting Pod objects.
• You can change the number of replicas you want at any time and the controller will take the necessary steps to honor your request. However, when you update the Pod template, the controller won’t update the existing Pods.
• Pods created by a ReplicaSet are owned by that ReplicaSet. If you delete the owner, the dependents are deleted by the garbage collector, but you can tell kubectl to orphan them instead.

However, as useful as ReplicaSets can be, they don’t provide everything you need to run a workload long-term. At some point, you’ll want to upgrade the workload to a newer version, and that’s where ReplicaSets fall short. For this reason, applications are typically deployed not through ReplicaSets, but through Deployments that let you update them declaratively. This begs the question of why you need to learn about ReplicaSets if you’re not going to use them. The reason is that most of the functionality that a Deployment provides is provided by the ReplicaSets that Kubernetes creates underneath it. Deployments take care of updates, but everything else is handled by the underlying ReplicaSets. Therefore, it’s important to understand what they do and how.

In the next chapter, you’ll replace the ReplicaSet with a Deployment object.