EKS环境下RabbitMQ StatefulSet Pod反亲和性规则不生效问题求助

• 第一步：验证亲和性配置是否实际下发到运行资源
  先确认StatefulSet的配置是否正确提交，执行命令：

  kubectl get statefulset rabbitmq -o yaml | grep -A30 affinity
  

  确认输出的亲和性规则和你配置的完全一致，排除CI/CD渲染错误、配置提交失败、yaml格式错误导致字段被忽略的问题。
  再检查当前运行的RabbitMQ Pod是否继承了规则：

  kubectl get pod rabbitmq-0 -o yaml | grep -A20 affinity
  

  如果Pod的亲和性配置缺失，说明StatefulSet更新后没有触发Pod重建，删除旧Pod触发重新调度即可。

• 第二步：排查Pod反亲和匹配逻辑异常
  你当前配置的反亲和规则为逻辑与关系，需要同时匹配Jenkins Pod的两个标签才会触发反亲和，从你提供的标签信息来看匹配条件是对的，需额外检查两点：

  1. 命名空间匹配问题：podAntiAffinity默认仅匹配当前RabbitMQ所在命名空间的Pod，如果Jenkins部署在其他命名空间，需要在规则中显式指定Jenkins的命名空间，示例如下：

  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - controller
          - key: app.kubernetes.io/component
            operator: In
            values:
            - jenkins
        namespaces: [jenkins] # 替换为Jenkins实际所在命名空间
        topologyKey: kubernetes.io/hostname
  

  2. 标签拼写校验：执行命令确认Jenkins Pod的标签没有拼写、大小写误差：

  kubectl get pod -n <Jenkins命名空间> jenkins-8499877f97-6jvb6 --show-labels
  

• 第三步：验证调度依赖条件

  1. 确认节点标签是否符合要求：首先检查所有带node.app/group=apps标签的节点数量，确认除了Jenkins所在节点外还有其他可用节点；再检查所有该类节点的kubernetes.io/hostname标签是否存在，该标签是你配置的topologyKey，缺失的话会导致反亲和规则失效：

  kubectl get nodes -l node.app/group=apps --show-labels | grep kubernetes.io/hostname
  

  2. 确认调度时机：你配置的规则是requiredDuringSchedulingIgnoredDuringExecution，也就是说如果RabbitMQ Pod调度到节点之后，才把Jenkins Pod部署到同一个节点，调度器不会主动驱逐已经运行的RabbitMQ Pod，需要手动删除RabbitMQ Pod触发重新调度验证规则。

• 第四步：查看调度决策日志
  删除旧RabbitMQ Pod触发重新调度后，立刻查看新Pod的事件信息，可以明确看到调度器的决策逻辑：

  kubectl describe pod <新生成的RabbitMQ Pod名称>
  

  观察Events字段的调度记录，会明确标注是否匹配到反亲和规则、过滤后的可用节点列表等信息，可以直接定位问题根因。

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