Shulou(Shulou.com)05/31 Report--

This article introduces how to use the kube-scheduler component in Kubernetes. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

Kubernetes as a container orchestration scheduling engine, resource scheduling is its most basic and most important function. Which node does an application run on when a developer deploys it? Does this node fully meet the operational requirements of the development? How does Kubernetes schedule resources?

There is a kube-scheduler component in Kubernetes, which runs on the master node and is mainly responsible for the scheduling of pod. Kube-scheduler listens to whether there is a pod in the kube-apiserver that has not been scheduled to the node (that is, the Pod whose Spec.NodeName is empty), and then assigns the node to run for the pod through a specific algorithm. If the allocation fails, the pod is placed at the end of the scheduling queue to reschedule. Scheduling is mainly divided into several parts: the first is the pre-selection process, which filters the nodes that do not meet the requirements of Pod. Then there is the optimization process, which prioritizes the required nodes, and finally selects the node with the highest priority, in which the two key points are the filtering and priority evaluation algorithm. The scheduler uses a set of rules to filter nodes that do not meet the requirements, including request with resources set and Nodename or other affinity settings specified, and so on. Priority evaluation scores the filtered list of nodes, and the scheduler considers some overall optimization strategies, such as assigning multiple replica sets controlled by Deployment to different nodes.

The influence of Resource request and restriction on pod scheduling

When deploying an application, the developer will consider how much memory and CPU resources are needed to make the application run, so that they can determine which node it should be run on. Add the requests field to the deployment file resource property to indicate the minimum resources required to run the container. When the scheduler starts to schedule the Pod, the scheduler ensures that for each resource type, the resource request sum of the plan container must be less than the capacity of the node before it can be allocated that node runs the limits field in the Pod,resource property to limit the maximum resources that the container gets when it runs. If the container exceeds its memory limit, it may be terminated. If the container can be restarted, kubelet will restart it. If the scheduler cannot find a suitable node to run the Pod, a scheduling failure event will occur, and the scheduler will place the Pod in the scheduling queue to schedule round robin until the scheduling is completed.

In the following example, when you run a nginx Pod, the resource requests 256Mi memory and 100m CPU, and the scheduler determines which node has so many resources left, and then dispatches the Pod when it is found. At the same time, the memory of 512Mi and the usage limit of 300m CPU are also set, and if the Pod runs beyond this limit, it will be restarted or even expelled.

ApiVersion: v1kind: Podmetadata: name: nginxspec: containers:-name: nginx image: nginx resources: requests: memory: "256Mi" cpu: "100m" limits: memory: "512Mi" cpu: "300m" View scheduling event events

After deploying the application, you can use the kubectl describe command to view the scheduling events of Pod. Here is a record of events that coredns was successfully dispatched to run by node3.

$kubectl describe po coredns-5679d9cd77-d6jp6-n kube-system...Events: Type Reason Age From Message-Normal Scheduled 29s default-scheduler Successfully assigned kube-system/coredns-5679d9cd77-d6jp6 to node3 Normal Pulled 28s kubelet Node3 Container image "grc.io/kubernetes/coredns:1.2.2" already present on machine Normal Created 28s kubelet, node3 Created container Normal Started 28s kubelet, node3 Started container

The following is an event record of a coredns scheduling failure. According to the record, the reason for the unschedulability is that no node meets the memory request of the Pod.

$kubectl describe po coredns-8447874846-5hpmz-n kube-system...Events: Type Reason Age From Message-Warning FailedScheduling 22s (x3 over 24s) default-scheduler 0ax 3 nodes are available: 3 Insufficient memory.label Selector impact on pod scheduling

For example, developers need to deploy an ES cluster. Because ES has higher requirements for disks, and only some nodes in the cluster have SSD disks, then you need to mark the nodes with SSD disks with Lable, so that the pod of ES can only run on the nodes with these tags.

Lable is a key-value pair attached to K8S objects such as Pod, Service, and so on. It can be specified when the object is created or at any time after the object is created. Kubernetes will eventually optimize the query and watch on the final index and reverse index of labels, which will be sorted on the UI and command line. In popular terms, it is to label K8S objects to facilitate selection and scheduling.

On how to use the kube-scheduler components in Kubernetes to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.