3个K8s控制平面节点无停机部署Haproxy的调度方案咨询

方案一：优化DaemonSet更新策略实现无停机发布 #

核心解决DaemonSet更新时无法并发Pod导致的停机问题：

• 调整更新参数：将DaemonSet的.spec.updateStrategy.rollingUpdate.maxUnavailable设为0，确保旧Pod在新Pod完全就绪前不会被删除；同时设置.spec.minReadySeconds为5-10，给新Pod预留启动就绪时间。
• 规避端口冲突：如果haproxy使用hostPort导致同节点无法同时运行新旧Pod，采用临时动态端口+Service转发的方式：
  1. 新Pod使用临时hostPort（如8080），旧Pod保留原业务端口；
  2. 更新控制平面流量转发配置（如kubelet的--kubeconfig指向新Service）；
  3. 确认新Pod接管流量后，删除旧Pod并将新Pod改回原端口。
• 蓝绿部署DaemonSet：创建两个DaemonSet（如haproxy-blue和haproxy-green），先部署新版本haproxy-green并通过nodeSelector调度到控制平面节点；修改Service指向haproxy-green后，删除旧版本haproxy-blue，实现无切换停机。

方案二：使用StatefulSet替代Deployment #

StatefulSet天生适配节点固定分布的场景，可解决Deployment的调度痛点：

• 配置严格反亲和性：在StatefulSet的Pod模板中添加requiredDuringSchedulingIgnoredDuringExecution类型的反亲和性，匹配kubernetes.io/hostname拓扑键，确保每个节点仅运行一个haproxy Pod：

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: haproxy
        topologyKey: kubernetes.io/hostname
  

• 控制更新节奏：使用RollingUpdate策略，通过.spec.updateStrategy.rollingUpdate.partition分批更新Pod，比如先更新索引0的Pod，就绪后再依次更新索引1、2，避免多节点同时停机。
• 规避Terminating Pod干扰：StatefulSet的Pod处于Terminating状态时，调度器会忽略其反亲和性约束（因ignoredDuringExecution），新版本Pod可正常调度到对应节点，等旧Pod完全终止后接管服务。

方案三：带节点绑定的多Deployment部署 #

针对3个控制平面节点，创建3个独立的单副本Deployment，分别绑定到对应节点：

• 节点绑定配置：给每个控制平面节点打唯一标签（如cp-node: cp-1、cp-node: cp-2、cp-node: cp-3），每个Deployment的.spec.template.spec.nodeSelector对应一个节点标签，确保Pod固定调度到目标节点。
• 分批更新：更新时逐个操作3个Deployment，先更新第一个，确认Pod就绪后再更新第二个、第三个，保证单节点更新时的服务连续性，避免全局停机。
• 简化维护：使用Helm模板或Kustomize批量生成3个Deployment的配置，减少重复工作量。

方案四：Deployment结合动态状态标签解决调度冲突 #

通过给Running状态的Pod打专属标签，解决反亲和性和拓扑分布的问题：

• 添加状态标签逻辑：使用准入控制器或Init Container，在Pod进入Running状态后自动打上pod-status: running标签；例如用Init Container执行脚本，检测Pod就绪后调用K8s API添加标签。
• 精准反亲和性配置：将Deployment的反亲和性改为仅匹配带有pod-status: running标签的Pod，Terminating状态的Pod因无此标签，不会阻止新Pod调度到同一节点：

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: haproxy
            pod-status: running
        topologyKey: kubernetes.io/hostname
  

• 优化拓扑分布：在topologySpreadConstraints的labelSelector中同样只匹配带有pod-status: running的Pod，避免Terminating Pod干扰分布计算，确保部署期间Pod均匀分布。

补充：K8s 1.26.5的matchLabelKeys问题排查 #

若必须使用matchLabelKeys，先确认集群已开启MatchLabelKeysInPodAffinity特性门控（K8s 1.25+默认开启，但部分发行版可能关闭）；若仍未生效，直接改用上述动态状态标签方案替代即可。

内容的提问来源于stack exchange，提问作者Vladimir