Lesson 09 Kubernetes Fundamentals
Theme:

Homework 09 — Kubernetes Fundamentals

Lesson 09 · Cloud Infrastructure & DevOps · Three tasks

These three tasks extend the kind cluster from the lab. Each introduces a real-world K8s pattern you will use repeatedly in the rest of Module 4. Start with the cluster from Lab 09 still running, or re-create it before beginning.

Task 1 — Add a PodDisruptionBudget for the API

A PodDisruptionBudget (PDB) tells Kubernetes how many pods of a Deployment may be voluntarily taken offline at once — for example, during a node drain or a cluster upgrade. Without a PDB, a drain can terminate all replicas simultaneously, causing downtime.

  1. Create the file cloud-devops/sample-app/k8s/api-pdb.yaml that defines a PodDisruptionBudget in the shortener namespace, requiring at least 1 API pod to remain available during voluntary disruptions.
  2. Apply it: kubectl apply -f cloud-devops/sample-app/k8s/api-pdb.yaml.
  3. Simulate a voluntary disruption. On a single-node kind cluster, cordon the node and delete one API pod manually: 
    kubectl cordon shortener-control-plane
kubectl -n shortener delete pod -l app=shortener-api --field-selector=status.phase=Running | head -1
  4. Observe that K8s will not evict the pod if doing so would violate the budget. Uncordon when done: kubectl uncordon shortener-control-plane.

✓ Self-check: kubectl get pdb -n shortener shows MIN AVAILABLE: 1 and ALLOWED DISRUPTIONS: 1 (with 2 API replicas running).

Task 2 — Add a HorizontalPodAutoscaler

A HorizontalPodAutoscaler (HPA) adjusts the replica count of a Deployment based on observed metrics. This task wires up CPU-based autoscaling for the API.

  1. Install metrics-server on your kind cluster (it is not included by default): 
    kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# Patch for kind (kubelet uses self-signed certs):
kubectl -n kube-system patch deploy metrics-server --type=json \
  -p='[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'
  2. Create the file cloud-devops/sample-app/k8s/api-hpa.yaml that defines a HorizontalPodAutoscaler in the shortener namespace, scaling the API Deployment between 2 and 5 replicas based on 70% average CPU utilisation.
  3. Apply it: kubectl apply -f cloud-devops/sample-app/k8s/api-hpa.yaml.
  4. Verify metrics-server is working: kubectl top pod -n shortener should show CPU and memory values (not <unknown>).

✓ Self-check: kubectl get hpa -n shortener shows the HPA with MINPODS: 2 and MAXPODS: 5. kubectl top pod -n shortener returns real CPU/memory figures.

Task 3 — Split readiness from liveness on the worker

Currently the worker Deployment has only a liveness probe. This task adds a separate readiness probe that checks a different signal, and asks you to explain why the two probes must be different.

  1. Edit cloud-devops/sample-app/k8s/worker-deployment.yaml to add a readiness probe using an exec check: verify that the file /tmp/ready exists. The liveness probe should check a different file (/tmp/healthy).
  2. Apply the updated manifest: kubectl apply -f cloud-devops/sample-app/k8s/worker-deployment.yaml.
  3. Verify both probes are active: kubectl describe deploy shortener-worker -n shortener should list both probes.
  4. Simulate a readiness failure: kubectl -n shortener exec deploy/shortener-worker -- rm /tmp/ready. Watch the worker’s READY column in kubectl get pods flip to 0/1 — without a restart.
  5. In a comment at the top of worker-deployment.yaml, write 3–4 sentences explaining why these two probes must check different endpoints. What would go wrong if both used the same path?

✓ Self-check: kubectl describe deploy shortener-worker -n shortener shows both probes. After deleting /tmp/ready, the worker pod shows 0/1 Ready with zero restarts. After recreating /tmp/ready (or restarting the pod), it flips back to 1/1 Ready.

View solutions →