If I understand correct, the flow of deploying a new Pod in Kubernetes is the following:
- User describes the new Pod through the Kubernetes API (kube-apiserver)
* The description turns into Kubernetes objects (pod, service, etc.)
- The objects are updated/stored to the cluster state (assume etcd)
* Current and desired state now diverge.
- The Pod is noticed by kube-scheduler that starts the worker node selection process
* kube-scheduler watched for Pods that are not assigned to any worker
- The most suitable worker is selected
* Likely the one with the most available resources
- The Pod is then assigned to the worker by calling its kubelet
Now, are the following assumptions correct?
(a) After the Pod is assigned to a worker node (kubelet), the worker alone is responsible for it.
(b) The master monitors only the health of the worker, but not of the Pod.
So the master “blindly” trusts the worker node, and the worker does its best to execute the Pod.
Now, there is the heartbeat mechanism that the master uses to monitor the healthiness of workers.
If I understood correct, heartbeat allows Master only to monitor the health of workers themselves?
Does the Master under any circumstances monitor the health of Pods?
Or are the responsibilities clearly segregated so that:
(a) Master is only responsible for monitoring health of workers
(b) Workers are alone responsible for executing Pods assigned to them
So the Master only becomes responsible of a worker’s Pods if the worker itself goes down failing to send the heartbeat. (Or the worker’s resources become exhausted, which I assume is indicated with the heartbeat.)
What I’m mostly after here, is that does Kubernetes implement a clear segregation of duty?
But what if a worker has the required resources but for some reason fails to start a Pod.
Is this issue somehow propagated back to the master?