forked from docs/doc-exports
qiujiandong1
0a674cd795
Reviewed-by: Eotvos, Oliver <oliver.eotvos@t-systems.com> Co-authored-by: qiujiandong1 <qiujiandong1@huawei.com> Co-committed-by: qiujiandong1 <qiujiandong1@huawei.com>
378 lines
34 KiB
HTML
378 lines
34 KiB
HTML
<a name="ucs_01_0152"></a><a name="ucs_01_0152"></a>
|
|
|
|
<h1 class="topictitle1">Scheduling Policy (Affinity/Anti-affinity)</h1>
|
|
<div id="body8662426"><p id="ucs_01_0152__en-us_topic_0000001244101079_p8060118">When creating a workload, you can use a nodeSelector to constrain pods to nodes with particular labels. The affinity and anti-affinity features greatly increase the types of constraints you can express.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p14784281034">Kubernetes supports node-level and pod-level affinity and anti-affinity. You can configure custom rules to achieve affinity and anti-affinity scheduling. For example, you can deploy frontend pods and backend pods together, deploy the same type of applications on a specific node, or deploy different applications on different nodes.</p>
|
|
<div class="section" id="ucs_01_0152__en-us_topic_0000001244101079_section1665272918139"><h4 class="sectiontitle">Node Affinity (nodeAffinity)</h4><p id="ucs_01_0152__en-us_topic_0000001244101079_p14720123173511">You can use a nodeSelector to constrain pods to nodes with specific labels. The following example shows how to use a nodeSelector to deploy pods only on the nodes with the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1139910455565">gpu=true</strong> label.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen1741420109362">apiVersion: v1
|
|
kind: Pod
|
|
metadata:
|
|
name: nginx
|
|
spec:
|
|
nodeSelector: # Node selection. A pod is deployed on a node only when the node has the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b168005496563">gpu=true</strong> label.
|
|
gpu: true
|
|
...</pre>
|
|
<div class="p" id="ucs_01_0152__en-us_topic_0000001244101079_p9838151173813">Node affinity rules can achieve the same results, as shown in the following example.<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen163933254405">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:
|
|
nodeAffinity:
|
|
requiredDuringSchedulingIgnoredDuringExecution:
|
|
nodeSelectorTerms:
|
|
- matchExpressions:
|
|
- key: gpu
|
|
operator: In
|
|
values:
|
|
- "true"</pre>
|
|
</div>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p872873864311">Even though the node affinity rule requires more lines, it is more expressive, which will be further described later.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p13756177174919"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b19552168115814">requiredDuringSchedulingIgnoredDuringExecution</strong> seems to be complex, but it can be easily understood as a combination of two parts.</p>
|
|
<ul id="ucs_01_0152__en-us_topic_0000001244101079_ul17285714134916"><li id="ucs_01_0152__en-us_topic_0000001244101079_li18285414134915">requiredDuringScheduling indicates that pods can be scheduled to the node only when all the defined rules are met (required).</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li152851014134915">IgnoredDuringExecution indicates that pods already running on the node do not need to meet the defined rules. That is, a label on the node is ignored, and pods that require the node to contain that label will not be re-scheduled.</li></ul>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p3133191362319">In addition, the value of <strong id="ucs_01_0152__en-us_topic_0000001244101079_b420764115810">operator</strong> is <strong id="ucs_01_0152__en-us_topic_0000001244101079_b92139419589">In</strong>, indicating that the label value must be in the values list. Other available operator values are as follows:</p>
|
|
<ul id="ucs_01_0152__en-us_topic_0000001244101079_ul761616252"><li id="ucs_01_0152__en-us_topic_0000001244101079_li186115112515"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b12163446582">NotIn</strong>: The label value is not in a list.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li961161112511"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b1633184735818">Exists</strong>: A specific label exists.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li86111116256"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b19920249105811">DoesNotExist</strong>: A specific label does not exist.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li86120115255"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b15840115214585">Gt</strong>: The label value is greater than a specified value (string comparison).</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li18611018254"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b17310138307">Lt</strong>: The label value is less than a specified value (string comparison).</li></ul>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p982815812264">Note that there is no such thing as nodeAntiAffinity because operators <strong id="ucs_01_0152__en-us_topic_0000001244101079_b8458411605">NotIn</strong> and <strong id="ucs_01_0152__en-us_topic_0000001244101079_b144645117019">DoesNotExist</strong> provide the same function.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p165721693914">The following describes how to check whether the rule takes effect. Assume that a cluster has three nodes.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen140818111298">$ kubectl get node
|
|
NAME STATUS ROLES AGE VERSION
|
|
192.168.0.212 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
|
|
192.168.0.94 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
|
|
192.168.0.97 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2 </pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p492899145111">Add the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1561275563517">gpu=true</strong> label to the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b7701191914361">192.168.0.212</strong> node.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen1628537145314">$ kubectl label node 192.168.0.212 gpu=true
|
|
node/192.168.0.212 labeled
|
|
|
|
$ kubectl get node -L gpu
|
|
NAME STATUS ROLES AGE VERSION GPU
|
|
192.168.0.212 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
|
|
192.168.0.94 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2
|
|
192.168.0.97 Ready <none> 13m v1.15.6-r1-20.3.0.2.B001-15.30.2 </pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p1652013550538">Create the Deployment. You can find that all pods are deployed on the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b523412718360">192.168.0.212</strong> node.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen15298123225413">$ kubectl create -f affinity.yaml
|
|
deployment.apps/gpu created
|
|
|
|
$ kubectl get pod -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
gpu-6df65c44cf-42xw4 1/1 Running 0 15s 172.16.0.37 192.168.0.212
|
|
gpu-6df65c44cf-jzjvs 1/1 Running 0 15s 172.16.0.36 192.168.0.212
|
|
gpu-6df65c44cf-zv5cl 1/1 Running 0 15s 172.16.0.38 192.168.0.212</pre>
|
|
</div>
|
|
<div class="section" id="ucs_01_0152__en-us_topic_0000001244101079_section168955237561"><h4 class="sectiontitle">Node Preference Rule</h4><p id="ucs_01_0152__en-us_topic_0000001244101079_p320564375620">The preceding <strong id="ucs_01_0152__en-us_topic_0000001244101079_b169534143612">requiredDuringSchedulingIgnoredDuringExecution</strong> rule is a hard selection rule. There is another type of selection rule, that is, <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1169153453620">preferredDuringSchedulingIgnoredDuringExecution</strong>. It is used to specify which nodes are preferred during scheduling.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p1413944714015">To achieve this effect, add a node attached with SAS disks to the cluster, add the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b26751852183611">DISK=SAS</strong> label to the node, and add the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b72101457203617">DISK=SSD</strong> label to the other three nodes. </p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen183694610114">$ kubectl get node -L DISK,gpu
|
|
NAME STATUS ROLES AGE VERSION DISK GPU
|
|
192.168.0.100 Ready <none> 7h23m v1.15.6-r1-20.3.0.2.B001-15.30.2 SAS
|
|
192.168.0.212 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD true
|
|
192.168.0.94 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD
|
|
192.168.0.97 Ready <none> 8h v1.15.6-r1-20.3.0.2.B001-15.30.2 SSD </pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p75709341339">Define a Deployment. Use the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1290693523718">preferredDuringSchedulingIgnoredDuringExecution</strong> rule to set the weight of nodes attached with the SAS disk to <strong id="ucs_01_0152__en-us_topic_0000001244101079_b890718357372">80</strong> and nodes with the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b590713354371">gpu=true</strong> label to <strong id="ucs_01_0152__en-us_topic_0000001244101079_b11907183512379">20</strong>. In this way, pods are preferentially deployed on the nodes attached with the SAS disk.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen952147175512">apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: gpu
|
|
labels:
|
|
app: gpu
|
|
spec:
|
|
selector:
|
|
matchLabels:
|
|
app: gpu
|
|
replicas: 10
|
|
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:
|
|
nodeAffinity:
|
|
preferredDuringSchedulingIgnoredDuringExecution:
|
|
- weight: 80
|
|
preference:
|
|
matchExpressions:
|
|
- key: DISK
|
|
operator: In
|
|
values:
|
|
- SSD
|
|
- weight: 20
|
|
preference:
|
|
matchExpressions:
|
|
- key: gpu
|
|
operator: In
|
|
values:
|
|
- "true"</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p15293645889">After the deployment, you can find that five pods are deployed on the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1752411833814">192.168.0.212</strong> node, and two pods are deployed on the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b20524518183820">192.168.0.100</strong> node.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen5883659482">$ kubectl create -f affinity2.yaml
|
|
deployment.apps/gpu created
|
|
|
|
$ kubectl get po -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
gpu-585455d466-5bmcz 1/1 Running 0 2m29s 172.16.0.44 192.168.0.212
|
|
gpu-585455d466-cg2l6 1/1 Running 0 2m29s 172.16.0.63 192.168.0.97
|
|
gpu-585455d466-f2bt2 1/1 Running 0 2m29s 172.16.0.79 192.168.0.100
|
|
gpu-585455d466-hdb5n 1/1 Running 0 2m29s 172.16.0.42 192.168.0.212
|
|
gpu-585455d466-hkgvz 1/1 Running 0 2m29s 172.16.0.43 192.168.0.212
|
|
gpu-585455d466-mngvn 1/1 Running 0 2m29s 172.16.0.48 192.168.0.97
|
|
gpu-585455d466-s26qs 1/1 Running 0 2m29s 172.16.0.62 192.168.0.97
|
|
gpu-585455d466-sxtzm 1/1 Running 0 2m29s 172.16.0.45 192.168.0.212
|
|
gpu-585455d466-t56cm 1/1 Running 0 2m29s 172.16.0.64 192.168.0.100
|
|
gpu-585455d466-t5w5x 1/1 Running 0 2m29s 172.16.0.41 192.168.0.212</pre>
|
|
</div>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p92179105145">In the preceding example, the node scheduling priority is as follows. Nodes with both <strong id="ucs_01_0152__en-us_topic_0000001244101079_b16521734123815">SSD</strong> and <strong id="ucs_01_0152__en-us_topic_0000001244101079_b3581134193816">gpu=true</strong> labels have the highest priority. Nodes with the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b195843443814">SSD</strong> label but no <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1258434143815">gpu=true</strong> label have the second priority (weight: 80). Nodes with the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b14581034133813">gpu=true</strong> label but no <strong id="ucs_01_0152__en-us_topic_0000001244101079_b65883463817">SSD</strong> label have the third priority. Nodes without any of these two labels have the lowest priority.</p>
|
|
<div class="fignone" id="ucs_01_0152__en-us_topic_0000001244101079_fig1074885585814"><span class="figcap"><b>Figure 1 </b>Scheduling priority</span><br><span><img id="ucs_01_0152__en-us_topic_0000001244101079_image1950520111683" src="en-us_image_0000001322427538.png"></span></div>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p1758543301514">From the preceding output, you can find that no pods of the Deployment are scheduled to node <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1067392813916">192.168.0.94</strong>. This is because the node already has many pods on it and its resource usage is high. This also indicates that the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b7679628143918">preferredDuringSchedulingIgnoredDuringExecution</strong> rule defines a preference rather than a hard requirement.</p>
|
|
<div class="section" id="ucs_01_0152__en-us_topic_0000001244101079_section3218151791419"><h4 class="sectiontitle">Workload Affinity (podAffinity)</h4><p id="ucs_01_0152__en-us_topic_0000001244101079_p9807315182015">Node affinity rules affect only the affinity between pods and nodes. Kubernetes also supports configuring inter-pod affinity rules. For example, the frontend and backend of an application can be deployed together on one node to reduce access latency. There are also two types of inter-pod affinity rules: <strong id="ucs_01_0152__en-us_topic_0000001244101079_b217612455407">requiredDuringSchedulingIgnoredDuringExecution</strong> and <strong id="ucs_01_0152__en-us_topic_0000001244101079_b17176194574018">preferredDuringSchedulingIgnoredDuringExecution</strong>.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p19665519228">Assume that the backend of an application has been created and has the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b67051008411">app=backend</strong> label.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen0560223122512">$ kubectl get po -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
backend-658f6cb858-dlrz8 1/1 Running 0 2m36s 172.16.0.67 192.168.0.100</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p1620441962614">You can configure the following pod affinity rule to deploy the frontend pods of the application to the same node as the backend pods.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen886384663812">apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: frontend
|
|
labels:
|
|
app: frontend
|
|
spec:
|
|
selector:
|
|
matchLabels:
|
|
app: frontend
|
|
replicas: 3
|
|
template:
|
|
metadata:
|
|
labels:
|
|
app: frontend
|
|
spec:
|
|
containers:
|
|
- image: nginx:alpine
|
|
name: frontend
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 200Mi
|
|
limits:
|
|
cpu: 100m
|
|
memory: 200Mi
|
|
imagePullSecrets:
|
|
- name: default-secret
|
|
affinity:
|
|
podAffinity:
|
|
requiredDuringSchedulingIgnoredDuringExecution:
|
|
- topologyKey: kubernetes.io/hostname
|
|
labelSelector:
|
|
matchExpressions:
|
|
- key: app
|
|
operator: In
|
|
values:
|
|
- backend</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p14534252192611">Deploy the frontend and you can find that the frontend is deployed on the same node as the backend.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen199741554162618">$ kubectl create -f affinity3.yaml
|
|
deployment.apps/frontend created
|
|
|
|
$ kubectl get po -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
backend-658f6cb858-dlrz8 1/1 Running 0 5m38s 172.16.0.67 192.168.0.100
|
|
frontend-67ff9b7b97-dsqzn 1/1 Running 0 6s 172.16.0.70 192.168.0.100
|
|
frontend-67ff9b7b97-hxm5t 1/1 Running 0 6s 172.16.0.71 192.168.0.100
|
|
frontend-67ff9b7b97-z8pdb 1/1 Running 0 6s 172.16.0.72 192.168.0.100</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p12885183116411">The <strong id="ucs_01_0152__en-us_topic_0000001244101079_b11928182514117">topologyKey</strong> field specifies the selection range. The scheduler selects nodes within the range based on the affinity rule defined. The effect of <strong id="ucs_01_0152__en-us_topic_0000001244101079_b18748184215413">topologyKey</strong> is not fully demonstrated in the preceding example because all the nodes have the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b774884217412">kubernetes.io/hostname</strong> label, that is, all the nodes are within the range.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p49155814502">To see how <strong id="ucs_01_0152__en-us_topic_0000001244101079_b12680174454114">topologyKey</strong> works, assume that the backend of the application has two pods, which are running on different nodes.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen152291428165020">$ kubectl get po -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
backend-658f6cb858-5bpd6 1/1 Running 0 23m 172.16.0.40 192.168.0.97
|
|
backend-658f6cb858-dlrz8 1/1 Running 0 2m36s 172.16.0.67 192.168.0.100</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p2799287516">Add the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b17590648194118">prefer=true</strong> label to nodes <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1595748154116">192.168.0.97</strong> and <strong id="ucs_01_0152__en-us_topic_0000001244101079_b15596124811411">192.168.0.94</strong>.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen690692725113">$ kubectl label node 192.168.0.97 prefer=true
|
|
node/192.168.0.97 labeled
|
|
$ kubectl label node 192.168.0.94 prefer=true
|
|
node/192.168.0.94 labeled
|
|
|
|
$ kubectl get node -L prefer
|
|
NAME STATUS ROLES AGE VERSION PREFER
|
|
192.168.0.100 Ready <none> 44m v1.15.6-r1-20.3.0.2.B001-15.30.2
|
|
192.168.0.212 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2
|
|
192.168.0.94 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true
|
|
192.168.0.97 Ready <none> 91m v1.15.6-r1-20.3.0.2.B001-15.30.2 true</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p82371197529">Define <strong id="ucs_01_0152__en-us_topic_0000001244101079_b226612577417">topologyKey</strong> in the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b5266857174110">podAffinity</strong> section as <strong id="ucs_01_0152__en-us_topic_0000001244101079_b13266757194119">prefer</strong>.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen14634134685215"> affinity:
|
|
podAffinity:
|
|
requiredDuringSchedulingIgnoredDuringExecution:
|
|
- topologyKey: prefer
|
|
labelSelector:
|
|
matchExpressions:
|
|
- key: app
|
|
operator: In
|
|
values:
|
|
- backend</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p885461775317">The scheduler recognizes the nodes with the <strong id="ucs_01_0152__b325671472018">prefer</strong> label, that is, <strong id="ucs_01_0152__b625681492014">192.168.0.97</strong> and <strong id="ucs_01_0152__b12256171462019">192.168.0.94</strong>, and then finds the pods with the <strong id="ucs_01_0152__b15256171442019">app=backend</strong> label. In this way, all frontend pods are deployed onto <strong id="ucs_01_0152__b172571314202012">192.168.0.97</strong>.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen11211143375517">$ kubectl create -f affinity3.yaml
|
|
deployment.apps/frontend created
|
|
|
|
$ kubectl get po -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
backend-658f6cb858-5bpd6 1/1 Running 0 26m 172.16.0.40 192.168.0.97
|
|
backend-658f6cb858-dlrz8 1/1 Running 0 5m38s 172.16.0.67 192.168.0.100
|
|
frontend-67ff9b7b97-dsqzn 1/1 Running 0 6s 172.16.0.70 192.168.0.97
|
|
frontend-67ff9b7b97-hxm5t 1/1 Running 0 6s 172.16.0.71 192.168.0.97
|
|
frontend-67ff9b7b97-z8pdb 1/1 Running 0 6s 172.16.0.72 192.168.0.97</pre>
|
|
</div>
|
|
<div class="section" id="ucs_01_0152__en-us_topic_0000001244101079_section59542620588"><h4 class="sectiontitle">Workload Anti-Affinity (podAntiAffinity)</h4><p id="ucs_01_0152__en-us_topic_0000001244101079_p1837112018595">Unlike the scenarios in which pods are preferred to be scheduled onto the same node, sometimes, it could be the exact opposite. For example, if certain pods are deployed together, they will affect the performance.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p660518191831">The following example defines an inter-pod anti-affinity rule, which specifies that pods must not be scheduled to nodes that already have pods with the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1294051894217">app=frontend</strong> label, that is, to deploy the pods of the frontend to different nodes with each node has only one replica.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen204251341745">apiVersion: apps/v1
|
|
kind: Deployment
|
|
metadata:
|
|
name: frontend
|
|
labels:
|
|
app: frontend
|
|
spec:
|
|
selector:
|
|
matchLabels:
|
|
app: frontend
|
|
replicas: 5
|
|
template:
|
|
metadata:
|
|
labels:
|
|
app: frontend
|
|
spec:
|
|
containers:
|
|
- image: nginx:alpine
|
|
name: frontend
|
|
resources:
|
|
requests:
|
|
cpu: 100m
|
|
memory: 200Mi
|
|
limits:
|
|
cpu: 100m
|
|
memory: 200Mi
|
|
imagePullSecrets:
|
|
- name: default-secret
|
|
affinity:
|
|
podAntiAffinity:
|
|
requiredDuringSchedulingIgnoredDuringExecution:
|
|
- topologyKey: kubernetes.io/hostname
|
|
labelSelector:
|
|
matchExpressions:
|
|
- key: app
|
|
operator: In
|
|
values:
|
|
- frontend</pre>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p5965143131410">Deploy the frontend and query the deployment results. You can find that each node has only one frontend pod and one pod of the Deployment is <strong id="ucs_01_0152__en-us_topic_0000001244101079_b0841427104217">Pending</strong>. This is because when the scheduler is deploying the fifth pod, all nodes already have one pod with the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b108411827144217">app=frontend</strong> label on them. There is no available node. Therefore, the fifth pod will remain in the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b15841192744210">Pending</strong> status.</p>
|
|
<pre class="screen" id="ucs_01_0152__en-us_topic_0000001244101079_screen74071719171410">$ kubectl create -f affinity4.yaml
|
|
deployment.apps/frontend created
|
|
|
|
$ kubectl get po -o wide
|
|
NAME READY STATUS RESTARTS AGE IP NODE
|
|
frontend-6f686d8d87-8dlsc 1/1 Running 0 18s 172.16.0.76 192.168.0.100
|
|
frontend-6f686d8d87-d6l8p 0/1 Pending 0 18s <none> <none>
|
|
frontend-6f686d8d87-hgcq2 1/1 Running 0 18s 172.16.0.54 192.168.0.97
|
|
frontend-6f686d8d87-q7cfq 1/1 Running 0 18s 172.16.0.47 192.168.0.212
|
|
frontend-6f686d8d87-xl8hx 1/1 Running 0 18s 172.16.0.23 192.168.0.94 </pre>
|
|
</div>
|
|
<div class="section" id="ucs_01_0152__en-us_topic_0000001244101079_section14975195565810"><h4 class="sectiontitle">Configuring Scheduling Policies</h4><ol id="ucs_01_0152__en-us_topic_0000001244101079_ol228103011185"><li id="ucs_01_0152__en-us_topic_0000001244101079_li32521216162315"><span>When creating a workload, click <span class="uicontrol" id="ucs_01_0152__en-us_topic_0000001244101079_uicontrol1869463216303"><b>Scheduling</b></span> in the <span class="uicontrol" id="ucs_01_0152__en-us_topic_0000001244101079_uicontrol2694103215303"><b>Advanced Settings</b></span> area.</span><p>
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" id="ucs_01_0152__en-us_topic_0000001244101079_table202751247311" frame="border" border="1" rules="all"><caption><b>Table 1 </b>Node affinity settings</caption><thead align="left"><tr id="ucs_01_0152__en-us_topic_0000001244101079_row6275154232"><th align="left" class="cellrowborder" valign="top" width="23.95%" id="mcps1.3.10.2.1.2.1.2.3.1.1"><p id="ucs_01_0152__en-us_topic_0000001244101079_p11274641534">Parameter</p>
|
|
</th>
|
|
<th align="left" class="cellrowborder" valign="top" width="76.05%" id="mcps1.3.10.2.1.2.1.2.3.1.2"><p id="ucs_01_0152__en-us_topic_0000001244101079_p12747418317">Description</p>
|
|
</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr id="ucs_01_0152__en-us_topic_0000001244101079_row1327511413311"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.1.2.1.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1827516415318">Required</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.1.2.1.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1427512410317">This is a hard rule that must be met for scheduling. It corresponds to <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1163153217176">required</strong><strong id="ucs_01_0152__en-us_topic_0000001244101079_b4163143281718">DuringSchedulingIgnoredDuringExecution</strong> in Kubernetes. Multiple required rules can be set, and scheduling will be performed if only one of them is met.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="ucs_01_0152__en-us_topic_0000001244101079_row112751441939"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.1.2.1.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p172751442316">Preferred</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.1.2.1.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p12275164932">This is a soft rule specifying preferences that the scheduler will try to enforce but will not guarantee. It corresponds to <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1873255212188">preferred</strong><strong id="ucs_01_0152__en-us_topic_0000001244101079_b973320529188">DuringSchedulingIgnoredDuringExecution</strong> in Kubernetes. Scheduling is performed when one rule is met or none of the rules are met.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</p></li><li id="ucs_01_0152__en-us_topic_0000001244101079_li442203101314"><span>Under <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1059013572035">Node Affinity</strong>, <strong id="ucs_01_0152__en-us_topic_0000001244101079_b292410716410">Workload Affinity</strong>, and <strong id="ucs_01_0152__en-us_topic_0000001244101079_b3235121110415">Workload Anti-Affinity</strong>, click <span><img id="ucs_01_0152__en-us_topic_0000001244101079_image684513499489" src="en-us_image_0000001322267590.png"></span> to add scheduling policies. In the dialog box displayed, add a policy directly or by specifying a node or an AZ.</span><p><div class="p" id="ucs_01_0152__en-us_topic_0000001244101079_p17631515161414">Specifying a node or an AZ is essentially implemented through labels. The <strong id="ucs_01_0152__en-us_topic_0000001244101079_b71812191020">kubernetes.io/hostname</strong> label is used when you specify a node, and the <strong id="ucs_01_0152__en-us_topic_0000001244101079_b1310915241324">failure-domain.beta.kubernetes.io/zone</strong> label is used when you specify an AZ.
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" id="ucs_01_0152__en-us_topic_0000001244101079_table723331051417" frame="border" border="1" rules="all"><caption><b>Table 2 </b>Scheduling policy configuration</caption><thead align="left"><tr id="ucs_01_0152__en-us_topic_0000001244101079_row102330108147"><th align="left" class="cellrowborder" valign="top" width="23.95%" id="mcps1.3.10.2.2.2.1.3.2.3.1.1"><p id="ucs_01_0152__en-us_topic_0000001244101079_p1423201015144">Parameter</p>
|
|
</th>
|
|
<th align="left" class="cellrowborder" valign="top" width="76.05%" id="mcps1.3.10.2.2.2.1.3.2.3.1.2"><p id="ucs_01_0152__en-us_topic_0000001244101079_p20232151015147">Description</p>
|
|
</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr id="ucs_01_0152__en-us_topic_0000001244101079_row19233110171411"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1323311105147">Label</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1423331081410">Node label. You can use the default label or customize a label.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="ucs_01_0152__en-us_topic_0000001244101079_row9233111019149"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p3233191011410">Operator</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1723314104146">The following relations are supported: <strong id="ucs_01_0152__en-us_topic_0000001244101079_b169191614122213">In</strong>, <strong id="ucs_01_0152__en-us_topic_0000001244101079_b164771016162210">NotIn</strong>, <strong id="ucs_01_0152__en-us_topic_0000001244101079_b898721992219">Exists</strong>, <strong id="ucs_01_0152__en-us_topic_0000001244101079_b669812342212">DoesNotExist</strong>, <strong id="ucs_01_0152__en-us_topic_0000001244101079_b168911924102311">Gt</strong>, and <strong id="ucs_01_0152__en-us_topic_0000001244101079_b889162462311">Lt</strong></p>
|
|
<ul id="ucs_01_0152__en-us_topic_0000001244101079_ul10233151017145"><li id="ucs_01_0152__en-us_topic_0000001244101079_li92331510131411"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b135661645112318">In</strong>: A label exists in the label list.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li423371031412"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b26231639172412">NotIn</strong>: A label does not exist in the label list.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li623351001416"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b152126283511">Exists</strong>: A specific label exists.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li14233171016140"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b975574143516">DoesNotExist</strong>: A specific label does not exist.</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li62331102148"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b15682967350">Gt</strong>: The label value is greater than a specified value (string comparison).</li><li id="ucs_01_0152__en-us_topic_0000001244101079_li15233121011411"><strong id="ucs_01_0152__en-us_topic_0000001244101079_b1330111719350">Lt</strong>: The label value is less than a specified value (string comparison).</li></ul>
|
|
</td>
|
|
</tr>
|
|
<tr id="ucs_01_0152__en-us_topic_0000001244101079_row1523391051416"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p4233181016141">Label Value</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1233131051415">Label value.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="ucs_01_0152__en-us_topic_0000001244101079_row13233810151420"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p196991729104014">Namespace</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p281835112545">This parameter is available only in a workload affinity or anti-affinity scheduling policy.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p47694256418">Namespace for which the scheduling policy takes effect.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="ucs_01_0152__en-us_topic_0000001244101079_row11982634104016"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p11982173424017">Topology Key</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p1073711319545">This parameter can be used only in a workload affinity or anti-affinity scheduling policy.</p>
|
|
<p id="ucs_01_0152__en-us_topic_0000001244101079_p1075725320423">Select the scope specified by <strong id="ucs_01_0152__en-us_topic_0000001244101079_b194618313486">topologyKey</strong> and then select the content defined by the policy.</p>
|
|
</td>
|
|
</tr>
|
|
<tr id="ucs_01_0152__en-us_topic_0000001244101079_row1389112844120"><td class="cellrowborder" valign="top" width="23.95%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.1 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p168911385411">Weight</p>
|
|
</td>
|
|
<td class="cellrowborder" valign="top" width="76.05%" headers="mcps1.3.10.2.2.2.1.3.2.3.1.2 "><p id="ucs_01_0152__en-us_topic_0000001244101079_p98926814113">This parameter can be set only in a <strong id="ucs_01_0152__en-us_topic_0000001244101079_b57171024471">Preferred</strong> scheduling policy.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
</p></li></ol>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="ucs_01_0105.html">Workload Management</a></div>
|
|
</div>
|
|
</div>
|
|
|