我正在尝试自动化 Kubernetes 集群中 Elasticsearch 节点的水平扩展和缩减过程。
最初,我在 Kubernetes 集群上部署了一个 Elasticsearch 集群(3 个主节点、3 个数据节点和 3 个摄取节点)。其中,
cluster.initial_master_nodes
是:
cluster.initial_master_nodes:
- master-a
- master-b
- master-c
然后,我进行了缩容操作,将主节点3的数量减少到1(出乎意料,但用于测试目的)。在执行此操作时,我删除了
master-c
、master-b
节点,并使用以下设置重新启动 master-a
节点:
cluster.initial_master_nodes:
- master-a
由于elasticsearch节点(即pod)使用持久卷,重新启动节点后,
master-a
会减慢以下日志:
"message": "master not discovered or elected yet, an election requires at least 2 nodes with ids from [TxdOAdryQ8GAeirXQHQL-g, VmtilfRIT6KDVv1R6MHGlw, KAJclUD2SM6rt9PxCGACSA], have discovered [] which is not a quorum; discovery will continue using [] from hosts providers and [{master-a}{VmtilfRIT6KDVv1R6MHGlw}{g29haPBLRha89dZJmclkrg}{10.244.0.95}{10.244.0.95:9300}{ml.machine_memory=12447109120, xpack.installed=true, ml.max_open_jobs=20}] from last-known cluster state; node term 5, last-accepted version 40 in term 5" }
似乎正在尝试寻找
master-b
和 master-c
。
问题:
master-a
不会搜索这些已删除的节点?cluster.initial_master_nodes
设置仅在集群第一次启动时有效,但为了避免一些非常罕见的极端情况,一旦设置它,您就不应该更改它的值,通常您应该尽快将其从配置文件中删除尽可能。来自参考手册关于cluster.initial_master_nodes
:
重新启动集群或向现有集群添加新节点时不应使用此设置。
除此之外,Elasticsearch 使用基于仲裁的选举协议,并表示以下内容:
为了确保集群保持可用,您不得同时停止投票配置中的一半或更多节点。
您同时停止了三个符合主节点资格的节点中的两个,占总数的一半以上,因此预计集群将不再工作。
参考手册还包含您未遵循的删除符合主资格的节点的说明:
只要集群中至少有 3 个符合主节点资格的节点,作为一般规则,最好一次删除一个节点,以便集群有足够的时间自动调整投票配置并调整投票配置。新节点集的容错级别。
如果只剩下两个符合主节点资格的节点,则两个节点都不能被安全删除,因为两个节点都需要可靠地取得进展。要删除其中一个节点,您必须首先通知 Elasticsearch 它不应该成为投票配置的一部分,并且投票权应该给予另一个节点。
它继续描述在缩小到单个节点时如何使用
POST /_cluster/voting_config_exclusions/node_name
从投票配置中安全地删除不需要的节点。
集群状态还将主配置存储存储在Elasticsearch节点的数据文件夹中,在您的情况下,它似乎正在读取旧集群状态(这是3个主节点及其ID)。
您可以删除您的
master-a
的数据文件夹,以便它可以从干净的集群状态启动,并且应该可以解决您的问题。
还要确保其他数据和摄取节点具有
master.node:false
设置,默认情况下它是 true。
我尝试了所有建议的解决方案,但不起作用。然而,就我而言,我最终通过简单地从有状态集规范中“删除就绪探针”来解决了这个问题。看来这是由于 k8s 的行为而导致的死锁。如果所有主节点都完成了。在第一个主节点准备就绪之前,K8s 不会启动第二个主节点。但第一个主节点将等待第二个主节点准备就绪。