NdFeB:
My second question is: by using the easier method of specifying nodeName: controlplane in the Pod definition, then replacing the Pod, the Pod is successfully created on controlplane. But if I check the controlplane taints, I see it has one that my Pod does not tolerate:
$ k get node controlplane -o jsonpath='{.spec.taints}'
[{"effect":"NoSchedule","key":"<http://node-role.kubernetes.io/master|node-role.kubernetes.io/master>"}]
Why is the Pod successfully created? Isn’t it supposed to be rejected by the admission controller because it does not tolerate the taint?
Radoslaw Czajkowski:
are you sure it is succesfully created? k get pods shows it’s running on the control plane node?
NdFeB:
Yes it was showing “Running” on node “controlplane”
Radoslaw Czajkowski:
Okay so i checked it in my lab and it is indeed running. So yes, what it does esentially is that it bypasses the scheduler - taints are part of the scheduler to confirm it can run a pod or not. So if bypassed the taints are not checked (as their are part of the scheduling process). Good to know!
NdFeB:
Alright, thanks for the heads up!
NdFeB:
I actually thought that there was a default admission controller, and that checking taints and tolerations was part of its job, not the scheduler’s duty. Got to learn about admission controllers!
Radoslaw Czajkowski:
yes, so taints fall under the scheduler, probably you could write your own admission control which checks for taints when forcing a pod to a specific node is used.