从容器到云原生 – 极致弹性-阿里云开发者社区

为云栖社区总监课系列准备的课件讲义，面向开发者入门向讲解云原生的一些实践经验和发展方向。

在企业上云的过程中，我们可以看到云计算演进的路径

第一个阶段是以搬迁上云为主 - 通过简单的 lift and shift，把运行在物理机上面的应用，迁移到虚拟化环境中，这个过程是以降低成本为主要驱动力的，应用的开发和运维方式并没有非常不同。

第二阶段我们称之为云就绪。企业开始关注整体拥有成本，并希望利用云计算提升创新效率。从运维方面开始利用利用虚拟机镜像或其他标准化、自动化的方式部署应用，利用专业化的RDS，SLB等云服务，提升了运维效率和SLA。同时，在应用架构上开始采用微服务架构, 每个服务可以独立部署、独立伸缩，提升了系统的可扩展性和可用性。

第三阶段就是今天的云原生时代。创新成为企业的核心竞争力，大多数企业开始完全拥抱云计算，很多应用从诞生之初就生长在云端。云计算已经重塑软件从架构设计、开发、构建、交付等整个生命周期。

首先，应用负载可以在专有云、公共云等平台之间无缝迁移，甚至可以将计算和智能延展到边缘现场环境中，实现了无边界的云计算；其次容器、服务网格、无服务计算等新的计算范型不断涌现，追求极致的敏捷和弹性，可以更加快速和低成本地创新、试错、和业务拓展；此外DevOps理念也被更多开发者广为接受，推动着IT组织架构改变和文化变革。

这个时代我们也非常感谢CNCF和其他开源技术社区的共同推动云原生生态的发展。

阿里云Kubernetes服务ACK同时支持阿里云公共云和专有云，提供了对阿里云基础能力的的优化整合，同时我们也把阿里集团在大规模分布式系统的实践沉淀成为普惠的能力，以与云原生的方式开放给所有用户。

首先，我们利用Kubernetes实现了一个基础设施抽象层，让容器化应用轻松地利用阿里云底层强大的计算、存储、网络等能力，比如面向追求极致效率的深度学习、高性能计算场景：我们可以采用裸金属机、或者GPU, FPGA实例等异构计算能力；配合阿里云Terway网络驱动使用弹性网卡可以几乎无损耗地达到 9Gb网络带宽，也可以采用融合以太网的RDMA协议（RoCE）技术25Gb网络；还可以采用CPFS这样并行文件系统提升处理效率，提供高达1亿IOPS和1TBps吞吐的能力。

我们提供两种不同的服务形态来简化集群生命周期管理。托管 Kubernetes，用户可以根据自己的工作负载选择节点类型，由阿里云负责集群创建、升级、扩容、监控、告警等集群生命周期管理操作。用户可以选择master节点托管，进一步简化运维和降低成本。无服务器 Kubernetes，用户无需关注任何底层资源和集群管理，应用按需部署扩容。

在此之上容器服务提供了更多的能力

多集群管理：支持不同的region，甚至云上云下集群的统一管理
安全合规：阿里云关注企业级安全合规：支持了众多金融企业
混合云、多云：阿里云借助Apsara Stack和Apsara Stack Agility，可以实现混合云平台，容器服务加强了混合云环境下的应用管理
弹性：今天我们会深入介绍弹性方面的进展
应用生命周期：除了了对容器日志、监控、告警等能力和阿里云的连接，阿里云Kubernetes服务还有很多增强，让您可以更加安全、可控地管理和发布容器化应用。

在容器化内容管理方面：我们除了支持容器镜像管理，还提供了Helm应用图表的支持。在CNCF调查中，Helm已经占比68%，成为主流的容器应用打包规范。另外也提供了容器应用与云服务的整合Open Service Broker API的支持

在此之上可以支撑不同的业务，除了大家熟知的DevOps、微服务应用；还有越来越多的企业应用容器化，比如.net，JEE等应用，通过容器化加速IT架构现代化，提升业务敏捷性。同时客户和阿里云有大量的创新业务基于阿里云容器服务，比如，阿里云的AI预测服务，IoT应用平台，区块链服务等业务都基于ACK。

云计算是通过规模效应，平衡不同租户的业务波峰波谷，大大减少宏观规模的IT使用成本。在云时代，弹性已经成为新常态，也是CNCF调查中客户最为关注的云原生应用特性之一。

