Kubernetes(K8S) 入门进阶实战完整教程-05k8s的Pod详解-03调度
概述
在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式。
- 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
- 定向调度：NodeName, NodeSelector
- 亲和性调度：NodeAffinity, PodAffinity, PodAntiAffinity
- 污点（容忍）调度：Taints, Toleration
定向调度
- 概述
定向调度，指的是利用在Pod上声明的nodeName或nodeSelector，以此将Pod调度到期望的Node节点上。注意，这里的调度是强制的，这就意味着即使要调度的目标Node不存在，也会向上面进行调度，只不过Pod运行失败而已。 - nodeName
● nodeName用于强制约束将Pod调度到指定的name的Node节点上。这种方式，其实是直接跳过Scheduler的调度逻辑，直接将Pod调度到指定名称的节点。
● 创建一个pod-nodename.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-nodename
namespace: dev
labels:
user: mayanan
spec:
containers: # 容器配置
- name: nginx
image: nginx:1.17.1
imagePullPolicy: IfNotPresent
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
nodeName: node1 # 指定将pod调度到node1节点上
创建Pod
kubectl create -f pod-nodename.yaml
3. nodeSelector
● nodeSelector用于将Pod调度到添加了指定标签的Node节点上，它是通过kubernetes的label-selector机制实现的，换言之，在Pod创建之前，会由Scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将Pod调度到目标节点，该匹配规则是强制约束。
● 首先给node节点添加标签：
kubectl label node node2 version=v2
创建pod-podselector.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeselector
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeSelector:
version: v2 # 指定调度到具有version=v2标签的节点上
创建pod，查看pod所在节点
kubectl create -f pod-nodeselector.yaml
kubectl get pod pod-nodeselector -n dev -o wide
亲和性调度概述
- 虽然定向调度的两种方式，使用起来非常方便，但是也有一定的问题，那就是如果没有满足条件的Node，那么Pod将不会被运行，即使在集群中还有可用的Node列表也不行，这就限制了它的使用场景。
- 基于上面的问题，kubernetes还提供了一种亲和性调度（Affinity）。它在nodeSelector的基础之上进行了扩展，可以通过配置的形式，实现优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使得调度更加灵活。
- Affinity主要分为三类：
- nodeAffinity(node亲和性): 以Node为目标，解决Pod可以调度到哪些Node的问题；
- podAffinity(pod亲和性): 以Pod为目标，解决Pod可以和那些已存在的Pod部署在同一拓扑域中的问题；
- podAntiAffinity(pod反亲和性): 以Pod为目标，解决Pod不能和那些已经存在的Pod部署在同一拓扑域中的问题。
- 关于亲和性和反亲和性使用场景的说明：
- 亲和性：如果两个应用频繁交互，那么就有必要利用亲和性将两个应用尽可能的靠近，这样可以减少因网络通信带来的性能损耗
- 反亲和性：当应用采用多副本部署的时候，那么就有必要利用反亲和性将各个应用示例打散分不到各个Node节点上，这样可以提高服务的高可用性。
亲和性调度-nodeAffinity
- 查看一下nodeAffinity配置向
kubectl explain pod.spec.affinity.nodeAffinity
requiredDuringSchedulingIgnoredDuringExecution Node节点必须满足指定的所有规则才可以，相当于硬限制
nodeSelectorTerms 节点选择列表
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, Lt
preferredDuringSchedulingIgnoredDuringExecution 优先调度到满足指定的规则的Node，相当于软限制 (倾向)
preference 一个节点选择器项，与相应的权重相关联
matchFields 按节点字段列出的节点选择器要求列表
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt
weight 倾向权重，在范围1-100。
- 关系符的使用说明
- matchExpressions:
- key: nodeenv # 匹配存在标签的key为nodeenv的节点
operator: Exists
- key: nodeenv # 匹配标签的key为nodeenv,且value是"xxx"或"yyy"的节点
operator: In
values: ["xxx","yyy"]
- key: nodeenv # 匹配标签的key为nodeenv,且value大于"xxx"的节点
operator: Gt
values: "xxx"
- 下面演示硬限制：requiredDuringSchedulingIgnoredDuringExecution：
创建文件：pod-nodeaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性配置
nodeAffinity: # node亲和性配置
requiredDuringSchedulingIgnoredDuringExecution: # node节点必须满足指定的所有规则才可以，相当于硬规则，类似于定向调度
nodeSelectorTerms: # 节点选择列表
- matchExpressions:
- key: name # 匹配存在的标签的key为name的节点，并且values是node1的节点
operator: In
values:
- "xxx"
- "yyy"
# - "node1" # 注意，如果添加上了node1, 因为有这个节点对应的标签，所以Pod就会成功调度到node1节点上去。
创建Pod，因为节点中key为name，值为xxx或yyy的节点并没有，所以Pod启动失败
kubectl create -f pod-nodeaffinity-required.yaml
4. 下面演示软限制：preferredDuringSchedulingIgnoredDuringExecution
创建文件pod-nodeaffinity-preferred.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-nodeaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
nodeAffinity: # 设置node亲和性
preferredDuringSchedulingIgnoredDuringExecution: # 软限制
- preference:
matchExpressions: # 匹配节点标签name在xxx或yyy(当前环境没有)
- key: name
operator: In
values: ["xxx", "yyy"]
weight: 1
创建pod，当前标签xxx或yyy没有匹配到任意节点，但是因为是软限制，还是会把该Pod调度到一个节点上去
kubectl create -f pod-nodeaffinity-prefered.yaml
5. nodeAffinity注意事项
如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都满足，Pod才能运行在指定的Node上。
如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可。
如果一个nodeSelectorTerms中有多个matchExpressions，则一个节点必须满足所有的才能匹配成功。
如果一个Pod所在的Node在Pod运行期间其标签发生了改变，不再符合该Pod的nodeAffinity的要求，则系统将忽略此变化。
亲和性调度-podAffinity
- podAffinity主要实现以运行的Pod为参照，实现让新创建的Pod和参照的Pod在一个区域的功能。
PodAffinity的可选配置项：
pod.spec.affinity.podAffinity
requiredDuringSchedulingIgnoredDuringExecution 硬限制
namespaces 指定参照pod的namespace
topologyKey 指定调度作用域
labelSelector 标签选择器
matchExpressions 按节点标签列出的节点选择器要求列表(推荐)
key 键
values 值
operator 关系符 支持In, NotIn, Exists, DoesNotExist.
matchLabels 指多个matchExpressions映射的内容
preferredDuringSchedulingIgnoredDuringExecution 软限制
podAffinityTerm 选项
namespaces
topologyKey
labelSelector
matchExpressions
key 键
values 值
operator
matchLabels
weight 倾向权重，在范围1-100
- topologyKey用于指定调度的作用域，例如:
如果指定为kubernetes.io/hostname，那就是以Node节点为区分范围。
如果指定为beta.kubernetes.io/os，则以Node节点的操作系统类型来区分。 - 首先创建一个参照Pod
创建pod-podaffinity-target.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-target
namespace: dev
labels:
podenv: pro # Pod的标签
spec:
containers:
- name: nginx
image: nginx:1.17.1
nodeName: node1
创建Pod kubectl create -f pod-podaffinity-target.yaml
4. 演示硬限制：requiredDuringSchedulingIgnoredDuringExecution
创建pod-podaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAffinity: # 设置pod亲和性
requiredDuringSchedulingIgnoredDuringExecution: # 硬限制
- namespaces: ["dev"]
topologyKey: kubernetes.io/hostname
labelSelector:
matchExpressions:
- key: podeenv
operator: In
values: ["xxx", "pro"] # 根据pod的标签去选择对应的节点
上面配置表达的意思是：新pod必须要与拥有标签podeenv=xxx或podenv=pro的pod在同一node上。
亲和性调度-podAntiAffinity
- podAntiAffinity主要实现以运行的Pod为参照，让新创建的Pod和参照的Pod不在一个区域的功能。
其配置方式和podAffinity一样，此处不做详细解释。
使用上个案例中的目标Pod： - 创建pod-podantiaffinity-required.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-podantiaffinity-required
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
affinity: # 亲和性设置
podAntiAffinity: # 设置Pod反亲和性
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: podenv
operator: In
values: ["xxx", "pro"]
topologyKey: kubernetes.io/hostname
创建pod，我们发现Pod已经被部署到了node2节点上，因为node1上已经有一个pod包含标签podenv=pro了。
kubectl create -f pod-podantiaffinity-required.yaml
调度-污点(Taints)
- 前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点属性，来决定是否运行Pod调度过来。
- Node被设置了污点之后就和Pod之间存在了一种相斥的关系，进而拒绝Pod调度进来，甚至可以将已经存在的Pod驱逐出去。
- 污点的格式为：key=value:effect，key和value是污点的标签，effect描述污点的作用，支持如下三个选项：
- PreferNoSchedule: kubernetes将尽量避免把pod调度到具有该污点的node上，除非没有其它节点可以调度
- NoSchedule: kubernetes将不会把pod调度到具有该污点的node上，但是不会影响当前node上已经存在的pod
- NoExecute: kubernetes将不会把pod调度到具有该污点的node上，同时会把node上已经存在的pod驱逐
- 语法
（1）设置污点
kubectl taint node node_name key=value:effect
（2）去除污点
kubectl taint node node_name key:effect-
（3）去除所有污点
kubectl taint node node_name key- - 接下来演示下污点的效果
（1）准备节点node1（为了演示效果明显，暂时停止node2节点）
（2）为node1设置一个污点tag=heima:PreferNoSchedule，然后创建pod1
（3）修改node1节点的污点为：tag=heima:NoSchedule, 然后创建pod2
（3）修改node1节点的污点为：tag=heima:NoExecute, 然后创建pod3
# 为node1设置污点
kubectl taint node node1 tag=mayanan:PreferNoSchedule
# 创建pod1
kubectl run taint1 --image=nginx:1.17.1 -n dev
kubectl get pod -n dev -o wide
# 为node1设置污点，取消PreferNoSchedule, 设置NoSchedule
kubectl taint node node1 tag:PreferNoSchedule-
kubectl taint node node1 tag=mayanan:NoSchedule
# 创建pod2
kubectl run taint2 --image=nginx:1.17.1 -n dev
kubectl get pods -n dev -o wide
# 为node1设置污点，取消NoSchedule，设置NoExecute
kubectl taint node node1 tag:NoSchedule-
kubectl taint node node1 tag=mayanan:NoExecute
# 创建pod3
kubectl run taint3 --image=nginx:1.17.1 -n dev
kubectl get pods -n dev -o wide
注意：使用kubeadm创建的集群，默认就会给master节点上添加一个污点标记，所以pod就不会被调度到master节点上。
调度-容忍（Toleration）
- 上面介绍了污点的作用，我们可以在Node上添加污点用来拒绝Pod调度上来，但是如果就是想让一个Pod调度到一个有污点的Node上去，这时候应该怎么做？这就需要使用到容忍
简而言之，言而总之：污点就是拒绝，容忍就是忽略，Node通过污点拒绝Pod调度上去，Pod通过容忍忽略拒绝。 - 容忍的详细配置
kubectl explain pod.spec.tolerations
......
FIELDS:
key # 对应着要容忍的污点的键，空意味着匹配所有的键
value # 对应着要容忍的污点的值
operator # key-value的运算符，支持Equal和Exists（默认）,Exists表示匹配键就可以，value可以省略
effect # 对应污点的effect，空意味着匹配所有影响
tolerationSeconds # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间
- 创建pod-toleration.yaml文件
apiVersion: v1
kind: Pod
metadata:
name: pod-toleration
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
tolerations: # 添加容忍
- key: tag # 要容忍的污点的key
operator: Equal # 操作符Equal或Exists
value: mayanan # 容忍的污点的value
effect: NoExecute # 添加容忍的规则，这里必须和标记的污点规则相同
创建pod，查看pod
kubectl create -f pod-toleration.yaml
kubectl get pod -n dev -o wide
