Pod Scheduling of Kubernetes

"Editor's words" The Kubernetes Scheduler dispatches the pod to the work node according to a specific algorithm and strategy. By default, the Kubernetes scheduler can meet most of the requirements, such as scheduling pods to run on resource-rich nodes, or scheduling pod dispersal to different nodes to make cluster nodes resource balanced. However, cpu limit kubernetes in some special scenarios, the default scheduling algorithm policy does not meet the actual requirements, such as the user expects to dispatch certain pod to a specific hardware node on demand (database service deployment to SSD hard disk machine, cpu/memory intensive service deployment to high cpu/memory server), or the nearest and most frequently interacting pod (for example, the same machine, the same room,kubernetes cpu limit 0  or the same network segment).

Kubernetes cpu limit 

The scheduling strategy in Kubernetes is divided into 2 kinds: Global scheduling and runtime scheduling. The global scheduling strategy is configured at the time of scheduler startup, while the scheduling strategy mainly includes selection nodes (Nodeselector), node affinity (nodeaffinity), pod affinity and anti affinity (podaffinity and podantiaffinity). The features of Node Affinity, podaffinity/antiaffinity, and the stain (taints) and tolerance (tolerations) that are about to be introduced later are all in the beta phase in Kuberntes1.6.

Kubernetes cpu memory limits

This article focuses on the runtime scheduling strategy. Set node label

Label is one of the core concepts of kubernetes, which is attached to various objects in the form of key/value, such as pod, kubernetes cpu limits vs requests ，Service, deployment, node, etc., to identify these objects and manage association relationships, such as node and pod associations.
To get all the nodes in the current cluster: cpu requests and limits kubernetes

Kubectl Get Nodes

To set the label for the specified node:

Kubectl Label Nodes <node-name> <label-key>=<label-value>

Confirm that node label is set successfully:

Kubectl get nodes-l ' Label_key=label_value '

Select node (nodeselector)

Nodeselector is currently the simplest of the pod run-time scheduling restrictions, currently available in kubernetes1.7.x and the following versions. Pod.spec.nodeSelector selects the node through the label-selector mechanism of the kubernetes, the scheduler schedules the policy to match the label, and then the pod to the target node, and the matching rule belongs to the mandatory constraint. After the text to speak of the nodeaffinity with nodeselector full function, so the future kubernetes will be nodeselector abolished. nodeselector Examples:

Set label

$ kubectl Label Nodes bjo-rpt-re-002.dev.fwmrm.net DISKTYPE=SSD
node "bjo-rpt-re-002.dev.fwmrm.net" labeled

View nodes that meet non-master nodes and have a disktype type of SSD:

Kubectl get Nodes-l ' role!=master, DISKTYPE=SSD '
NAME STATUS age VERSION
bjo-r Pt-re-002.dev.fwmrm.net Ready 39d v1.7.1

Pod.yaml File Contents:

APIVERSION:V1
kind:pod
metadata:
name:nginx
Labels:
env:test
Spec:
containers:
-Name:nginx
image:nginx
imagepullpolicy:ifnotpresent
nodeselector:
DISKTYPE:SSD

To create a pod:

Kubectl create-f Pod.yaml

View pod Nginx is dispatched to the expected node to run:

$ kubectl Get PO nginx-o wide
NAME READY STATUS restarts age IP NODE
nginx 1/1 Running 0 10s 10.244.3.13 bjo-rpt-re-002.dev.fwmrm.net

Note: If not the default namespace, you need to specify a specific namespace, for example:

Kubectl-n Kube-system get pods-o Wide

built-in node label

Kubernetes starting from v1.4, nodes have some built-in label, listed as follows: Kubernetes.io/hostname Failure-domain.beta.kubernetes.io/zone Failure-domain.beta.kubernetes.io/region Beta.kubernetes.io/instance-type Beta.kubernetes.io/os Beta.kubernetes.io/arch Built-in label Example

Yaml File Contents:

APIVERSION:V1
kind:pod
metadata:
name:nginx
Labels:
env:test
Spec:
containers:
-Name:nginx
image:nginx
imagepullpolicy:ifnotpresent
nodeselector:
kubernetes.io/ Hostname:bjo-ep-svc-017.dev.fwmrm.net

To create the pod and check the results to meet expectations, the pod is scheduled to bjo-ep-svc-017.dev.fwmrm.net in the preset node:

$ kubectl Get PO nginx-o wide
NAME READY STATUS restarts age IP NODE
nginx 1/1 Running 0 3m 10.244.1.58 bjo-ep-svc-017.dev.fwmrm.net

Affinity (Affinity) and non-affinity (anti-affinity)

The nodeselector mentioned earlier, it is only in a very simple way, that is, the label force limit pod Dispatch to the specified node. While Affinity (Affinity) and incompatibility (anti-affinity) are more flexible to specify pod scheduling to the expected node, compared to the nodeselector,affinity and anti-affinity advantages embodied in: More diverse expression syntax, is no longer restricted to forced constraints and matches. The scheduling rule is no longer a mandatory constraint (hard), but is replaced by a soft limit (soft) or preference (preference). Specifies which pods can be deployed under the same/different topologies as the pod.

Affinity is divided into 3 types: node affinity and Inter-pod affinity/anti-affinity, which are described in detail below. Nodal affinity (node affinity)

Node affinity is introduced as Alpha in Kubernetes 1.2, which covers the Nodeselector function, Mainly divided into requiredduringschedulingignoredduringexecution and preferredduringschedulingignoredduringexecution 2 types. The former can be regarded as a constraint, and if node's label changes so that it does not meet the requirements of pod scheduling nodes, then pod scheduling will fail. The latter can be interpreted as soft limits or preferences, and pod will still be scheduled to run if Node's label changes so that it no longer meets the requirements of pod scheduling. Node Affinity Example

To set the node label:

$ kubectl Label Nodes bjo-ep-dep-040.dev.fwmrm.net cpu=high
node "bjo-ep-dep-040.dev.fwmrm.net" labeled

$  Kubectl label Nodes bjo-ep-svc-017.dev.fwmrm.net cpu=mid
node "bjo-ep-svc-017.dev.fwmrm.net" labeled

$ Kubectl label Nodes bjo-rpt-re-002.dev.fwmrm.net cpu=low
node "bjo-rpt-re-002.dev.fwmrm.net" labeled

The expected deployment of Pod is to a non-master node (Role!=master), with a CPU-high machine (Cpu=high).
To view meeting condition nodes:

$ kubectl Get nodes-l ' Cpu=high, Role!=master '
NAME STATUS age VERSION
bjo-ep- Dep-040.dev.fwmrm.net Ready 41d v1.7.1

The contents of the Pod.yaml file are as follows:

apiversion: v1 kind: pod Metadata:name: nginx labels:env: test spec:affinity:nodeAffinity: & Nbsp; requiredduringschedulingignoredduringexecution:     nodeselectorterms:      - matchexpressions:       - key: role          operator