nodeSelector
pod只会运行在匹配nodeSelector的node上。
要使用这个功能需要先配置node label。
使用如下命令获取集群中的节点
kubectl get nodes
为节点添加label
kubectl label nodes =
查看所有node分配的label
kubectl get nodes --show-labels
查看某一个节点分配的label
kubectl describe node "nodename"
pod描述文件中添加nodeSelector
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
Node Affinity
用于限制node可以被调度在哪些node上。
Node Affinity有两种类型：
- requiredDuringSchedulingIgnoredDuringExecution: 强制要求，必须满足条件。
- preferredDuringSchedulingIgnoredDuringExecution: 非强制要求，k8s尽量满足要求。
如果node的label改变后，已经在这个node上运行的pod的nodeSelector不匹配修改后的label，这些pod仍会继续运行。
一个使用例子如下：
apiVersion: 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
如果同时指定了nodeSelector和nodeAffinity, pod会调度到这两个条件都满足的节点上。
如果在nodeAffinity中使用了nodeSelectorTerms，node只要满足其中的一个条件，pod就可以调度到这个节点上。
如果在nodeAffinity中使用了matchExpressions，pod只会调度到满足所有表达式的节点上。
node label如果修改了，已经运行的pod不会受到任何影响。nodeAffinity仅在调度阶段起作用。
Inter-pod affinity and anti-affinity
和node affinity不同的是，这种亲和性的目标指的是和pod的亲和性，而不是node本身。比如pod X的亲和性设置为Y，那么X会被调度到正在运行着Y的对象上去。这里的对象可以是node，机架或云提供商区域等，使用topologyKey来标记。
topologyKey的可能取值如下：
- kubernetes.io/hostname
- failure-domain.beta.kubernetes.io/zone
- failure-domain.beta.kubernetes.io/region
- topology.kubernetes.io/zone
- topology.kubernetes.io/region
- beta.kubernetes.io/instance-type
- node.kubernetes.io/instance-type
- kubernetes.io/os
- kubernetes.io/arch
其中kubernetes.io/hostname为node级别。kubernetes.io/os为操作系统类型级别。kubernetes.io/arch为CPU架构级别。
和node affinity相同，pod affinity也具有强制(requiredDuringSchedulingIgnoredDuringExecution)和非强制(preferredDuringSchedulingIgnoredDuringExecution)配置。
pod affinity的一个例子：
apiVersion: v1
kind: Pod
metadata:
name: with-pod-affinity
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S1
topologyKey: failure-domain.beta.kubernetes.io/zone
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: security
operator: In
values:
- S2
topologyKey: failure-domain.beta.kubernetes.io/zone
containers:
- name: with-pod-affinity
image: k8s.gcr.io/pause:2.0
如果pod affinity或anti-affinity使用requiredDuringSchedulingIgnoredDuringExecution，必须制定topologyKey。
如果pod affinity或anti-affinity使用preferredDuringSchedulingIgnoredDuringExecution，不指定topologyKey的含义为所有的topologies，即上述topologyKey所有可能值。
使用例子1：
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine
以上配置app=store的pod不会在一个节点运行两个。
使用例子2：
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
selector:
matchLabels:
app: web-store
replicas: 3
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx:1.12-alpine
app=store这个pod不会在同一个节点运行多个，会和app=store（应该是in，但是上个例子中pod的label为app=store），运行在同一个节点中。
NodeName
Pod调度到特定name的节点上。
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
nodeName: kube-01
Taint and Toleration
Node Affinity（节点亲和性）用于指定pod可以运行在哪些node上。Taint是相反的作用，用于指定Pod不能在哪些节点运行。
Taint意为污点，标记为污点的节点，不会有node调度到这台机器上。一个污点具有3个组成部分，key、value和effect。
Toleration为容忍，如果一个pod配置的容忍和节点的污点相匹配，那么此pod可以被调度在这个节点上。
如果使用preferredDuringSchedulingIgnoredDuringExecution，它有一个权重值weight的配置。权重值大的条件会优先被满足。
Taint的配置
下面为node1增加一个taint：
kubectl taint nodes node1 key=value:NoSchedule
这里NoSchedule的含义为除非pod具有符合条件的toleration（容忍），任何pod都不会调度到这个节点上。
要删除node1的污点，可以执行如下命令：
kubectl taint nodes node1 key:NoSchedule-
Toleration的配置
在pod的spec下增加：
tolerations:
- key: "key"
operator: "Equal"
value: "value"
effect: "NoSchedule"
意思为该pod可以调度到污点为key=value，effect为NoSchedule的节点上。
tolerations:
- key: "key"
operator: "Exists"
effect: "NoSchedule"
意思为该pod可以调度到污点存在名字为"key"的键，effect为NoSchedule的节点上。
一个完整的pod描述文件实例如下：
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
tolerations:
- key: "example-key"
operator: "Exists"
effect: "NoSchedule"
一个节点可以配置多个污点，pod只有容忍所有的污点，才有可能被调度到这个节点上。
特殊情况
tolerations:
- operator: "Exists"
使用Exists，不指定key的话，可以匹配所有的key，value和effect
tolerations:
- key: "key"
operator: "Exists"
使用Exists，指定key，但是不指定effect，可以匹配所有的effect。
effect的三种类型
- NoSchedule：不会调度到该节点上
- PreferNoSchedule：尽最大可能不调度到该节点上，但是不保证绝不调度到该节点上
- NoExecute：如果节点被标记为NoExecute污点之前有pod不容忍这个污点，这些pod会被立刻清除掉。
可以配置pod容忍在NoExecute节点下运行一段时间，配置如下所示。
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"
tolerationSeconds: 3600
查看pod在哪个节点运行的命令
kubectl get pods -o wide