Daily Exercise 003: How-Kubernetes-Scheduler-Works

Day 1 Script

Today we are going to talk about how the scheduler in Kubernetes works. First of all, it is worth noting what the scheduler actually is. In Kubernetes, you have a bunch of machines and a single container that a user has asked to run. The job of the scheduler is to figure out which specific machine should execute this container. It decides where to place the workload across all the available nodes. This is one of the most important jobs in the cluster because without it, the containers would have no idea where they should be running. It is very similar to how an operating system on your laptop determines when and where a particular program should execute.

Day 1 Translate

Day 2 Script

When you create a pod, that object exists in the Kubernetes API, but it does not have a node associated with it yet. The API object for that pod does not have a machine that has been scheduled onto. The scheduler is continually watching for pods that have been created but have not been successfully scheduled. It is also continually watching the state of all of the machines. Of course, where to schedule the container has a lot to do with the current existing state of a particular machine. What the scheduler is thinking about when it makes a decision is a mixture of two things. These are predicates and priorities.

Day 2 Translate

Day 3 Script

Predicates are hard constraints that cannot be violated. They include things like memory requirements or node selectors. For example, you might need to run on a machine with at least four gigabytes of memory. If a machine does not have enough memory, there is no way that the container can be scheduled there. Predicates eliminate machines entirely from consideration. Hard constraints are a mix of things that are system supplied and things that a user can supply. You could say you only want to schedule onto machines that have a label of SSD, which means they have flash hard drives available to them.

Day 3 Translate

Day 4 Script

Priorities are soft constraints. They are things that would be nice if your application was spread across multiple machines. Spreading is the desire for an application to be spread across multiple machines, so if one happens to fail, the entire application does not fail. Priorities can be violated but give you some sense of the badness or goodness of either satisfying or not satisfying the constraint. For example, if you have absolutely no space to run three replicas of your application without putting two of them on the same machine, you would still rather place them on one machine than not run them at all.

Day 4 Translate

Day 5 Script

The actual scoring associated with priorities can give you some notion of how the scheduler behaves. Ultimately, it is this mixture of predicates that eliminate whole machines from consideration and priorities that give you the relative value of the different machines. The way this works is that the first step starts with a complete list of nodes. The scheduler filters those nodes by the predicates and then sorts those filtered nodes by the priorities. The number one node that comes out of this sort is going to be the place where the container is actually going to be scheduled in the cluster.

Day 5 Translate