Kubernetes Fundamentals: Pods, Deployments, Services Kubernetes Fundamentals: Pods, Deployments, Services

Kubernetes has a reputation for being overwhelming, but the core of it rests on three objects: pods, deployments, and services. Learn these Kubernetes fundamentals and most of the rest of the system suddenly makes sense.

This guide is hands-on. You will spin up a real cluster on your laptop with kind, deploy an app the naive way, watch it fail to self-heal, and then fix it the Kubernetes way. By the end you will understand not just what pods, deployments, and services are, but why each one exists.

Set Up a Local Cluster with kind

kind runs a Kubernetes cluster inside Docker containers — perfect for learning the fundamentals without a cloud bill. You need Docker installed, then:

# macOS / Linux (Homebrew)
brew install kind kubectl

# or grab the binary directly
curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64
chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind

kind create cluster --name learn
kubectl get nodes

If kubectl get nodes shows a node in Ready state, you have a working cluster. Every command in this article runs against it. If you want a refresher on the commands themselves, keep the kubectl cheat sheet open in another tab.

Pods: The Smallest Deployable Unit

A pod wraps one or more containers that share a network and storage. You rarely create pods directly, but doing it once shows why you shouldn’t. Create a bare pod:

kubectl run web --image=nginx
kubectl get pods -o wide

Now simulate a failure by deleting it:

kubectl delete pod web
kubectl get pods

The pod is gone. Nothing brings it back. That is the key lesson of this section: a bare pod has no self-healing. If its node crashes or someone deletes it, your app stays down. Pods are the unit of execution, not the unit you manage.

Deployments: Self-Healing and Scaling

A Deployment is the object you actually use. It manages a ReplicaSet, which guarantees a desired number of identical pods are always running. Write your first manifest:

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

Apply it and watch three pods appear:

kubectl apply -f web-deploy.yaml
kubectl get pods -l app=web

Now delete one pod and watch the difference:

kubectl delete pod -l app=web --field-selector=status.phase=Running | head -1
kubectl get pods -l app=web

A replacement pod appears within seconds. The Deployment noticed reality (2 pods) drifted from desired state (3 pods) and reconciled it. That reconciliation loop is the heart of Kubernetes.

    graph TD
  A[Deployment: replicas=3] --> B[ReplicaSet]
  B --> C[Pod 1]
  B --> D[Pod 2]
  B --> E[Pod 3]
  E -. deleted .-> F[ReplicaSet creates a replacement]
  F --> G[Pod 3 - new]
  

Scaling is a one-liner — no manifest edit required for a quick change:

kubectl scale deploy/web --replicas=5
kubectl rollout status deploy/web

Services: A Stable Address for Ephemeral Pods

Your three pods each have their own IP, and those IPs change constantly. A client cannot chase them. A Service solves this by giving the set of pods one stable virtual IP and DNS name, then load-balancing requests across whichever pods currently match its label selector.

# web-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web        # routes to every pod labeled app=web
  ports:
  - port: 80
    targetPort: 80

kubectl apply -f web-svc.yaml
kubectl get svc web
kubectl get endpoints web      # the pod IPs the Service is routing to

The endpoints output is the magic: it lists the live pod IPs behind the stable Service IP, updated automatically as pods come and go. Test it from your laptop with a port-forward:

kubectl port-forward svc/web 8080:80
# now visit http://localhost:8080

How the Three Objects Fit Together

Put the fundamentals in one sentence: a Deployment keeps the right number of pods running, and a Service gives those pods a stable front door. Everything else in Kubernetes — ConfigMaps, Ingress, autoscaling, probes — builds on this spine.

Common Beginner Pitfalls

• Creating bare pods. Always use a Deployment so your workload self-heals. Bare pods are for one-off debugging only.
• Mismatched labels and selectors. The Deployment’s template.metadata.labels must match both its own selector.matchLabels and the Service’s selector.
• Expecting kubectl edit to stick. Editing a live object managed by apply gets reverted on the next deploy. Change the manifest in Git instead.
• A pod stuck in CrashLoopBackOff. That means the container starts and dies repeatedly. It deserves its own playbook — see how to fix Kubernetes CrashLoopBackOff.

Where to Go Next

Once the local fundamentals click, the natural next step is a real cloud cluster. Moving from kind to a managed control plane is straightforward with EKS setup on AWS using eksctl. From there, autoscaling, Ingress, and Helm are incremental additions on top of the same pod-deployment-service spine.

References and Further Reading

• Kubernetes Authors. Kubernetes Concepts. Kubernetes Documentation.
• Kubernetes Authors. Deployments. Kubernetes Documentation.
• Kubernetes Authors. Service. Kubernetes Documentation.
• The kind Authors. kind — Kubernetes IN Docker. kind Documentation.
• Burns, B., Beda, J., Hightower, K., & Evenson, L. (2022). Kubernetes: Up and Running, 3rd Edition. O’Reilly Media.