Module 1 Exercises: Kubernetes Foundations
Put your knowledge to the test. Identify Kubernetes-ready apps and master the basics of kubectl.
Module 1 Exercises: Kubernetes Foundations
Before we dive into the complex architecture of Module 2, let's solidify your understanding of what Kubernetes is and why it exists. These exercises are designed to shift your thinking from "Single Server" to "Cluster Orchestration."
Exercise 1: Identify "K8s-Ready" Applications
Look at the following four application scenarios. For each one, decide if it is a GOOD fit or a BAD fit for Kubernetes. Explain why.
- A Legacy Windows Desktop App: Used by one person in an office, relies on a physical USB license key plugged into the back of the computer.
- A FastAPI Image Processing Service: Used by thousands of users. It spikes in CPU usage when high-res images are uploaded and needs to be highly available.
- A Simple Static Portfolio Site: Created using HTML and CSS. Gets about 5 visits per month and never changes.
- A Real-time AI Chatbot: Built with LangChain and Next.js. Needs to maintain stateful connections via WebSockets and scales based on query volume.
Exercise 2: Mapping the Architecture
Imagine you are explaining Kubernetes to a friend. Using the "Smart Warehouse" metaphor from Lesson 4, map the following technical components to their warehouse counterparts:
- etcd: _______________
- kube-scheduler: _______________
- Kubelet: _______________
- The Deployment YAML: _______________
- An AWS EC2 Instance: _______________
Exercise 3: Defining Desired State
You have a Kubernetes Deployment where replicas: 5.
A hardware failure causes 2 of the worker nodes to catch fire and melt.
- How many Pods remain running immediately after the fire?
- What does the Controller Manager do once it detects the failure?
- Where does the Scheduler look to place the new Pods?
Solutions (Self-Check)
Exercise 1 Solution:
- BAD: K8s is for containers. Apps requiring physical hardware keys (USB) or non-containerizable legacy Windows components are very difficult (or impossible) to orchestrate in a cloud cluster.
- GOOD: High scale, CPU spikes, and availability requirements are the "sweet spot" for Kubernetes autoscaling.
- BAD (Overkill): A static site with 5 visits/month is best hosted on a CDN (like Vercel or Netlify). K8s adds unnecessary cost and complexity here.
- GOOD: Complexity in networking (WebSockets) and variable scaling needs make K8s an ideal platform for AI agents.
Exercise 2 Solution:
- etcd: The Filing Cabinet (The Truth).
- kube-scheduler: The Dispatcher (Decision Maker).
- Kubelet: The Robot Brain/Agent on the floor.
- The Deployment YAML: The blueprint or work order.
- An AWS EC2 Instance: The physical floor space or the Robot Body (Worker Node).
Exercise 3 Solution:
- 3 Pods (Assuming 2 pods were on the nodes that failed).
- The Controller Manager notices that "Current State (3)" does not match "Desired State (5)." It creates 2 new Pod objects in the API Server.
- The Scheduler looks at the remaining healthy Worker Nodes to find space for the 2 new Pods.
Summary of Module 1
You have successfully completed the foundation!
- You know why we moved from Physical -> Virtual -> Containers.
- You understand that Docker packages and Kubernetes manages.
- You can visualize the Control Plane and Data Plane.
- You understand why K8s is the backbone of modern AI Engineering.
In Module 2: Kubernetes Architecture, we will get our hands dirty with namespaces, control plane internals, and cluster networking secrets. Get ready!