Kubernetes eviction API 不能完全解释 Elasticsearch 集群的健康状况？答案

【问题标题】：Kubernetes eviction APIs can't fully account for Elasticsearch cluster health?Kubernetes eviction API 不能完全解释 Elasticsearch 集群的健康状况？
【发布时间】：2019-03-03 21:37:54
【问题描述】：

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

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

这个 ES 集群的索引有 number_of_replicas: 1，还有一个 PDB 有 maxUnavailable: 1。每个 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 集群的可能性（假设这些分片复制速度很慢）。
同上，在readinessProbe 上设置一个大的initialDelaySeconds。这可能会低于完成分片复制的时间。
同样使用preStop 挂钩 (this is the approach the community Helm chart appears to take) 和较长的宽限期。
将 PDB 的 maxUnavailable 减少到 0 意味着滚动更新必须由可以删除 PDB、评估 ES 集群状态等的人员运行。
一个假设的，嗯，evictablenessProbe 检查 wait_for_status=green 会起作用，但不存在这样的 API。

【问题讨论】：

标签： elasticsearch kubernetes

【解决方案1】：

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

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

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

希望这会有所帮助！

【讨论】：