This is the 14th day of my participation in the August More Text Challenge. For details, see: August More Text Challenge

Introduction to the

Scheduling, in Kubernetes, refers to putting the Pod on the optimal node so that the Pod runs in a relatively optimal environment

The scheduling line is operated by the scheduler, which uses k8s’s Watch mechanism to find newly created pods in the cluster that have not yet been scheduled to a node. The scheduler will place each unscheduled POD published on an appropriate node

kube-scheduler

The default scheduler in Kubernetes is kube-Scheduler, which is the component of the default cluster installation

Kube-scheduler schedules POD in two steps:

  1. filter
  2. score

In the filtering phase, all nodes that meet the needs of Pod scheduling will be selected. For example, the PodFitsResources filtering function will check whether the available resources of candidate nodes can meet the Pod resource request. After filtering, a list of nodes is generated, which contains all the schedulable nodes. Typically, this list of nodes contains more than one Node. If the list is empty, the Pod is unschedulable.

In the splitting stage, the scheduler will score each node among all schedulable nodes according to the current scoring rules, and then schedule Pod to the node with the highest score. If multiple nodes have the highest score, they will be randomly selected

Node selector

To constrain Pod to run on a specific node, a common practice is to label the node and then use nodeSelector to select the tag at deployment time. The scheduler will automatically match and place the tag

Kubectl label Nodes node1 disktype= SSDCopy the code
# Using tag selector, pod will run on node1 nodeapiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd
Copy the code

Affinity and antiaffinity

The affinity function provides two types of affinity, namely, node affinity and INTER-POD affinity/anti-affinity

Agreeableness and antiagreeableness increased:

  1. The language is more expressive (not just “AND for perfectly matching rules”)
  2. The requirement is non-locked and can continue scheduling if the rule is a soft requirement or preference rather than a hard requirement
  3. Multiple tag options, support for POD tag constraints, not just node tag

Node affinity

The concept of node affinity is similar to that of nodeSelector, and Pod can be constrained to which nodes can be scheduled according to the label on the node

Currently, there are two types of node affinity:

  • RequiredDuringSchedulingIgnoredDuringExecution hard demand
  • PreferredDuringSchedulingIgnoredDuringExecution soft demand

Hard requirements are the requirements that Pod scheduling to a node must meet

Soft requirements are those that the scheduler tries to execute but cannot guarantee preferences

Node affinity example:

# Node affinity via PodSpec`affinity`Under the field of`nodeAffinity`Field to specifyapiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0
Copy the code
  • The Pod can be scheduled only on the node that has the label key kubernetes. IO/e2E-az-name and the label value is E2E-AZ1 or E2e-AZ2
  • Among nodes that meet these criteria, nodes with the label key of another-node-label-key and the label value of another-node-label-value should be used preferentially
  • Specifies nodeSelector and nodeAffinity,bothMust be met before the Pod can be scheduled to the candidate node

Pod affinity and antiaffinity

Pod affinity and anti-affinity can be used to constrain the nodes to which Pod can be scheduled based on Pod criteria running on the nodes

Where the rule is that if one or more Pods meeting rule Y have been run on the x node, the Pod should (or should not in the case of anti-affinity) run on the X node (Y represents a LabelSelector with an optional list of associated command Spaces).

  • Affinity between Pods through PodSpecaffinityUnder the field ofpodAffinityField to specify
  • Antiaffinity between Pods through PodSpecaffinityUnder the field ofpodAntiAffinityField to specify
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: k8s.gcr.io/pause:2.0
Copy the code

Stain and tolerance

Smudging is what makes a node reject a particular type of POD

The tolerance is added to the POD, allowing (but not requiring) the POD to schedule to the node with the matching stain

Stain example

Kubectl taint Nodes node1 key1=value1:NoScheduleCopy the code

Indicates that only pods that match the stain can be assigned to node1

Kubectl taint Nodes node1 key1=value1:NoSchedule-Copy the code

Tolerance example

The tolerance is allowed, but does not require the POD to schedule to the node with the stain rule

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoSchedule"
Copy the code
  • Key matches the key set when the stain was created. No key means anything is tolerated
  • If there is no value, operator is Equal
  • The default operator is Equal, matches any key,value, or effect, and can tolerate any tainted standoff
  • Effect rule,NoSchedule: indicates that the node cannot tolerate stains, PreferNoSchedule: indicates that the node cannot tolerate stains