Cloud, deployment & production
Run workloads on Kubernetes
Deployments, services, scaling, and GPU scheduling basics for model serving.
~15 focused hours·advanced
Tools: kubectl, Deployments/Services, Helm (basic), GKE/EKS/AKS, HPA (autoscaling)
Market relevance — share of job ads asking for this
What employers mean
You should be able to…
- Write a Deployment + Service manifest to run a containerized API on a cluster
- Scale a deployment up/down manually and via a HorizontalPodAutoscaler
- Debug a pod stuck in CrashLoopBackOff using kubectl logs/describe
- Set resource requests/limits so a pod doesn't starve or get OOM-killed
- Roll out a new image version with zero downtime and roll back if it fails
- Understand namespaces and basic GPU/node-pool scheduling for model-serving pods
- Use a ConfigMap/Secret to inject config into a pod without rebuilding the image
Needs first: Containerize an application with Docker
Learn — free, link-checked
The few resources that matter
Read · beginner · 90 min · kubernetes.io
Kubernetes Basics
The official interactive tutorial — deploy, scale and update an app in a sandboxed cluster with zero setup. — Kubernetes.io
Watch · beginner · 240 min · youtube.com
Kubernetes Tutorial for Beginners [FULL COURSE in 4 Hours]
Diagrams-first explanation of pods, services and scaling that makes the abstract k8s object model click before you touch YAML. — TechWorld with Nana
Read · intermediate · 20 min · cloud.google.com
GKE Quickstart
Get a real managed cluster running in minutes — useful for GPU node pool scheduling once you've learned the basics. — Google Cloud
Read · intermediate · 30 min · kubernetes.io
Deployments
The core object you'll use to run and scale a model-serving workload — replicas, rollouts and rollbacks explained precisely. — Kubernetes.io
Practice
Kubernetes Deployment for the Containerized API
Deploy the containerized ticket/RAG API to a local (kind/minikube) or managed (GKE) cluster with a Deployment, Service, ConfigMap for non-secret config, a Secret for API keys, resource requests/limits, and a HorizontalPodAutoscaler. Simulate a crash-looping pod and document how you diagnosed and fixed it.
Done when
- `kubectl get pods` shows the Deployment running with the correct replica count
- Service exposes the API and it's reachable (via port-forward or LoadBalancer/Ingress)
- HPA is configured and demonstrated scaling under a simple load test
- A documented CrashLoopBackOff incident: cause found via `kubectl logs`/`describe`, then fixed
Prove it
Evidence a recruiter can check
- YAML manifests (Deployment, Service, ConfigMap, Secret, HPA) in a public repo
- Screenshot/output of `kubectl get pods,hpa` showing the running, scaled deployment
- Incident note documenting the CrashLoopBackOff diagnosis and fix
Interview
Questions you'll get asked
- Walk me through the YAML for a Deployment and Service exposing a Python API.
- A pod is stuck in CrashLoopBackOff — what commands do you run to find out why?
- How does a HorizontalPodAutoscaler decide when to add more pods?
- What happens during a rolling update, and how do you roll it back if the new version is broken?
- How do resource requests/limits affect scheduling and OOM kills?
- How would you schedule a GPU-heavy model-serving pod onto the right node pool?
- What's the difference between a ConfigMap and a Secret, and when do you use each?