Deployments, Services and ConfigMaps

A pod on its own is fragile — if it dies, nothing brings it back. That's why we almost never create pods directly. Instead we use Deployments, Services and ConfigMaps.

Deployment — "keep N copies alive"

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

Kubernetes will always try to keep 3 pods running. Kill one, another appears in seconds.

Service — a stable address

Pods get new IPs every time they restart. A Service gives them a name that never changes.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 80

Now any other pod can reach the web pods at http://web:80.

ConfigMap — configuration you can change without rebuilding

apiVersion: v1
kind: ConfigMap
metadata: { name: web-config }
data:
  WELCOME_MESSAGE: "Hello, students!"

Inject it into your pod as an environment variable:

env:
  - name: WELCOME_MESSAGE
    valueFrom: { configMapKeyRef: { name: web-config, key: WELCOME_MESSAGE } }

The mental model

                     Client
                       |
                       v
                +-------------+
                |   Service   |  <-- stable DNS name
                +------+------+
                       |
        +--------+-----+-----+--------+
        v        v           v        v
      Pod A    Pod B       Pod C   (managed by Deployment)

Real-world example

Your company's checkout API needs to be always-on. Wrap it in a Deployment with 5 replicas, put a Service in front, store the payment provider URL in a ConfigMap. If one pod crashes at 3am, Kubernetes replaces it — you sleep through the night.