天猫双11购物狂欢节全天交易总额2135亿元。作为双11技术后台支撑方，阿里云在今年双11期间新增调用的弹性计算能力累计超过1000万核，相当于10座大型数据中心，创造了“脉冲计算”的新纪录。

当然很多的业务场景不是可以提前规划或者可预期的，比如大家喜闻乐见的明星八卦会导致社交网站的瞬时过载。

周鸿祎在乌镇互联网大会开玩笑 “如果云计算能同时支撑5个小鲜肉结婚，4个明星出轨不宕机，云计算才是真的牛。”

要达到上述目标，不但要求基础设施具备弹性，在短时间内有足够资源可以提供出来，也需要应用架构拥有弹性可以充分利用扩容的计算资源承载更多的业务负载。

在应用层不同类型的工作负载对于资源弹性伸缩的要求有所不同，

很多在线业务有明显的波峰波谷效应，比如大部分业务类网站的峰值在白天，而娱乐类网站大多在晚间达到业务高峰；在线业务也常会出现瞬时的业务尖峰。
计算类的离线任务很多对调度时机不敏感，如机器学习、基因测序，但是他们成本敏感
定时任务对调度稳定性敏感

在云时代，弹性伸缩解决的不仅是激增的流量峰值与资源容量规划的矛盾，也是资源成本与系统可用性的博弈。

所有弹性的架构大多由有几个基本部分组成

监控指标的采集
监控指标聚合，判断是否触发伸缩条件
执行伸缩动作

Kubernetes将支持弹性伸缩分成两个维度：

资源维度：保障集群资源池大小满足整体容量规划，由于资源不足导致未调度的Pod事件作为资源维度伸缩的触发条件。
应用维度：保障应用负载处在容量规划之内

对伸缩策略分为两类

水平伸缩 (Scale out/in)
- Cluster Autoscaler (CA) -> 自动调整资源池（Worker节点）规模
- Horizontal Pod Autoscaler (HPA) -> 自动调整Pod的复本数量
垂直伸缩 (Scale up/down)
- 资源池没有类似支持
- Vertical Pod Autoscaler (VPA) - 自动调整应用资源分配

Kubernetes HPA支持以下三种不同的监控指标：

Resource metrics：由Metrics Server 提供 (v2beta1)
Custom metrics：由Prometheus adapter提供 (v2beta1)
External metrics：由外部provider提供，主要是非k8s集群内部的触发条件（v2beta2)

HPA Controller 通过 Metrics Aggregator 聚合 Metrics Server和Prometheus adapter采集的性能指标，并计算一个Deployment需要多少复本可以支持目标的工作负载。

为了防止扩缩容震荡，K8s提供缺省冷却周期设置：扩容冷却时间3分钟，缩容冷却时间5分钟

Cluster Autoscaler 会监听所有的Pod，当Pod出现因资源不足导致未调度的时候，会将配置的Auto Scaling Group（ASG弹性伸缩组）模拟成为一个虚拟节点，尝试将未调度的容器进行重新调度，并选择一个符合条件ASG进行节点伸缩。没有扩容任务的时候，会便利每个节点的Request资源利用率，低于阈值的时候会逐个删除。

一个集群可以有不同的伸缩组，比如包含CPU实例的ASG，GPU实例的ASG等

比如，本页的示例就是当一个GPU应用无法调度时，会选择一个GPU ASG来进行扩容的过程

阿里云在基本的Cluster AutoScaler上提供了一系列的增强：

多伸缩组、多可用区、多实例类型优化弹性伸缩成功率和成本
资源占位模式提供缓冲池支持更顺滑的负载伸缩
模拟分组标签与调度策略支持更灵活的调度伸缩
定时伸缩、监控指标伸缩支持更全面的自定义伸缩
竞价实例ASG，降低资源的成本

与节点的扩容相比，节点的缩容是更为复杂的事情。我们要避免节点缩容导致应用的稳定性收到影响。为此K8s提供了上述规则来保障安全缩容。

竞价型实例（Spot instance）是阿里云弹性计算的一种实例类型，也叫抢占式实例。创建竞价实例时，必须为指定的实例规格设置一个价格上限，如果当前市场价格低于出价时，就能成功创建竞价实例，并按当前市场价格计费。默认能稳定持有实例一小时。之后，如果市场价格高于出价或者资源供需关系变化时，实例会被自动释放。

合理的使用阿里云ECS竞价实例，最高可以为您降低50% – 90% 的运营成本(相比按量付费的实例)。竞价实例对于批量计算或者离线任务等价格敏感的场景有很重要的意义。阿里云还推出了竞价型GPU云服务器，极大程度的降低深度学习和科学计算成本，普惠众多开发者。

