etcd 配置 initial-cluster-state
1. 概述
这是一个序列总结文档。
- 第1节 安装etcd 中,在CentOS7上面安装etcd。
- 第2节 单节点运行etcd 在单节点上面运行etcd。
- 第3节 三节点部署etcd集群 在三节点上面部署etcd集群,并为etcd配置了一些快捷命令。
- 第4节 etcd TLS集群部署 在三节点上面部署etcd集群,并开启TLS协议的加密通讯。
- 第5节 etcd角色权限控制 在三节点上面部署etcd TLS集群的基础上,开启角色控制。详细可参考 https://etcd.io/docs/v3.5/demo/ 。
- 第6节 etcd证书过期处理,在etcd证书过期后,etcd相关命令行都操作不了,讲解如何处理这个问题。
- 第7节 etcd配置文件, 通过etcd配置文件来配置相关参数,然后启动etcd服务。
- 第8节 etcd可视化工具, 介绍一款好用的etcd可视化工具etcd-workbench。
- 第9节 etcd的关键配置initial-cluster-state, 介绍
initial-cluster-state设置成new和existing的区别。 - 第10节 集群ID和成员ID的不同显示方式, 介绍etcd集群ID和成员ID的不同显示方式,以及ID值如何在十六进制和十进制间进行转换。
- 第11节 etcd compaction压缩, 介绍etcd compaction压缩相关说明,如何修改压缩配置等。
1.1 VirtualBox虚拟机信息记录
学习etcd时,使用以下几个虚拟机:
| 序号 | 虚拟机 | 主机名 | IP | CPU | 内存 | 说明 |
|---|---|---|---|---|---|---|
| 1 | ansible-master | ansible | 192.168.56.120 | 2核 | 4G | Ansible控制节点 |
| 2 | ansible-node1 | etcd-node1 | 192.168.56.121 | 2核 | 2G | Ansible工作节点1 |
| 3 | ansible-node2 | etcd-node2 | 192.168.56.122 | 2核 | 2G | Ansible工作节点2 |
| 4 | ansible-node3 | etcd-node3 | 192.168.56.123 | 2核 | 2G | Ansible工作节点3 |
后面会编写使用ansible部署etcd集群的剧本。
操作系统说明:
| |
1.2 配置说明
参考第7节 etcd配置文件, 可以看到etcd配置文件配置的initial-cluster-state是new,表示新建集群,如下所示:
| |
如果后续重启etcd服务,应将这个配置修改成initial-cluster-state: 'existing'表示加入一个已经存在的。初始化过的集群中,此时集群ID不会发生变化!
为了验证这个设置,我做以下实验:
- 备份各节点的
/srv/etcd/node目录,以备测试完成后还原。 - 使用
initial-cluster-state: 'existing'配置启动etcd服务,观察集群ID和节点ID变化,以及日志信息。 - 使用
initial-cluster-state: 'new'配置启动etcd服务,观察集群ID和节点ID变化,以及日志信息。 - 测试完成后,使用备份文件还原并启动etcd服务。
1.3 回顾历史
之前参考第7节 etcd配置文件, 通过etcd配置文件来配置相关参数,然后启动etcd服务。
在三个节点上面使用start_by_config.sh启动etcd服务。
| |
启动后,查看etcd集群状态:
| |
可以知道三个节点的ID情况:
- 节点1, e14cb1abc9daea5b
- 节点2,d553b4da699c7263
- 节点3,a7d7b09bf04ad21b
以下就开始进行测试。
2. 配置项测试
2.1 备份文件
三个节点,切换到/srv/etcd目录下,然后执行cp -rp node node.bak备份目录:
| |

2.2 以initial-cluster-state: 'existing'配置启动
查看当前三个节点的initial-cluster-state: 配置。
| |
可以看到,当前三个节点都配置的是initial-cluster-state: 'existing',即加入已有集群!!
此时,启动一下三个节点的服务:
| |

三个节点都启动了!
| |
此时,通过ecm和ecs都可以看到,三个节点的十六进制ID是:
- 节点1 ID是 e14cb1abc9daea5b
- 节点2 ID是 d553b4da699c7263
- 节点3 ID是 a7d7b09bf04ad21b
即与以前启动时显示的节点ID是一致的,说明节点ID没有发生变化!
同时,可以对比5月31日的截图,可以看到之前的十进制集群ID和成员ID信息:
- 集群ID是 11928626832149063955
- 节点1 ID是 16234546108147886683
- 节点2 ID是 15371828803313365603
- 节点3 ID是 12094329508124611099

