
Module 2 Exercises: Cluster Architecture
Put your architectural knowledge to the test. Visualize the cluster, explore namespaces, and verify resource isolation.
Module 2 Exercises: Cluster Architecture
In Module 2, we moved away from the high-level concept of Kubernetes and looked at its "Nervous System" and "Brain." These exercises will help you solidify that knowledge by requiring you to visualize the connections and explore the internal organization of a live cluster.
Exercise 1: Diagram Your Kubernetes Cluster
Based on what you learned in Lesson 4 (Networking) and Lesson 2 (Internals), create a mental (or physical) diagram of a user request flow.
Scenario: A user makes an HTTPS request to your ai-agent-frontend. The frontend needs to call a summarization-api to process some text.
- Start your diagram with the User.
- Include the Cloud Load Balancer.
- Show the Inbound Node and the kube-proxy rules.
- Show the CoreDNS lookup for the
summarization-apiservice. - Show the final Pod responding.
Self-Check: Did you include the API Server? (Hint: It’s not in the data path of the request, but it’s what set up all the parts!)
Exercise 2: Exploring the "Hidden" World
If you have a Kubernetes cluster running (or are using a playground like Killercoda), run the following commands and answer the questions:
-
kubectl get namespaces- Which namespaces exist besides
default? - What is the purpose of
kube-system?
- Which namespaces exist besides
-
kubectl get pods -n kube-system- Identify the "Brain" components: Can you see the API Server, Scheduler, and Controller Manager?
- Identify the "Nervous System" components: Can you see the CNI plugin (e.g., aws-node, calico, or flannel) and kube-proxy?
-
kubectl describe pod <any-pod-name> -n kube-system- Find the Priority Class. Why is it set to "system-cluster-critical"?
Exercise 3: Debugging the "Desired State"
You have a Deployment with replicas: 10. You run the command kubectl get pods and you only see 4 pods in the "Running" state and 6 pods in the "Pending" state.
- Which Control Plane component is responsible for noticing the missing 6 pods?
- Which component is responsible for the "Pending" pods not having a home?
- If you run
kubectl describe pod <one-of-the-pending-pods>, and you see a message saying "0/3 nodes are available: 3 Insufficient cpu," what does that tell you about your ResourceQuotas or Cluster size?
Solutions (Self-Check)
Exercise 1 Strategy:
Your diagram should follow this flow:
User -> LoadBalancer (Public IP) -> Service (ClusterIP) -> kube-proxy (iptables) -> Target Pod.
The CoreDNS part happens inside the calling Pod before it even sends the first packet to the Service IP.
Exercise 2 Hints:
kube-systemis for the cluster's own internal operations.- Components like the Scheduler and API Server are marked "system-cluster-critical" so that Kubernetes knows to never kill them, even if the node is low on memory. They are the highest priority residents.
Exercise 3 Solution:
- Controller Manager: It's the one that sees "4 vs 10" and tries to create the missing ones.
- Scheduler: The pods are created in the API Server, but the Scheduler cannot find a node with enough free CPU to host them.
- It tells you that your Infrastructure is too small. You either need to add more Worker Nodes or reduce the Resource Requests in your Deployment YAML.
Summary of Module 2
You are now an Architect.
- You understand the Control Plane internals (API, etcd, Scheduler, Controller).
- You know what happens on the Worker Node (Kubelet, Proxy, Runtime).
- You understand the CNI and Service networking model.
- You know how to use Namespaces and Quotas to protect your cluster.
In Module 3: Kubernetes Objects, we move from the "Invisible" internals to the "Visible" YAML manifests. We will learn to write the code that brings your AI applications to life.