点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》
本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片即可下载！
作者 | 张振（守辰）阿里云云原生应用平台高级技术专家
导读：2019 年阿里巴巴核心系统 100% 以云原生方式上云，完美地支撑了 双11 大促。这次上云的姿势很不一般，不仅是拥抱了 Kubernetes，而且还以拥抱 Kubernetes 为契机进行了一系列对运维体系的深度改造。
Kubernetes 作为云原生的最佳实践，已经成为了事实上的容器编排引擎标准，Kubernetes 在阿里巴巴集团落地主要经历了四个阶段：
研发和探索：2017 年下半年阿里巴巴集团开始尝试使用 Kubernetes api 来改造内部自研平台，并开始了对应用交付链路的改造，以适配 Kubernetes；
初步灰度： 2018 年下半年阿里巴巴集团和蚂蚁金服共同投入 Kubernetes 技术生态的研发，力求通过 Kubernetes 替换内部自研平台，实现了小规模的验证，支撑了当年部分 双11 的流量；
云化灰度： 2019 年初阿里巴巴经济体开始进行全面上云改造，阿里巴巴集团通过重新设计 Kubernetes 落地方案，适配云化环境，改造落后运维习惯，在 618 前完成了云化机房的小规模验证；
规模化落地：2019 年 618 之后，阿里巴巴集团内部开始全面推动 Kubernetes 落地，在大促之前完成了全部核心应用运行在 Kubernetes 的目标，并完美支撑了 双11 大考。
在这几年的实践中，一个问题始终萦绕在各个架构师的头脑中： 在阿里巴巴这么大体量、这么复杂的业务下， 遗留了大量传统的运维习惯以及支撑这些习惯的运维体系，落地 Kubernetes 到底要坚持什么？要妥协什么？要改变什么？
本文将分享阿里巴巴这几年对于这些问题的思考。答案很明显：拥抱 Kubernetes 本身并不是目的，而是通过拥抱 Kubernetes 撬动业务的云原生改造，通过 Kubernetes 的能力，治理传统运维体系下的沉疴顽疾，释放云弹性的能力，为业务的应用交付解绑提速。
在阿里巴巴的 Kubernetes 落地实践中，关注了下面几个关键的云原生改造：
面向终态改造在阿里巴巴传统的运维体系下，应用的变更都是 PaaS 通过创建操作工单，发起工作流，继而对容器平台发起一个个的变更来完成的。
当应用发布时， PaaS 会从数据库中查到应用所有相关的容器，并针对每个容器，向容器平台发起修改容器镜像的变更。每一个变更实际上也是一个工作流，涉及到镜像的拉取、旧容器的停止和新容器的创建。工作流中一旦发生错误或者超时，都需要 PaaS 进行重试。一般而言，为了保证工单及时的完成，重试仅会执行几次，几次重试失败后，只能依靠人工处理。
当应用缩容时，PaaS 会根据运维人员的输入，指定容器列表进行删除，一旦其中有容器因为宿主机异常的情况下删除失败或者超时，PaaS 只能反复重试，为了保证工单的结束，在重试一定次数后只能认为容器删除成功。如果宿主机后续恢复正常，被“删除”的容器很有可能依然运行着。
传统的面向过程的容器变更一直存在如下问题无法解决：
单个变更失败无法保证最终成功
例如，一旦容器镜像变更失败，PaaS 无法保证容器镜像的最终一致；一旦删除容器失败，
也无法保证容器最后真的被删除干净。两个例子都需要通过巡检来处理不一致的容器。而巡检任务因为执行较少，其正确性和及时性都很难保证；
多个变更会发生冲突
例如应用的发布和应用的扩容过程需要加锁，否则会出现新扩的容器镜像未更新的情况。而一旦对变更进行加锁，变更的效率又会大幅下降。
Kubernetes 的能力提供了解决这个问题的机会。Kubernetes 的 workload 提供了声明式的 API 来修改应用的实例数和版本，workload 的控制器可以监听 pod 的实际情况，保证应用 pod 的实例数量和版本符合终态，避免了并发扩容和发布的冲突问题。Kubernetes 的 kubelet 会依据 pod 的 spec，反复尝试启动 pod，直到 pod 符合 spec 描述的终态。重试由容器平台内部实现，不再和应用的工单状态绑定。
自愈能力改造在阿里巴巴传统的运维体系下，容器平台仅生产资源，应用的启动以及服务发现是在容器启动后由 PaaS 系统来执行的，这种分层的方法给了 PaaS 系统最大的自由，也在容器化后促进了阿里巴巴第一波容器生态的繁荣。但是这种方式有一个严重的问题，即：
容器平台无法独立地去触发容器的扩缩容，需要和一个个 PaaS 来做复杂的联动，上层 PaaS 也需要做很多重复的工作。这妨碍了容器平台在宿主机发生故障、重启、容器中进程发生异常、卡住时的高效自愈修复，也让弹性扩缩容变得非常复杂。