共计 4665 个字符，预计需要花费 12 分钟才能阅读完成。
本文译自 Kafka on PaaSTA: Running Kafka on Kubernetes at Yelp (Part 2 – Migration)
作者：Lennart Rudolph
上一篇文章，咱们具体介绍了开发基于 PaaSTA 的新部署模型的架构和动机。当初想分享咱们将现有 Kafka 集群从 EC2 无缝迁徙到基于 Kubernetes 的外部计算平台的策略。为了帮忙促成迁徙，咱们构建了与集群架构的各种组件接口的工具，以确保该过程是自动化的，并且不会影响用户读取或写入 Kafka 记录的能力。
将 EC2 上的 Kafka 迁徙到 PaaSTA 上的 Kafka
背景
在施行过程中，集群中反对 EC2 的 Kafka 代理与一个主动扩大组 ASG 相关联。每个 ASG 都有一个弹性负载均衡器(ELB)，它促成了与集群的所有连贯并充当入口点。每个集群还附带一些辅助服务和作业，但其中大部分曾经部署在 PaaSTA 上。然而，一些重要的管理系统间接在 Kafka 服务器上作为 cron 作业运行。这次从新设计特地重要的一点是集群从新均衡算法和主题主动分区算法。从新均衡算法尝试在集群的代理之间平均调配分区和领导，而主动分区算法会依据吞吐量指标主动设置主题分区数量。因为咱们曾经打算在架构中退出巡航管制，当初是迁徙到新的再均衡算法的好时机。
因而，在这次迁徙中，咱们重点替换的三个要害组件是集群入口、集群均衡算法和主题主动分区算法。咱们不须要寻找 ELB 的替代品，因为 PaaSTA 通过 Yelp 的服务网格提供了原生的负载平衡能力，这使得在组成集群的 Kubernetes 容器上公布 Kafka 变得简略。在以后的 EC2 场景中，咱们还在 Kafka 主机上运行了自定义从新均衡算法，但这最终被 Cruise Control 取代（无关此服务的更多详细信息，请浏览第 1 局部），它提供了相似的性能。最初，咱们基于 Puppet 的运行主题主动分区脚本的 cron 作业被替换为相似的 Tron 在 PaaSTA 上运行的作业。下表提供了跨部署办法的不同组件的概述。
| 整机 | EC2 | PaaSTA |
|---|---|---|
| 集群入口点 | 电子负载均衡器 | Yelp 的服务网格 |
| 集群均衡 | kafka-utils 中的再均衡算法 | 巡航管制 |
| 主题主动分区 | cron 作业（基于 Puppet） | Tron 工作 |
每种部署办法应用的组件表
因为咱们不会同时迁徙所有集群，因而咱们心愿防止对 Kafka 集群发现配置文件进行重大更改。为了理解更多状况，在 Yelp，咱们应用一组 kafka_discovery 文件（由 Puppet 生成），其中蕴含每个集群的疏导服务器、ZooKeeper chroot 和其余元数据的信息。咱们的许多外部零碎（如 Schematizer 和 Monk) 依赖于这些文件中的信息。这种迁徙策略只须要更新 broker_list 以指向服务网格的入口，从而放弃与咱们现有工具的兼容性。咱们的确将这次迁徙作为一个机会，通过删除 Puppet 作为实在起源来改良流传办法，而是抉择应用 srv-configs（服务应用的配置的标准地位）。上面是一个发现文件的例子：
>> cat /kafka_discovery/example-cluster.yaml
---
clusters:
uswest1-devc:
broker_list:
- kafka-example-cluster-elb-uswest1devc.<omitted>.<omitted>.com:9092
- kafka-example-cluster-elb-uswest1devc.<omitted>.<omitted>.com:9092
zookeeper: xx.xx.xx.xxx:2181,xx.xx.xx.xxx:2181,xx.xx.xx.xxx:2181/kafka-example-cluster-uswest1-devc
local_config:
cluster: uswest1-devc
...迁徙策略概述
在高层次上，迁徙的指标是从应用 EC2 兼容组件无缝切换到应用 PaaSTA 兼容组件，而不会导致现有生产者和消费者客户端呈现停机。因而，在将任何数据从基于 EC2 的代理迁徙到基于 PaaSTA 的代理之前，咱们须要确保所有新组件都已到位。咱们还心愿最大限度地缩小迁徙所需的工程工夫，因而咱们施行了一些工具来帮忙自动化流程。最初，咱们须要确保这个过程通过全面测试并且是平安回滚的。
迁徙过程的第一步是为咱们的每个 Kafka 集群设置一个基于 PaaSTA 的负载均衡器，它也能够用于宣传基于 EC2 的代理。这裸露了连贯 Kafka 集群的两种不同办法：现有的 ELB 和新的服务网格代理，它将在迁徙期间和之后用于基于 PaaSTA 的代理。这须要更新上述 kafka_discovery 文件，以包含备用的连贯办法，咱们还设计了一种新办法来应用 cron 作业流传这些文件，而不是依赖 Puppet。正如在前一篇文章中提到的，缩小对 Puppet 的依赖有助于咱们将部署一个新 Kafka 集群的工夫减半，因为咱们能够更快地更改和散发这些配置文件。实现这些工作后，咱们还革除了相干缓存，以确保没有客户应用过期的集群发现信息。上面是一组图，阐明了这一过程：
集群连贯迁徙
接下来，咱们为集群部署了一个专用的 Cruise Control 实例，并禁用了自愈性能。咱们不心愿多个再均衡算法同时运行，因为自愈算法可能从新均衡集群，咱们阻止了 Cruise Control 主动挪动主题分区。在此之后，咱们为集群创立了一个 PaaSTA 实例，但咱们明确禁用了 Kafka Kubernetes operator 对 Cruise Control 的应用。对于具备 N 个代理的 EC2 集群，咱们随后增加了额定的 N 个基于 PaaSTA 的代理，从而在迁徙期间无效地将集群规模扩充了 1 倍。
在新的 PaaSTA 代理上线并衰弱运行后，集群中的 EC2 代理和 PaaSTA 代理数量相等。咱们还通过创立 \_\_CruiseControlMetrics 主题并在每次迁徙前设置适当的配置来启用指标报告。为了放弃对分区挪动工夫的管制，咱们禁用了以后的主动从新均衡算法。在这一点上，咱们已筹备好开始将数据从 EC2 代理中移出，并利用 Cruise Control 的 API 来移除他们。请留神，这个 API 仅将分区从指定的代理移开，并不会真正停用主机。在整个迁徙过程中，咱们持续 EC2 生命周期口头发送心跳，因为与 EC2 代理关联的主动缩放组将继续到迁徙过程完结。下图阐明了整个迁徙过程中每个组件的状态：
从条件再均衡脚本迁徙到 Cruise Control
咱们没有手动收回代理删除申请，而是构建了一个根本的迁徙助手服务来查看集群状态，重复向 Cruise Control REST API 发出请求，并逐个删除 EC2 代理。在 Cruise Control 实现将所有分区数据从 EC2 代理移到 PaaSTA 代理之后，咱们筹备终止 EC2 代理。这是通过将 ASG 的大小从 N 放大到 0，并在咱们的配置文件中删除对旧 EC2 ELB 的援用来实现的。因为咱们应用 Terraform 来治理 AWS 资源，因而回滚过程就像 git revert 从新创立资源。停用 EC2 代理后，咱们删除了停用帮忙程序服务的实例，并在集群的 Cruise Control 实例中启用了自我修复。当初这样做是平安的，因为集群齐全由基于 PaaSTA 的代理组成。至此，集群迁徙已实现，剩下的工作须要在认为平安后清理任何杂项 AWS 资源（主动缩放 SQS 队列、ASG、ELB 等）。
危险、回滚和金丝雀公布
尽管咱们致力优化平安而不是迁徙速度，但咱们的办法天然还是存在一些危险和毛病。一个思考因素是因为每个集群的规模翻倍而导致的长期成本增加。对此的代替办法是迭代地增加一个 PaaSTA 代理，从一个 EC2 代理进行数据迁徙，停用一个 EC2 代理，而后反复。因为这种办法将数据迁徙限度在每次一个代理的正本集，因而这种办法会缩短迁徙过程的总工夫。最终，咱们决定咱们偏向于迁徙速度，因而领有两倍数量的代理的后期老本是咱们违心领取的老本。此外，从久远来看，在 PaaSTA 上应用集群所带来的益处将超过这些初始老本。另一个衡量是，集群规模加倍也会导致咱们的一些高流量集群的集群规模十分大。这些集群在迁徙过程中须要额定的关注，而这种工程工夫老本也是咱们为了缩短迁徙工夫而违心进行的初始投资。
如果迁徙过程中呈现灾难性问题，咱们还须要设计回滚程序。在任何阶段按程序扭转迁徙过程的程序，就足以回滚更改（这次应用 Cruise Control 的 add_brokerAPI 而不是remove_broker 删除任何未决的重新分配打算后的 API）。与此相关的次要危险是, 迁徙和回滚过程都在很大水平上依赖于 Cruise Control 处于衰弱状态。为了升高这种危险，咱们评估了这些实例在测试集群上的资源需要，而后为非测试 Cruise Control 实例超额配置了硬件资源。咱们还确保对这些实例的健康状况进行充沛的监控和警报。最初，咱们提供了备份实例，如果主实例变得不衰弱，它将作为代替。
尽管这个打算在实践上仿佛是正当的，但咱们须要在实在集群测试它，并彻底记录任何异常情况。为此，咱们首先应用 Kafka MirrorMaker 克隆现有集群，而后在非生产环境中执行残缺的金丝雀公布迁徙，而后在生产环境中反复金丝雀公布迁徙。一旦咱们建设了足够的信念和文档，咱们就在开发和暂存环境中对所有的 Kafka 集群进行了真正的迁徙，而后再执行任何生产迁徙。
挑战和学习
如前所述，该打算的次要危险是 Cruise Control 必须是衰弱的，能力进行迁徙或回滚。在一些非产品迁徙中，咱们遇到了一些不稳固的状况，其中 Cruise Control 实例因为 Kafka 集群中的离线分区而变得不衰弱，临时呈现了代理不稳固的状况。因为 Cruise Control 的算法和外部集群模型依赖于可能读取（和写入）一组指标主题，则必须保护 Cruise Control 和每个 Kafka 集群之间的通信。因而，离线分区会阻止 Cruise Control 失常运行，所以在这些状况下，优先级是首先对 Kafka 中的问题进行分类和修复。此外，Cruise Control 公开配置值以调整其外部度量算法的各个方面，咱们发现缩小回溯窗口和所需数据点的数量有时会有所帮忙。这样做有助于 Cruise Control 在 Kafka 代理遇到离线分区的状况下更快地从新生成其外部模型。
因为咱们正在迁徙单个集群，从开发环境中的集群开始，咱们可能深刻理解 Kafka 集群在 PaaSTA/Kubernetes 上运行时与在 EC2 上运行时相比的性能特色。就像咱们在 EC2 裸机上运行的实例抉择规范一样，咱们可能依据资源需要建设具备不同实例类型的 Kafka 池（例如，规范池和大型池，每个池都蕴含不同的实例类型）。
咱们最后为迁徙过程思考的另一种办法是建设一个新的基于 PaaSTA 的集群，其中蕴含 N 个代理，而后应用 Kafka MirrorMaker 将现有 EC2 集群的数据“克隆”到这个新集群上。咱们还思考调整策略，减少一个 PaaSTA 代理，删除一个 EC2 代理，而后反复 N 次。然而，这将须要为迁徙目标更新 operator 的协调逻辑，并且咱们须要手动确保每个代理对位于同一可用区。它还会引入一个简短的数据复制步骤，咱们认为这对于大型集群来说是不可承受的。在咱们的开发环境中对程序进行了一些进一步的测试后，咱们最终确定了这里形容的程序。
云原生技术社区有 20+ 技术交换群，想进群跟技术大牛们聊天，请加小助手 vx：alaudacloudnative
本文由 mdnice 多平台公布
