架构团队中间件容器化优势和挑战
架构团队：戈震、周培、李亮
当下，为了降本增效，各大厂都在通过 PaaS 平台，管理各类中间件服务。一种常规的实现思路是通过实现 PaaS 对虚拟机、物理机的直接操作，实现中间件生命周期的管理，这也是新东方技术团队之前的方案。但要做到完善的资源管理、可用性保证、可观测性、资源利用率最大化等方面的能力，需要大量的开发成本。因此我们决定引入 Kubernetes 来解决这个问题。现在，新东方集团架构团队提供的 Redis、Kafka、RocketMQ 等 PaaS 产品已经实现了 100% 的中间件服务运行在 Kubernetes 环境上。实现了集群秒级交付，监控告警运维一体化。在云化的过程中，既有收益也有挑战，本文将分为三大部分展开，分别是：
传统运维困境和云化运维对比 中间件 PaaS 产品生态和功能 中间件容器化过程中遇到的网络方面挑战
针对目前业务场景，架构团队自研并落地了 Capo 项目：基于 Calico 的“IP 预留延迟释放”方案，以解决网络治理遇到的挑战，保证大批量 Pod 重建时，集群和业务的稳定运行。目前该项目已经开源：
项目地址：https://github.com/xdfdotcn/capo
让我们来看一下其中的细节。
传统运维困境和云化运维优势
摘要
资源管理会一直伴随中间件的整个生命周期，在不同阶段对管理的需求也各不相同，概览如下：
创建阶段
需求描述
本阶段的主要需求是资源分配。首先我们需要根据各类中间件的拓扑特点以及资源需求进行主机分配，然后在主机上进行实际的内存、CPU、磁盘规划分配，以及端口资源分配。
例如某个 3 主 3 从的 redis 集群，我们需要：
将其主从分配到空闲资源满足其内存、cpu 需求主机上。 为了更高的可用性，我们需要尽量将实例调度到不同的主机上。 确定了分配的主机后，需要根据该主机的端口使用情况分配若干可用的端口给该实例作为服务端口。
这里面实际是执行了工作负载调度和端口分配两个操作。
调度的依据是拓扑反亲和性和主机空闲资源情况，这时需要考虑的情况有很多，例如：
若存在空闲资源的主机数量小于实例数量，我们如何执行调度？ 最少需要几台主机存在，我们才可以完成具备目标可用性的中间件集群部署？ 若可用主机数量低于可接受的最小值，能否有一些优先级较低的集群出让一些资源，以满足本集群需要？
端口的分配需要考虑到端口资源空闲的情况，以及将来集群被释放后动态规划、调整。
传统实现成本
若要在传统的 PaaS 平台中实现上述需求，则至少需要开发以下几个能力：
节点资源采集、存储对接（需要考虑兼容不同类型的存储） 工作负载调度 端口资源采集与管理
云化实现成本
通过 Kubernetes 申明式 API，配置期望的工作负载的拓扑策略，即可通过 Kube-Scheduler 的能力完成调度工作，这其中包含了计算资源的分配。 通过容器的网络命名空间（Network Namespace）隔离即可实现同一台主机上的不同中间件实例使用相同的服务端口，从而省略了端口资源管理的需求。 利用 Kubernetes 提供的容器存储接口（Container Storage Interface），通过一个标准接口规范，借助 CSI 编排系统可以将任意存储系统对接给中间件容器工作负载。
因此在云化的环境下，实现上述需求只需要开发以下能力：通过 Kubernetes API 构建工作负载资源。
运行阶段
需求描述
对于已分配资源的隔离：如何保证工作负载可以且只能使用分配给自己计算资源。通过对工作负载的参数配置可以实现一部分资源的隔离，但不完全，例如 通过 JVM 的配置可以实现大部分内存区域最大值限制，但无法对进程占用的总内存做限制 JVM 没有对于最大 CPU 使用率、最大磁盘空间的限制 若主机上资源不足时，如何按照某种优先级转移一部分工作负载到其他主机 如何保证主机的资源使用率达到理想阈值：单一中间件很难使各计算资源都充分使用，多中间件混合部署会造成 PaaS 的开发复杂度上升
动态需求主要包含以下几点：
水平扩容：集群中增加新实例的场景，这和创建阶段的需求类似 垂直扩容：本主机空闲资源可满足扩容和不满足扩容时的处理策略
传统实现成本
若要在传统的 PaaS 平台中实现上述需求，则至少需要开发以下几个能力：
主机资源限制和隔离：通常是利用 PaaS 平台控制 CGroup、Namespace、LVM 等实现 由于主机计算资源不足而触发的工作负载驱逐 多种中间件集群（甚至是其他无状态服务）在同一主机集群中混合部署 已经启动的工作负载重新分配资源，设置隔离阈值
云化实现成本
Docker 容器天然就具备对工作负载的资源隔离和限制、以及 Kubelet 在主机资源紧张时对工作负载进行驱逐。 在一个 Kubernetes 集群中运行多种中间件、工作负载类型即可解决资源使用率的问题。 对于工作负载重新配置资源阈值即可实现计算资源重新分配。
因此，在云化的环境中，实现上述需求只需要开发以下能力：通过 Kubernetes API 指定和修改工作负载资源阈值。
可用性
需求描述
虽然大部分中间件天然就具备高可用的能力，可以允许同一个集群中的小部分节点不可用。但当故障发生时，虽然集群工作状态正常，但仍需要尽快将故障节点恢复，使集群恢复至高可用状态。比如在一个 3 主 3 从的 redis 集群中，某个 master 所在的主机发生了宕机。这时通过集群模式的自动故障恢复可使集群在 10 秒左右恢复正常的服务状态，但考虑到这时集群已不是高可用状态，运维人员仍需要尽快介入，恢复故障节点，使集群恢复 3 主 3 从的高可用拓扑。若宕机的主机不能立即恢复，我们还需要在另一台主机上恢复该实例。那么持久化数据如何迁移到新主机上。
持久化数据一般分为两种：元数据及应用数据。元数据是指集群运行过程中产生的必要元数据，例如 redis 集群模式下的 node.conf 配置文件。这部分数据只能通过备份到远程存储系统解决迁移问题。应用数据可以通过中间件本身的恢复机制，但会对集群中的其他实例造成一定性能压力，数据量较大时甚至会影响客户端应用。
因此，大概率要通过引入一套分布式存储服务来解决数据迁移问题。这时需要 PaaS 中实现远程卷的控制。若要做到很高的鲁棒性，会大幅提升整体的实现复杂度。
传统实现成本
若要在传统的 PaaS 平台中实现上述需求，则至少需要开发以下几个能力：
各工作实例的状态监控 各中间件集群的拓扑监控 故障节点处理策略：重启实例还是构建新实例，这往往需要人工参与 构建新实例 旧实例环境清理 分布式存储系统的构建与运维 PaaS 平台对于分布式存储系统的控制
云化实现成本
通过 Kubelet、CSI、Kube-controller-manager 我们可以 0 成本实现上述能力中的 1、2、3、4、5、7所以云化需要的实现成本是：分布式存储系统的构建与运维。
可观测性和告警
需求描述
作为 DevOps 系统，具备可观测性已经是必备能力，基本都是基于 Promethes + Grafana + Alertmanager 生态实现。指标的暴露和抓取需要根据 PaaS 平台的实例状态动态调整。
传统实现成本
若要在传统的 PaaS 平台中实现上述需求，则至少需要开发以下几个能力：
部署中间件实例的 Exporter 服务用于暴露集群监控指标 修改中间件实例的 Exporter 的配置文件：修改实例目标 引入注册中心，动态发现 Exporter Target，也可以通过修改 Prometheus 的配置文件实现
云化实现成本
通过 Kubernetes 的 Sidecar 机制，实现 Exporter 和中间件实例在同一个 Pod 中启动，我们只需要通过对 Target Pod 增加 Annotation 即可完成指标的暴露，以及 Promethues 的采集。 结合成熟的 Prometheus Operator 实现告警策略的动态热更新，轻松对接 Alertmanager 告警通道和 Grafana 可视化展示各种监控指标。
因此，云化实现成本为 0。
收益
通过对比两种方式实现 PaaS 中的部分功能：资源管理、可用性、可观测性，我们可以非常明显的体会到 Kubernetes 带给我们收益：
大幅降低 PaaS 平台开发成本 缩短了中间件集群交付周期 强大的调度机制实现精细化资源管理，提高了资源利用率 只需要较低的人力成本，即可维护多样化的中间件集群生命周期
中间件 PaaS 产品生态功能
下图是架构团队基于 Kubernetes 的中间件 PaaS 产品生态
底层通过自研 Operator 和 基于开源 Operator 做二次开发，实现了中间件集群的自动化运维能力。集成了 Prometheus + Grafana + AlertManager + Xcloud-Alert 实现了监控告警自动化。底层存储使用了架构团队自研的 XLSS 存储系统，利用 DRBD 物理实时备份到多个主机的机制，保证主副本数据严格一致。有状态工作负载直接操作本地存储资源，避免网络传输延时，具有极致的 IO 性能。
Kafka PaaS 功能
实现自动化运维 Kafka 集群整个生命周期 多租户认证授权管理 支持 SCRAM、PLAIN、SSL、PLAINTEXT 认证类型的集群 故障自愈 Zookeeper、Kafka 监控可观测性，对接告警系统
Kafka PaaS 架构图如下：
Kakfa PaaS 产品界面如下：
RocketMQ PaaS 功能
实现自动化运维 RocketMQ 集群整个生命周期 创建主从集群； 创建 DLeger 高可用集群，故障主从自动切换； 创建 ACL 集群，访问需要认证授权； 扩 Broker、NameServer 实例数；扩实例 CPU、内存； 支持 RocketMQ 版本 4.7、4.8 支持创建主从集群、DLedger 高可用集群（故障时主从自动切换）、ACL 集群（访问需要认证授权） 扩 Broker、NameServer 实例数；扩实例 CPU、内存 支持监控、原生 Console 管理平台
RocketMQ PaaS 架构图如下：
RocketMQ PaaS 产品界面如下：
Redis PaaS 功能
实现自动化运维 Redis 集群整个生命周期 自定义主节点数量和每个主节点的副本数量 主从均匀打散分布 自定义集群配置 故障自动修复 整合监控报警系统，增强可观测性
Redis PaaS 架构图如下：
Redis PaaS 产品界面如下：
中间件容器化挑战
在 Kubernetes 中，管理和配置容器网络是非常重要的，Calico 作为 Kubernetes 的第三方容器网络插件，为 Kubernetes 集群提供容器网络解决方案，使得集群中的容器能够相互通信，并且与外部网络进行交互。Pod IP 地址是由 Calico 自动动态分配的，可能会随着 Pod 的重建而变化。容器化的中间件集群，Pod 重建也是不可避免的。如何保证重建后集群拓扑不会混乱，客户端能重连成功，存在很大的挑战。为此架构团队落地了 Capo 项目，其中采用了“IP 预留延迟释放”的方案。当 Pod 重建时，会将 Pod 的 IP 地址保留一段时间，保证 IP 在短时间内不会被重复使用。总的来说，采用了一些措施来保证容器化中间件集群在 Pod 重建后不会出现拓扑混乱和客户端重连失败的问题。
Zookeeper
问题
新东方部分业务使用 ElasticJob 做分布式任务调度，使用了架构团队容器化的 Zookeeper。ElasticJob 调度框架使用 Curator 客户端连接 ZK 集群。当 ZK 集群所有 PodIP 变化之后，Curator 客户端连接集群会失败，导致业务 Job 运行异常，只能重启业务端服务才能恢复。
经过阅读 ElasticJob 和 Curator 源码之后发现，Curator 提供了一个 ensembleTracker 参数，默认为 true。会动态跟踪集群实例变化。1、我们给业务方提供的是 Service 域名（不会变化）连接 ZK 集群。2、连接成功后，会读取 /zookeeper/config 配置，获取集群各个实例的域名，然后解析为每个 ZK 实例的 PodIP（会变化），之后发生重连时会连接 PodIP。3、当集群内 PodIP 全部变化之后，无法获取到正确的 IP ，此时不会尝试通过种子节点 ClusterIP 连接集群，导致重试一直失败。
解决方法
虽然 Curator 提供了 ensembleTracker 参数，但 ElasticJob 框架没有将此参数暴露出来供开发者修改。我们通过修改 ElasticJob 源码，暴露 EnsembleTracker 参数可配置，发布新东方内部版本，提供给业务做升级。将 ensembleTracker 设置为 false，这样 Curator 客户端总是和 Service ClusterIP 建立连接。
Redis 集群和客户端异常
问题
在基于 Kubernetes 的云原生环境下，多个 Redis 集群实例会分布到一个或多个主机上。
例如下面各 6 个实例的 A、B 两个集群：
A、B 集群的 6 个 Pod 实例都均匀分布到 node01~node06 主机上。当 node01 主机故障后，A1 和 B1 Pod 实例会一直处于 Terminating 状态直到 kubelet、docker 恢复正常才可以完成 Pod 删除。
此时 node01 主机恢复正常，A1、B1 还会调度回 node01，会发生 IP 交换的问题，即：
A1 Pod 的 IP 从 172.20.1.1 变化为 172.20.1.2（原来 B1 Pod IP） B1 Pod 的 IP 从 172.20.1.2 变化为 172.20.1.1（原来 A1 Pod IP）
对于 Redis 集群特点，客户端必须使用 IP 连接集群，当多个 Redis 集群 Pod 同时重建之后，如果 IP 发生交换，会带来两个问题：1、Redis 集群中实例通过 Gossip 协议通信时不会校验密码， 导致多个 Redis 集群组成一个“大集群”，拓扑变的不符合预期；2、客户端仍然会连接旧的 IP，但此时这个 IP 被另一个集群占用，即：连接到错误的集群。如果密码错误，会一直重试，这会对客户端系统造成中断。
解决方法
Calico 内置了 IPReservations 资源对象，可以从 IP 池中预留 IP 地址、CIDR，保证 IPAM 在分配 IP 时不会将预留的 IP 分配给 Pod。所以需要有一个组件实现这些功能：
在 Pod 发生重建时，将 IP 添加到 IPReservations 增加已预留时间达到阈值、预留数量达到阈值时释放 IP 的机制
本方案将上述功能点自研了名为 Capo 的项目，架构图如下：
IP 预留流程说明：在删除 Pod （Delete）和主机维护驱逐 Pod（Drain）时，会发起 Delete Pod 请求：
请求先到达 Kube-APIServer，根据 Pod 是否符合有状态服务（StatefulSet）的特征（标签中包含 statefulset.kubernetes.io/pod-name） 如果是有状态服务 Pod，则会发送请求到 Capo Webhook Server 此时 Pod 还没有到真正的删除阶段（即 IPAM cmdDel 释放 IP），所以 Capo 可以获取到 IP 信息 Capo 将 IP 更新到 IPReservations 资源对象中，调用 Kube-APIServer 持久化到 Etcd 中 Capo 将 Pod 详情、预留的开始时间和 IP 对应关系更新到 IP Info ConfigMaps 中，调用 Kube-APIServer 持久化到 Etcd 中 上面步骤都成功之后，给客户端返回删除 Pod 请求发送成功
此时，Kube-APIServer 发送删除请求，触发 Kubelet 开始释放 IP 资源，调用 Calico CNI 执行 cmdDel 逻辑，将 Pod IP 释放掉。
重新分配 IP 说明：当 Pod 重建分配 IP 时，Calico IPAM 不会自动将 IPReservations 资源对象中的 IP 分配给容器，而是从其余的 IP 中进行分配，所以 IP 不会发生交换。
Redis 集群实例之间利用 Gossip 协议通信时，由于连不上旧 IP，所以不会发生集群拓扑混乱。Operator 会将新建的 Redis 实例加入集群，失败的实例 Forget 掉，保证集群拓扑恢复正常。 客户端在经过拓扑刷新之后，就可以连接到正确的集群实例。
IP 释放机制：IP 预留数量不宜过多，否则会造成 IP 资源浪费，所以需要有种机制，在合适的时机将其释放，以便被重复利用。
Capo 程序每 5 秒检测一次是否需要释放，目前有两种释放机制：
IP 已预留时间达到阈值：判断 IP Info ConfigMaps 中已经预留的 IP 时间是否达到设定值，达到则开始释放流程。 已预留 IP 数量达到阈值：允许单个 Kubernetes 主机上所有 Pod 重建时 IP 可以预留，所以 IP 预留数量阈值一般设置为 1.2 * maxPods。Capo 程序判断 IP Info ConfigMaps 中已经预留的 IP 数量是否达到设置阈值，如果达到，则会根据已经预留时长对 IP 进行排序，获取已预留时间最长的 IP 数据列表，开始释放流程。
IP 释放流程说明：满足释放条件的 IP，进行释放流程：
Capo 将需要释放的 IP 从 IP Info ConfigMaps 资源对象中删除，然后调用 Kube-APIServer 持久化到 Etcd 中 Capo 将需要释放的 IP 从 IPReservations 资源对象中删除，然后调用 Kube-APIServer 持久化到 Etcd 中
释放后，Calico IPAM 在分配 IP 时，则会将释放的 IP 分配给 Pod。
总结
经过架构团队 2 年时间的中间件容器化经验沉淀，目前各类中间件接入集群数量共：140+，并总结出以下收益：
快速部署和扩展：容器化中间件可以在几秒钟内快速启动和停止，而且可以轻松地部署到多个服务器中，也方便进行水平扩展，从而提高了应用程序的可靠性和性能。 资源隔离和更高的稳定性：容器化中间件可以提供更好的资源隔离，确保不同的应用程序和服务不会相互干扰，从而提高了系统的稳定性。 关注点分离：容器化中间件可以快速搭建开发和测试环境，专人运维，使得业务方专注于开发和测试，从而提高了软件交付效率和质量。 更好的容错和恢复能力：容器化中间件可以帮助应用程序快速恢复到以前的状态，因为容器可以轻松地备份和还原。 安全性：容器化中间件可以提供更好的安全性，因为容器之间是隔离的，并且可以使用容器专用的网络来保护应用程序和数据。 可移植性：容器化中间件可以在不同的环境中运行，因为容器本身包含了应用程序所需的所有依赖项和配置信息，从而提高了应用程序的可移植性。
在下一篇文章中，将对架构团队 Capo 的原理及开源之路展开详细讲解。
项目地址：https://github.com/xdfdotcn/capo