Shulou(Shulou.com)06/02 Report--

This article mainly explains "what is the meaning of K8s default scheduler scheduling strategy". The explanation in this article is simple and clear and easy to learn and understand. let's study and learn "what is the meaning of K8s default scheduler scheduling strategy?"

Predicates

First, let's take a look at Predicates.

The role of Predicates in the scheduling process can be understood as Filter, that is, it filters out a series of qualified nodes from all the nodes in the current cluster according to the scheduling strategy. These nodes are hosts that can run Pod to be scheduled.

In Kubernetes, there are three default scheduling policies.

The first type is called GeneralPredicates.

As the name implies, this set of filtering rules is responsible for the most basic scheduling strategy.

PodFitsResources

PodFitsResources calculates whether the CPU and memory resources of the host are sufficient.

Of course, as I mentioned earlier, PodFitsResources examines only the requests field of Pod. It should be noted that Kubernetes's scheduler does not define specific resource types for hardware resources such as GPU, but is described uniformly by an extension field called Extended Resource in Key-Value format. For example, the following example:

ApiVersion: v1kind: Podmetadata: name: extended-resource-demospec: containers:-name: extended-resource-demo-ctr image: nginx resources: requests: alpha.kubernetes.io/nvidia-gpu: 2 limits: alpha.kubernetes.io/nvidia-gpu: 2

As you can see, our Pod declares the use of two GPU of type NVIDIA through the definition of alpha.kubernetes.io/nvidia-gpu=2.

In PodFitsResources, the scheduler does not know that the field Key means GPU, but directly uses the following Value for calculation. Of course, in the Capacity field of Node, you have to add the total number of GPU on the host, such as alpha.kubernetes.io/nvidia-gpu=4. These processes will be described in detail when I explain Device Plugin later.

PodFitsHost

PodFitsHost checks whether the name of the host is the same as the spec.nodeName of Pod.

PodFitsHostPorts

PodFitsHostPorts checks whether the host port (spec.nodePort) applied for by Pod conflicts with the port that has already been used.

PodMatchNodeSelector

PodMatchNodeSelector checks whether the node specified by the nodeSelector or nodeAffinity of Pod matches the node under inspection, and so on.

As you can see, a set of GeneralPredicates like the above is the most basic filter condition for Kubernetes to examine whether an Pod can run on a Node. Therefore, GeneralPredicates will also be called directly by other components (such as kubelet).

As I mentioned in the previous article, kubelet performs an Admit operation to make a second confirmation before starting Pod. The rule of second confirmation here is to execute the GeneralPredicates once.

The second type is the filtering rules related to Volume

This set of filtering rules is responsible for scheduling policies related to container persistence Volume.

Among them, NoDiskConflict checks whether there is a conflict with the persistent Volume mounted on multiple Pod declarations. For example, Volume of type AWS EBS is not allowed to be used by two Pod at the same time. So, when an EBS Volume named An is already mounted on a node, another Pod that also claims to use the A Volume cannot be dispatched to that node.

The condition of MaxPDVolumeCountPredicate checking is whether a certain type of persistent Volume on a node has exceeded a certain number, and if so, Pod that declares that this type of persistent Volume can no longer be dispatched to this node.

VolumeZonePredicate, on the other hand, checks whether the Zone tag of the persistent Volume matches the Zone tag of the node to be examined.

In addition, there is a rule called VolumeBindingPredicate. It is responsible for checking whether the nodeAffinity field of the PV corresponding to the Pod matches the label of a node.

It has been explained that Local Persistent Volume (local persistence volume) must be bound to a specific node using nodeAffinity. This actually means that in the Predicates phase, Kubernetes must be able to schedule according to the Volume property of Pod.

In addition, if the PVC of the Pod is not already bound to a specific PV, the scheduler is responsible for checking all the PV to be bound, and this rule returns "success" only if a PV is available and the nodeAffinity of the PV is consistent with the node under inspection. For example, the following example:

ApiVersion: v1kind: PersistentVolumemetadata: name: example-local-pvspec: capacity: storage: 500Gi accessModes:-ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: local-storage local: path: / mnt/disks/vol1 nodeAffinity: required: nodeSelectorTerms:-matchExpressions:-key: kubernetes.io/hostname operator: In values:-my-node

As you can see, the persistence directory corresponding to this PV will only appear on the host called my-node. Therefore, any Pod that uses this PV through PVC must be dispatched to my-node to work properly. VolumeBindingPredicate, which is where this decision is made in the scheduler.

The third type is host-related filtering rules.

This set of rules mainly examines whether the Pod to be scheduled satisfies some conditions of Node itself.

PodToleratesNodeTaints, for example, is responsible for checking the "stain" mechanism of Node that we often use before. This Pod can be dispatched to the node only if the Toleration field of the Pod matches the Taint field of the Node.

NodeMemoryPressurePredicate, on the other hand, checks whether the memory of the current node is insufficient, and if so, the Pod to be scheduled cannot be dispatched to that node.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.