可以看到,集群ID和成员ID保持不变,仍然是以前的ID值。
这是我期望的状态,说明当配置initial-cluster-state: 'existing'时,etcd集群节点ID和成员ID不会发生变化。
此时,使用./stop.sh脚本,将三个节点的etcd服务停掉!
| |
2.3 以initial-cluster-state: 'new'配置启动
查看当前三个节点的initial-cluster-state: 配置。
| |
2.3.1 仅修改initial-cluster-state值为new
修改三个节点配置:
| |
执行以下命令后,再次查看配置情况:
| |

可以看到配置已经改变!
此时启动三个节点的etcd服务:
| |
此时查看集群ID和成员ID信息:
| |
可以看到与上一节获取到的十进制集群ID和成员ID信息是一样的:
- 集群ID是 11928626832149063955
- 节点1 ID是 16234546108147886683
- 节点2 ID是 15371828803313365603
- 节点3 ID是 12094329508124611099
此时,为什么没有变化!!!
根本原因:数据目录的优先级高于启动参数
etcd 在启动时遵循一个核心原则:
若数据目录(
--data-dir)已存在且包含有效集群状态(如member/snap/db文件),则忽略initial-cluster-state的配置,直接加载本地数据恢复集群。启动流程解析:
- 检查数据目录 etcd 启动时首先检查
--data-dir目录:
- 若目录 不存在 或 为空 → 进入初始化流程,遵循
initial-cluster-state=new的配置。- 若目录 存在且包含有效数据(如
member/snap/db)→ 跳过初始化流程,直接加载持久化数据。- 参数
initial-cluster-state的作用范围 该参数 仅在初始化新集群时生效。若检测到已有数据,etcd 会:
- 自动切换为
existing模式(无论配置如何)。- 从磁盘加载 集群 ID、成员 ID、Raft 日志、快照 等状态。
即当存在数据目录相关文件时,etcd会忽略 initial-cluster-state 的配置。
| |
可以看到,我们的确存在了相关的集群状态文件。
2.3.2 删除数据目录data.etcd
先停止三个节点的etcd服务:
| |
三个节点都执行stop.sh脚本。
为了验证数据目录不存在时,使用initial-cluster-state=new 时会重新创建集群ID和成员ID信息,将三个节点的数据目录下的文件删除掉(注意,你在删除前应像我在2.1节那样,提前做好备份):
| |
再启动三个节点的etcd服务:
| |
然后查看集群相关信息:
| |
此时,不用理会authentication is not enabled这些告警信息。只关心最后的集群ID和成员ID信息:
- 集群ID是 11928626832149063955
- 节点1 ID是 16234546108147886683
- 节点2 ID是 15371828803313365603
- 节点3 ID是 12094329508124611099
此时可以看到,集群ID和成员ID信息还是保持之前一样的!!!
您的观察揭示了 etcd 中一个关键但常被忽视的行为。即使删除了所有节点的
data.etcd目录,集群 ID 和成员 ID 仍然保持不变,这确实可能发生。以下是根本原因和解决方案:根本原因:集群配置参数的持久性
etcd 的集群身份不完全依赖磁盘存储,而是由 启动参数决定,特别是:
--initial-cluster-token这是决定集群 ID 的核心参数。如果您没有显式修改它,etcd 会使用默认值或之前的值。--initial-cluster配置 成员 ID 是由节点名称 (--name) 和 peer URL 的组合通过算法生成的哈希值
2.3.3 修改initial-cluster-token令牌值
停掉各节点服务:
| |
查看当前令牌配置:
| |
修改令牌令牌:
| |
注意,此处同样要删除数据目录!!!
此时再启动三个节点服务:
| |
此查看集群ID和成员ID令牌:
| |
可以看到,此时集群id和成员发生了变化!

2.4 还原配置
在以上测试完成后,停止etcd服务,并删除测试使用的/srv/etcd/node目录,并将备份的目录/srv/etcd/node.bak复制为/srv/etcd/node,然后再启动etcd服务。
| |
此时再检查一下etcd相关的命令,以及查看集群ID和成员ID等信息:
| |

可以看到,etcd恢复正常,集群ID和成员ID也与测试前的一致!!此时使用etcd-workbench登陆查看集群信息也是恢复正常的!
3. etcd启动顺序

根据前面第2节的实验,绘制了一个流程图,在什么情况下集群ID和成员ID会保持不变,或者重新生成新的集群ID和成员ID信息。

