Kubernetes驱逐API不能完全解决Elasticsearch集群运行状况吗？

Question

我正在寻找一种对Kubernetes集群执行自动滚动更新的方式，这种方式不了解集群上运行的应用程序的详细信息。原则上，PodDisruptionBudget应该对此起到促进作用。

这是一个障碍：在这个Kubernetes集群上运行着一个Elasticsearch集群，我找不到一种正确表达“可以驱逐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钩子（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

希望这会有所帮助！