当前位置: 首页 > 知识库问答 >
问题:

Kubernetes pod 亲和力 - 在不同节点上调度 pod

申屠晟
2023-03-14

我们在一个3节点kubernetes集群上用3个pods运行我们的应用程序。当我们部署应用程序时,有时,pods被调度到同一个kubernetes节点。

我们希望我们的 Pod 以这样一种方式调度,即它将我们的 Pod 分布在节点上(同一应用程序的 2 个 Pod 不应该是同一个节点)。事实上,根据文档(https://kubernetes.io/docs/concepts/configuration/assign-pod-node/),kubernetes 在这方面已经做得很好。但是,如果找不到资源,则会将其调度到同一节点。它如何使其成为硬约束?

要求:如果pod不遵守约束,我们希望部署失败或处于挂起状态(同一个应用程序的没有2个pod应该是同一个节点)

共有1个答案

云承天
2023-03-14

我想这个会有用的

affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - <VALUE>
        topologyKey: "kubernetes.io/hostname"

有关更多参考,您可以访问:https://thenewstack.io/implement-node-and-pod-affinity-anti-affinity-in-kubernetes-a-practical-example/

 类似资料:
  • k8s节点关联文档解释了如何通过首先用标签标记节点并使用nodeSelector选择节点来将pod部署到特定节点。 但是,我有一个用例,我在集群中有40-50个部署,我希望向集群添加一个新节点,并将该节点设置为专用于其中一个部署/吊舱,而不更改所有那些没有指定nodeSelector的部署 我唯一能想到的是污染节点,但如果我这样做了,没有一个豆荚会被调度到那里。 这里有没有一个更好的方法来实现这个

  • 如果我只使用CoreOS和fleet,我可以在单元文件中指定我希望某些服务不与其他服务运行在同一物理机器上(反亲和性)。这对于高可用性来说是必不可少的。但是看起来kubernetes还没有这个功能。 在我的特定用例中,我将需要运行几个elasticsearch机器集群,这些机器需要始终可用。如果出于任何原因,kubernetes决定在一台机器上为给定的ES集群调度我的所有elasticsearch

  • 一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的,默认情况下调度器考虑的是资源足够,并且负载尽量平均,但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度,比如我们内部的一些服务 gitlab 之类的也是跑在Kubernetes集群上的,我们就不希望对外的一些服务和内部的服务跑在同一个节点上了,害怕内部服务对外部的服务产生影响;但是有的时候我们的服务之间交流比较频繁,又希望

  • 每当 Pod 在其上计划或取消计划时,我都需要在节点 shell 级别(而不是容器内)运行脚本。我已经搜索了文档,但只找到了添加在容器内运行的钩子的方法(https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/、https://kubernetes.io/docs/concept

  • 使用复制控制器,当我调度一个pod的2个(两个)副本时,我期望每个节点中各有1个(一个)副本。相反,我发现两个副本都是在同一个吊舱中创建的。这将使1个节点成为我需要避免的单点故障。 对于2个pod:节点A中的1个pod,节点B中的1个pod 对于3个吊舱:节点A中的2个吊舱,节点B中的1个吊舱,kubernetes可以根据资源可用性进行调度 有没有正确配置的建议吗?

  • 我有一个多分支管道架构的以下Jenkinsfile 我试图在Ubuntu和Red Hat节点上并行运行“构建”阶段,而仅在Ubuntu节点上运行“测试”阶段。 任何人都可以帮助我指定如何选择在哪些节点上运行哪些阶段。我在网上找到的解决方案很少,但他们建议重写构建阶段两次:一次用于Red Hat节点,另一次用于Ubuntu节点。难道没有办法在没有代码重复的情况下做到这一点吗? 非常感谢