Confluent 为 Kubernetes 控制器引入检查点机制，冷启动时间从 6 小时缩短至 1 分钟

博客首页如何构建从6小时到1分钟：为Kubernetes风格控制器实现检查点机制 作者：Luca Filipponi，Staff软件工程师2026年11月5日 我们在三大主流云平台上、覆盖一百多个区域运行Confluent Cloud，在4000多个K8s集群上管理着超过80000个客户Kafka集群，每天写入超过3万亿条消息。 我们基础设施的核心组成部分之一，就是使用K8s和K8s风格的控制器来运维我们提供的许多服务。 K8s控制器是一种非常出色的模式，但在Confluent的规模下暴露出了一个弱点：冷启动。 冷启动是指控制器在重启时，需要读取它控制的每一个对象的期望状态，并检查其当前状态。 对于许多资源规模最多几千个的普通K8s部署来说，这算不上什么大事。 但在Confluent Cloud，这意味着要从数据库中读取超过115 GB的数据，覆盖超过2500万个对象。 在本文中，我们将拆解控制器，展示其底层工作原理，并演示我们如何通过开发一个框架，让控制器从上次中断的地方继续运行且不丢失任何事件，从而绕开了冷启动问题。 对于我们最大的控制器，重启时间从6小时降到了1分钟！ 前面我们提到了K8s风格的控制器，但这具体是什么意思呢？ 对于不熟悉这个概念的同学，请允许我引用K8s文档中的说法： “在Kubernetes中，控制器是监控集群状态的控制循环，并在需要时进行变更或请求变更。 每个控制器都试图让当前集群状态更接近期望状态。” 换句话说，控制器是K8s对变更做出反应的基本构建块：每当你修改某个K8s对象（比如一个Deployment的副本数），就会触发一个控制器，将当前状态与期望状态对齐。 在Confluent，某些场景下我们确实使用原生的K8s控制器配合etcd，但对于内部资源和元数据，我们无法依赖K8s存储，因此我们需要一个类似的抽象，能在我们运行的所有云和区域中以统一的方式工作，且规模超出单个K8s控制平面所能承载的范围。 基于这些原因，我们开发了一个K8s apiserver及其内置控制器（kube-controller-manager）的衍生项目，以及一套自定义的watch协议，称为Resource Platform。 这个想法简单而强大：我们的工程师熟悉K8s及其数据模型，控制器模式又非常适合管理资源——那我们为什么不做一个完全一样工作的内部方案呢？ 这是我们的Resource Platform的简化视图： 我说过我们的Resource Platform是一个衍生项目，因为我们不仅遵循相同的K8s架构，还依赖K8s开源库，并对其中一些进行了fork。 最大的区别在于我们不使用etcd——由于大小限制，它在我们这个规模下无法工作——所以我们使用可水平扩展的数据库，并对部分组件和架构进行了适配以适用于我们的数据模型。 Resource Platform本身值得单独写一篇博客，但本文我们重点关注的是：我们的控制器行为与K8s控制器一致。 我们使用上游的controller-runtime库，加上我们自己复制的一些包，针对我们的平台做了适配，但接口保持一致。 我们再深入聊聊K8s控制器的架构。 以Job控制器为例：它watch Job来发现新工作，watch Pod来得知工作何时完成。 一般来说，当控制器收到它所watch的某个资源发生变更的通知时，它可以入队0到N个请求。 更具体地说： 下面是三个不同的事件流经这条流水线： 第2步就是冷启动：每次控制器启动时，它都会读取它所watch的所有资源的当前状态。 如果你watch了10万个Pod，那么所有这些Pod都会被读取并reconcile。 这个过程耗时随对象数量增长，而控制器的重启频率比你想象的高得多：每次部署、每次节点轮转、每次leader election。 每一次都意味着重新读取所有资源带来的时间代价。 （K8s informer也可以周期性地把每个对象重新投递给控制器，即resync，但那是从本地缓存来的，不会再次读取存储。） 这在原生K8s中是个问题吗？ 是也不是。 我们前面简单提过etcd的大小限制：正是这个限制让典型K8s部署中的冷启动保持在可控范围内，因为数据被限制在几个GB以内。 尽管8 GB只是建议上限，并非etcd强制，但托管服务替你设定了这个边界：Amazon EKS为etcd配置8 GB数据库，GKE则列出集群状态数据库6 GB的上限。 如果你自己运行etcd，技术上可以超过这个限制，但不推荐。 云厂商确实提供了更高上限的特殊变体：EKS ultra-scale集群对新集群可选开启，将数据库最大大小提高到20 GB，GKE则正在将集群状态迁移到Spanner。 话虽如此，即使etcd规模减小了，K8s项目也已经为冷启动性能实现了一些缓解措施： 这两项改进仍然会列出所有数据：一个改变了处理优先级，另一个则提前进行。 据我们所知，目前没有针对跨重启恢复控制器的K8s增强提案（KEP）。 所以是的，原生K8s中的冷启动是个问题，但更小的数据规模加上缓解措施使其变得可以承受。 如上所述，由于前面提到的容量限制，我们的控制器不使用etcd：在Confluent Cloud，我们需要容纳的数据量比etcd设计支持的几个GB高出几个数量级。 这是我们最终构建自己平台的主要原因之一。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）