That's the thing about kubernetes, it's a nice product but a lot of magic and mystery box in exactly at what point what internal events happen inside it unless you read a lot of documentation carefully.
Question: From a design perspective, why is the scheduler not just another controller? Seems like the assignment of nodes to pods could either be baked into a pod controller or be some other node assignment controller. Thanks!
It is "just another controller", but it runs within its own process (instead of being in the controller manager). My understanding is that on bigger clusters with lots of pods - and specifically, lots of pod creation, with lots of placement constraints, especially with weighted preferences - the scheduler can use quite a bit of resources, so it makes sense to run it on its own. Take this with a grain of salt, though - I never had the opportunity to ask to one of the Kubernetes architects if that was the real reason :)
How kubelet will place the pod? I mean what is the process running behind it? I got this question in one of the interview but not sure about the answer?
kubelet doesn't place the pod; this is the responsibility of the scheduler. The scheduler takes all the available information: the resources (e.g. RAM, CPU) requested by the pods, the resources available on the nodes, the placement constraints (affinity, antiaffinity, volumes, etc) and it makes a decision with that. Then kubelet just takes care of starting the pod, or rather, technically, the containers that compose the pod. I hope that helps!
Great explanation, Thank you!
That's the thing about kubernetes, it's a nice product but a lot of magic and mystery box in exactly at what point what internal events happen inside it unless you read a lot of documentation carefully.
Great explanation!
Question: From a design perspective, why is the scheduler not just another controller? Seems like the assignment of nodes to pods could either be baked into a pod controller or be some other node assignment controller. Thanks!
It is "just another controller", but it runs within its own process (instead of being in the controller manager). My understanding is that on bigger clusters with lots of pods - and specifically, lots of pod creation, with lots of placement constraints, especially with weighted preferences - the scheduler can use quite a bit of resources, so it makes sense to run it on its own. Take this with a grain of salt, though - I never had the opportunity to ask to one of the Kubernetes architects if that was the real reason :)
Thank u so much 👍
That’s what I need
How kubelet will place the pod? I mean what is the process running behind it? I got this question in one of the interview but not sure about the answer?
kubelet doesn't place the pod; this is the responsibility of the scheduler. The scheduler takes all the available information: the resources (e.g. RAM, CPU) requested by the pods, the resources available on the nodes, the placement constraints (affinity, antiaffinity, volumes, etc) and it makes a decision with that. Then kubelet just takes care of starting the pod, or rather, technically, the containers that compose the pod. I hope that helps!
Great!
Do you have this course available?
Hi! This is an excerpt from a private training, so I don't have the full course available, sorry!