反亲和性调度:就好像2个Pod是赌气的2个孩子,互相对着干,一个往东,另一随便去哪个方向就是不往东,他们不会去到同一个地方。 4.1、记住这3种调度关系 亲和性调度 和 反亲和性调度的关系就3种: node亲和调度:硬亲和、软亲和 pod亲和调度:硬亲和、软亲和 pod反亲和调度:硬亲和、软亲和 4.2、记住这2种亲和表...
podAntiAffinity(pod 反亲和性):该 Pod 不喜欢和某些 Pod 调度在一起 上面三种亲和性调度,无论是哪一种,都要依赖标签才能起作用,只是不同的亲和性调度方法,亲和性调度器匹配标签的对象不同 node 亲和性:检查的是亲和性调度器与 node 标签的匹配 pod (反)亲和性:检查的是亲和性调度器与 pod 标签的匹配 4....
反亲和性(Anti-Affinity)是一种在Kubernetes(K8s)中用于控制容器调度策略的机制。 具体来说,反亲和性定义了某些Pod(容器组)不能在同一个节点上运行。这种机制主要是出于高可靠性的考虑,通过尽量分散实例来避免资源竞争和单点故障。当某个节点发生故障时,由于实例被分散部署,因此故障对应用的影响只是整体的一部分,而...
然后我们在 Pod 中添加了三个 Tolerations,一个用于容忍 disk-pressure=Ture 的节点,一个用于容忍存在 Nvidia GPU 的节点,一个用于容忍存在自定义 Taints 的节点,但只是尽量不要调度到该节点上。 在使用亲和性、反亲和性、污点和容忍时需要注意以下几点: 亲和性和反亲和性只在节点之间的调度时生效,而不会影响 Po...
利用K8S 的反亲和性构建高可用应用 K8S 支持多副本部署,但不代表应用的高可用,因为多个副本可能部署到同一个节点上。 早上发现应用的某一个功能有一半的请求失败,排查之后发现,原来容器服务中节点未设置反亲和性,导致 Pod 部署到同一个节点中,影响API 网关请求后端服务。
nodeSelector可以很方便的解决以上比较简单的需求,但是它还不够灵活。比如我想以机架为单位,部署的服务可以很好的分散在不同机架的服务器上,此时nodeSelector就并不是那么管用了。因此,Kubernetes 引入了亲和性和反亲和性概念。 Affinity and anti-affinity
亲和和反亲和,包含两种类型:“节点亲和”和“pod间亲和/反亲和” 为何要做node亲和 我们在日常工作中经常会遇到要在k8s环境下维护多条产品线,甚至在微服务架构中,又有前端、中台、底层之分,如何将关联密切的服务划分到一组服务器上,保持架构的相对独立,避免交叉部署带来的管理和故障诊断难题,就用到了node亲和;所谓...
pod亲和性和反亲和性都是处理pod与pod之间的关系。 pod亲和性: 主要是想把pod和某个依赖的pod放在一起。 pod亲和性主要解决pod可以和哪些pod部署在同一个拓扑域中的问题(其中拓扑域用主机标签实现,可以是单个主机,也可以是多个主机组成的 cluster等等)
Kubernetes支持节点和Pod两个层级的亲和(affinity)与反亲和(anti-affinity)调度。通过配置亲和与反亲和规则,可以允许您指定硬性限制或者偏好,例如将前台Pod和后台Pod部署在一起、某类应用部署到某些特定的节点、不同应用部署到不同的节点等等。Pod模板中可以通过nodeS
Pod间亲和 & 反亲和 其他需要注意的点: pod调度到node(nodeSelector) AI检测代码解析 apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: # 匹配节点的label,多个label之间为‘与’关系 ...