通过Helm在带污点EKS集群部署Consul时Gossip加密自动生成的容忍问题

你的核心问题是调度配置的位置错误：你把nodeSelector和tolerations放在了global.acls子块下，这部分配置不会被Consul Helm Chart识别为调度规则，自然无法让Pod获得对应容忍度。

正确的配置方式 #

方案1：全局生效（所有Consul组件应用调度规则）

将nodeSelector和tolerations移到global层级下，这样Consul的Server、Client、Connect注入器等所有组件都会遵循该调度策略：

global:
  enabled: true
  logLevel: debug
  imagePullPolicy: Always
  tls: 
    enabled: true
  acls:
    manageSystemACLs: true
  # 全局节点选择器
  nodeSelector:
    Internal: "true"
  # 全局容忍度，建议明确指定污点effect（和节点污点保持一致）
  tolerations:
    - key: "Internal"
      operator: "Equals"
      value: "true"
      effect: "NoSchedule"

gossipEncryption:
  autoGenerate: true

方案2：仅针对特定组件生效

如果只需要让Consul Server（或其他组件）调度到带污点节点，可以单独在对应组件的配置块下设置：

global:
  enabled: true
  logLevel: debug
  imagePullPolicy: Always
  tls: 
    enabled: true
  acls:
    manageSystemACLs: true

# 仅给Consul Server配置调度规则
server:
  nodeSelector:
    Internal: "true"
  tolerations:
    - key: "Internal"
      operator: "Equals"
      value: "true"
      effect: "NoSchedule"

gossipEncryption:
  autoGenerate: true

后续验证步骤 #

1. 确认节点污点的effect：执行kubectl describe node <目标节点名称>，查看污点的Effect字段，确保和你配置的effect一致（常见值为NoSchedule/PreferNoSchedule/NoExecute）。
2. 重新部署Consul：修改配置后执行helm upgrade --install consul hashicorp/consul -f values.yaml（首次部署用install，已部署用upgrade）。
3. 检查Pod调度状态：执行kubectl describe pod <Consul Pod名称>，查看Events栏，确认是否因容忍度问题导致调度失败，若配置正确，Pod会成功调度到目标节点。

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