Slack 开发 Bedrock Operator 以优化 Kubernetes StatefulSets 管理
内容提要
Slack开发了Bedrock Rollout Operator来解决在Kubernetes集群中管理StatefulSet部署的限制。该操作符提供了更好的控制和功能，用于部署有状态的应用程序，如更快的部署、增强的回滚能力以及与Slack内部服务发现和发布管理UI的集成。它允许自定义的部署逻辑，并通过Slack通知提供实时更新。尽管该操作符有一些限制，但对于Slack的需求已经证明是有效的。Slack计划扩大其在管理Kubernetes部署中使用操作符模型的范围。
延伸解读
为何需要自定义 Operator
Slack 发现 Kubernetes 原生 StatefulSet 更新策略存在不足：默认的 RollingUpdate 一次只更新一个 Pod，对于 Pod 数量多的应用部署缓慢；OnDelete 虽可手动控制，但缺乏基于百分比的滚动等高级功能。这些限制促使 Slack 开发 Bedrock Rollout Operator，以提供更快的部署、更好的控制和回滚能力，并集成内部服务发现和发布管理 UI。
Operator 的工作机制
该 Operator 管理自定义资源 StatefulsetRollout，其中封装了 StatefulSet 规范及额外参数。工程师在 bedrock.yaml 中定义应用配置，Bedrock API 将其转换为 StatefulsetRollout 资源。Operator 通过自我排队的调和循环监控资源，顺序处理自定义资源，降低竞态条件风险，并简化调和过程。它创建或更新 StatefulSet、终止 Pod 以推进发布，并通过 Slack 通知提供实时更新。
规模与限制
Operator 部署在 Slack 的 200 多个 Kubernetes 集群中，管理近 100 个有状态服务，支持多达 1000 个 Pod 的 StatefulSet。但在处理超大 StatefulSet 时，通知系统需调整以避免速率限制。此外，使用 OnDelete 策略存在“版本泄漏”问题：当发布暂停或部分完成时，因其他原因终止的旧版本 Pod 可能被新版本 Pod 替换，导致逐渐意外地完成全量发布。Slack 通过鼓励团队及时完成发布来缓解此问题。
未来方向与行业实践
Slack 计划扩大 Operator 模型的使用范围，并探索现有的 CNCF 项目如 Argo Rollouts 和 OpenKruise 用于非有状态 Deployment 资源。其他组织也开发了类似 Operator，例如 Grafana Labs 提供更细粒度控制的 Operator，Argo Rollouts 支持蓝绿、金丝雀等渐进式交付功能，Flagger 则提供金丝雀发布和 A/B 测试。这些方案为有复杂部署需求的组织提供了参考。
Q&A
Bedrock Rollout Operator的主要功能是什么？
Bedrock Rollout Operator提供更好的控制和功能，用于快速部署有状态应用程序，增强回滚能力，并与Slack内部服务发现和发布管理UI集成。
Slack为什么开发Bedrock Rollout Operator？
Slack开发该操作符是为了克服Kubernetes中管理StatefulSet部署的限制，如慢部署、缺乏控制和有限的回滚能力。
Bedrock Rollout Operator如何改善StatefulSet的更新策略？
该操作符允许更快的百分比基础的滚动更新，并提供暂停更新的能力，解决了默认RollingUpdate策略的慢更新问题。
Slack在使用Bedrock Rollout Operator时遇到了哪些限制？
在处理大型StatefulSets时，存在通知系统的速率限制问题，以及使用OnDelete策略时可能出现的版本泄漏问题。
Bedrock Rollout Operator是如何与Slack的内部系统集成的？
该操作符与Slack的内部服务发现（Consul）集成，并通过Slack通知用户版本号和正在部署的pod列表，增强了可见性。
Slack计划如何扩展其Kubernetes部署管理？
Slack计划扩大在Kubernetes部署管理中使用操作符模型，探索现有的CNCF项目，如Argo Rollouts和OpenKruise。
