1.给node节点打上标签
2.通过nodeSelectro 调度pod
- nodeSelectro为硬限制，必须要满足的条件有：指定标签和值。
- Affinity [əˈfɪnəti]/anti-affinity node 相对于nodeSelector机制更加的灵活和丰富
- 表达的语法：支持In,NotIn,Exists,DoesNotExist,Gt,Lt．匹配标签的方式
- 支持soft(preference)和hard(requirement),
- hard表示pod sheduler到某个node上时必须满足的亲和性设置．
- soft表示scheduler的时候，当无法满足节点的时候，会选择非 nodeSelector 匹配的节点．
- requiredDuringSchedulingIgnoredDuringExecution 硬亲和性 必须满足亲和性
- preferredDuringSchedulingIgnoredDuringExecution 软亲和性 能满足最好，不满足也没关系。
- nodeAffinity 的基础上添加多个 nodeSelectorTerms 字段，调度的时候 Node 只需要 nodeSelectorTerms 中的某一个符合条件就符合 nodeAffinity 的规则．在nodeSelectorTerms 中添加 matchExpressions，需要可以调度的Node是满足 matchExpressions 中表示的所有规则．
- 需要注意的是preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution名字中后半段字符串IgnoredDuringExecution表示的是，在Pod资源基于节点亲和性规则调度到某个节点之后，如果节点的标签发生了改变，调度器不会将Pod对象从该节点上移除，因为该规则仅对新建的Pod对象有效。
1.硬亲和性
- 硬亲和性是强制性的规则，Pod调度时必须满足的规则。
- 如果存在满足硬亲和性规则的节点，Pod将被调度至该节点；否则，Pod将无法正常调度，处于Pending状态。
2.软亲和性
- 软亲和性允许Pod对象定义针对一组可以调度于其上的节点的偏好，调度器会尽量满足此需求，但在无法满足调度需求时，它会退而求其次地选择一个不匹配规则的节点。
- 优化Pod的调度，以便将Pod调度到满足特定条件的节点上，从而实现更高效的资源利用、提高容错性和性能等方面的需求。
3.软硬亲和性同时存在
- 当软硬亲和性同时存在时，硬亲和性具有更高的优先级。调度器会首先检查硬亲和性规则，如果找到满足条件的节点，则将该Pod调度到该节点上。
- 如果找不到满足硬亲和性规则的节点，Pod将处于Pending状态，直到找到满足条件的节点或超时。
基于已经运行在 Node 上 pod 的 labels 来决定需要新创建的Pods是否可以调度到node节点上，配置的时候可以指定那个namespace中的pod需要满足pod的亲和性．可以通过 topologyKey 来指定 topology domain, 可以指定为 node／cloud provider zone 的范围．
- 表达的语法：支持In, NotIn, Exists, DoesNotExist
- Pod的亲和性和反亲和性可以分成
- requiredDuringSchedulingIgnoredDuringExecution # 硬要求
- preferredDuringSchedulingIgnoredDuringExecution ＃软要求
- labelSelector : 选择跟那组Pod亲和
- namespaces : 选择哪个命名空间
- topologyKey : 指定节点上的哪个键，可以设置成如下几种类型(节点标签) 1、标签是不是存在（硬性），2、节点key的值相同的情况下只启动一个 ， 应用场景 ，高可用 上海，北京， 广州 zone=beijing 多个node1-10 zone=shanghai 多个node11-20 zone=guangzhou 多个node21-30 rediis 3个节点 夸区高可用部署
- kubernetes.io/hostname ＃Node
- failure-domain.beta.kubernetes.io/zone ＃Zone
- 可以设置node上的label的值来表示node的name,zone,region等信息，pod的规则中指定topologykey的值表示指定topology 范围内的 node 上运行的 pod 满足指定规则
1.pod亲和性
- Pod反亲和性场景，当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。
2.pod反亲和性
- Pod反亲和性场景，当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。
3.pod亲和性和反亲和性
1)、podAffinity 亲和性要求满足
- node上具有 kubernetes.io/hostname区域，并且 node 上运行有一个pod 包含标签 label为securtity=S1.
2)、podAntiAffinity 反亲和性要求满足
- 不会调度 pod 到运行包含有 security=S2 的 pod 的 node上．
- 如果这里将topologyKey＝ kubernetes.io/hostname，那么 pod 将不会调度到 node
- 满足的条件是：node上具有 kubernetes.io/hostname 相同的 value,并且这些相同 zone下的 node 上运行有 security=S2 的 pod
3)、对于topologyKey字段具有如下约束 第一步 要配置有key (节点标签名)， 第二步这个标签相同值的节点只能启动一个pod zone=cd
- topologyKey 定义pod亲和性调度和反亲和性调度中需要各个相关的pod对象是否运行于"同一位置"，指定“同一位置” 是通过 topologyKey 来定义的，topologyKey 对应的值是 node 上的一个标签名称
- 如果topologyKey指定区域已经在运行一个或多个满足LabelSelector规则的Pod，则该Pod应该（或者在非亲和性的情况下不应该）在 topologyKey 中运行
- 对于亲和性和 反亲和性 requiredDuringSchedulingIgnoredDuringExecution （硬亲和），topologyKey 不能为空。
- 对于 反亲和 性 requiredDuringSchedulingIgnoredDuringExecution（硬亲和） ，引入 LimitPodHardAntiAffinityTopology 准入控制器来限制 topologyKey 只能是 kubernetes.io/hostname。如果要使用自定义拓扑域，则需要修改准入控制器，或者直接禁用它。
- 对于反亲和性 preferredDuringSchedulingIgnoredDuringExecution （软亲和），空的 topologyKey 表示所有拓扑域，没有限制。
- topologyKey 除上述情况外，可以是 node 任何合法的标签 key。规则中可以指定匹配pod所在namespace,如果定义了但是为空，它表示所有namespace范围内的pod.
- 所有关联requiredDuringSchedulingIgnoredDuringExecution（硬亲和）的matchExpressions全都满足之后，系统才能将pod调度到某个node上。
4.topologKey 调度
需求：当前有两个机房（ beijing，shanghai），需要部署一个nginx产品，副本为两个，为了保证机房容灾高可用场景，需要在两个机房分别部署一个服务器
1.pod反亲和性调度
创建了一个Deployment,副本数为３，指定了反亲和规则如上所示，pod的label为app:store,那么pod调度的时候将不会调度到node上已经运行了label为app:store的pod了，这样就会使得Deployment的三副本分别部署在不同的host的node上
2.pod亲和性调度
在一个例子中基础之上，要求pod的亲和性满足 requiredDuringSchedulingIgnoredDuringExecution 中topologyKey=”kubernetes.io/hostname”,并且 node上需要运行有 app=store 的label.
3.pod亲和性调度
在一些应用中，pod副本之间需要共享cache,需要将pod运行在一个节点之上
污点（Taints）和污点容忍（Tolerations）是 Kubernetes（k8s）中用于节点调度的另一种重要机制。以下是对污点容忍调度的详细解释：
1、污点（Taints）
污点是定义在节点上的键值型属性数据，用于让节点拒绝将 Pod 调度运行于其上，除非 Pod 有接纳节点污点的容忍度。污点可以使节点能够排斥一类特定的 Pod，避免 Pod 调度到特定节点上。
污点的格式：
2、污点容忍（Tolerations）
污点容忍是定义在 Pod 上的键值型属性数据，用于配置 Pod 可容忍的污点。调度器只能将 Pod 调度到该 Pod 能够容忍的污点的节点上。
3.污点与容忍度匹配规则
- 当Pod的容忍度与节点的污点在键、值（当操作符为Equal时）和效应上完全匹配时，Pod可以被调度到该节点上。
- 如果Pod的容忍度使用Exists操作符，则只需匹配键和效应，无需匹配值。
- Pod可以具有多个容忍度，以匹配节点上的多个污点。
4.操作实例
5.设置容忍时间
- 污点容忍时间，主要涉及的是当节点被设置了NoExecute类型的污点时，Pod如果没有相应的容忍度，则会被驱逐出该节点。然而，如果Pod具有对应的容忍度，并且容忍度中设置了tolerationSeconds字段，那么Pod在被驱逐前还可以在节点上继续运行一段时间。tolerationSeconds字段指定了Pod在节点上可以继续运行的时间（单位为秒），这相当于给Pod一个宽限期，让其有时间完成必要的清理工作或等待其他操作完成。
6.污点驱逐
边我们提到了污点的effect可以设置为 NoExecute，它会影响节点上已经运行的pod，如下所示：
- 立即将没有配置容忍的pod逐出。
- 设置容忍但是没有指定 tolerationSeconds 参数的，那么该容忍永久生效。
- 设置容忍但是有指定 tolerationSeconds 参数的，那么在指定的时间内，容忍有效，超出指定时间后将被剔除。
此外，当某些条件为true时，节点控制器会自动污染节点。也就是k8s的内置污点：
- node.kubernetes.io/not-ready： 节点尚未准备好。这对应于NodeCondition Ready为false。
- node.kubernetes.io/unreachable： 无法从节点控制器访问节点。这对应于NodeCondition Ready 为Unknown。
- node.kubernetes.io/out-of-disk： 节点磁盘不足。
- node.kubernetes.io/memory-pressure： 节点有内存压力。
- node.kubernetes.io/disk-pressure： 节点有磁盘压力。
- node.kubernetes.io/network-unavailable： 节点的网络不可用。
- node.kubernetes.io/unschedulable： 节点不可调度。
- node.cloudprovider.kubernetes.io/uninitialized： 当kubelet从 “外部” 云提供程序开始时，此污点在节点上设置为将其标记为不可用。来自cloud-controller-manager的控制器初始化此节点后，kubelet删除此污点。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/jszy-jszl/69386.html