Uber引入ServiceScale解耦Kubernetes扩缩容

Uber推出ServiceScale控制器，允许多个编排器安全管理同一批Kubernetes工作负载的扩缩容。该方案把扩缩容决策与具体执行拆开，使系统无需长期预留大量闲置资源，也能应对区域故障转移。

Uber的容器平台覆盖数据中心、Oracle云和谷歌云等环境，管理100多个集群，运行约4000个服务，使用约300万核CPU，每天启动150万个Pod。内部平台Up负责集群联邦和声明服务期望状态，Uber部署控制器（UDC）则把这些意图转换为Kubernetes资源。

Uber采用双活数据中心架构。过去，各区域都会保留空闲容量；现在，故障发生后可先压缩低优先级工作负载，再将资源让给高优先级服务。团队没有把故障转移逻辑继续塞入UDC，而是新增ServiceScale自定义资源和服务扩缩容控制器（SSC），由不同编排器分别提交意图，再由SSC合并并调和为Kubernetes对象。

扩缩容意图直接存储在Kubernetes中，因此工程师能查看各编排器的目标，故障恢复时也无需依赖日志重建状态。方案没有引入外部数据库、协调服务或额外控制平面，以降低应急场景中的排查复杂度。

生产实践中，团队针对Informer缓存落后真实状态数秒的问题加入“读己所写”保护：控制器更新资源时记录版本号，报告成功前确认本地缓存已读到该版本。Kubernetes v1.36（2026年4月发布）也引入了类似的缓存过期缓解机制；相关讨论认为，这属于API契约问题，而不只是缓存实现问题。

多写入者同时修改资源时，竞态可能造成ReplicaSet元数据与规范漂移，进而破坏滚动更新和比例扩缩容。Uber为UDC增加全集群观测、自动修复和扩缩容路径上的长期修正。2026年1月发布的相关论文显示，更统一的故障转移架构可将稳态配置比例从2倍降至1.3倍，节省超过100万CPU核。

该项目历时一年，经过预发布、金丝雀发布和基于KubeKind的集成测试，覆盖控制器交互与竞态条件，支持原生Kubernetes Deployment及OpenKruise CloneSet，未造成客户可感知中断。团队认为，多编排器系统真正困难的部分并非API，而是并发写入带来的分布式系统问题；CNCF近期毕业的Karmada以及Kubernetes v1.36的相关改进，也反映出业界对这类问题的持续关注。