Written by Nelson Koning
on September 15, 2026

Pods, Deployments, and Services: the beginner’s playbook for running and exposing apps on Kubernetes

Kubernetes can feel like a new language at first. If you focus on three things—Pods, Deployments, and Services—you’ll understand most everyday workflows: how code runs, how it’s kept healthy, and how it’s reached by other software or users. Below is a gentle tour, with a practical YAML sketch and a note about a recent change to watch for.

1) Pod — the “process” that Kubernetes schedules

Think of a Pod as a small stage where one (or rarely a couple) of containers perform together. A Pod groups containers that share networking and storage; Kubernetes schedules that Pod onto a node and manages its lifecycle. In practice most apps use one container per Pod, but sidecars (small helper containers) are common when they need to share the same network or volumes. This is the atomic unit you’ll see in commands like kubectl get pods. (kubernetes.io)

Why this matters: Pods are ephemeral. If a node dies, Kubernetes replaces the Pod elsewhere — which leads us to Deployments.

2) Deployment — the manager that keeps replicas running

A Deployment declares the desired state: “run three copies of image X, expose port Y.” It doesn’t create Pods once and forget them; the Deployment controller watches, and if any Pod dies or a node fails, it creates replacements to keep your declared replica count. Deployments also handle rolling updates and controlled rollbacks when you change the Pod template (for example, to a new container image). That behavior is why in production you usually create Deployments instead of creating naked Pods directly. (kubernetes.io)

A simple Deployment YAML (minimal):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: web
        image: nginx:alpine
        ports:
        - containerPort: 80

replicas: how many identical Pods you want.
selector/template labels: how the Deployment knows which Pods it manages.
rolling update: when you change the image, Kubernetes replaces Pods gradually so the app stays available. (kubernetes.io)

3) Service — a stable front door to changeable Pods

Because Pods come and go, you don’t want callers to hit a Pod IP directly. A Service provides a stable IP (and DNS name) and load-balances traffic to whatever Pods match its selector. Services are the abstraction that decouples “where my app runs” from “how other things reach it.” There are several Service types:

ClusterIP: reachable only inside the cluster (default).
NodePort: exposes the Service on a port on every node.
LoadBalancer: asks a cloud provider to provision an external load balancer. (kubernetes.io)

Minimal Service YAML to front the Deployment above:

apiVersion: v1
kind: Service
metadata:
  name: hello-svc
spec:
  selector:
    app: hello
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

This Service gives your three Pods a single stable name and virtual IP that other Pods (or an Ingress or LoadBalancer) can use. (kubernetes.io)

A recent note worth knowing (short and practical)

Kubernetes continues to evolve. A recent release series began formally deprecating the Service field .spec.externalIPs (deprecation started around v1.36), which previously let you pin external IP addresses directly to a Service. The project recommends using LoadBalancer services, NodePort in simple cases, or the newer Gateway API for more flexible/external traffic patterns. If you run or inherit clusters that use externalIPs, expect deprecation warnings and a migration plan over future releases. (kubernetes.io)

Why mention this? Services are simple in concept but have several ways to expose traffic to the outside world; recent changes reflect tighter security and clearer, more provider-aligned patterns.

Quick mental model (analogy)

Pod = single live performer on stage (the process).
Deployment = the troupe manager who hires three performers, replaces tired ones, and rehearses new material without interrupting the show.
Service = the theater’s box office and front door that always points ticket-holders to the active performers, even if the performers move to another theater.

Useful kubectl commands (cheat-sheet)

kubectl apply -f deployment.yaml — create/update a Deployment.
kubectl get pods, kubectl get deployments, kubectl get services — check what’s running.
kubectl describe pod — detailed state and events.

(These are the everyday commands you’ll use while building and observing the objects above; official docs have the full reference.) (kubernetes.io)

Closing note

Mastering these three objects (Pod, Deployment, Service) unlocks nearly everything you’ll do with Kubernetes day-to-day. They’re simple building blocks but they compose into resilient, upgradeable, and discoverable systems. If something breaks, you’ll often find the answer by asking three questions: Is the Pod running? Is the Deployment healthy? Is the Service pointing at the right Pods? The answers will point you to the next practical step.

Further reading from the official docs and approachable tutorials can help translate this high-level map into hands-on practice. (kubernetes.io)

← → Top