Pods ReplicaSets and Deployments in Kubernetes

Pods run containers; ReplicaSets maintain three desired Pods; Deployments manage ReplicaSets through failures and updates.

This web Pod contains one web container, which runs one application replica. When the Deployment requests three replicas, Kubernetes uses three separate Pods; it doesn't place three copies of the container inside this one Pod.

The web ReplicaSet’s desired count is three. It continually compares that target with the actual number of web Pods in the cluster, creating or removing Pods as needed to bring the count back to three.

The web Deployment manages the web ReplicaSet, and that ReplicaSet maintains three web Pods at the requested count. Each layer has a distinct job.

Let's think this through. In this three-replica application, which resource creates a replacement when one web Pod disappears? A: The missing Pod. B: The ReplicaSet. C: The Deployment directly. Choose an answer, or just think it through. I'll explain in a moment.

The answer is B: The ReplicaSet. The ReplicaSet compares the remaining Pod count with the requested three and creates a replacement. The Deployment manages the ReplicaSet, but does not directly create the replacement Pod.

When web Pod 3 disappears, the ReplicaSet sees only two Pods against the requested three, so it creates a new web Pod. It replaces the missing Pod, not repairs it. The Deployment manages the ReplicaSet, and the ReplicaSet maintains the Pods.

When the web Pod template changes, web Deploy manages a new ReplicaSet alongside the old one. Each ReplicaSet maintains its own Pods, letting the Deployment transition between versions. The total Pod count during that rollout can vary with the rollout settings.

Pods run containers; ReplicaSets reconcile a desired Pod count; Deployments manage ReplicaSets for declarative updates and ongoing control. At three replicas, a missing Pod is replaced by its ReplicaSet; the Deployment manages updates.