电商网站维护,百度无广告搜索引擎,外贸推广平台排名,无锡网站建设 百家号背景
1. k8s 升级#xff0c;导致环境中的ES集群#xff08;7.17版本#xff09;重启
2. 集群由于在公有云环境#xff0c;IP不固定#xff08;重启后IP可能发生变化#xff09;#xff0c;通过 svc 进行访问
curl xxx-master-svc:9200/_cat/health
3. 由多个sts一…背景
1. k8s 升级导致环境中的ES集群7.17版本重启
2. 集群由于在公有云环境IP不固定重启后IP可能发生变化通过 svc 进行访问
curl xxx-master-svc:9200/_cat/health
3. 由多个sts一起维护一个ES集群非operator的模式
xxx-masterxxx-ingestxxx-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/healthyellow才可以存活将其改成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: unsafedetach
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该现象对前期排障造成巨大干扰。
