Skip to content
Lucas Mauro

Type to search…

↑↓ to navigate
Esc

What is a Kubernetes ReplicaSet?

And does it differ from a Deployment?

kubernetes 1 min read

A ReplicaSet is a Kubernetes object that ensures a specified number of pod replicas are running at any given time. We rarely create ReplicaSets directly, though, and instead we rely on a Deployment, which creates and manages ReplicaSets on our behalf. When we apply a deployment, it spins up a ReplicaSet, which in turn creates the pods. When we update the deployment, it creates a new ReplicaSet and gradually shifts traffic to it.

ReplicaSets support set-based label selectors (e.g. app in (nginx, apache), env notin (dev)), which give us expressive rules for matching pods across different dimensions.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

This is what the relevant attributes mean:

  • replicas tells Kubernetes how many identical copies of the pod to maintain (three in this case);
  • selector.matchLabels defines which pods this ReplicaSet owns (it matches pods with the label app: nginx);
  • template is the pod template, identical to what we’d see in a Deployment.

When we create a deployment, Kubernetes does the following:

  1. Creates a ReplicaSet with a hash-based name (e.g. nginx-deployment-7fb94c8f4);
  2. The ReplicaSet creates the pods according to the template;
  3. When we update the deployment, it creates a new ReplicaSet and scales it out while scaling the old one in;
  4. Once the old ReplicaSet has zero pods, it remains in the cluster (but does nothing) until the deployment cleans it up or we roll back.

This indirection is what enables rolling updates: by controlling which ReplicaSet has active pods, the deployment can gradually shift from one version to another.

Honestly, I can’t even think of a scenario. If we find ourselves wanting to manage pod replicas, a deployment is almost always the better choice because it gives us update strategies and rollbacks on top of what a ReplicaSet already provides. The only reason to interact with a ReplicaSet directly is when debugging or inspecting a deployment’s internals.

Comments