外部行业实践 ·
Uber基于Kubernetes实现扩缩容意图与执行解耦，优化资源利用率提升故障转移能力
Uber针对原有区域故障转移需预留闲置容量导致资源浪费的问题，重构Kubernetes扩缩容架构，引入自定义资源定义ServiceScale和独立服务扩缩容控制器SSC，实现多编排器共同参与扩缩容决策，解决了缓存不一致、多写入者并发冲突等生产问题，上线过程无客户感知中断，大幅降低资源冗余，节省大量算力成本。
仅供行业学习与场景参考，不代表优秘交付、客户关系或效果承诺。
面临的问题
原有区域故障转移方案需要在所有数据中心预留空闲容量，造成大量算力资源浪费，资源利用率偏低；若直接在核心控制器UDC上扩展故障转移扩缩容逻辑，会增加UDC的复杂度，且UDC处于服务生命周期操作的关键路径，一旦故障转移逻辑出现问题，会影响整个集群的正常部署；多编排器共同管理扩缩容时，会面临Informer缓存过期导致的一致性问题，以及多写入者并发更新同一资源时出现的配置漂移、工作负载卡住等问题；若引入外部数据库、独立协调服务或控制平面，会大幅提升故障应急场景下的排查难度。
AI 落地做法
Uber容器平台团队采用扩缩容意图与执行操作解耦的架构设计，新增独立的自定义资源定义ServiceScale和服务扩缩容控制器SSC，包括原有Up平台、UDC以及故障转移编排器在内的所有编排器均可通过ServiceScale提交扩缩容意愿，由SSC统一将组合后的意图调和为Kubernetes对象，不引入额外外部存储或协调服务，所有扩缩容意图直接存储在Kubernetes中，方便问题排查和故障恢复。针对缓存过期问题，实现“读己所写”一致性防护机制，控制器更新下游资源时标注资源版本号，上报状态前校验本地缓存版本不低于已写入版本；针对多写入者并发导致的ReplicaSet不一致问题，在UDC中增加全集群可观测能力检测配置漂移，搭建自动修复程序处理受影响的ReplicaSet，同时推进扩缩容路径的长期修复。上线阶段采用预发布环境验证、金丝雀发布的方式，并基于KubeKind测试工具搭建集成测试模拟控制器交互，提前捕获竞态条件。
实施路径
- 引入自定义资源定义ServiceScale和独立的服务扩缩容控制器SSC，将扩缩容意图与执行操作解耦
- 各编排器通过ServiceScale表达扩缩容意愿，由SSC统一将组合后的意图调和为Kubernetes对象，不引入额外外部数据库、协调服务或控制平面
- 实现“读己所写”一致性防护机制，控制器更新下游资源时标注当前资源版本号，上报状态前校验本地缓存至少已读到该版本
- 在UDC中加入全集群可观测能力，检测元数据与规范不一致问题，构建自动修复程序修补受影响的ReplicaSet，同时推进扩缩容路径的长期修复方案
- 上线前基于KubeKind测试工具搭建集成测试环境模拟控制器交互，捕获竞态条件，上线采用预发布环境验证、金丝雀发布的渐进式发布策略
来源：InfoQ 中文（本站改写摘要，成效数据均取自原文）
项目背景
Uber的容器平台Up作为Kubernetes集群联邦层，管理分布在自有数据中心及Oracle、谷歌等云厂商的上百个计算集群，运行数千个服务，共使用数百万核CPU，每天启动超百万个Pod，原有扩缩容逻辑由核心的Uber部署控制器UDC负责。为提升区域故障转移的资源使用效率，Uber计划在故障发生时通过缩容低优先级工作负载、扩容高优先级工作负载的方式替代原有预留闲置容量的方案，由此产生了多个扩缩容意图来源，需要支持多编排器共同管理同一组Kubernetes工作负载的扩缩容。 本案例依据「InfoQ 中文」公开发布的信息整理，原文：https://www.infoq.cn/article/2SNgaiHoK808v22dl5SJ?utm_source=rss&utm_medium=article
业务问题
原有区域故障转移方案需要在所有数据中心预留空闲容量，造成大量算力资源浪费，资源利用率偏低；若直接在核心控制器UDC上扩展故障转移扩缩容逻辑，会增加UDC的复杂度，且UDC处于服务生命周期操作的关键路径，一旦故障转移逻辑出现问题，会影响整个集群的正常部署；多编排器共同管理扩缩容时，会面临Informer缓存过期导致的一致性问题，以及多写入者并发更新同一资源时出现的配置漂移、工作负载卡住等问题；若引入外部数据库、独立协调服务或控制平面，会大幅提升故障应急场景下的排查难度。
实践方案
Uber容器平台团队采用扩缩容意图与执行操作解耦的架构设计，新增独立的自定义资源定义ServiceScale和服务扩缩容控制器SSC，包括原有Up平台、UDC以及故障转移编排器在内的所有编排器均可通过ServiceScale提交扩缩容意愿，由SSC统一将组合后的意图调和为Kubernetes对象，不引入额外外部存储或协调服务，所有扩缩容意图直接存储在Kubernetes中，方便问题排查和故障恢复。针对缓存过期问题，实现“读己所写”一致性防护机制，控制器更新下游资源时标注资源版本号，上报状态前校验本地缓存版本不低于已写入版本；针对多写入者并发导致的ReplicaSet不一致问题，在UDC中增加全集群可观测能力检测配置漂移，搭建自动修复程序处理受影响的ReplicaSet，同时推进扩缩容路径的长期修复。上线阶段采用预发布环境验证、金丝雀发布的方式，并基于KubeKind测试工具搭建集成测试模拟控制器交互，提前捕获竞态条件。
原始来源：https://www.infoq.cn/article/2SNgaiHoK808v22dl5SJ?utm_source=rss&utm_medium=article