kube-scheduler 是 Kubernetes 集群的默认调度器; 在做调度决定时需要考虑的因素包括: 单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间 的干扰等等
一，指定nodeName
一，指定nodeName:(与containers同级别)
示例:
spec:
containers:
- name: nginx
image: nginx
nodeName: node1
1)如果节点没有资源容纳pod，则调度失败
2)节点不存在，调度失败
二，nodeSelector
二，nodeSelector(与containers同级别)
示例:
# 给node1打标签
kubectl label nodes node1 disktype=ssd
#指定按照标签选择节点
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
disktype: ssd
1) 如果没有匹配到标签会无法运行pod，pending状态
2) 删除node标签不会影响已运行的pod，伸缩或者重新部署会pending
三，亲和/反亲和
(基于上面的nodeSelector扩展，nodeSelector匹配不到标签会调度失败，可以发现规则是“软”/“偏好”，而不是硬性要求，因此，如果调度器无法满足该要求，仍然调度该pod)
节点亲和
• requiredDuringSchedulingIgnoredDuringExecution 必须满足
• preferredDuringSchedulingIgnoredDuringExecution 倾向满足
• IgnoreDuringExecution 表示如果在Pod运行期间Node的标签发生变化，导致 亲和性策略不能满足，则继续运行当前的Pod。
nodeaffinity还支持多种规则匹配条件的配置:
• In: label 的值在列表内
• NotIn: label 的值不在列表内
• Gt: label 的值大于设置的值，不支持Pod亲和性 • Lt:label 的值小于设置的值，不支持pod亲和性 • Exists:设置的label 存在
• DoesNotExist: 设置的 label 不存在
示例1: spec:
containers:
- name: nginx
image: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
必须满足，调度到标签为disktype=ssd的节点上
示例2:
template:
metadata:
labels:
app: nginx
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
weight: 1
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostnme
operator: NotIn
values:
- cn-shanghai.192.168.50.27
1） 倾向满足调度到，标签为disktype=ssd的节点上
2） 必须满足，不调度在节点cn-shanghai.192.168.50.27上
示例3:
template:
metadata:
labels:
app: nginx
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: disktype
operator: In
values:
- ssd
topologyKey: kubernetes.io/hostname
weight: 100
反亲和
不调度到，标签为disktype=ssd的节点
四，污点
# • Taints(污点)是Node的一个属性，设置了Taints后，所以Kubernetes是不会将 Pod调度到这个Node上的，
于是Kubernetes就给Pod设置了个属性Tolerations(容忍)， 只要 Pod能够容忍Node上的污点，那么Kubernetes就会忽略Node上的污点，就能够(不是必须)把Pod调度过去
tolerations中定义的key、value、effect，要与node上设置的taint保持一致:
• 如果 operator 是 Exists ，value可以省略。
• 如果 operator 是 Equal ，则key与value之间的关系必须相等。
• 如果不指定operator属性，则默认值为Equal
还有两个特殊值:
• 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。 • 当不指定effect ，则匹配所有的effect。
#必须满足
# 添加污点
kubectl taint node node1 node-role.kubernetes.io/master:NoSchedule
#Toleration(容忍)
operator可以定义为:
Equal:表示key是否等于value，默认 Exists:表示key是否存在，此时无需定义value
tain 的 effect 定义对 Pod 排斥效果
NoSchedule:仅影响调度过程，对现存的Pod对象不产生影响;
NoExecute:既影响调度过程，也影响显著的Pod对象;不容忍的Pod对象将被驱逐
PreferNoSchedule: 表示尽量不调度
#示例1:
spec:
containers:
- name: myapp
image: myapp:v1
tolerations:
- effect: NoExecute
key: kafka
operator: Equal
value: kafkadaptation
#以上的配置容忍kafka=kafkadaptation，则打了污点的标签可以调度(如果没有这个配置的容器，不可以被调度打了污点的节点上)
#示例2: containers:
- name: myapp
image: myapp:v1
tolerations:
- operator: "Exists"
effect: "NoSchedule"
tolerationSeconds: 6000(当 pod 需要被驱逐时，可以继续在 node 上 运行的时间)
# 当不指定key，再配合Exists 就能匹配所有的key与value ，可以容忍所有污点。(容忍后有污点的节点都可以调度)
1）如果effect是NoSchedule（如上），则打了污点的NoSchedule节点也会被调度
2）如果effect是NoExecute，则打了污点的NoExecute节点可以被调度
3）如果不指定effect，则忽视所有污点，所有打了污点的标签都可以被调度（如示例3）
#示例3:
containers:
- name: myapp
image: myapp:v1
tolerations:
- operator: "Exists"
# • 当不指定effect ，则匹配所有的effect。即所有污点都会忽视
PS1:
如果想让一个deployment不管有多少个pod都在一个节点上，
tolerations:
- effect: NoExecute
key: wd
operator: Equal
value: wd
只能NoExecute才可以做到
PS2:
如果10个节点打了一样的污点，有10个deployment需要在这10台机器跑，并且各个服务之间的pod不能再用一个节点上（10个deployment各只有一个pod为例）
# 设置pod反亲和
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: adaptor
operator: In
values:
- adaptor
topologyKey: kubernetes.io/hostname
containers:
... ...
resources:
requests:
cpu: 250m
memory: 64Mi
terminationGracePeriodSeconds: 30
# 增加容忍度
tolerations:
- effect: NoExecute
key: kafka
operator: Equal
value: kafkadaptation
volumes:
- hostPath:
path: /etc/localtime
type: ''
name: volume-localtime
