环境正在生产中。我在集群中有156个GKE Node worker。 我想将1个(最大)nginx pod签名到1个节点。这意味着,我必须使用PodAntiAffinity。
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: project
operator: In
values:
- nginx-web
topologyKey: kubernetes.io/hostname
当我在暂存环境中对此进行测试时,预期会得到结果。
我的暂存GKE群集是“高可用性(Zonal)”,它意味着将工作节点部署到A,B和C区域。
具有“必需”模型的PodAntiAffinity
是将广告连播扩展到A,B,C区域还是由CloudProvider(GKE)自动控制?
我很好奇它的工作原理
我可能需要您的帮助,因此需要您的一些建议。
=============================
第二次尝试
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: project
operator: In
values:
- ingress-web
topologyKey: topology.kubernetes.io/zone
weight: 100
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: project
operator: In
values:
- nginx-web
topologyKey: kubernetes.io/hostname
答案 0 :(得分:0)
管理Pod在整个集群中的分布非常困难。众所周知的Kubernetes具有Pod亲和力和反亲和力功能,可以对Pod在不同拓扑中的位置进行一些控制。但是,这些功能只能解决部分Pod分发用例:将无限个Pod放置到单个拓扑中,或者不允许两个Pod共同位于同一拓扑中。在这两种极端情况之间,通常需要在各个拓扑之间均匀分布Pod,以实现更好的群集利用率和应用程序的高可用性。
PodTopologySpread调度插件(最初建议为EvenPodsSpread)旨在填补这一空白。在1.18中被提升为Beta。
字段pod.spec.topologySpreadConstraints
的介绍如下:
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
topologySpreadConstraints:
- maxSkew: <integer>
topologyKey: <string>
whenUnsatisfiable: <string>
labelSelector: <object>
您可以定义一个或多个topologySpreadConstraint
,以指示kube-scheduler如何相对于群集中的现有Pod放置每个传入Pod。字段是:
maxSkew 描述Pod分布不均匀的程度。它是给定拓扑类型的任何两个拓扑域中的匹配Pod数量之间的最大允许差异。它必须大于零。
topologyKey 是节点标签的键。如果两个节点都用此键标记并且具有相同的值,则调度程序会将两个节点都视为处于同一拓扑中。调度程序尝试将均衡数量的Pod放入每个拓扑域。
何时无法满足:指示不满足传播限制条件的Pod的处理方式:
DoNotSchedule(默认)告诉调度程序不要调度它。
ScheduleAnyway告诉调度程序在对节点进行优先级排序以最大程度地减少偏斜的同时仍要调度它。
labelSelector 用于查找匹配的Pod。计算与该标签选择器匹配的Pod,以确定其相应拓扑域中的Pod数。有关更多详细信息,请参见标签选择器
此博客here
中的一个很好的解释