本文节选自《不一样的 双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 也需要做很多重复的工作。这妨碍了容器平台在宿主机发生故障、重启、容器中进程发生异常、卡住时的高效自愈修复，也让弹性扩缩容变得非常复杂。
在 Kubernetes 中通过容器的命令以及生命周期钩子，可以将 PaaS 启动应用以及检查应用启动状态的流程内置在了 pod 中；另外，通过创建 service 对象，可以将容器和对应的服务发现机制关联起来，从而实现容器、应用、服务生命周期的统一。容器平台不再仅仅生产资源，而是交付可以直接为业务使用的服务。这极大地简化了上云之后故障自愈以及自动弹性扩缩容能力的建设，
真正地发挥了云的弹性能力。
另外，在宿主机发生故障的情况下，PaaS 传统上需要先对应用进行扩容，然后才删除宿主机上的容器。然而在大规模的集群下，我们发现往往会卡在应用扩容这步。应用资源额度可能不够，集群内满足应用调度限制的空闲资源也可能不够，无法扩容就无法对宿主机上的容器进行驱逐，进而也无法对异常的宿主机进行送修，久而久之，整个集群很容易就陷入故障机器一大堆，想修修不了、想腾腾不动的困境之中。
在 Kubernetes 中对于故障机的处理要“简单和粗暴”得多，不再要求对应用先扩容，而是直接把故障机上的容器进行删除，删除后才由负载控制器进行扩容。这种方案乍一听简直胆大妄为，落地 Kubernetes 的时候很多 PaaS 的同学都非常排斥这种方法，认为这会严重影响业务的稳定性。事实上，绝大多数核心的业务应用都维护着一定的冗余容量，以便全局的流量切换或者应对突发的业务流量，临时删除一定量的容器根本不会造成业务的容量不足。
我们所面临的关键问题是如何确定业务的可用容量，当然这是个更难的问题，但对于自愈的场景完全不需要准确的容量评估，只需要一个可以推动自愈运转的悲观估计就可以。在 Kubernetes 中可以通过 PodDisruptionBudget 来定量地描述对应用的可迁移量，例如可以设置对应用进行驱逐的并发数量或者比例。这个值可以参考发布时的每批数量占比来设置。假如应用发布一般分 10 批，那么可以设置 PodDisruptionBudget 中的 maxUnavailable 为 10%（对于比例，如果应用只有 10 个以内的实例，Kubernetes 还是认为可以驱逐 1 个实例）。万一应用真的一个实例都不允许驱逐呢？那么对不起，这样的应用是需要改造之后才能享受上云的收益的。一般应用可以通过改造自身架构，或者通过 operator 来自动化应用的运维操作，从而允许实例的迁移。
