672 讀數

改变游戏规则的流媒体：Apache Pulsar 推出自动缩放功能

经过 DataStax9m2023/07/13

太長; 讀書

我们很高兴为 Apache Pulsar（即 KAAP）推出 Kubernetes Autoscaling。 KAAP 是一个 Kubernetes Operator，可在 OperatorHub 上使用。

featured image - 改变游戏规则的流媒体：Apache Pulsar 推出自动缩放功能

Apache Pulsar 始终将自己视为云原生。它就在主页上：

“Apache® Pulsar™ 是一个专为云构建的开源分布式消息传递和流媒体平台”

Pulsar 当然体现了许多云原生原则，包括计算与存储的分离，其中 Pulsar 代理处理消息服务，Apache BookKeeper 处理消息的存储，以及可以随意扩展和缩小的无状态组件的想法Pulsar 经纪人。

然而，它从未真正兑现云的最终承诺：自动扩展。至少，直到今天。

我很高兴向大家介绍 Kubernetes Autoscaling for Apache Pulsar（即 KAAP）。 KAAP 是一个 Kubernetes Operator，可在OperatorHub 上使用。它包含您期望 Kubernetes 运营商提供的所有细节。一旦您在 Kubernetes 集群中安装了 Operator，您就可以通过应用单个自定义资源定义 (CRD) 来获得功能齐全的 Pulsar 集群，如下所示：

 apiVersion: kaap.oss.datastax.com/v1alpha1 kind: PulsarCluster metadata: name: pulsar spec: global: name: pulsar image: 'apachepulsar/pulsar:3.0.0'

Pulsar 有多个组件：ZooKeeper、BookKeeper、代理和代理。操作员使用PulsarCluster CRD 来配置所有这些。由于操作员在集群级别工作，因此您不必担心组件如何协同工作。接线员会为您处理这些事情。

自动分阶段升级

为 Pulsar 运营生产云服务的时间比我认识的任何人都长（首先是凯斯克现在有了 DataStax Astra Streaming），我直接知道了 Pulsar 集群的正确升级需要多长时间。虽然 YOLO 可以一次升级所有组件，但推荐且最安全的方法是一次升级每个组件，确保每个组件已成功升级，然后再转到下一个组件。

这是我们在 Astra Streaming 服务中升级 Pulsar 集群时遵循的流程，因为我们的客户服务的可用性至关重要，但这对于我们的生产工程团队来说非常耗时。事实上，这是他们的首要要求：你能让升级更智能、更自动化吗？嗯，通过 KAAP，我们已经做到了这一点。

通过PulsarCluster CRD 中的单行更改，您可以触发 Pulsar 集群的分阶段升级。 KAAP 操作员将精心安排您的集群的分阶段升级。当然，您应该在升级期间监控指标，但您可以让 KAAP 操作员驾驶（不要在方向盘上睡觉）。

开源自动缩放

自动分阶段升级固然不错，但这并不是我对 KAAP 最感兴趣的地方。弹性资源的概念是云的一个关键承诺。这就是为什么许多 AWS 服务的名称中都包含“弹性”。我（实际上是ChatGPT ）快速搜索了一下，至少有 10 个。

云使您能够按需获取和释放资源，因此您可以使用自动缩放技术来将应用程序正在使用的资源数量与其负载相匹配。随着负载的增加，您可以自动添加更多资源。随着负载的减少，您可以释放资源。由于云提供商对资源的使用收费，因此自动扩展可以帮助您最有效地利用云支出。

我相信我们都能想到具有幕后自动缩放功能的云服务示例。大多数“弹性”AWS 服务都是这样工作的。然而，自动缩放的实现是专有的，锁定在供应商的私人存储库中。有时他们会谈论他们如何实现自动缩放，就像这样纸关于 AWS DynamoDB，或者这个博客文章关于 Confluence Cloud 如何使 Kafka 具有弹性。但据我所知，没有人将其自动缩放实现开源，并在真正的开源许可下免费提供给所有用户。这正是我们与 KAAP 所做的事情。

KAAP 为您的 Pulsar（或露娜流媒体，我们的 Pulsar 发行版），采用 Apache 2.0 许可证。您可以在我们的中查看GitHub 存储库。如果喜欢的话记得给个star哦。

Pulsar + 自动缩放：完美搭配

KAAP 为您提供了一种在 Kubernetes 中运行时向 Pulsar 添加自动缩放功能的方法。不是在 Pulsar 代理部署上附加一些简单的 Horizontal Pod Autoscaler (HPA)，而是一个复杂的自动缩放器，它与 Pulsar 现有的云原生组件配合使用，提供真正弹性的流和消息传递系统。在我看来，这是一个无可匹敌的组合。

无状态代理扩展

我们来看看KAAP的两个主要的自动缩放维度。首先，我们来看看 Pulsar 经纪商。您可能知道，Pulsar 代理是无状态的，这意味着您可以根据需要轻松扩展和缩小它们。但您可能不知道的是，Pulsar 有一个内置的 Broker 负载均衡机制，可以持续监控每个 Broker 上的 CPU、内存和网络带宽。使用该信息和一种可配置的负载平衡算法，Pulsar 会将主题从一个代理转移到另一个代理，以防止代理过载。

一个简单的自动扩展解决方案是在代理上配置 Kubernetes Horizontal Pod Autoscaler (HPA)，当 CPU 等某些指标变高时，扩展另一个代理 Pod。但这实际上可能没有必要，因为 Pulsar 代理负载均衡器可以决定转移主题以同时平衡负载。现在，您已经扩展了不需要的 Broker Pod，因为 Pulsar 负载均衡器已经平衡了一切。因此，现在 HPA 决定缩小新代理 Pod 的规模，这会导致在其上创建的任何新主题都转移到现有代理中。正如您可以想象的那样，Pulsar 负载均衡器和 HPA 可能会导致代理上下混乱，并且主题在代理之间转移。

