服务网站建设公司,哪个网站做体检预约的,狗和女人做的网站,太原开发网站公司默认的情况下#xff0c;一个pod在哪个node节点上运行#xff0c;是由scheduler组件采取对应的算法计算出来的#xff0c;这个过程是不受人工控制的#xff0c;在实际的使用过程中#xff0c;这不能够满足客观的场景#xff0c;针对这样的情况#xff0c;k8s 提供了四大…默认的情况下一个pod在哪个node节点上运行是由scheduler组件采取对应的算法计算出来的这个过程是不受人工控制的在实际的使用过程中这不能够满足客观的场景针对这样的情况k8s 提供了四大类调度方式
自动调度: 运行在哪个node节点上完全由scheduler 经过一些里的算法计算出来定向调度NodeName、NodeSelector亲和性调度NodeAffinity、PodAffinity、PodAntiAffinity污点(容忍)调度taints、Toleration
定向调度
定向调度指的是利用在 Pod 上声明的 nodeName 或 nodeSelector 以此将 Pod 调度到期望的 Node 节点上。这里的调度是强制的这就意味着即使要调度的目标 Node 不存在也会向上面进行调度只不过 Pod 运行失败而已。
NodeName方式调度
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:nodeName: k8s-node1 # 指定调度到k8s-node1节点上containers:- name: nginximage: nginx:1.20.2resources:limits:cpu: 200mmemory: 500Mirequests:cpu: 100mmemory: 200Miports:- containerPort: 80name: httpvolumeMounts:- name: localtimemountPath: /etc/localtimevolumes:- name: localtimehostPath:path: /usr/share/zoneinfo/Asia/ShanghairestartPolicy: AlwaysNodeSelector方式调度
apiVersion: v1
kind: Pod
metadata:name: nginxnamespace: defaultlabels:app: nginx
spec:nodeSelector:nodeevn: pro # 指定调度到 nodeevn pro 标签的 Node 节点上containers:- name: nginximage: nginx:1.20.2resources:limits:cpu: 200mmemory: 500Mirequests:cpu: 100mmemory: 200Miports:- containerPort: 80name: httpvolumeMounts:- name: localtimemountPath: /etc/localtimevolumes:- name: localtimehostPath:path: /usr/share/zoneinfo/Asia/ShanghairestartPolicy: Always亲和性调度
虽然定向调度的两种方式使用起来非常方便但是也有一定的问题那就是如果没有满足条件的 Node那么 Pod 将不会被运行即使在集群中还有可用的 Node 列表也不行这就限制了它的使用场景。基于上面的问题Kubernetes 还提供了一种亲和性调度Affinity。它在 nodeSelector 的基础之上进行了扩展可以通过配置的形式实现优先选择满足条件的 Node 进行调度如果没有也可以调度到不满足条件的节点上使得调度更加灵活。
● Affinity 主要分为三类 ○ nodeAffinitynode亲和性以 Node 为目标解决 Pod可 以调度到那些 Node 的问题。 ○ podAffinitypod亲和性以 Pod 为目标解决 Pod 可以和那些已存在的 Pod 部署在同一个拓扑域中的问题。 ○ podAntiAffinitypod反亲和性以 Pod 为目标解决 Pod 不能和那些已经存在的 Pod 部署在同一拓扑域中的问题。
关于亲和性和反亲和性的使用场景的说明 ● 亲和性如果两个应用频繁交互那么就有必要利用亲和性让两个应用尽可能的靠近这样可以较少因网络通信而带来的性能损耗。 ● 反亲和性当应用采用多副本部署的时候那么就有必要利用反亲和性让各个应用实例打散分布在各个 Node 上这样可以提高服务的高可用性。
pod.spec.affinity.nodeAffinityrequiredDuringSchedulingIgnoredDuringExecution # Node节点必须满足指定的所有规则才可以硬性过滤nodeSelectorTerms # 节点选择列表matchFields # 按节点字段列出的节点选择器要求列表 matchExpressions # 按节点标签列出的节点选择器要求列表(推荐)key # 键values # 值operator # 关系符 支持Exists, DoesNotExist, In, NotIn, Gt, LtpreferredDuringSchedulingIgnoredDuringExecution # 优先调度到满足指定的规则的Node软性评分 (倾向) preference # 一个节点选择器项与相应的权重相关联matchFields # 按节点字段列出的节点选择器要求列表matchExpressions # 按节点标签列出的节点选择器要求列表(推荐)key # 键values # 值operator # 关系符 支持In, NotIn, Exists, DoesNotExist, Gt, Lt weight # 倾向权重在范围1-100。● podAffinity 主要实现以运行的 Pod 为参照实现让新创建的 Pod 和参照的 Pod 在一个区域的功能。 ● podAntiAffinity 主要实现以运行的 Pod 为参照让新创建的 Pod 和参照的 Pod 不在一个区域的功能。 ● PodAffinity 的可选配置项
pod.spec.affinity.podAffinityrequiredDuringSchedulingIgnoredDuringExecution 硬限制namespaces 指定参照pod的namespacetopologyKey 指定调度作用域labelSelector 标签选择器matchExpressions 按节点标签列出的节点选择器要求列表(推荐)key 键values 值operator 关系符 支持In, NotIn, Exists, DoesNotExist.matchLabels 指多个matchExpressions映射的内容 preferredDuringSchedulingIgnoredDuringExecution 软限制 podAffinityTerm 选项namespacestopologyKeylabelSelectormatchExpressions key 键 values 值 operatormatchLabels weight 倾向权重在范围1-1污点和容忍
● 前面的调度方式都是站在 Pod 的角度上通过在 Pod 上添加属性来确定 Pod 是否要调度到指定的 Node 上其实我们也可以站在 Node 的角度上通过在 Node 上添加污点属性来决定是否运行 Pod 调度过来。 ● Node 被设置了污点之后就和 Pod 之间存在了一种相斥的关系进而拒绝 Pod 调度进来甚至可以将已经存在的 Pod 驱逐出去。
污点的格式为
keyvalue:effect
key 和 value 是污点的标签及对应的值
effect 描述污点的作用
● effect 支持如下的三个选项 ○ PreferNoScheduleKubernetes 将尽量避免把 Pod 调度到具有该污点的 Node 上除非没有其他节点可以调度换言之尽量不要来除非没办法。 ○ NoScheduleKubernets 将不会把 Pod 调度到具有该污点的 Node 上但是不会影响当前 Node 上已经存在的 Pod ;换言之新的不要来在这的就不要动。 ○ NoExecuteKubernets 将不会将 Pod 调度到具有该污点的 Node 上同时会将 Node 上已经存在的 Pod 驱逐换言之新的不要来这这里的赶紧走。
新增污点
kubectl taint node xxx keyvalue:effect
去除污点
kubectl taint node xxx key:effect-
去除所有污点
kubectl taint node xxx key-
查看污点
kubectl describe node xxx | grep -i taints 容忍
● 上面介绍了污点的作用我们可以在 Node上 添加污点用来拒绝 Pod 调度上来但是如果就是想让一个 Pod 调度到一个有污点的 Node 上去这时候应该怎么做这就需要使用到容忍。
污点就是拒绝容忍就是忽略Node 通过污点拒绝 Pod 调度上去Pod 通过容忍忽略拒绝。
kubectl explain pod.spec.tolerations … FIELDS: key # 对应着要容忍的污点的键空意味着匹配所有的键 value # 对应着要容忍的污点的值 operator # key-value的运算符支持Equal和Exists默认 effect # 对应污点的effect空意味着匹配所有影响 tolerationSeconds # 容忍时间, 当effect为NoExecute时生效表示pod在Node上的停留时间
● 污点和容忍的匹配 ○ 当满足如下条件的时候Kubernetes 认为污点和容忍匹配 ■ 键key相同。 ■ 效果effect相同。 ■ 污点的 operator 为 ● Exists 此时污点中不应该指定 value 。 ● Equal此时容忍的 value 应该和污点的 value 相同。 ○ 如果不指定 operator 默认为 Equal 。 ● 特殊情况 ○ 容忍中没有定义 key 但是定义了 operator 为 Exists Kubernetes 则认为此容忍匹配所有的污点如
tolerations:
- operator: Exists
# 最终所有有污点的机器我们都能容忍Pod 都可以调度。tolerations: # 容忍- key: tag # 要容忍的污点的keyoperator: Exists # 操作符
# 最终有这个污点的机器我们可以容忍Pod 都可以调度。
