Workload affinity determines the pods as which the target workload will be deployed in the same topology domain.
There are two types of pod affinity rules: Required (hard rule) and Preferred (soft rule). The label operators include In, NotIn, Exists, and DoesNotExist.
Parameter |
Description |
---|---|
Required |
It specifies a rule that must be met in scheduling. It corresponds to requiredDuringSchedulingIgnoredDuringExecution in Kubernetes. You can click Add Rule to add multiple required rules. Ensure that all the labels specified in the rules must be in the same workload. Each rule requires a namespace and topology key. |
Preferred |
It specifies a preference in scheduling. It corresponds to preferredDuringSchedulingIgnoredDuringExecution in Kubernetes. You can click Add Rule to add multiple preferred rules. The scheduler will try to enforce the rules but will not guarantee. If the scheduler cannot satisfy any one of the rules, the pod will still be scheduled. |
Parameter |
Description |
---|---|
Weight |
|
Namespace |
By default, the namespace of the current pod is used. You can also use another namespace. |
Topology Key |
Key of the worker node label that the system uses to denote a topology domain in which scheduling can be performed. Default and custom node labels can be used. |
Label |
Label of the workload. You can customize the label name. |
Operator |
The following relations are supported: In, NotIn, Exists, and DoesNotExist |
Value |
Tag value. Operators In and NotIn allow one or more label values. Values are separated with colons (;). Operators Exists and DoesNotExist are used to determine whether a label exists, and do not require a label value. |
Operation |
You can click Delete to delete a selector. |
Add Selector |
A selector corresponds to matchExpressions in Kubernetes. You can click Add Selector to add multiple selectors for a scheduling rule. The rule is applied in scheduling only when all its selectors are satisfied. |
This section uses Nginx as an example to describe how to configure pod affinity.
Prerequisites
A workload that uses the nginx container image has been deployed on a node.
Procedure
Set Namespace to default and Topology Key to the built-in node label kubernetes.io/hostname, which means that the scheduling scope is a node. Set labels app and type and their value to redis and database, respectively. Set Operator to In and click OK.
The YAML of the workload with pod affinity is as follows:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx namespace: default spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx imagePullPolicy: Always name: nginx imagePullSecrets: - name: default-secret affinity: nodeAffinity: {} podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - redis - key: type operator: In values: - database namespaces: - default topologyKey: kubernetes.io/hostname
In this example, only when a candidate workload (for example, workload A) with both labels app=redis and type=database is found can the workload Nginx be successfully scheduled to the node of the candidate workload.