Uber发布博文，详细介绍其全新的ServiceScale控制器。该控制器允许多个编排器安全地管理同一组Kubernetes工作负载的扩缩容，使Uber能够将扩缩容意图与执行分离，在无需预留闲置容量的情况下支持区域故障转移。相关博文由高级软件工程师Egor Grishechko和Srikar Paruchuru撰写。

Uber的容器平台团队管理着分布在数据中心及Oracle、谷歌等云厂商的100多个计算集群，运行约4000个服务，使用300万核CPU，每天启动150万个Pod。其内部平台Up作为Kubernetes集群联邦层，服务所有者通过Up部署构建版本并设置扩缩容预期，专门的Uber部署控制器（UDC）则将这些意图调和为Kubernetes原语。

这一改变的动机来自Uber区域故障转移方式的变革。Uber在不同区域运行双活数据中心，过去需在所有数据中心保留预留空闲容量以应对故障时的流量重定向。工程师希望改为复用低优先级工作负载的容量，故障发生时缩容低优先级负载、扩容高优先级负载。这产生了新的扩缩容意图来源，但团队认为在已处于服务生命周期关键路径上的UDC中叠加故障转移逻辑会放大风险，因此引入新的自定义资源定义ServiceScale和新的服务扩缩容控制器（SSC），由各编排器通过ServiceScale表达扩缩容意愿，SSC将组合意图调和为Kubernetes对象。

团队表示，不希望额外引入外部数据库、独立协调服务或控制平面，否则故障应急场景下调试难度会大幅上升。扩缩容意图直接物化在Kubernetes中，便于排查问题，故障恢复时也无需从日志重建状态。博文还分享了生产环境经验，其中之一是过期的Informer缓存问题：控制器依赖的缓存数据会比真实状态延迟数秒，团队为此实现了“读己所写”一致性防护机制，在更新下游资源时打上当前资源版本号注解，并在上报状态前校验本地缓存已读到该版本。