Configuring Node Affinity Scheduling

Configuring Node Affinity on the Console

1. When creating a workload, click Scheduling in the Advanced Settings area. For details about how to create a workload, see Creating a Workload.
2. Select a node affinity scheduling policy.
   • Not configured: No node affinity policy is configured.
   • Node Affinity: Specify the nodes where workload pods are to be deployed. If no nodes are specified, the pods will be randomly scheduled according to the default cluster scheduling policy.
   • Specified Node Pool Scheduling: Specify the node pools where workload pods are to be deployed. If no node pools are specified, the pods will be randomly scheduled according to the default cluster scheduling policy.
   • Custom policies: allow flexible scheduling of workload pods based on node labels. For details about the supported scheduling policies, see Table 1. Select a proper policy type and click to add a policy. For details about the parameters, see Table 2. You can also click Specify Node or Specify AZ to quickly select a node or AZ on the console for scheduling.

     Specifying a node or AZ is also implemented through labels. The console frees you from manually entering node labels. The kubernetes.io/hostname label is used when you specify a node, and the failure-domain.beta.kubernetes.io/zone label is used when you specify an AZ.

     Table 1 Node affinity settings

     Parameter	Description
     Required	Hard constraint, which corresponds to requiredDuringSchedulingIgnoredDuringExecution for specifying the conditions that must be met. If multiple rules that must be met are added, scheduling will be performed when only one rule is met.
     Preferred	Soft constraint, which corresponds to preferredDuringSchedulingIgnoredDuringExecution for specifying the conditions that need to be met as much as possible. If multiple rules that are preferentially met are added, scheduling will be performed even if one or none of the rules is met.

     Table 2 Parameters for configuring node affinity scheduling policies

     Parameter	Description
     Weight	This parameter is available only in a preferred scheduling policy. Weights range from 1 to 100 and are taken into account as an extra scoring factor during scheduling. The scheduler combines the weight with other priority functions of the node to determine the final score and then assigns pods to the node with the highest total score.
     Label Key	When configuring node affinity, enter the node label to be matched. Both default labels and custom labels are supported.
     Operator	The following operators are supported: In: The label of the affinity or anti-affinity object is in the label value list (values field). NotIn: The label of the affinity or anti-affinity object is not in the label value list (values field). Exists: The affinity or anti-affinity object has a specified label key. DoesNotExist: The affinity or anti-affinity object does not have a specified label key. Gt: (available only for node affinity) The label value of the scheduled node is greater than the list value (string comparison). Lt: (available only for node affinity) The label value of the scheduled node is less than the list value (string comparison).
     Label Value	When configuring node affinity, enter the value of the node label.

3. After the scheduling policy is added, click Create Workload.

Configuring Node Affinity Using YAML

Workload node affinity rules are implemented using node labels. When a node is created in a CCE cluster, it is automatically assigned certain labels. Here are some examples of commonly used node labels (for more labels, see Inherent Label of a Node):

• topology.kubernetes.io/zone: the AZ where the node is located, which can be used for scheduling in a specified AZ.
• kubernetes.io/hostname: hostname of a node, which can be used for specified node scheduling.
• cce.cloud.com/cce-nodepool: node pool to which a node belongs, which can be used for scheduling in a specified node pool.

The following is an example of configuring node affinity:

apiVersion: apps/v1
kind: Deployment
metadata:
  name:  gpu
  labels:
    app:  gpu
spec:
  selector:
    matchLabels:
      app: gpu
  replicas: 3
  template:
    metadata:
      labels:
        app:  gpu
    spec:
      containers:
      - image:  nginx:alpine
        name:  gpu
        resources:
          requests:
            cpu: 100m
            memory: 200Mi
          limits:
            cpu: 100m
            memory: 200Mi
      imagePullSecrets:
      - name: default-secret
      affinity:  # Configure a scheduling policy.
        nodeAffinity:  # Node affinity scheduling
          requiredDuringSchedulingIgnoredDuringExecution:  # Scheduling policy that must be met
            nodeSelectorTerms:     # Select a node that meets the requirements according to the node label.
              - matchExpressions:    # Node label matching rule
                - key: gpu   # The key of the node label is gpu.
                  operator: In  # The rule is met if a value exists in the value list.
                  values:   # The value of the node label is true.
                  - "true"
          preferredDuringSchedulingIgnoredDuringExecution:  # Scheduling policy that is met as much as possible
            - weight: 100  # Priority that can be configured when the best-effort policy is used. The value ranges from 1 to 100. A larger value indicates a higher priority.
              preference:  # Preferred node label matching rule when the best-effort policy is used
                matchExpressions:   # Node label matching rule
                  - key: topology.kubernetes.io/zone   # Nodes' AZs
                     operator: In  # The rule is met if a value exists in the value list.
                    values:   # The value of the node label is az1.
                    - "az1"

In this example, the rule that must be met indicates that the node to be scheduled must be labeled with key gpu and value true. The rule that needs to be met as much as possible indicates that pods are preferentially scheduled to nodes in AZ 1 based on topology.kubernetes.io/zone.

To implement node anti-affinity, use the NotIn and DoesNotExist operators to reversely filter node label values.