Skip to main content

Pods and Deployments

What You Will Learn

  • What a Pod is and why it exists
  • What a Deployment is and how it manages Pods
  • How to read a Deployment YAML file

Pods: The Smallest Unit

A Pod is the smallest thing Kubernetes can run. It is one or more containers that share the same network and storage. Most of the time, a Pod runs exactly one container.

Think of a Pod like one game server instance. It runs, it has an IP address, players (or users) can connect to it. But it is temporary. If it crashes, it is gone. Kubernetes does not restart Pods on its own.

That is where Deployments come in.

Deployments: The Manager

A Deployment tells Kubernetes: "I want N copies of this Pod running at all times." If a Pod crashes, the Deployment creates a new one. If you update the container image, the Deployment rolls out the change gradually.

Concept What It Does Analogy
Pod Runs one container One game server instance
Deployment Manages N copies of a Pod The matchmaker that keeps N servers online

Reading a Deployment YAML

Here is a real Deployment, annotated line by line:

# apiVersion: which Kubernetes API to use
apiVersion: apps/v1

# kind: what type of object this is
kind: Deployment

# metadata: name and labels for this Deployment
metadata:
  name: my-app              # the name you'll use to refer to this
  namespace: hst-my-client  # which namespace it lives in

# spec: the desired state
spec:
  replicas: 2               # run 2 copies of the Pod

  # selector: how the Deployment finds its Pods
  selector:
    matchLabels:
      app: my-app            # Pods with this label belong to this Deployment

  # template: the Pod blueprint
  template:
    metadata:
      labels:
        app: my-app          # must match selector above
    spec:
      containers:
        - name: my-app                           # container name
          image: 123456789.dkr.ecr.eu-central-1.amazonaws.com/my-app:v1.0.0  # container image
          ports:
            - containerPort: 8080                # port the app listens on
          resources:
            requests:
              memory: "128Mi"                    # minimum memory guaranteed
              cpu: "100m"                        # minimum CPU (100 millicores = 0.1 CPU)
            limits:
              memory: "256Mi"                    # maximum memory allowed
              cpu: "500m"                        # maximum CPU allowed

Breaking It Down

The YAML has four sections:

Section Purpose
apiVersion + kind Tells Kubernetes what type of object to create
metadata Names the object and places it in a namespace
spec.replicas + spec.selector How many Pods and how to find them
spec.template The Pod blueprint: which image, ports, and resource limits

What Happens When You Apply This

When this YAML is applied to the cluster:

  1. Kubernetes creates 2 Pods from the template
  2. Each Pod runs the my-app:v1.0.0 container
  3. If one Pod crashes, Kubernetes creates a replacement
  4. If you change the image to v1.1.0 and reapply, Kubernetes does a rolling update (starts new Pods, then stops old ones)

Key Takeaways

  • A Pod runs one or more containers; a Deployment manages multiple Pods
  • Deployments ensure the right number of Pods are always running
  • The YAML structure is predictable: apiVersion, kind, metadata, spec

What Is Next

Next up: Services and Ingress where you will learn how traffic reaches your Pods from the outside world.

Back to top