污点
污点包含了 一个 key、 νalue,以及一个 effect,表现为
- NoSchedule 表示如果 pod 没有容忍这些污点, pod 则不能被调度到包含这 些污点的节点上。
- PreferNoSchedule 是 NoSchedule 的一个宽松的版本,表示尽量阻止 pod 被调度到这个节点上,但是如果没有其他节点可以调度, pod 依然会被调 度到这个节点上。
- NoExecute 不同于 NoSchedule 以及 PreferNoSchedule ,后两者只在调度期间起作用,而 NoExecute 也会影响正在节点上运行着的 pod。 如果 在一个节点上添加了 NoExecute 污点,那些在该节点上运行着的 pod,如果没有容忍这个 NoExecute 污点,将会从这个节点去除。
污点 taint 标记节点的命令如下:
kubectl taint nodes node01 node-type=test:NoSchedule

查看污点
kubectl describe nodes node01

所以我们这里要想 pod 能够调度到 node01 节点去,就需要增加容忍的声明:
cat > pod-toleration.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: default
labels:
app: myapp
type: pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
tolerations:
- key: "node-type"
operator: "Exists"
effect: "NoSchedule"
EOF


对于 tolerations 属性的写法,其中的 key、value、effect 与 Node 的 Taint 设置需保持一致, 还有以下几点说明:
- 如果 operator 的值是 Exists,则 value 属性可省略
- 如果 operator 的值是 Equal,则表示其 key 与 value 之间的关系是 equal(等于)
- 如果不指定 operator 属性,则默认值为 Equal
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: "NoSchedule"
tolerations:
- key: "node-type"
operator: "Equal"
value: "test"
effect: "NoSchedule"
另外,还有两个特殊值:
- 空的 key 如果再配合 Exists 就能匹配所有的 key 与 value,也是是能容忍所有 node 的所有 Taints
- 空的 effect 匹配所有的 effect
tolerations:
- key:
operator: "Exists"
effect:
去除指定key及其effect:
kubectl taint nodes node_name key:[effect]-
去除指定key所有的effect:
kubectl taint nodes node_name key-
nodeSelector
Pod 通过默认的 default-scheduler 调度器被绑定到了node01节点。不过需要注意的是nodeSelector属于强制性的,如果我们的目标节点没有可用的资源,Pod 就会一直处于 Pending 状态,这就是nodeSelector的用法。
cat > pod-nodeselector.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: default
labels:
app: myapp
type: pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
nodeSelector:
kubernetes.io/hostname: node01
EOF


节点亲和性
亲和性调度可以分成软策略和硬策略两种方式:
软策略就是如果你没有满足调度要求的节点的话,pod 就会忽略这条规则,继续完成调度过程,说白了就是满足条件最好了,没有的话也无所谓了的策略硬策略就比较强硬了,如果没有满足条件的节点的话,就不断重试直到满足条件为止,简单说就是你必须满足我的要求,不然我就不干的策略。
对于亲和性和反亲和性都有这两种规则可以设置: preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution,前面的就是软策略,后面的就是硬策略。
提供的操作符有下面的几种:
- In:label 的值在某个列表中
- NotIn:label 的值不在某个列表中
- Gt:label 的值大于某个值
- Lt:label 的值小于某个值
- Exists:某个 label 存在
- DoesNotExist:某个 label 不存在
如果
nodeSelectorTerms下面有多个选项的话,满足任何一个条件就可以了; 如果matchExpressions有多个选项的话,则必须同时满足这些条件才能正常调度 POD。
cat > pod-nodeAffinity.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity
namespace: default
labels:
app: myapp
type: pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node01
EOF

cat > pod-prefer.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: pod-prefer
namespace: default
labels:
app: myapp
type: pod
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 10
preference:
matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node01
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 20
preference:
matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- node02
EOF

pod亲和性
cat > pod-affinity.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: default
labels:
app: busybox
spec:
containers:
- name: busybox
image: busybox:1.28.4
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Pod
metadata:
name: pod-affinity
namespace: default
labels:
app: myapp
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- busybox
EOF

该部署将创建包含强制性要求的 pod,其中要求 pod 将被调度到包含 app=busybox 标签的 pod 所在的相同节点上
cat > pod-Preper.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: pod-preper
namespace: default
labels:
app: myapp
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 10
podAffinityTerm:
topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- busybox
EOF
了解 topologyKey 是如何工作的
举例来说,你有 20 个节点,每 10 个节点在同一个机柜中,你将前 10 个节点 加上标签 rack=rackl , 另外 10 个加上标签 rack=rack2 。 接着, 当定义 pod 的 podAffinity 时,将 toplogyKey 设置为 rack。
当调度器决定 pod 调度到哪里时, 它首先检查 pod 的 podAffinity 配置,找出那些符合标签选择器的 pod,接着查询这些 pod 运行在哪些节点上。特别的是, 它会寻找标签能匹配 podAffinity 配置中 topologyKey 的节点。接着,它会优先选择所有的标签匹配 pod 的值的节点。
pod反亲和性
pod 反亲和性则是反着来的,比如一个节点上运行了某个 pod,那么我们的 pod 则希望被调度到其他节点上去
cat > pod-Antiaffinity.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: pod-anti-affinity
namespace: default
labels:
app: myapp
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- busybox
EOF

