聊聊云上弹性的演进

众所周知，“弹性”是公有云的核心特点之一。近 10 年来，各种技术的诞生逐步将弹性推向极致，从天到小时，从小时再到分秒。量变引起质变，当弹性扩缩的时间足够短时，势必给业务带来更多的可能性。

讨论相关技术前，让我们回顾十年前面对的一个的问题：扩容一个服务包括哪些环节？普遍来看，绝大部分公司涉及如下五个步骤：

   申请资源   获取资源   初始化与交付   部署业务   上线服务
 +---------+--------+------------+---------+--------->

申请资源：采用工单、邮件等形式发起资源申请，涉及上级领导、运维等部门的审批。
获取资源：运维采购新机器或者腾出机器。
初始化和交付：运维安装系统和初始化，录入物料库后交付给业务方。
部署业务：业务方部署业务，包括安装、配置和启动服务等。
上线服务：采用服务发现或者更新负载均衡等方式引入流量。

与之对应的缩容流程则简单些：

   下线服务   停止服务   资源回收   
 +---------+--------+--------->

下线服务：采用服务发现或者更新负载均衡等方式将流量下线。
停止服务：停止服务和卸载相关包。
资源回收：以工单等形式将资源退回给运维。

让我们基于这些环节，分析近十年来诞生的各种云计算技术和服务是如何优化这些环节和提升效率。

物理机时代

物理机时代的扩容往往长达数天、甚至上月。资源的申请涉及多个部门审批，通常花费数个小时。真正的耗时流程在于获取资源，在机器资源紧缺的情况，物理机资源的采购流程普遍长达数十天乃至上月。物理机系统的初始化和录入固资库往往在小时级别，交付给业务方后，业务方一般需要分钟级别的安装、配置和启动服务，之后还需要分钟级别的上线时间。

   申请资源   获取资源   初始化与交付   部署业务   上线服务
 +---------+--------+------------+---------+--------->
    小时      数十天       小时        分钟       分钟       总共：数十天

物理机回收流程简单许多，流量下线、停止服务、卸载应用和资源回收的时间在分钟级别，这些步骤需要人工衔接，所以平均来看整条回收流程最快也需要数十分钟。

   下线服务   停止服务   资源回收   
 +---------+--------+--------->
    分钟       分钟      分钟          总共：数十分钟

公有云 IaaS

2006 年，老大哥 AWS 推出的 EC2 实例开启了云计算 IaaS 元年，而国内公有云的发力，应该是从 2015 年开始。Xen、Qemu-KVM 等虚拟化技术为基础设施灵活化、弹性化提供了必要条件，基于公有云服务商维护海量的资源和建设强大的管理平台，用户可在数分钟内获取大量的计算资源，革命性的压缩了资源获取的流程。通过制作私有镜像，免去系统安装和环境初始化的流程，最终将业务扩容的时间缩短到小时级别，其中资源申请由于涉及到多部门的审批和沟通，反而成为耗时的主要环节。

   申请资源   获取资源   初始化与交付   部署业务   上线服务
 +---------+--------+------------+---------+--------->
    小时      分钟         无         分钟      分钟        总共：数小时 

公有云上的 IaaS 回收的流程和物理机区别不大，回收周期大概在数十分钟。

   下线服务   停止服务   资源回收   
 +---------+--------+--------->
    分钟       分钟      分钟          总共：数十分钟

事实上我们曾经尝试通过在 IaaS 之上增加编排层，进一步压缩业务的弹性部署时间，比如基于 AWS 的 CloudFormation，OpenStack 的 Heat 等，但是由于虚拟机解决的是资源层面的问题，无法代表业务的真正状态，给编排造成诸多难题，落地困难重重，收效甚微。

公有云上的 K8S

当回首云计算技术的过往，2010 年开源的 OpenStack、2013 年开源的 Docker 和 2014 年开源的 Kubernetes 绝对是三大最重要的项目。前者提供了 IaaS 层面的方案，后者成为 PaaS 的标准，从此一统江湖。各大公有云厂商在 2017 年先后推出 K8S + Docker 的容器云服务。计算节点的扩缩容还需要走工单流程，但是容器的扩缩容则不需要走工单，由业务方调用 K8S API 自行完成容器实例扩缩。在资源充足的 PaaS 平台下，由于容器的启动时间为秒级，所以将资源获取的时间压缩到秒级。并且将应用制作成镜像，省去了业务部署环节，加上 K8S 强大的编排和服务治理能力，业务的上线由 K8S 完成，最终将整体时间压缩至秒级。

   资源申请   获取资源   初始化与交付   部署业务   上线服务
 +---------+--------+------------+---------+--------->
     无        秒         无          无        秒        总共：数十秒      

在资源不足的情况下，计算节点的扩容涉及工单和资源购买等环节，反而成为主要的耗时环节。

   资源申请   获取资源   初始化与交付   部署业务   上线服务
 +---------+--------+------------+---------+--------->
    小时       秒         无          无        秒        总共：小时级别

公有云上 PaaS 的回收分为两个层面，Pod 回收非常简单，通常在秒级，但是计算节点的回收比较麻烦，需要将对应节点上所有的 Pod 删除完后才会提回收工单，一旦涉及到计算节点的回收，时间通常在数十分钟级别。

   下线服务   停止服务   资源回收   
 +---------+--------+--------->
     秒        秒       分钟          总共：数十分钟

公有云上的容器云服务有个明显的缺点，就是 K8S 集群通常会预留一些资源，保持一个资源水位线，以应对不时之需，因而也造成资源的浪费。Cluster Autoscaler(简称 CA) 正是为了解决这个问题而生，当 CA 发现资源不足时，会自动向云服务商扩容计算节点，当发现资源存在较大空闲时，会将节点回收并驱逐 Pod。CA 的理想很完美，但是频繁的驱逐 Pod 对业务的健壮和容错要求非常高，带来较大的落地难点。

公有云上的 Serverless K8S

有没有一种技术，它既兼备容器的优点，又具备虚拟机强大的隔离和安全性？答案是 2017 年底开源的 KataContainer。当 KataContainer 推出之时，本人并不看好，因为 Docker 的安全性基本满足私有云的要求。但是放眼公有云，K8S + KataContainer 却大放异彩，各个云产商在 2019 年左右基于该技术推出 Serverless K8S，既兼备 K8S 强大的编排能力和容器的优势，又具备虚拟机的安全性。在 Serverless K8S 产品中，公有云产商维护一个资源大池，对用户提供兼容 K8S 的 API，用户无需维护 K8S 和计算节点，在获得良好弹性能力的同时免去维护成本；其次，用户无需再预留资源 buffer；再次，按秒计费非常利于优化离线任务的资源成本。

   资源申请   获取资源   初始化与交付   部署业务   上线服务
 +---------+--------+------------+---------+--------->
     无        秒         无          无        秒        总共：数十秒

避免工单环节的资源回收更是简单，将时间从数十分钟压缩至秒级。

   下线服务   停止服务   资源回收   
 +---------+--------+--------->
     秒        秒        无          总共：数十秒

本人认为，Serverless K8S 将成为未来 2-3 年的热点，随着 Spark On K8S，Flink On K8S 的逐步成熟，Serverless K8S 以其秒级弹性的优势，必受到大数据、机器学习等离线任务的青睐。而且 Serverless K8S 还利于离在线的混部，故还会逐步受到在线业务的关注，让我们拭目以待。