ReplicaSets for Pod Availability

Ensuring the availability and resilience of Pods in Kubernetes is achieved through a dedicated controller called the ReplicaSet. This controller's primary job is to maintain a stable set of running Pods by ensuring that a specified number of Pod replicas are running at any given time. This capability provides a foundational layer of self-healing and scalability for applications.

A ReplicaSet works by continuously monitoring the state of the cluster. If the number of Pods it manages drops below the desired count, perhaps due to a node failure or accidental deletion, the ReplicaSet's control loop will automatically create new Pods to compensate. Conversely, if there are too many Pods, it will terminate the excess ones to match the desired state.

The Structure of a ReplicaSet Manifest

Like other Kubernetes objects, a ReplicaSet is defined using a YAML manifest. Its definition consists of three main parts in its spec: the number of replicas, a selector to identify the Pods it manages, and a template to create new Pods when needed.

Let's examine a typical ReplicaSet manifest:

# myapp-replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-rs
  labels:
    app: myapp
spec:
  # 1. Desired number of Pods
  replicas: 3

  # 2. Selector to identify managed Pods
  selector:
    matchLabels:
      app: myapp-pod

  # 3. Template for creating new Pods
  template:
    metadata:
      labels:
        app: myapp-pod
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.21.6

1. replicas: This simple integer field declares the desired state. Here, the ReplicaSet is configured to maintain exactly three Pods. You can change this value at any time to scale your application up or down.

2. selector: This field defines how the ReplicaSet finds which Pods to manage. It uses labels to create this link. In this example, the ReplicaSet will monitor any Pod in its namespace that has the label app: myapp-pod. This decoupling is powerful; a ReplicaSet can manage Pods it didn't create, as long as their labels match.

3. template: This section is the blueprint for new Pods. When the ReplicaSet needs to create a Pod to meet the replicas count, it uses this template. The template contains its own metadata (including labels) and a spec (including the container definitions), just like a standalone Pod manifest.

It is a strict requirement that the labels defined in spec.template.metadata.labels match the labels in spec.selector.matchLabels. If they do not match, the Kubernetes API will reject the ReplicaSet. This prevents a situation where a controller creates Pods that it cannot subsequently find and manage.

The Reconciliation Loop in Action

The ReplicaSet controller continuously runs a process called a reconciliation loop. This loop compares the desired state (from the replicas field) with the actual state (the number of running Pods matching the selector) and takes action to correct any discrepancies.

The ReplicaSet's reconciliation loop ensures the number of active Pods always matches the desired replica count.

Creating and Inspecting a ReplicaSet

You can create the ReplicaSet using the manifest file with kubectl apply.

$ kubectl apply -f myapp-replicaset.yaml
replicaset.apps/myapp-rs created

After creation, you can inspect its status with kubectl get rs.

$ kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
myapp-rs   3         3         3       12s

The output shows that the DESIRED state is 3, the CURRENT number of Pods is 3, and all 3 are READY to serve traffic.

To see the Pods managed by this ReplicaSet, you can use the selector's label:

$ kubectl get pods -l app=myapp-pod
NAME             READY   STATUS    RESTARTS   AGE
myapp-rs-5x2kz   1/1     Running   0          45s
myapp-rs-h7j8p   1/1     Running   0          45s
myapp-rs-w9n4f   1/1     Running   0          45s

Notice that the Pod names are generated by appending a random hash to the ReplicaSet's name, ensuring uniqueness.

Demonstrating Self-Healing

The true value of a ReplicaSet is its ability to automatically recover from failures. To see this in action, manually delete one of the Pods:

# Get the name of a Pod to delete
$ POD_NAME=$(kubectl get pods -l app=myapp-pod -o jsonpath='{.items[0].metadata.name}')

# Delete the Pod
$ kubectl delete pod $POD_NAME
pod "myapp-rs-5x2kz" deleted

Now, immediately check the Pods again. You might need to run the command quickly to see the full cycle.

$ kubectl get pods -l app=myapp-pod
NAME             READY   STATUS              RESTARTS   AGE
myapp-rs-h7j8p   1/1     Running             0          2m10s
myapp-rs-w9n4f   1/1     Running             0          2m10s
myapp-rs-z1b3x   0/1     ContainerCreating   0          2s

The ReplicaSet detected that only two Pods were running, falling short of its desired state of three. It immediately used its template to create a new Pod (myapp-rs-z1b3x) to replace the one that was terminated. This self-healing capability is fundamental to running resilient applications on Kubernetes.

The Modern Role of ReplicaSets

While ReplicaSets are effective for maintaining a stable replica count, they are considered a lower-level building block in modern Kubernetes workflows. They do not have a built-in mechanism for performing application updates, such as changing a container image version without downtime.

For this reason, you will rarely define a ReplicaSet directly in your daily work. Instead, you will use a higher-level controller called a Deployment, which manages ReplicaSets on your behalf to orchestrate sophisticated updates and rollbacks. We will cover Deployments in the next section.