作者简介
易立，阿里云容器平台资深技术专家，目前负责阿里云容器服务产品线研发。之前曾在IBM中国开发中心工作，担任资深技术专员，负责一系列云计算、中间件产品研发工作。关注Docker/Kubernetes等云原生计算和Hyperledger Fabric/Ethereum等区块链技术。技术极客，热爱开源。
本文来自易立在 2019 携程技术峰会上的分享，首发于“阿里巴巴云原生”公众号。
今天我跟大家分享的题目是“拐点已至，云原生引领数字化转型升级”。先做个简单的自我介绍，我叫易立，来自于阿里云容器平台，从 2015 年开始负责阿里云容器产品，之前在 IBM 工作 14 年，主要负责企业中间件和云计算的产品研发。
今天会跟大家分享我们对云原生领域的思考，以及我们对云原生发展四个趋势的介绍：拥抱 Serverless – 极致弹性，无需运维；
服务网格 – 将服务治理能力与应用解耦，并下沉到基础设施层；
云原生应用管理标准化 – 构建高效、自动化和可信赖的应用交付体系；
计算无边界 – 实现云-边缘-IoT 设备的高效协同。
我们接触了很多的客户，对于这些客户而言，上不上云已经不是问题，他们关注的是该怎么上云？该如何充分利用云的能力、最大化云的价值？在 All in Cloud 的时代，企业的技术能力已经成为核心竞争力，他们非常愿意用云作为企业 IT 能力的增效器。云原生计算是一组最佳实践和方法论，在公共云、专有云环境中，构建可伸缩、健壮、松耦合的应用，可以更加快速地创新和低成本试错；容器、服务网格、无服务计算等新的计算范型不断涌现。- Docker 镜像形成了应用分发和交付的标准，可以将应用与底层运行环境实现解耦；
- Kubernetes 技术成为了分布式资源调度和编排的标准，Kubernetes 屏蔽了底层基础架构的差异，帮助应用运行在不同的基础设施之中；
- 在此基础之上，社区开始建立上层的应用抽象。比如服务治理层，Istio 成为了服务通信的网络协议栈，将服务治理能力与应用层实现解耦。
在此之上，面向领域的云原生框架也在迅速出现，比如面向机器学习的云原生平台 Kubeflow 和面向无服务器的 Knative 等等。通过这样的架构分层，开发者只需关注自身的业务逻辑，而无需关注底层实现的复杂性。我们可以看到一个云原生操作系统的雏形开始出现，这是开发者最好的时代，极大地提升了业务创新的速度。在早期，Kubernetes上主要运行无状态的 Web 应用，比如基于 Apache Dubbo/Spring Cloud 的微服务应用。而现在，越来越多的企业核心业务、数据智能业务以及创新业务也运行在 Kubernetes 之上。以阿里云自身的云产品举例，如企业级分布式应用服务 EDAS、实时计算平台 Flink、弹性 AI 算法服务 EAS 以及区块链平台 BaaS 也部署在阿里云 Kubernetes 服务 ACK 之上。K8s 已经成为云时代操作系统，成为应用使用云基础设施能力的界面。阿里云 ACK 实现了对云基础设施的优化集成，提供敏捷、弹性和可移植的云原生应用平台；而且可以在公共云、专有云、边缘云上实现一致的应用部署和管理。
下面我们来谈一下，Kubernetes 的 Serverless 进化。所有人都喜欢 K8s 提供的强大和灵活，但是运维一个 Kubernetes 生产集群极具挑战。阿里云的 Kubernetes 服务 ACK 简化了 K8s 集群的生命周期管理，托管了集群的 master 节点，但是用户依然要保有 worker 节点资源池，还需要维护节点，比如进行升级安全补丁等，并根据自己的使用情况对资源层进行容量规划。针对 K8s 的运维复杂性挑战，阿里云推出了 Serverless Kubernetes 容器服务 ASK，完全兼容现有 K8s 容器应用，但是所有容器基础设施被阿里云托管，用户可以专注于自己的应用。它具备几个特点：- 首先用户没有任何预留资源，按照容器应用实际消耗的资源付费；
Serverless Kubernetes 极大降低了运维复杂性，而且其自身设计非常适合突发类应用负载，如 CI/CD，批量计算等等。比如一个典型的在线教育客户，根据教学需要按需部署教学应用，课程结束自动释放资源，整体计算成本只有使用包月节点的 1/3。
云规模的 Nodeless 架构 —— Viking
在 2017 年底，我们启动 Serverless Kubernetes 项目的时候，就一直在思考：如果 Kubernetes 天生长在云上，它的架构应该如何设计？我们为它内部的产品代号为 Viking，因为古代维京战船以迅捷和便于操作而著称。首先，我们希望兼容 Kubernetes。用户可以直接使用 Kubernetes 的声明式 API，兼容 Kubernetes 的应用定义，Deployment, StatefulSet, Job, Service 等无需修改。其次 Kubernetes 底层尽可能充分利用云基础设施服务的能力和云服务来实现，比如计算、存储、网络、资源的调度等；根本性简化容器平台的设计，提升规模，降低用户运维复杂性。我们遵从 Kubernetes 控制器设计模式，驱动整个 IaaS 资源状态不断地向用户应用声明的状态逼近。我们在资源层提供了弹性容器实例 - ECI。与 Azure Container Instance ACI, AWS Fargate 不同，ECI 提供 Kubernetes Pod 的原生支持而不是提供单独 container 实例。ECI 基于轻量虚拟机提供了沙箱环境实现安全隔离，完全兼容 Pod 的语义、支持多容器进程、健康检查、启动顺序等能力。这样使得上层构建 K8s 兼容层，变得非常简单直接。在编排调度层，我们使用了微软的 Virtual-Kubelet，并对其进行了深度扩展。Virtual-Kubelet 提供了一个抽象的控制器模型来模拟一个 Kubernetes 节点。当一个 Pod 被调度到虚拟节点上，控制器会利用 ECI 服务创建一个 ECI 实例来运行 Pod。同时控制器支持双向状态同步，如果一个运行中的 ECI 实例被删除，控制器会根据应用目标状态重新恢复一个新的 ECI 实例。同时我们基于阿里云的云服务实现了 Kube-Proxy、Kube-DNS、Ingress Controller 的行为，提供了完整的 Kubernetes Service 能力支持：- 比如利用阿里云的 DNS 服务 PrivateZone，为 ECI 实例动态配置 DNS 地址解析，支持了 Headless Service；
- 通过内网 SLB 提供了 Cluster IP，提供负载均衡能力；
- 通过 SLB 提供的 7 层路由来实现 Ingress 的路由规则。
我们也为 ECI 提供了端到端可观测性能力，并与阿里云日志服务，云监控等服务进行了深度集成，也可以轻松支持 HPA 水平扩容。
对于 Serverless 容器技术而言，应用启动速度是一个核心指标。容器对应用启动速度的影响主要在于：- 资源的准备：通过端到端管控链路的优化和针对容器场景虚拟化和操作系统的剪裁和优化，ECI 可以将资源准备时间优化到秒级；
- 镜像下载时间：从 Docker 镜像仓库下载镜像并在本地解压缩是一个非常耗时的操作。下载时间取决于镜像大小，通常在 30 秒到数分钟不等。
在传统 Kubernetes 中， worker 节点会在本地缓存已下载过的镜像，这样下次启动不会重复下载和解压。为了实现极致弹性成本效率，ECI 和 ECS 采用并池的策略，计算存储分离的架构，这也意味着我们不可能通过传统方式利用本地盘来做容器镜像的缓存。为此我们实现了一个创新的方案：可以将容器镜像制作成一个数据盘快照。当 ECI 启动时，如果镜像快照存在，可以直接基于快照创建一个只读数据盘，并随着实例启动自动挂载，容器应用直接利用挂载数据盘作为 rootfs 进行启动。基于盘古 2.0 架构和阿里云 ESSD 云盘的极致 I/O 性能，我们可以将镜像加载的时间缩小到 1 秒以内。为了简化用户操作，我们在 K8s 中提供了 CRD 可以让用户指明哪些镜像需要构建镜像快照。同时，在 ACR 镜像仓库服务的软件交付流水线上，我们可以声明哪些镜像需要进行加速，这样当用户推送一个新镜像时，就会自动构建相应的快照缓存。
下面谈弹性，对于绝大多数的企业来讲，弹性是上云最重要的一个诉求，双 11 就是一个典型的脉冲式计算，峰值计算资源会是平时的很多倍。也有不可预期的峰值发生，比如一个爆款游戏大热之后，就需要迅速地在云上扩容。Kubernetes 可以将云的弹性能力发挥到极致。ACK 在资源层和应用层提供了丰富的弹性策略，在资源层目前主流的方案是通过 cluster-autoscaler 进行节点的水平伸缩。当出现 Pod 由于资源不足造成无法调度时，cluster-autoscaler 会选择一个伸缩组中，并自动向组内加入实例。在弹性伸缩组中，我们可以根据应用负载需求选择 ECS 虚拟机，神龙裸金属和 GPU 实例进行扩容。值得一提的是 Spot instance，竞价实例可以利用阿里云的空闲计算资源，成本折扣可以低至按量付费实例的 90%。竞价实例非常适合无状态和容错性好的应用，比如批量数据处理或者视频渲染等，可以大大降低计算成本。基于阿里云强大的弹性计算能力，我们可以在分钟级实现千节点伸缩。进一步结合上文提到的 ECI，我们可以在 ACK 中基于虚拟节点实现弹性伸缩。virtual-kubelet 可以注册为一个虚拟节点，理论上拥有无限大的容量。当 Pod 调度到虚拟节点上时，会利用 ECI 动态创建 Pod，这非常适合大数据离线任务、CI/CD 作业、突发型在线负载等。在一个大型客户的生产环境中，弹性容器实例可以在 30 秒内启动 500 Pod，轻松应对突发的请求峰值。在应用层，Kubernetes 提供了 HPA 的方式进行 Pod 的水平伸缩，和 VPA 进行 Pod 的垂直伸缩。阿里云提供了 alibaba-cloud-metrics-adapter，可以提供更加丰富的弹性指标，比如可以根据 Ingress Gateway 的 QPS 指标、云监控的指标，动态调整应用 Pod 数量。另外对很多行业客户而言，应用负载的资源画像是具有周期性的。比如，我们一个证券行业的客户，每周一到周五，股市开盘时间是交易时间，而其他的时间，只能查询不提供交易，峰谷资源需求量高达 20 倍以上的差异。为了解决这个场景，阿里云容器服务提供了定时伸缩组件，专门应对资源画像存在周期性的场景 ，开发者可以定义 time schedule，提前扩容好资源，而在波谷到来后定时回收资源；结合底层 cluster-autoscaler 的节点伸缩能力，很好平衡了系统的稳定性和资源成本的节约。未来我们会发布一些基于机器学习的弹性伸缩策略，可以根据历史资源画像，实现更好地资源预测，提升弹性的 SLA。
上文说到了为什么 Serverless 受到越来越多开发者的欢迎，因为大家更关注自己的业务，而不是基础设施的维护。Serverless 化是云服务发展的必然趋势，我们需要将资源调度，系统运维等能力下沉到基础设施。Google, IBM，CloudFoundry 等共同推出了 Knative 作为 Serverless 编排框架，可以非常简洁、高效地实现无服务器化应用。它提供了几个核心能力：
结合应用管理能力和应用性能监控服务, 我们可以基于 Knative 快速搭建具备领域特色的应用托管服务 (Micro PaaS)，大大降低直接操作 Kubernetes 资源的复杂度，让开发者更加专注于应用迭代和服务交付效率提升。
刚才谈完了编程模型，看一下底层实现，所有的 Serverless下面核心实现就是安全容器沙箱。传统的 Docker RunC 容器与宿主机 Linux 共享内核，通过 CGroup 和 namespace 实现资源隔离。这种方式非常高效，但是由于操作系统内核的攻击面比较大，一旦恶意容器利用内核漏洞，可以影响整个宿主机上所有的容器。越来越多企业客户关注容器的安全性，为了提升安全隔离，阿里云和蚂蚁金服团队合作，引入安全沙箱容器技术。今年 9 月份我们发布了基于轻量虚拟化技术的 RunV 安全沙箱。相比于 RunC 容器，每个 RunV 容器具有独立内核，即使容器所属内核被攻破，也不会影响其他容器，非常适合运行来自第三方不可信应用或者在多租户场景下进行更好的安全隔离。经过性能优化，安全沙箱容器现在可以达到 90% 的原生 RunC 性能，并且 RunV 容器提供了和 RunC 容器完全一致的用户体验，包括日志、监控、弹性等。同时，ACK 可以在一台神龙裸金属实例上同时混布 RunC 和 RunV 容器，用户可以根据自己的业务特性自主选择。在财年年底，我们会推出基于 Intel SGX 可信计算技术的可信容器沙箱 RunE。容器应用运行在 CPU 中被称为 enclave 的安全可信执行环境中。一个比喻：我们把容器放进了保险箱，任何人，包括云服务供应商，都无法从外部篡改和截获之中数据。客户可以将高机密应用，比如秘钥的加签、验签，隐私数据处理等逻辑运行在 RunE 容器中。
互联网应用架构催生了微服务架构的发展。它的核心思想是通过应用功能拆分，将复杂应用拆解为一组松耦合服务，每个服务遵守单一责任原则（Single Responsibility Principle）。每个服务可以独立部署和交付，大大提升了业务敏捷性；每个服务可以独立横向扩展/收缩，应对互联网规模的挑战。
微服务框架，比如 HSF/Dubbo 或 Spring Cloud，都提供了强大的服务治理能力，比如服务发现、负载均衡、熔断降级等。这些服务治理能力以 Fat SDK 的方式与应用程序构建在一起，随着应用一起发布和维护，服务治理能力与业务逻辑的生命周期耦合在一起。微服务框架的升级会导致整个应用的重新构建和部署。此外由于 Fat SDK 通常与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构。它将服务治理能力下沉到基础设施，通过一个独立的 Sidecar 进程来提供服务治理能力，而应用侧只保留协议的编解码即可。从而实现了服务治理与业务逻辑的解耦，二者可以独立演进不相互干扰，提升了整体架构的灵活性；同时服务网格架构减少了对业务逻辑的侵入性，降低了多语言支持的复杂性。
在阿里巴巴经济体内部，我们已经开始大规模应用服务网格技术，来提供多语言支持，降低业务对接门槛；提供统一架构模式，提升技术迭代速度。以 Istio 为代表的服务网格技术具有光明的前途，但是大规模生产落地时仍然存在非常多的挑战。- 在海量服务的情况下，控制平面是否可以支持服务配置的高效分发？
- 下沉可观测性和策略管理能力到数据平面，避免集中化 Mixer 引入的性能瓶颈等。
- 最后是和现有的微服务架构兼容并存，支持现有微服务的统一配置管理服务和通信协议。
为了解决上述挑战，阿里巴巴和蚂蚁金服与 Istio 社区兼容的技术体系上，构建了服务网格能力。在今年 618，蚂蚁金服已经完成核心系统上到 SOFAMosn 的验证工作，刚刚结束的双 11，阿里巴巴和蚂蚁金服在核心系统大规模上线了 Service Mesh。同时阿里巴巴经济体会把自身技术演进的结果及时反馈到上游去，与社区共同推进 Service Mesh 发展。比如在阿里巴巴开源的服务发现与配置管理项目 Nacos 最新版本中，就提供了 Istio 对 MCP 协议支持。晚些时候，阿里云会推出托管 Service Mesh 服务，帮助云上的开发者能够便捷地使用服务网格技术。
另外一个关注的焦点是应用生命周期的自动化、标准化。我们知道 Kubernetes 的定位是 Platform for Platform，帮助企业实现自动化应用运维、管理。Kubernetes 为分布式应用管理提供了很多基础的元语抽象，比如面向无状态应用的 Deployment 和面向有状态应用的 StatefulSet。但是在企业生产环境中，面对应用的不同需求，现有能力还存在一些不足。参加技术分享我们经常会听到每个企业都在谈如何修改 K8s 来解决自己的问题，这里面很多问题都是相似的。
作为云原生技术的引领者，阿里巴巴将我们在云原生计算技术上大规模生产的最佳实践沉淀下来，以开源项目 OpenKruise 的方式与社区开放、共建。
- Broadcast Job：可以让一次性任务运行在机器上指定的节点，比如我们要在节点上安装安全补丁，或者在节点上预先下载一个容器镜像；
- Sidecar Set：越来越多的运维能力以 Sidecare 方式提供，比如日志、监控、和服务网格中的数据平面组件 Envoy。我们可以通过 Sidecar Set 以声明式方法管理 Sidecar的生命周期；
- Advanced StatefulSet: 支持原地发布和批量升级，让大家在更加简单地支持有状态服务。
在 11 月 16 日，微软和阿里云共同发布了 Open Application Model（OAM），希望能够建立起一个标准化的云原生应用模型，帮助开发者、应用运维和基础设施运维团队，进行更加高效的协同。
它采用的关注点设计标准包括不同的维度，开发者负责定义应用的组件、依赖与架构；应用运维人员负责定义应用运行时配置与运维需求，比如发布策略和监控指标，而基础架构运维团队可以针对应用部署环境的不同，配置定制化参数。通过这种关注点分离（Separation of Concerns）的设计，可以将应用定义、运维能力与基础设施实现解构。让应用交付变得更加高效、可靠和自动化。
最后一个方面，我们来讲一下对未来无边界云计算的思考。
随着 5G 时代的临近，低延迟网络、AI 硬件算力提升和智能化应用快速发展，一个万物智联的时代必将到来，将计算能力从云延展到到边缘侧、设备侧，并通过云进行统一应用交付、资源管控，将会是云计算发展的必然趋势。
基于容器，我们建立了云边端一体协同平台 —— ACK@Edge。这样我们可以将一些需要低延迟处理的应用部署在边缘节点实现就近访问。比如，我们可以把 AI 模型预测和实时数据处理放置到边缘，进行实时智能决策，而将模型训练，大数据处理等需要海量算力应用放到云端。ACK 边缘版提供了统一管控能力，在 K8s 集群中可以同时支持云端 ECS、边缘 ENS 节点以及 IoT 设备。并且针对边缘的特殊性，提供了单元化隔离和断连自治、自愈能力。我们已经在阿里云视频云、优酷等场景中开始大规模应用。优酷是国内最大的视频平台，随着优酷业务的快速发展，需要将原来部署在若干 IDC 内的集中式架构，演进到云+边缘计算的架构。这时候需要一种方式来统一管理阿里云十几个 region 和众多的边缘节点。优酷选择了 ACK@Edge，可以统一管理云与边缘的节点，并实现了统一的应用发布和弹性扩缩容。通过弹性能力，节省了机器成本 50%。采用新的架构之后，用户终端可以就近访问边缘节点，让端到端网络延迟降低了 75%。
最后，云原生技术源自于社区的共同的建设。阿里巴巴作为云原生的实践者和引领者，全面拥抱云原生技术，并将我们在大规模生产最佳实践回馈到社区，与社区共同建设更加美好的云原生技术生态。【推荐阅读】