最近，我们在不停机的状况下将数百个 ZooKeeper 实例迁移到了 Kubernetes。我们应用了弱小的 Kubernetes 特性（例如端点）简化了迁移进程，那些想要跟我们一样停止 Zookeeper 迁移的人可以在这篇文章里找到答案。文章的末尾列出了停止迁移所需的网络条件。

1. 传统的 ZooKeeper 迁移办法

ZooKeeper 是很多散布式系统的基础，它为这些系统提供了一个弱小的平台，让它们可以聚在一同构成集群。它提供了一种比较基础的办法来构成集群：每个效劳器实例都有一个配置文件，文件里列出了集群成员的主机名和数字 ID，一切的效劳器都有相反的集群成员列表，如下所示：

server.1=host1:2888:3888 

server.2=host2:2888:3888 

server.3=host3:2888:3888 

每台效劳器都有一个叫作 myid 的文件，用来指明它在列表中对应的是哪个数字 ID。

集群可以随意添加和移除效劳器，只需没有违犯这个关键规则：每台效劳器必须可以与配置文件中列出的仲裁效劳器通讯。传统的 ZooKeeper 效劳器迁移步骤主要包括：

启动一台新主机，在效劳器列表配置中参加“server.4=host:4…”；

更新已有主机上的配置文件，添加新的效劳器条目，或删除已退役的主机；

滚动重启旧主机（3.4x 版本分支不提供静态效劳器配置功用）；

更新客户端的衔接串。

这种办法的缺陷是需求修正少量的配置文件并停止滚动重启，这种方式能够无法停止牢靠的自动化。在将 ZooKeeper 迁移到 Kubernetes 之前，我们也思索过这种办法，但后来找到了一种更复杂的办法。这种办法更为安全，由于依据我们的阅历，每一次新的首领选举都存在一个小风险，就是有能够会让依赖它们的细叱崩溃。

2. 新的迁移办法

我们将已有的 ZooKeeper 效劳器包装成 Kubernetes 效劳，然后运用相反的 ZooKeeper ID 停止从效劳器到 Pod 的一对一交流。这只需求一次滚动重启就可以重新配置现有的 ZooKeeper 实例，然后逐一封锁效劳器。不过，我们不计划深化讨论如何为 ZooKeeper 配置 Kubernetes 拓扑，也不计划深化讨论底层的形状就绪反省机制，由于有很多办法可以完成这些操作。

我们将分五个步骤停止迁移：

确保为 ZooKeeper 集群的迁移做好预备；

在 Kubernetes 中创立 ClusterIP 效劳，将 Zookeeper 包装成效劳；

修正 ZooKeeper 客户端，让它们衔接到 ClusterIP 效劳；

配置 ZooKeeper 效劳器实例，让它们可以基于 ClusterIP 效劳地址执行点对点事务；

经过 Kubernetes Pod 运转 ZooKeeper 实例。

关于下面的每一个步骤，我们都将提供一个基础设备拓扑关系图。为了便于了解，这些图只包含两个 ZooKeeper 实例（在理想当中普通不会创立少于三个节点的集群）。

预备好先决条件

我们从一个可运转的 ZooKeeper 集群末尾，确保主机上的效劳可以与 Kubernetes 集群通讯。文末引见了几种办法。

图 1：初始形状，一个包含两个实例的 ZooKeeper 集群和一些客户端

创立 ClusterIP 效劳

为每个 ZooKeeper 效劳器创立一个具有婚配端点的 ClusterIP 效劳，可以让客户端端口（2181）和集群外部端口（2888、3888）经过。完成之后，就可以经过这些效劳主机名衔接到 ZooKeeper 集群。Kubernetes ClusterIP 效劳在这个时分很有用，由于它们提供了可以作为后端 Pod 负载平衡器的静态 IP 地址。我们用它们停止从效劳到 Pod 的一对一映射，相当于为每个 Pod 提供了一个静态的 IP 地址。

图 2：可以经过 ClusterIP 效劳拜访我们的集群（ZooKeeper 依然运转在物理硬件上）

重新配置客户端

在可以经过 Kubernetes ClusterIP 效劳衔接到 ZooKeeper 集群之后，接上去就可以重新配置客户端了。假设你在 ZooKeeper 衔接串中运用了 CNAME 记载，那么请修正 DNS 记载。假设客户端在衔接失败时不会重新解析 DNS 条目，那么就重新启动客户端。假设没有运用 CNAME 记载，那么就需求运用新的衔接串，并重新启动客户端。在这个时分，新旧衔接串都可以运用。

图 3：客户端如今经过 ClusterIP 效劳虚例与 ZooKeeper 集群通讯

重新配置 ZooKeeper 实例

(责任编辑：admin)