随着云计算和容器化技术的迅猛发展，企业对容器编排平台的需求日益增长，如何高效可靠地管理海量容器资源成为关键课题。Uber作为全球领先的出行服务平台，拥有庞大的计算资源和复杂多样的应用服务，其计算平台的稳定性与可扩展性直接关系到业务表现与用户体验。在经历了三年以上基于Apache Mesos的稳定运行后，Uber在2024年完成了其无状态容器编排平台从Mesos到Kubernetes的全面迁移，开展了一场大规模的技术革新。本文将带您全面剖析Uber迁移背后的动因、面临的挑战、关键技术改造及未来发展规划，助力读者深入理解云原生架构下大型容器平台的演进路径。 Uber的计算平台涵盖超过50个跨区域和多可用区的集群，既包括自有数据中心，也使用了Oracle云和谷歌云等公有云资源。每个集群规模巨大，承载主机数量从五千到七千五百不等，拥有约25万核心处理能力和5万个Pod实例，每天服务更新高达十万次，每秒启动120到130个POD的压力远超业界常见规模。
此外，这些集群支撑超过四千个微服务，累计使用核心数达到三百万，构成了Uber服务联邦层“Up”，为开发者提供端到端的服务生命周期管理体验。 在长时间依赖Mesos构建容器平台后，Uber团队面临的最大挑战来自于Mesos项目自2021年起基本停止维护，缺乏社区支持、无新功能及安全修复，使得平台长期演进陷入停滞。相比之下，Kubernetes已成为业界标配，拥有丰富的生态体系，活跃的开源社区保障持续迭代，且云厂商均提供原生支持。选择迁移到Kubernetes不仅符合未来发展趋势，也有助于保持平台安全、稳定且具备适应技术变迁的韧性。 然而，实现跨数百万核资源的迁移并非易事。Uber秉持几项核心原则确保迁移过程的平滑与高效。
首先，平台升级必须无缝且与主流云提供商保持一致，借助Kubernetes的原生可扩展特性避免自研孤岛。其次，构建可靠的升级验证体系至关重要，涵盖集成测试及性能评估，杜绝版本升级带来的服务中断风险。最重要的是全程自动化迁移，保持开发者体验透明，无须其修改代码或工作流程，确保Mesos与Kubernetes集群间服务安全共存。 Uber所采取的集群架构与业界普遍做法截然不同。业内普遍倾向于规模较小（1500至2000节点）分散式集群，以降低控制平面负载与碎片化问题，但这往往伴随资源浪费和运维成本飙升。Uber大胆采用超大规模集群设计，单集群承载达七千五百台节点规模，极大提升资源利用率。
为支撑如此规模，Uber团队优化了API服务器负载管理，提升调度器处理能力，解决高频POD调度需求带来的瓶颈问题。通过自研基准测试工具，推演出7,500节点、20万个Pods和每秒150个Pod调度的极限性能，期间调优包括调整控制器管理器及调度器的QPS参数并行度，利用API优先级与公平性机制限制昂贵API调用，采用Proto编码替代JSON提升网络传输效率，同时改进拓扑扩展调度插件，使调度效率明显提升。 平台迁移的另一大难点在于与Uber内部开发生态的深度集成。Mesos与Kubernetes在架构层面差异显著，Uber必须重新搭建CI/CD流水线、服务发现、权限管理、主机生命周期管理及监控体系，打造全链路一致的开发体验。为实现自动化迁移，Uber充分利用了“Up”服务联邦层的集群选择功能，允许Mesos与Kubernetes集群在同一可用区内共存，通过流量和资源逐步迁移，完全屏蔽服务所有者。如此一来，开发者几乎无感知地完成了数百万核的计算资源转换，大幅降低人为误操作和迁移风险。
在实现功能对等的基础上，Uber还针对独有业务需求进行了多项定制。Mesos允许开发者在容器退出后继续访问核心转储、堆快照及日志，帮助开发者调试异常关闭和OOM问题，而Kubernetes默认在Pod删除时清理本地卷且UI缺乏对应功能。为此，Uber设计了侧车容器+宿主机守护进程上传机制：每个Pod带有一个持续运行的侧车容器，主容器退出时，上传守护进程会自动将容器遗留的调试文件压缩上传至对象存储，实现容器退出后数据持久化和UI可视化。 Uber还针对微服务对快速扩缩容敏感的特性，设计了渐进式扩缩容机制。通过自定义控制器将一次大规模扩缩容拆分为多个小批次执行，每一批次成功后再执行下一批次，避免因快速规模变动导致的分片不稳定、Helix服务协调延迟以及临时服务不可用等问题。原生Kubernetes滚动更新机制仅对升级速率提供控制，未覆盖扩缩容节奏，Uber方案有效弥补了这一缺陷。
为了提升大容器更新速度，Uber引入CloneSet实现就地更新，减少Pod替换开销，同时部署了镜像预拉取守护进程，提前将镜像分发到其他可用区节点，极大缩短冷启动时间，提升整体部署效率。此外，针对原生Kubernetes Dashboard在大规模集群上崩溃和卡顿的问题，Uber团队优化了前端缓存策略及数据请求方式，确保UI在数千节点规模依然保持流畅响应。 迁移过程中，团队也遭遇一些预料之外的挑战。缺乏针对大规模Kubernetes集群的全局健康监控工具限制了故障排查能力。为此，Uber自研了部署观测工具，全面揭示资源碎片化、节点性能瓶颈及频繁更新带来的影响，显著提升了监控可视化能力。Kubernetes默认的Informers事件重播机制因控制器领导权变更导致事件遗漏，最长延迟达十小时，团队重构了事件重试机制，缩短重试间隔至十五分钟，保障部署事件及时生效。
自动回滚能力亦得到增强。原生依赖进度超时判定触发回滚反应迟缓且信号隐晦，且部分服务禁用健康检查使得Pod状态假就绪，导致故障检测滞后。Uber研发了基于容器重启次数的启发式算法，若超出一定Pod重启阈值，自动触发回滚，精准迅速地保障服务稳定。 迁移历时一年半，期间经历了多次战略性暂停，用以修复在大规模实际运行中暴露出的定制控制器和调度器边缘案例，优化API服务器负载和调度性能，换用Proto序列化提升网络效率，最终实现稳定可靠的生产环境应用。暂停后迁移进度大幅加速，曾单周迁移30万CPU核，推动平台向统一Kubernetes生态彻底过渡。 未来，Uber计划持续整合其他框架如Apache Hadoop YARN和Odin，将所有批处理及有状态工作负载迁移到Kubernetes，打造统一、高效的集群管理平台。
同时，Uber期待将此次迁移过程中积累的创新经验与工具贡献回开源社区，推动整个生态进一步发展。 总体而言，Uber此次从Mesos到Kubernetes的迁移，是在大型云原生环境下跨平台迁移的典范案例，体现了严谨的工程实践和技术创新。通过自动化、定制化与规模化的深度结合，Uber不仅完成了技术栈的升级换代，更为业界树立了在复杂环境下一站式迁移的成功路径。随着生态不断成熟，更多企业可借鉴类似策略，迈向高可用、高弹性与高效能的容器平台新时代。