KAAP 通过直接与 Pulsar 负载均衡器集成来避免这个问题。当 Pulsar 负载均衡器的集群范围指标表明集群接近容量时，KAAP 会扩展代理，而不是在单个代理 Pod 繁忙时扩展代理。只有当整个集群的使用率低于配置的阈值时，它才会缩小代理的规模。 KAAP 操作员与 Pulsar 代理负载均衡器一起工作，而不是与之对抗。

上下扩展存储：太棒了！

扩展 Pulsar 的计算（或服务）层很棒，但对于真正的自动扩展实现来说还不够。当然，需要处理的消息（或事件）数量可能会随着时间的推移而变化，但是需要存储的消息数量又如何呢？我们可能都必须处理由于下游系统故障而积压的消息。随着中断时间的延长，流媒体系统上的可用存储空间开始减少。

在这个场景中，Pulsar 及其对 BookKeeper 的依赖大放异彩。要向 Pulsar 集群添加存储容量，您只需添加一个新的 BookKeeper 节点（亲切地称为“bookie”）。由于 BookKeeper 存储基于主题片段而不是整个主题，因此新的 bookie 可以立即用于缓解存储压力，无需进行任何痛苦的主题重新平衡或任何其他操作干预。

KAAP 当然可以为您处理这种情况。它不断监控 bookie 节点的磁盘使用情况，如果可用存储空间变低，它将扩展一个新的 bookie 节点。这并不是那么了不起（至少对于 Pulsar 来说）。在 Kubernetes 中添加新副本非常简单，即使它是有状态的并且由持久卷支持。但是，当停电结束并且积压的订单已清除时呢？您现在是否遇到了额外的 bookie 节点消耗不再真正需要的资源的情况？

KAAP 则不然，你就不是。一旦 BookKeeper 存储下降到配置的阈值以下，KAAP 操作员将仔细安排删除不需要的 bookie 节点。它以非常安全的方式做到这一点，确保不会丢失任何消息，并且始终保持所需的复制因子。例如，如果您已将 Pulsar 配置为保留每条消息的三个副本（写入和确认仲裁数量均等于 3），KAAP 会与 BookKeeper 交互，将消息从正在缩小的 bookie 复制到其他 bookie，以确保有该消息至少有三份可用。一旦成功完成，它将继续删除不需要的赌注。

借助 KAAP，您可以自动上下扩展 Pulsar 集群中的存储，以便您可以优化集群中的存储使用情况，而不会在发生不幸的生产事件后陷入闲置容量。我不了解你，但我认为这非常了不起。

区域感知和迁移工具

KAAP 可以对 Pulsar 集群进行分阶段升级和智能扩展。但还有更多。要在云提供商中运行高度可用的集群，考虑可用性区域 (AZ) 非常重要。如果您不跨可用性区域分布组件（尤其是 BookKeeper），您将无法在可用区故障中幸存并提供多个 9 的可用性。

幸运的是，Pulsar 具有强大的内置功能，例如机架感知，以支持高可用性部署。棘手的部分是，要正确设置它，您需要使用区域感知正确配置 Kubernetes，并配置 Pulsar。 KAAP 操作员通过引入资源集的概念为您提供帮助，使您能够对组件进行分组并赋予它们机架意识。 KAAP Operator 将根据您的资源集声明性配置自动应用 Kubernetes 和 Pulsar 配置。资源集非常灵活，允许您支持各种 Pulsar 部署选项。

如果您已经使用 Helm 图表或者只是一些 Kubernetes 显化魔法来运行 Pulsar，该怎么办？ KAAP 有一个迁移工具可以帮助您。您可以将迁移工具指向现有的 Kubernetes Pulsar 部署，它将自动生成匹配的 CRD 配置，您可以使用该配置让 KAAP 操作员接管为您操作集群。

KAAP 堆栈

KAAP Operator 具有许多出色的功能，可将常规 Pulsar 集群涡轮增压为运转良好、高度可用的自动扩展机器。但作为长期运营生产 Pulsar 集群的人，我知道创建生产 Pulsar 集群还有很多其他考虑因素，例如 TLS 证书管理、身份验证和监控。

这就是为什么我们在操作员中包含了所谓的 KAAP 堆栈。它是一个伞形 Helm 图表，安装 KAAP 操作员以及关键生产工具，包括：

证书经理
钥匙斗篷
普罗米修斯堆栈（Grafana）
Pulsar Grafana 仪表板

这些是运行我们的生产 Pulsar 集群时必备的工具，我们不想让您陷入困境，因此我们将它们全部放在一起，并将它们集成到一个方便的包中。

为什么要使用KAAP？

您已经了解了适用于 Apache Pulsar 的 Kubernetes Autoscaling 的所有出色功能。您可以使用单个 CRD 创建整个 Pulsar 集群。您可以将升级置于自动驾驶状态，并让 KAAP 操作员执行安全、分阶段的升级。您可以根据 Pulsar 代理负载均衡器（表示代理过载）自动扩展和缩减 Pulsar 代理，并且您可以根据集群的存储要求安全地扩展和缩减 BookKeeper 节点（！）。您可以轻松配置集群以实现可用性区域感知，从而实现高可用性。它甚至还包括一个迁移工具，以便您可以轻松地从旧的基于 Helm 的部署迁移到基于 KAAP 操作员的涡轮增压部署。

那么，KAAP 有很多很棒的功能，但有哪些好处呢？我能想到几个：