Slack 发布用于 Kubernetes StatefulSet 部署的 Operator_AI阅读总结 — 包阅AI

Slack 开发了一个定制的 Kubernetes Operator，旨在克服管理 StatefulSet 部署时的限制。在 Slack 的工程博客上，Clément Labbe（高级云计算工程师）介绍了 Bedrock Rollout Operator，开发这个 Operator 的初衷是为了提供更精细的控制和增强功能，优化在 Kubernetes 集群中部署有状态应用程序的过程。

工程师通常使用 StatefulSet 来运行需要持久存储和具有唯一 Pod 标识的应用。然而，Slack 的工程团队发现，现有的 StatefulSet 更新策略存在一些局限性。默认的 RollingUpdate 策略虽然实现了自动化更新，但一次只更新一个 Pod，在处理拥有大量 Pod 的应用程序时会导致部署过程变得相当缓慢。OnDelete 策略虽然提供了手动控制的灵活性，但缺少像基于百分比的滚动更新这样的高级功能。

Slack 使用 Kubebuilder 开发了 Bedrock Rollout Operator，以满足其内部团队对于更高效部署的需求。这个 Operator 负责管理一个叫作 StatefulsetRollout 的自定义资源，封装了 StatefulSet 规范以及用于增强功能的附加参数。

Bedrock Rollout Operator 解决了几个基本问题：

部署缓慢： 它突破了默认 RollingUpdate 策略的局限，这个策略一次只更新一个 Pod，对于拥有许多 Pod 的应用程序来说效率低下。

控制不足： 它提供了比原生 Kubernetes 更精细可控的滚动更新机制，允许进行更快的基于百分比的更新，并能够暂停更新。

回滚能力有限： 它在必要时提供了更为迅速的回滚选项。

集成差距： 它与 Slack 的内部服务发现（Consul）集成，并通过 Slack 发送滚动更新状态通知，填补了现有工作流的空白。

定制需求： 它允许 Slack 实现符合其特定需求的自定义滚动逻辑，而标准的 Kubernetes 功能未能满足这些需求。

可见性： 通过实时的 Slack 通知和与内部发布管理 UI 的集成，提高了滚动更新过程的可见性。

大规模管理： 尽管需要做一些调整，但该解决方案有效支持管理多达 1000 个 Pod 的大型 StatefulSet 部署。

该 Operator 已成功部署在 Slack 庞大的 Kubernetes 基础设施中，覆盖了 200 多个集群，并有效管理着近 100 个有状态服务。

滚动更新过程从 Slack 工程师在 bedrock.yaml 文件中定义他们的应用配置开始。当开发人员通过 Slack 的内部发布平台启动部署时，Bedrock API 将这个配置转换为 StatefulsetRollout 资源。

Bedrock Rollout Operator 持续监控 StatefulsetRollout 资源，确保期望状态与集群的实际状态保持一致。它负责执行创建或更新 StatefulSet 和终止 Pod 等操作以实现滚动更新。与事件驱动方式不同，这个 Operator 采用了自排队协调循环机制。这种方法可以确保按顺序处理自定义资源，减少了竞态条件的发生，简化了整个协调过程。

该 Operator 通过详尽的文本 Slack 通知向用户实时传达更新情况，包括版本号和正在滚动更新的 Pod 列表等详细信息。此外，它还与 Bedrock API 通信，报告滚动更新的成功或失败状态，确保 Slack 的发布管理 UI 能够准确反映当前的更新状态。

虽然这个自定义 Operator 已被证明对 Slack 的需求有效，但也存在一些限制。在处理包含多达 1000 个 Pod 的大型 StatefulSet 部署时出现了一个挑战，需要对通知系统做出调整，以防止因频繁通知而触发的速率限制问题。另一个限制是在对 StatefulSet 部署采用 OnDelete 策略时固有的“版本泄露”问题。在滚动更新被暂停或未完全执行的情况下，运行旧版本的 Pod 因非更新原因而被终止，它们可能会被运行新版本的 Pod 所替换，这可能导致渐进、无意的全滚动更新。为了缓解这一问题，Slack 鼓励团队及时完成他们的滚动更新流程。

Slack 开发了一个与现有内部系统和通信渠道完美融合的定制解决方案，实现了对 StatefulSet 部署的更精细的控制。随着 Kubernetes 的持续演进，其维护者可能会将其中一些功能纳入 Kubernetes 的核心功能集中。然而，在这一过程中，Operator 模型所提供的灵活性和深度集成能力，对于那些有着复杂部署需求和定制化基础设施的组织来说，仍然具有不可估量的价值。

Slack 计划扩大使用 Operator 模型来管理 Kubernetes 部署的策略。他们正在探索现有的 CNCF 项目，如 Argo Rollouts 和 OpenKruise，这些项目主要针对非有状态部署资源。其他组织也开发了专门用于滚动更新的 Operator——例如，Grafana Labs 提供了一个对滚动更新进行更细粒度控制的 Operator。其他产品，如 Argo Rollouts 也提供了类似的功能，另外还提供了蓝绿部署、金丝雀部署、金丝雀分析、实验和渐进式交付功能，但主要专注于 Deployment 资源。Flagger 提供了带有或不带有会话亲和性的金丝雀发布功能，以及蓝绿和 A/B 测试，以满足类似的需求。Bikram Kundu 在 Jstobigdata 博客上讨论了 Kubernetes StatefulSet 的复杂性和局限性，并总结了该领域的一些最佳实践。

查看英文原文：

https://www.infoq.com/news/2024/08/slack-kubernetes-operator-bedroc/

声明：本文由 InfoQ 翻译，未经许可禁止转载。