Why is kube-controller-manager implemented as pull instead of push?

svenmathijssen

Question about 2 => Kubernetes Architecture => API flow. An explanation is given of how the kube-controller-manager performs its work. I'm a little curious as to why the process seems to be implemented as a control loop (i.e. pull) instead of push? I would think a setup where the API server pushes changes to the kube-controller-manager feels more logical since it is aware of any change requests that come in.

What triggered me also was the fact that in the example, it is clear tha the response for creation of a deployment returns almost instantly, suggesting that either there is only a small amount of time that passes before each control loop is executed, or the request is processed asynchronously in the background.

Thanks in advance!

asciimo

I have a similar question, but my expectation is the opposite. I suspect that all of the components watch/poll kube-apiserver, and the description in the video is inconsistent and misleading.

In the video, the kube-controller is described as watching/polling the kube-apiserver, as you describe. But then we are told that kube-apiserver "tells" kube-scheduler and kubelets that changes have happened. I find that surprising, because that would mean kube-apiserver does not follow the "do one thing well" principle. It would need logic to know what is interesting to the other components, which should be encapsulated in those components only. kube-apiserver would also have to know how to communicate with all of the other components at any time. It makes more sense that each resources would simply need to know how to talk to kube-apiserver.