Administrator
发布于 2025-10-30 / 4 阅读
0
0

pod反亲和使多副本被分配到不同节点上

一、背景

最近由于业务量激增,导致负责主要业务的 pod 副本数量不足,所以临时又增加了几个副本。本以为这样就 OK 了,但是没想到新增加的 pod 副本都被分配到了同一个节点上,致使该节点资源紧张最终出现异常(该节点上的 pod 副本无法正常启动)。

就此问题,下面的内容里我将介绍下我们的解决方案。

二、解决方案

我们是通过借助 K8s 的「pod 非亲缘性」来解决这个问题,先看一段儿 Deployment 的 yaml 文件片段截图:

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - app-service
          topologyKey: kubernetes.io/hostname

🧠 含义详解

配置项

作用

说明

affinity

亲和性规则总入口

包含三类:nodeAffinity

(节点亲和)、podAffinity

(Pod 亲和)和 podAntiAffinity

(Pod 反亲和)

podAntiAffinity

Pod 反亲和规则

表示调度器会尽量避免把指定的 Pod 调度到同一个节点上。

preferredDuringSchedulingIgnoredDuringExecution

软约束(soft rule)

调度器会“尽量满足”规则,但不是强制的。如果资源紧张也可以忽略。
(对应的强约束是 requiredDuringSchedulingIgnoredDuringExecution

weight: 100

权重(0~100)

表示满足该规则的节点“得分更高”,调度时更倾向选择它。权重越高优先级越高。

podAffinityTerm

匹配条件定义

定义“哪些 Pod”需要避开。

labelSelector

标签选择器

匹配 app=app-service

的 Pod。

topologyKey: kubernetes.io/hostname

拓扑域键

表示“在不同节点上”进行分布。kubernetes.io/hostname

表示节点名,不让这些 Pod 落在同一节点。

三、参考链接


评论