我们最近将数百个ZooKeeper实例从单个服务器实例迁移到Kubernetes，而没有停机。我们的方法使用了强大的Kubernetes功能（例如端点）来简化流程，因此我们为希望遵循我们脚步的任何人共享该方法的高级概述。有关重要的联网先决条件，请参见最后。
传统ZooKeeper迁移方法
ZooKeeper是许多分布式系统的基础，它使它们成为一个强大的平台，可以聚集并参加会议并形成集群。在幕后，它依靠一种相对基本的方法来形成集群：每个服务器实例都有一个配置文件，其中列出了所有成员主机名和数字ID，并且所有服务器都具有相同的服务器列表，如下所示：
server.1 =主机1：2888：3888
server.2 =主机2：2888：3888
server.3 =主机3：2888：3888
每个服务器都有一个名为myid的唯一文件，以告诉它与该列表对应的数字id。
只要不违反关键规则，就可以添加和删除主机：每台服务器必须能够达到其配置文件中列出的服务器的法定人数（定义为简单多数）。将ZooKeeper服务器迁移到新实例的传统方法涉及较高的层次：
- 使用服务器列表中的“ server.4 = host：4…”配置并启动新主机
- 更新现有主机上的配置文件以添加新服务器条目，并从其服务器列表中删除已淘汰的主机
- 滚动重启旧主机（3.4x分支中没有动态服务器配置）
- 更新客户端中的连接字符串（如果客户端在错误时重新解析DNS，则可能只是更改CNAME记录）
这种方法的缺点是许多配置文件更改和滚动重新启动，您可能需要或可能没有可靠的自动化。当我们开始将ZooKeeper迁移到Kubernetes时，我们开始考虑这种方法，但是找到了一种更简单的方法。也更安全，因为根据我们的经验，每次新的领导人选举都有很小的风险，即花费足够长的时间来压倒依赖他们的系统。
新的方法
我们的方法包括将现有的ZooKeeper服务器包装在Kubernetes服务中，然后使用相同的ZooKeeper ID进行一对一的服务器到主机的替换。这仅需要一次滚动重新启动即可重新配置现有的ZK实例，然后一步一步关闭服务器。我们不会在这里讨论为ZooKeeper配置Kubernetes拓扑的方法或低级的准备情况检查的琐碎，因为有很多方法可以实现各种优点和缺点。不论顶层拓扑如何，下面讨论的概念都是一样的。
我们将分五个步骤进行：
- 完成前提条件，以确保我们的ZooKeeper集群已准备好迁移
- 在包装ZooKeeper服务的Kubernetes中创建ClusterIP服务
- 配置ZooKeeper客户端以连接到ClusterIP服务
- 配置ZooKeeper服务器实例以通过ClusterIP服务地址执行对等事务
- 用Kubernetes窗格中的ZooKeeper实例替换服务器上运行的每个ZooKeeper实例
对于下面的每个步骤，我们将包括一个基础架构拓扑图。为了便于理解，这些图将仅包含两个ZooKeeper实例，即使一个实例不想创建少于三个的集群。
点击标题见原文详细介绍