Title: Lab 6 — Standing Up and Inspecting a Local Kubernetes Cluster
Course: AIINFRA 101: Applied Infrastructure & Containerization > Section: Week 06 — Introduction to Kubernetes: Architecture & kubectl

🛠️ Lab 6 — Standing Up and Inspecting a Local Kubernetes Cluster (50 pts)

Goal: Install kind, create a local 3-node Kubernetes cluster (1 control-plane, 2 workers) for zero cost, and use kubectl to explore how the control plane and worker nodes actually show up on disk and in the API — connecting today's lecture concepts to real command output. Steps:

1. Confirm Docker Desktop (or another local Docker engine) is installed and running — kind uses Docker containers as its cluster "nodes," so Docker must be up first.
2. Install kind v0.32.0 using Homebrew (brew install kind) on macOS, or via go install sigs.k8s.io/kind@v0.32.0 if you prefer the Go toolchain. Verify with kind version.
3. Install kubectl if you do not already have it (brew install kubectl on macOS works well). Verify with kubectl version --client.
4. Create a 3-node cluster config file named kind-config.yaml describing 1 control-plane node and 2 worker nodes (use the kind documentation's multi-node example as your template — do not just accept the single-node default).
5. Run kind create cluster --config kind-config.yaml --name aiinfra102 and note how quickly it finishes — this is the "under a minute, zero cloud cost" experience the lecture described.
6. Run kubectl cluster-info and record the control-plane endpoint it prints.
7. Run kubectl get nodes and confirm you see three nodes with the expected roles (one control-plane, two workers).
8. Run kubectl get pods -A (all namespaces) and identify, in your submission, which pods correspond to which control-plane component from the lecture table (etcd, kube-apiserver, kube-scheduler, kube-controller-manager) — note that they are all running inside the kube-system namespace.
9. Run kubectl describe node <one-of-your-worker-node-names> and record its capacity (CPU/memory), currently allocated resources, and any conditions listed (e.g., MemoryPressure, DiskPressure, Ready).
10. Clean up when finished with kind delete cluster --name aiinfra102 (note: not required before submission, but good practice).

Deliverables: Submit a short lab report (online text entry or upload) containing: (1) terminal output/screenshots of steps 6–9, (2) a two-to-three sentence explanation, in your own words, of why the pods you saw in kube-system are the "real" control plane rather than something separate from it, and (3) your kind-config.yaml file.