ES7.17由于IP变化导致的故障及恢复

背景 

1. k8s 升级，导致环境中的ES集群（7.17版本）重启

2. 集群由于在公有云环境，IP不固定（重启后IP可能发生变化），通过 svc 进行访问

curl xxx-master-svc:9200/_cat/health

3. 由多个sts一起维护一个ES集群（非operator的模式）

xxx-master

xxx-ingest

xxx-data

注：一般开源的ES，无论在虚拟机还是容器中部署，最佳实践还是固定IP；

4. 集群重启之后，状态变成了 red

分析

1. 初步发现是掉了2个节点（_cat/nodes），元信息还可以访问，总体表现为red

2. 发现data节点无法加入集群，新扩出来的节点也无法加入集群

    - 排除网络影响，节点之间都是通的

    - 无法加入的节点 local:9200/ 发现节点活着，但是 cluster_uuid: "_na_"（空）

    - 对节点进行 unsafe的 detach 操作，脱离集群，重启（依然无法加入集群）

3.  日志（异常的data节点）表现为 `master not discovered or elected yet, an election requires at least 2 nodes with ids from`，以及各种访问master超时;

日志中打印的IP地址是先有master节点的IP（不存在IP错误）

4. 发现data节点存在readinessProbe策略（sts），要求_cluster/health=yellow才可以存活，将其改成red，依然无法加入集群

5. data节点无法加入集群，这里尝试修改data节点的配置，强行指定master的地址。结果data节点重启后依然无法加入集群。

cluster.initial_master_nodes: "xxx-master-1, xxx-master-2, ..."

注：

## 为了保证安全，对sts进行如下操作，对sts管理的部分节点生效（此处表示 pod 编号大于等于2 的才会执行操作，如果要sts管理的全部节点生效，改成0即可，或者去掉该配置）

updateStrategy:
 rollingUpdate:
   partition: 2
type: RollingUpdate

6. 发现“正常”节点（master/ingest）的_cat/nodes命令的结果中包含个别data节点

    - 反复确认过，在全部的data节点，都无法访问集群元信息（没加入集群）

    - 怀疑元数据异常，整个集群已经挂了（没有形成集群）

7. 节点无法形成集群，一般有2种方法

    - 方案1: （unsafe）detach

su elasticsearch -g root

./bin/elasticsearch-node unsafe-bootstrap

./bin/elasticsearch-node detach-cluster

    - 方案2: 对全部master候选节点的配置进行修改，重启，重新形成集群

Bootstrapping a cluster | Elasticsearch Guide [7.17] | Elastic

cluster.initial_master_nodes: "xxx-master-1, xxx-master-2, ..."

解决方案

使用上面描述的方案2；

具体流程如下：

1. （容器环境才需要考虑）修改 readinessProbe，_cluster/health 需要访问元数据信息，集群已经挂掉的情况下不合理（由于集群已经挂了，所以会一直阻塞），这里改成 check 9200 端口（只需要访问本地进程/端口）。

2. 修改master节点的 initial_master_nodes 配置，指定master节点的节点name列表。

注：容器环境中滚动重启即可，不需要同时重启

疑惑

1.  如果是滚动重启，即使IP发生变化，ES也可以感知到，除非是一次重启多个节点（修改多个IP），比如超过一半的master节点，那么无法形成集群（k8s升级工艺已经无法追溯......）

2.  如果短时间太多节点变化IP，无法形成集群，为什么有些节点可以访问元数据（ _cat/health，_cat/nodes 等），而不是全部节点访问ES集群元数据都是503.

（可能极端情况触发了ES的bug，该现象对前期排障造成巨大干扰。）