Nimendra's Notes 🪴

Replicaset

3 min read

kubernetes kubernetes/kcna

‘Chapter 9. ReplicaSets’
—Brendan Burns, “Kubernetes: Up & Running”

Core Idea

A ReplicaSet is a cluster-wide pod manager: it keeps the desired types and numbers of pods running and reschedules them when nodes or networks fail.

  • The reconciliation loop is the mechanism: watch actual state, compare to desired, act.
  • Quarantining containers covers what happens when a pod is unhealthy.
  • Hands-on: create a ReplicaSet and autoscale it.

Replicaset acts as a cluster-wide Pod manager, ensuring that the right types and numbers of Pods are running at all times.

Pods managed by ReplicaSets are automatically rescheduled under certain failure conditions, such as node failures and network partitions.

Reconciliation Loop

The central concept behind a reconciliation loop is the notion of desired state versus observed or current state.

The reconciliation loop is constantly running, observing the current state of the world and taking action to try to make the observed state match the desired state

👉 K8s Principles > Declarative model and desired state

Important

Relationship between ReplicaSets and Pods is loosely coupled. Though ReplicaSets create and manage Pods, they do not own the Pods they create.
ReplicaSets use label queries to identify the set of Pods they should be managing.

Kubernetes and Reconciliation Patterns

Quarantining Containers

Pod-level health checks will automatically restart that Pod. But if your health checks are incomplete, a Pod can be misbehaving but still be part of the replicated set.

In these situations, while it would work to simply kill the Pod, that would leave your developers with only logs to debug the problem. Instead, you can modify the set of labels on the sick Pod.

Doing so will disassociate it from the ReplicaSet (and service) so that you can debug the Pod. The ReplicaSet controller will notice that a Pod is missing and create a new copy, but because the Pod is still running.

Create Replicaset

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: kuard
    version: "2"
  name: kuard
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kuard
      version: "2"
  template:
    metadata:
      labels:
        app: kuard
        version: "2"
    spec:
      containers:
        - name: kuard
          image: "gcr.io/kuar-demo/kuard-amd64:green"
kubectl describe rs kuard

Autoscaling a Replicaset

Kubernetes makes a distinction between horizontal scaling, which involves creating additional replicas of a Pod, and vertical scaling, which involves increasing the resources required for a particular Pod (such as increasing the CPU required for the Pod).

Autoscaling requires the presence of the metrics-server in your cluster. The metrics-server keeps track of metrics and provides an API for consuming metrics that HPA uses when making scaling decisions. Most inMetrics Serverinclude metrics-server by default.
👉 05306 [[Metrics Serveraling based on CPU usage

kubectl autoscale rs kuard --min=2 --max=5 --cpu-percent=80

This command creates an autoscaler that scales between two and five replicas with a CPU threshold of 80%.

to view, modify and delete this horizontalpodautoscalers resource.

kubectl get hpa

Backlinks

Graph View