Deployments & Services: self-healing apps with stable addresses

Part 3 of Kubernetes from Zero. Bare Pods don't survive failures — let's fix that.

Deployments: the herder for your cattle

A Deployment wraps your Pod spec with two superpowers: replica management and rolling updates.

deployment.yaml

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

kubectl apply -f deployment.yaml
kubectl get pods            # three pods, named hello-xxxx
kubectl delete pod <one>    # watch a replacement appear in seconds

That self-healing you just watched? That's the desired-state machine from part 1 doing its job.

Rolling updates and rollbacks

kubectl set image deployment/hello web=nginx:1.28
kubectl rollout status deployment/hello   # new pods up, old pods drained
kubectl rollout undo deployment/hello     # v1 is back, no drama

Services: a stable address for moving targets

Pods come and go, and their IPs change every time. A Service gives a stable virtual IP + DNS name that load-balances across whatever Pods match its selector:

service.yaml

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

Inside the cluster, anything can now reach http://hello — regardless of which Pods are alive this minute.

Next in this series: ConfigMaps and Secrets — getting configuration out of your images.