Kubernetes Deployment滚动更新后Pod节点分布失衡问题求助

问题根源分析 #

当前配置存在两个核心问题：

1. 拓扑约束的标签选择器范围过窄：topologySpreadConstraint中包含version: v1标签，滚动更新时新版本Pod的version标签会变化，导致调度器仅统计旧版本Pod的分布，无法约束新版本Pod的调度，最终出现分布失衡。
2. Pod反亲和与滚动更新策略不匹配：硬反亲和规则未配合合理的滚动更新策略，导致更新过程中无可用节点调度新Pod，触发Pending；软反亲和则无法强制保证分布。

最佳配置方案 #

1. 修正拓扑分布约束 #

移除topologySpreadConstraint中随版本变化的标签，确保调度器统计所有同应用的Pod，维持跨可用区的分布平衡：

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: my-apps

2. 配置节点级硬反亲和+匹配的滚动更新策略 #

通过kubernetes.io/hostname作为拓扑键，强制同一个节点仅部署一个目标Pod；同时调整滚动更新策略，先删除旧Pod再创建新Pod，避免更新过程中出现无节点可用的情况：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-apps
spec:
  replicas: 3
  revisionHistoryLimit: 0
  # 调整滚动更新策略
  strategy:
    rollingUpdate:
      maxSurge: 0          # 不允许额外创建Pod
      maxUnavailable: 1    # 允许最多1个Pod不可用
    type: RollingUpdate
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: app
                operator: In
                values:
                - my-apps
        # 节点级硬反亲和
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchLabels:
                app: my-apps
            topologyKey: kubernetes.io/hostname
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-apps

配置说明 #

• 拓扑约束：仅匹配app: my-apps标签，确保调度器计算所有该应用Pod的跨区分布，避免版本变化导致约束失效。
• 硬反亲和：基于节点hostname，强制每个节点仅运行一个目标Pod，彻底杜绝单节点多Pod的情况。
• 滚动更新策略：maxSurge: 0确保不会额外创建Pod，maxUnavailable:1允许先删除一个旧Pod，空出节点后再调度新Pod，避免Pending。

内容的提问来源于stack exchange，提问作者Dhody Rahmad Hidayat