Kubernetes集群提供了多种竞价策略，您可以同时选择多AZ多种实例类型进行竞价，系统会根据当前规格定价，选择价格最优规格实例进行创建，大大提升了创建实例的成功率并降低成本。
弹性扩容出的Spot节点实例会有 “workload_type=spot”标签，通过node selector，可以将可以能够适配Spot instance特性的应用负载调度到新扩容实例上。

基因测序是精准医疗基础技术，它需要海量的计算能力，而且有上千种不同框架参与计算。最近阿里云容器团队与安诺优达基因科技有限公司通力合作，利用容器技术封装基因计算能力，并允许科研人员自行定义数据处理流程；实现了云下及云上上千节点的混合云部署与统一调度，让基因数据的处理效率提升2-3倍。

利用 Cluster Autoscaler，每批基因测序任务流水线5分钟内会扩容数百台节点，跑完回收，并且进行优化下次启动速度，节约大量资源成本，又保证了快速调度能力。

HPA对无状态服务非常有帮助，通过增加复本数量来应对业务增长。但是对于一些遗留的有状态应用，比如数据库，消息队列等，很多无法通过水平扩展来实现扩容，通常需要分配更多的计算资源来实现扩容。

Kubernetes中提供了request/limits这样资源调度和限制策略，然而如何根据业务水平，正确设置应用资源，是一个挑战。如果分配的资源用量过小，导致稳定性问题，比如OOM， CPU争抢，如果设置的资源过高，则会影响系统利用率。

VPA要解决的问题：对有状态服务资源进行自动垂直扩展，提升系统运维的自动化效率和利用率。

我们看一个典型VPA执行流程

用户配置一个 VPA 策略
VPA Recommender持续从Prometheus、metrics server获取监控信息、也会从集群事件中获取驱逐、OOM等事件。
VPA Recommender根据历史监控数据信息，基于算法预测模型，计算容器资源。如果发现Pod分配的资源不足，提供推荐值容器的资源请求给VPA。（注意：VPA只关注Request，会默认设置Limit为无限。）在这个例子中，应用内存利用率超过水位。
VPA Updater侦听到Pod的资源建议，执行更新命令，删除Pod。
Deployment Controller会发起重新创建Pod的操作，
VPA Admission Controller，拦截创建Pod的Spec，获取VPA建议并修改资源调整。在这个例子中增加了内存的用量。
利用更新后的Pod的request资源配置来创建Pod

VPA目前还是在一个比较早期的状态，成熟度还有待提升。包括它的监控数据模型、预测计算模型和更新操作实现都有待完善。同时为了避免VPA Updater更新的不确定性，社区也建议可以让Updater变成可选，VPA只提供一些资源分配建议，而让用户决定如何执行扩缩容等操作。

阿里云在5月份推出了Serverless Kubernetes容器服务，无需节点管理和容量规划，按应用所需资源付费，弹性扩容。

Serverless Kubernetes的底层是构建在阿里云针对容器优化的虚拟化方案之上，提供了轻量、高效、安全的容器应用执行环境。Serverless Kubernetes还充分利用阿里云提供的负载均衡，DNS服务发现，实现了服务发现，通过SLB7层路由等能力提供Ingress支持，对Kubernetes应用的大多数语义兼容，无需修改即可部署

Serverless的HPA目前支持autoscaling/v1，支持CPU的伸缩，计划12月初支持autoscaling/v2beta1的版本，增加Pod其他指标的伸缩需求（内存、网络）。

我们看看Serverless Kubernetes是如何实现的，它的核心组件项目代号为Viking，其缘起是古代维京人战船以敏捷和快速而著称。
Viking：把自己注册成为Kubernetes集群中的一个虚拟节点，实现了kubelet, kube-proxy, kube-dns等组件行为，负责管理Sandbox生命周期、网络配置、服务发现等。它会与集群API Server交互，监听当前namespace下的Pod、Service、Ingress等变化事件，并为Pod创建ECI弹性容器实例、为服务创SLB或注册DNS域名，配置路由规则等。

ECI是一个面向容器的轻量级虚拟化实现，他内部的agent: 它会负责Pod的生命周期管理，负责容器的启动顺序、健康检查、进程守护、监控信息上报等能力。ECI底层可以基于ECS虚拟机，也可以基于神龙+轻量级虚拟化技术。

Serverless Kubernetes提供了一个面向Cloud的弹性伸缩设计