Pods, Deployments and ReplicaSets

Now the objects. Kubernetes runs your containers inside pods, but you almost never create pods directly — you create a Deployment, which keeps a set of pods running for you. Understanding pods, Deployments, and the ReplicaSet in between is the core of running an app on Kubernetes. This lesson builds a real Deployment for the greetings app and applies it to a live cluster.

Pods: the smallest unit

A pod is the smallest thing Kubernetes runs — a wrapper around one container (occasionally a few tightly coupled containers that must share a network and storage). Your app container runs inside a pod. Each pod gets its own IP address and is scheduled onto a node.

The critical fact about pods: they are disposable and ephemeral. A pod can be killed at any time — a node dies, you deploy a new version, the scheduler rebalances — and it is simply replaced by a new pod with a new name and new IP. You never grow attached to a specific pod; you care that the right number of healthy pods exist. This is the container "cattle, not pets" idea from the volumes lesson, at cluster scale — and it is why you do not create pods by hand.

Why you don't create pods directly

If you created a bare pod and it crashed, nothing would bring it back — a bare pod has no supervisor. You want "keep 3 of these running, always", and that is what a controller does. So instead of pods, you create a Deployment, and the Deployment manages the pods for you.

A Deployment declares: "run this many replicas of this pod template, keep them healthy, and manage updates to them." It is the object you use to run a stateless application, and it is where the desired-state magic (the previous lesson) lives: you say "3 replicas", and the Deployment ensures 3 exist, recreating any that die.

The greetings Deployment

Here is the real Deployment for the greetings app, applied and verified on a live cluster:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: greetings
spec:
  replicas: 2                 # desired state: keep 2 pods running
  selector:
    matchLabels:
      app: greetings          # this Deployment manages pods with this label
  template:                   # the pod template — what each replica looks like
    metadata:
      labels:
        app: greetings        # pods get this label (matched by the selector above)
    spec:
      containers:
        - name: greetings
          image: greetings:1.0
          ports:
            - containerPort: 3000

Read the structure:

• replicas: 2 — the desired number of pods.
• selector.matchLabels — how the Deployment identifies its pods (by the label app: greetings).
• template — the blueprint for each pod: its labels and its container(s). Every replica is created from this template.

Apply it and watch:

kubectl apply -f deployment.yaml    # declare the desired state
kubectl get pods -l app=greetings   # two pods, Running

The verified result is two pods running (greetings-b5d7b9fd9-4m8kq, greetings-b5d7b9fd9-brz5n) — created from the template, each a Running instance of your image. kubectl apply is the declarative verb: it makes the cluster match the file, creating what is missing.

Labels and selectors: the glue

Notice the label app: greetings appears twice — on the pod template and in the Deployment's selector. This is not redundant; labels and selectors are how Kubernetes objects find each other. The Deployment manages "pods with label app: greetings"; later, a Service will route to "pods with label app: greetings". Labels are simple key-value tags on objects, and selectors match them. This loose coupling — objects find each other by label, not by hard reference — is a core Kubernetes pattern and worth internalising early: you will use the same label to connect the Service to these pods in two lessons' time.

Deployment → ReplicaSet → Pods

One layer to know about, because you will see it in kubectl get all: a Deployment does not manage pods directly. It creates a ReplicaSet, and the ReplicaSet keeps the right number of pods. The chain is:

Deployment → ReplicaSet → Pods.

• The ReplicaSet is the controller that actually maintains "N pods with this label exist" — the self-healing you will see next.
• The Deployment manages ReplicaSets, and its job over the ReplicaSet is updates: when you change the image, the Deployment creates a new ReplicaSet (with the new version) and scales it up while scaling the old one down — that is the rolling update (the scaling-and-health lesson).

You rarely touch ReplicaSets directly — you work with the Deployment — but knowing the chain explains what you see when you inspect the cluster, and why a Deployment can do rolling updates (it has two ReplicaSets during one). The pod name greetings-b5d7b9fd9-4m8kq even shows it: greetings (Deployment) + b5d7b9fd9 (ReplicaSet) + 4m8kq (pod).

Check your work

Pod = the smallest unit Kubernetes runs — a wrapper around your container, with its own IP, scheduled onto a node. Pods are disposable/ephemeral: killed and replaced (new name, new IP) any time — care about the count of healthy pods, not a specific one. So you don't create pods by hand (a bare pod has no supervisor).

Deployment = the object to run a stateless app: declares "N replicas of this pod template, kept healthy, updates managed". Desired state lives here — say replicas: 2 and it keeps 2, recreating any that die. Fields: replicas, selector.matchLabels (which pods it owns), template (the pod blueprint). kubectl apply -f makes the cluster match the file.

Labels/selectors = the glue: objects find each other by matching label key-values (the Deployment's selector matches the template's labels; a Service will match the same). Loose coupling by label, not hard reference — a core pattern.

Chain: Deployment → ReplicaSet → Pods. The ReplicaSet maintains "N pods exist" (self-healing); the Deployment manages ReplicaSets to do updates (new ReplicaSet up, old down = rolling update). You work with the Deployment; the pod name shows all three.

Practice

1. Explain why pods are disposable and why you never create them directly.
2. Write a Deployment for the greetings app with 2 replicas; kubectl apply it and kubectl get pods.
3. Point out where the desired replica count and the pod template are in your Deployment YAML.
4. Explain the role of the app: greetings label appearing in both the selector and the template.
5. Describe the Deployment → ReplicaSet → Pods chain and what each layer is responsible for.
6. Run kubectl get all and identify the Deployment, its ReplicaSet, and the pods.

Official documentation

• Kubernetes — Pods — What a pod is and how it is run.
• Kubernetes — Deployments — Declaring replicas and managing updates.
• Kubernetes — Labels and selectors — How objects find each other.

Next: Services and Ingress — how traffic reaches a pod.