Week 11: Kubernetes Fundamentals

1. Pods, Deployments & Services

A Pod is the smallest deployable unit in Kubernetes — not a container. A Pod wraps one or more containers that share a network namespace (one IP address, one localhost) and can share storage volumes. In practice you'll run one container per Pod almost always, with a second "sidecar" container only for things tightly coupled to the main one, like a log shipper.

apiVersion: v1
kind: Pod
metadata:
  name: web-single
  labels:
    app: web
spec:
  containers:
    - name: web
      image: ghcr.io/acme/web-app:1.4.0
      ports:
        - containerPort: 8080

You'll almost never create a bare Pod, though — Pods are ephemeral and Kubernetes won't reschedule one that dies on its own. A Deployment wraps Pods in a desired-state description: how many replicas, which container image, how to roll out updates. Under the hood a Deployment manages a ReplicaSet, which manages the Pods themselves — you'll interact with the Deployment and rarely touch the ReplicaSet directly.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: ghcr.io/acme/web-app:1.4.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

Pods get new IP addresses every time they're rescheduled, so nothing should ever talk to a Pod IP directly. A Service gives a stable virtual IP and DNS name that load-balances across every Pod matching its label selector — Pods come and go, the Service address doesn't move.

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

The selector: app: web here is the entire mechanism — the Service doesn't know about the Deployment at all, it just watches for any Pod whose labels match and routes traffic to it. This is how you'll swap a Deployment's Pods out from under a Service with zero downtime during a rolling update in Week 12.

2. Control Plane vs. Worker Nodes

A Kubernetes cluster is a set of machines split into two roles. The control plane makes decisions; worker nodes run your containers. In a managed service like EKS or GKE you never see the control plane machines directly, but understanding what runs there explains almost every piece of kubectl behavior.

kube-apiserver     # the front door -- every kubectl command talks to this over HTTPS
etcd               # distributed key-value store holding all cluster state
kube-scheduler     # decides which worker node a new Pod should run on
kube-controller-manager  # runs the reconciliation loops (Deployment, ReplicaSet, ...)

kubelet            # agent that talks to the API server and runs Pods on this node
kube-proxy         # programs network rules so Services route traffic correctly
container runtime  # containerd (or CRI-O) -- actually pulls images and runs containers

The reconciliation model is the same idea as Terraform's plan/ apply loop, just running continuously instead of on demand. You declare "3 replicas of web-app" in a Deployment; the controller manager compares that desired state against etcd's record of actual state every few seconds, and if a Pod has died it creates a replacement without you doing anything. That's the mechanism behind Kubernetes "self-healing" — there's no magic, just a loop that never stops running.

3. kubectl & Declarative YAML

kubectl is your one interface to the API server, and it reads its connection details — cluster address, credentials, default namespace — from a kubeconfig file, usually ~/.kube/config. You'll switch between clusters (a local kind cluster, a staging EKS cluster) by switching contexts.

kubectl config get-contexts        # list every cluster/user combo kubectl knows about
kubectl config use-context kind-devops   # switch the active context
kubectl config set-context --current --namespace=web-app  # default namespace for this context

Almost everything you'll do falls into one of two styles: imperative commands that mutate the cluster directly, and declarative manifests applied with kubectl apply. This course uses declarative YAML almost exclusively, for the same reason it uses Terraform instead of clicking through the AWS console: the file is the source of truth, it's reviewable in a pull request, and it's the exact same mechanism CI will use to deploy in later weeks.

kubectl apply -f deployment.yaml -f service.yaml
kubectl get deployments
kubectl get pods -o wide
kubectl describe pod web-app-7d9f6c5b8-x2k4p   # events, restarts, resource usage
kubectl logs web-app-7d9f6c5b8-x2k4p            # container stdout/stderr
kubectl logs -f web-app-7d9f6c5b8-x2k4p         # follow, like tail -f
kubectl exec -it web-app-7d9f6c5b8-x2k4p -- sh  # shell into a running container
kubectl delete -f deployment.yaml -f service.yaml

Pod names get a random suffix appended by the ReplicaSet, so you'll rarely type them from memory — copy them from kubectl get pods, or use kubectl logs deployment/web-app to target the Deployment directly and let Kubernetes pick a Pod for you.

4. ConfigMaps & Secrets

Baking configuration into a container image means rebuilding the image every time a setting changes — the exact problem environment variables solved for docker run back in Week 3. Kubernetes has two objects for this: ConfigMaps for ordinary configuration, and Secrets for anything sensitive.

apiVersion: v1
kind: ConfigMap
metadata:
  name: web-app-config
data:
  LOG_LEVEL: "info"
  FEATURE_NEW_CHECKOUT: "true"
  API_TIMEOUT_MS: "3000"

kubectl create secret generic web-app-db \
  --from-literal=DB_USER=app_svc \
  --from-literal=DB_PASSWORD='S7!kq2vLpR' \
  --dry-run=client -o yaml > db-secret.yaml

Both get consumed the same way — as environment variables or as mounted files — which is why the split exists at all: it's purely about who's allowed to read the value and how it's stored, not how the app accesses it.

spec:
  containers:
    - name: web
      image: ghcr.io/acme/web-app:1.4.0
      envFrom:
        - configMapRef:
            name: web-app-config
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: web-app-db
              key: DB_PASSWORD

Critically: a Kubernetes Secret is base64-encoded, not encrypted, by default. kubectl get secret web-app-db -o jsonpath='{.data.DB_PASSWORD}' | base64 -d reveals the plaintext to anyone with read access to that namespace. That's enough to keep credentials out of your YAML in Git, but it is not a substitute for a real secrets manager — Week 14 covers encrypting Secrets at rest and integrating an external vault.

5. Running a Local Cluster with kind or minikube

You don't need a cloud account to learn Kubernetes. kind ("Kubernetes in Docker") runs an entire cluster as Docker containers on your laptop, and is fast enough to spin up and tear down as part of a CI job — which is exactly how you'll use it starting in Week 12.

# macOS
brew install kind kubectl

# Linux
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.23.0/kind-linux-amd64
chmod +x ./kind && sudo mv ./kind /usr/local/bin/kind

kind create cluster --name devops
kubectl cluster-info --context kind-devops

For a multi-node cluster that more closely mirrors production, give kind a config file instead of relying on the single-node default:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

kind create cluster --name devops --config kind-config.yaml
kubectl get nodes
# NAME                     STATUS   ROLES           AGE   VERSION
# devops-control-plane     Ready    control-plane   45s   v1.30.0
# devops-worker            Ready    <none>          30s   v1.30.0
# devops-worker2           Ready    <none>          30s   v1.30.0

minikube is the older, single-node-by-default alternative and is still common in tutorials — minikube start gets you a similar result, with a built-in dashboard (minikube dashboard) that's handy while you're still building a mental model of the objects involved. Either tool is fine for this course; examples assume kind because it starts faster and matches what you'll use in a GitHub Actions job later.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.