Challenge: turn off the scheduler
You started the course looking at the cluster's components with respect, from the outside. Now that you have finished it, you have earned the right to do what no book can offer you: turn one off and see exactly what breaks.
The target is the kube-scheduler, and it is no casual choice. Its absence produces the cleanest symptom of all, and that symptom connects with practically everything you have learned: the Pending of impossible requests, the one of untolerated taints, the one of the anti-affinity that finds no room. All of those had a reason written in their events. This challenge's will have none, and understanding why is the last piece of the puzzle.
The playground is once again the kubeadm cluster from the previous lesson, with the components in plain view.
Passing criterion: the scheduler is removed, a new Pod stays in Pending with no node and no events, and when the component is restored the Pod gets scheduled on its own, without anyone asking for it again.
And with this the course ends. You have walked the whole road: from the first Pod to a cluster that repairs itself, configures itself, protects itself, governs itself, sizes itself and, when needed, gets operated on with open-heart surgery.
- Previous lesson
- The cluster's components