ReplicaSets

This article explains Kubernetes replication controllers and ReplicaSets, focusing on their roles in maintaining high availability and load balancing in clusters.

Introducing ReplicaSet¶

A ReplicaSet is a modern alternative to the replication controller, using an updated API version and some improvements. Here are the key differences:

1. API Version: Use apps/v1 for a ReplicaSet.
2. Selector: In addition to metadata and specification, a ReplicaSet requires a selector to explicitly determine which pods to manage. This is defined using matchLabels, which can also capture pods created before the ReplicaSet if they match the criteria.

Below is an example ReplicaSet definition:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: app01-replicaset
  labels: #(1)!
    app: app01
    type: front-end
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app01
      type: front-end
  template:
    metadata:
      name: app01-pod
      labels: #(2)!
        app: app01
        type: front-end
    spec:
      containers:
      - name: podinfo-container
        image: ghcr.io/stefanprodan/podinfo:latest

1. Labels du replicaSet
2. Labels des pods

Create the ReplicaSet with:

kubectl create -f replicaSet.yaml
replicaset.apps/app01-replicaset created

Then, verify its creation:

kubectl get replicaset
NAME               DESIRED   CURRENT   READY   AGE
app01-replicaset   3         3         3       5s

And view the associated pods:

kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
app01-replicaset-4dpd8   1/1     Running   0          17s
app01-replicaset-fzwmj   1/1     Running   0          17s
app01-replicaset-x9s8z   1/1     Running   0          17s

Labels and Selectors¶

Labels in Kubernetes are critical because they enable controllers, such as ReplicaSets, to identify and manage the appropriate pods within a large cluster. For example, if you deploy multiple instances of a front-end web application, assign a label (e.g., tier: front-end) to each pod. Then, use a selector to target those pods:

selector:
  matchLabels:
    tier: front-end

The pod definition should similarly include the label:

metadata:
  name: myapp-pod
  labels:
    tier: front-end

This label-selector mechanism ensures that the ReplicaSet precisely targets the intended pods and maintains the set number of replicas by replacing any failed pods.

Is the Template Section Required?¶

Even if three pods with matching labels already exist in your cluster, the template section in the ReplicaSet specification remains essential. It serves as the blueprint for creating new pods if any fail, ensuring the desired state is consistently maintained.

Scaling the ReplicaSet¶

Scaling a ReplicaSet involves adjusting the number of pod replicas. There are two methods to achieve this:

1. Update the Definition File

Modify the replicas value in your YAML file (e.g., change from 3 to 6) and update the ReplicaSet with:

kubectl replace -f replicaset-definition.yml

1. Use the kubectl scale Command

Scale directly from the command line:

kubectl scale --replicas=6 -f replicaset-definition.yml
kubectl scale replicaset app01-replicaset --replicas=6

Keep in mind that if you scale using the kubectl scale command, the YAML file still reflects the original number of replicas. To maintain consistency, it may be necessary to update the YAML file after scaling.

Common Commands Overview¶

Below is a quick reference table summarizing some useful commands when working with replication controllers and ReplicaSets: