Kubernetes Blog
·
在升级到etcd v3.6时避免出现僵尸集群成员
内容提要
在升级到etcd v3.6之前，必须先升级到v3.5.26或更高版本，以确保集群自动修复，避免出现“僵尸成员”问题。此问题源于旧版本的v2store与v3store不一致，导致已删除的节点重新出现。
关键要点
-
在升级到etcd v3.6之前，必须先升级到v3.5.26或更高版本。
-
升级到v3.6可以确保集群自动修复，避免出现“僵尸成员”问题。
-
“僵尸成员”是指已从数据库集群中删除但重新出现的etcd节点。
-
在v3.5及更早版本中，v2store是成员数据的真实来源，v3store在v3.6中成为真实来源。
-
在v3.5.26中添加了自动同步v3store与v2store的机制。
-
升级路径为：先升级到v3.5.26，确认所有成员健康后再升级到v3.6。
-
如果无法升级到v3.5.26，则应推迟升级到v3.6。
-
此问题可能由多个因素引起，包括etcdctl快照恢复中的错误和不安全的同步选项。
-
一旦升级到v3.6，v3store将成为成员数据的唯一来源，进一步的不一致将不再可能。
-
感谢Christian Baumann报告此长期升级问题，帮助我们解决了该问题。
延伸解读
升级前的准备工作
在升级到etcd v3.6之前，确保先升级到v3.5.26或更高版本是至关重要的。这一过程不仅可以避免出现僵尸成员，还能确保集群的健康状态。用户应在升级后确认所有成员的健康状况，以防止潜在的集群故障。
僵尸成员的风险
僵尸成员问题可能导致集群无法正常运作，影响服务的可用性。特别是在生产环境中，及时处理和升级是避免此类问题的关键。用户应关注集群成员的状态，定期检查以确保没有旧节点重新出现。
不安全选项的警示
使用--unsafe-no-sync选项可能导致数据不一致，进而引发僵尸成员问题。尽管在某些情况下可能会使用此选项，但不建议在生产环境中使用，以免破坏共识协议的保证。
延伸问答
在升级到etcd v3.6之前需要做什么？
必须先升级到etcd v3.5.26或更高版本。
什么是僵尸成员？
僵尸成员是指已从数据库集群中删除但重新出现的etcd节点。
如何避免在升级中出现僵尸成员问题？
通过在升级到v3.6之前先升级到v3.5.26，确保集群自动修复。
升级到v3.6后，v3store的角色是什么？
在v3.6中，v3store将成为成员数据的唯一来源。
如果无法升级到v3.5.26，该怎么办？
应推迟升级到v3.6，直到能够升级到v3.5.26。
导致僵尸成员问题的可能原因有哪些？
可能原因包括etcdctl快照恢复中的错误和不安全的同步选项。
