ECK部署Elasticsearch集群时Pod容忍度配置不生效的正确配置方法咨询

我之前在使用ECK部署ES集群时也碰到过类似的容忍度（tolerations）不生效的情况，结合你的配置和问题描述，咱们可以从这几个方向排查和解决：

1. 确认Elasticsearch CR的配置是否正确保存 #

首先检查你定义的Elasticsearch自定义资源（CR）是否已经正确存储了容忍度配置：

kubectl get elasticsearch elastic-data-factory -o yaml | grep -A5 tolerations

如果输出能看到你设置的tolerations内容，说明CR配置没问题，问题出在ECK Operator生成StatefulSet的环节；如果看不到，那说明你的配置文件可能有缩进错误或者应用时出现了隐性问题，需要重新核对YAML的缩进格式。

2. 检查ECK Operator的运行日志 #

ECK Operator负责将Elasticsearch CR转换成StatefulSet等资源，查看Operator日志能帮我们找到是否有处理容忍度时的异常：

kubectl logs -n elastic-system -l control-plane=elastic-operator --tail=100

搜索关键词toleration或者StatefulSet，看看有没有警告或错误信息，比如是否有权限问题、配置解析错误等。

3. 触发StatefulSet的滚动更新 #

如果你的ES集群是已经存在的，ECK可能不会自动触发StatefulSet的更新（除非配置变化触发了滚动策略）。你可以通过修改Pod模板的一个微小配置来强制触发滚动更新，比如添加一个无关的注解：
在每个nodeSet的podTemplate.metadata.annotations里加一行：

podTemplate:
  metadata:
    annotations:
      force-update: "20240520"
  spec:
    tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "esdfnp"
      effect: "NoSchedule"
    # 其他原有配置...

应用这个更新后，ECK会重新生成StatefulSet，并逐步重建Pod，此时新Pod应该会带上配置的容忍度。

4. 确认ECK版本与ES版本的兼容性 #

你使用的ES版本是7.14.0，对应的ECK Operator版本应该是1.9.x左右（ECK 1.x系列对应ES 7.x系列）。如果你的ECK版本过低，可能存在配置解析的bug。可以检查ECK版本：

kubectl get pods -n elastic-system -l control-plane=elastic-operator

如果版本不匹配，建议升级到对应兼容的ECK版本后再重新应用配置。

5. 排查是否有Admission Controller拦截配置 #

如果你的集群中有PodSecurityPolicy、Gatekeeper等Admission Controller，可能会修改或移除Pod的容忍度配置。可以检查这些组件的日志，或者在测试环境临时禁用相关组件来验证是否是这个原因导致的。

最终验证 #

等Pod重建完成后，检查Pod的容忍度配置是否生效：

kubectl get pod elastic-data-factory-master-0 -o yaml | grep -A5 tolerations

如果能看到你设置的容忍度内容，就说明配置已经生效了。

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