不过，Kubernetes 默认的滚动升级过程过于僵硬地执行了不可变基础设施的理念，导致对多容器 pod 的能力支持有严重的缺失。虽然可以在一个 pod 中编排多个容器，但如果要发布 pod 中的一个容器，在实际执行发布时，不仅会重建待发布的容器，还会把整个 pod 都删除，而后重调度、再重建。这意味着假如要升级基础设施的日志采集组件，会导致其他组件，特别是业务的应用服务器被一起删除重启，从而干扰到正常的业务运行。因此，多个组件的变更依然没有解耦。
对业务而言，假如 pod 中有本地缓存的组件，而每次业务的发布都会重启缓存进程，这会导致业务发布期间缓存的命中率大幅下降，影响性能甚至用户的体验；另外，如果基础设施、中间件等团队的组件升级都和业务的组件升级绑定在一起，这会给技术的迭代更新带来巨大的阻碍。假设负责中间件的团队推出了新的 service mesh 版本， 而为了升级 mesh 还需要央求一个个业务发布才能更新 mesh 组件，那么中间件的技术升级就会大大减速。
因此，相比 pod 层次的不可变，我们认为坚持容器级别的不可变原则，更能发挥 Kubernetes 多容器 pod 的技术优势。为此，我们建设了支持应用发布时只原地修改 pod 中部分容器的能力，特别地建设了支持容器原地升级的工作负载控制器，并替换 Kubernetes 默认的 deployment 和 statefulset 控制器作为内部的主要工作负载。
另外，还建设了支持跨应用进行 sidecar 容器升级的 sidecarset， 方便进行基础设施以及中间件组件的升级。此外，通过支持原地升级还带来了集群分布确定性、加速镜像下载等的额外优势。这部分能力，我们已经通过 OpenKruise 项目开源出来。OpenKruise 中的 Kruise 是 cruise的谐音，'K' for Kubernetes, 寓意 Kubernetes 上应用的自动巡航，满载着阿里巴巴多年应用部署管理经验和阿里巴巴经济体云原生化历程的最佳实践。目前，OpenKruise 正在计划发布更多的 Controller 来覆盖更多的场景和功能，比如丰富的发布策略、金丝雀发布、蓝绿发布、分批发布等等。
总结今年我们实现了 Kubernetes 的规模化落地，经受了 双11 大促真实场景的考验。像阿里巴巴这样有着大量存量应用的场景，落地 K8s 并没有捷径，我们经受住了快速规模化落地的诱惑，没有选择兼容和妥协落后的运维习惯，而是选择深蹲打好基础、选择深挖云原生价值。接下来，我们将继续推动更多应用的云原生改造，特别是有状态应用的改造，让有状态应用的部署和运维更加高效；另外，还将推动整个应用交付链路的云原生改造，让应用交付更加高效和标准化。
本书亮点
双11 超大规模 K8s 集群实践中，遇到的问题及解决方法详述
云原生化最佳组合：Kubernetes+容器+神龙，实现核心系统 100% 上云的技术细节
双 11 Service Mesh 超大规模落地解决方案
“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术公众号。”