Kubernetes Fundamentals: Pods, Deployments, and Services Explained

If Docker answers "how do I package my app?", Kubernetes answers "how do I run hundreds of these reliably, across many machines, without babysitting them?" It's the industry-standard container orchestrator, and this Kubernetes for beginners guide breaks down the core objects that make everything else about it click faster.

Why orchestration exists

Running one container on one server is easy. Running a dozen services, each needing multiple replicas for reliability and spread across many machines, with automatic recovery when something crashes, load balancing, and zero-downtime rolling updates, is a fundamentally different problem. Kubernetes exists to solve it declaratively: you describe the desired state, and Kubernetes continuously works to make reality match it.

The building blocks

Pods

A Pod, not a container, is the smallest deployable unit in Kubernetes. Most of the time a Pod wraps exactly one container, but it can hold multiple tightly-coupled containers that share networking and storage. Pods are ephemeral: Kubernetes expects them to die and be replaced, not to be nursed back to health individually.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
    - name: my-app
      image: my-app:latest
      ports:
        - containerPort: 3000

Deployments

You almost never create Pods directly in production. Instead, you create a Deployment, which manages a set of identical Pods (via an intermediate object called a ReplicaSet) and handles rolling updates.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-app:latest

This says: "always keep 3 replicas of my-app running." If a Pod crashes, the Deployment's controller notices and creates a replacement automatically. No human intervention needed. Update the image tag and reapply, and Kubernetes performs a rolling update, replacing old Pods with new ones gradually so the app stays available throughout.

Services

Pods are constantly being created and destroyed, each getting a new internal IP address. You can't point other parts of your system directly at a Pod's IP; it won't stay valid. A Service solves this by giving a stable network identity to a group of Pods (matched by label), and load-balancing traffic across whichever Pods currently exist.

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 3000
  type: ClusterIP

Other components in the cluster can now reach your app at my-app-service, regardless of which specific Pods are currently backing it.

ConfigMaps and Secrets

Hardcoding configuration into container images defeats the purpose of building once and deploying everywhere. ConfigMaps hold non-sensitive configuration (feature flags, URLs), while Secrets hold sensitive data (API keys, credentials), and both can be injected into Pods as environment variables or mounted files, separate from the image itself.

Namespaces

A namespace is a way to partition a single cluster into multiple virtual clusters, useful for separating environments (dev, staging, prod) or teams, without needing separate physical infrastructure.

Putting it together

A typical request flow looks like this: a Service receives traffic and forwards it to one of the healthy Pods matching its selector. Those Pods are managed by a Deployment, which constantly compares the actual number of running Pods against the desired replica count, creating or destroying Pods as needed to reconcile the difference. Configuration is pulled from ConfigMaps and Secrets rather than baked in, so the same image can run identically across namespaces.

kubectl: your daily driver

# Apply a manifest file (create or update resources)
kubectl apply -f deployment.yaml

# List running pods
kubectl get pods

# Stream logs from a pod
kubectl logs -f my-app-pod

# Get a shell inside a running container
kubectl exec -it my-app-pod -- /bin/sh

# Scale a deployment
kubectl scale deployment my-app --replicas=5

A common interview trip-up: Deployment vs. StatefulSet

Deployments assume Pods are interchangeable: any replica can serve any request, and none of them need a stable identity. That's fine for stateless web apps. Databases and other stateful systems need each replica to keep a stable network identity and its own dedicated storage across restarts. That's what a StatefulSet provides.

Where to go next

Kubernetes has a steep initial learning curve, but the core loop, desired state described declaratively with controllers reconciling reality toward it, repeats throughout the ecosystem (Helm charts, operators, GitOps tools). Once Pods, Deployments, and Services feel natural, test yourself with the Kubernetes quiz on OpsQuiz.