elasticsearch - Kubernetes 驱逐 API 不能完全考虑 Elasticsearch 集群的健康状况？

Question

我希望以一种不知道集群上运行的应用程序细节的方式执行 Kubernetes 集群的自动滚动更新。原则上，PodDisruptionBudget 应该促进这一点。

问题来了:这个 Kubernetes 集群上运行着一个 Elasticsearch 集群，我找不到正确表达“OK to evict an ES Pod”信号的方法。具体来说，这似乎是 “此 Pod 可以接收流量”和“此 Pod 可以被驱逐”信号不能同时由 readinessProbe 表示的情况。 .

这个 ES 集群的索引有 number_of_replicas: 1 ，并且有一个带有 maxUnavailable: 1 的 PDB .每个 ES Pod 都指定一个请求 /_cluster/health?wait_for_status=yellow 的就绪探测器.

照原样，如果我们驱逐一个 ES Pod，替换的 Pod 将加入 ES 集群，启动并返回就绪状态，而 ES 集群作为一个整体仍然是黄色的并且正在复制分片(因此驱逐任何额外的 ES Pod 仍然是不安全的)。

有人成功解决过这个问题吗？我是否误解了探测器/PDB 的语义？

---

我们考虑过的一些选项:

• 使用 wait_for_status=green在就绪探测中将意味着当 ES 集群运行状况为黄色时，所有 ES Pod 都未就绪。
• 增加 ES 指数' number_of_replicas至 2只会稍微降低滚动更新损坏 ES 集群的可能性(假设这些分片复制速度很慢)。
• 同上设置大 initialDelaySeconds在 readinessProbe 上.这可能会低于完成分片复制的时间。
• 同上使用 preStop Hook ( this is the approach the community Helm chart appears to take ) 和很长的宽限期。
• 减少 PDB 的 maxUnavailable至 0意味着滚动更新必须由可以删除 PDB、评估 ES 集群状态等的人员运行。
• 假设，嗯，evictablenessProbe检查了wait_for_status=green会工作，但不存在这样的 API。

Answer 1

首先，无论如何，使用 Helm 图表可以节省大量时间和麻烦: https://github.com/helm/charts/tree/master/incubator/elasticsearch

但以防万一你不能，或者万一它可以帮助别人，我认为你正在寻找的是 /_cluster/health?local=true，例如:

    readinessProbe:
      httpGet:
        path: /_cluster/health?local=true
        port: 9200

希望这对您有所帮助!