# Exercise 1: Trace a Deployment Through the Cluster

Set up a local cluster with **kind** or **minikube** (`kind create cluster --name lab`).

## Tasks

1. **Explore the control plane**: list the Pods in `kube-system` and map each to the component it implements (apiserver, etcd, scheduler, controller-manager, CoreDNS, kube-proxy, CNI). Which of these would you *not* see on a managed cluster like EKS, and why?
2. **Trace an apply**: run `kubectl get events -A --watch` in one terminal, then apply a Deployment with 3 replicas of `nginx:1.27` in a new namespace `lab`. Record the sequence of events and attribute each one to the component that produced it (Deployment controller, ReplicaSet controller, scheduler, kubelet).
3. **Break scheduling**: change the Deployment to request `cpu: "64"`. What state are the Pods in, what does `kubectl describe pod` say, and which component reports it?
4. **Self-healing**: delete one Pod and watch it come back; then `docker stop` the kind worker node container (or `minikube node stop` on a multi-node cluster) and observe what happens to its Pods over the next few minutes. Explain the timing.
5. **RBAC**: create a ServiceAccount `viewer` in `lab` with a Role allowing only `get`/`list`/`watch` on Pods, and prove with `kubectl auth can-i --as=system:serviceaccount:lab:viewer` that it can list Pods but not delete them or read Secrets.
6. **Answer**: why is the API server the only component that talks to etcd? What would break if the scheduler crashed — and what would keep working?

## Requirements Checklist

- [ ] kube-system components correctly mapped; notes that managed control planes hide apiserver/etcd/scheduler/controller-manager Pods.
- [ ] Event trace shows ScalingReplicaSet → SuccessfulCreate → Scheduled → Pulling/Pulled → Created → Started with the right component for each.
- [ ] Unschedulable Pods are `Pending` with a `FailedScheduling` event ("Insufficient cpu") from the scheduler.
- [ ] Node failure: Pods replaced after the node is NotReady and eviction/tolerations time out (~5 min default `node.kubernetes.io/unreachable` toleration).
- [ ] Role + RoleBinding YAML and `can-i` outputs (yes for list pods, no for delete pods / get secrets).
- [ ] Explanation: single point for authn/authz/admission/consistency; scheduler outage → existing Pods keep running, new Pods stay Pending.