来源 | 阿里巴巴云原生公众号

作者 | 志敏、智清

2020 年 双11，阿里核心系统实现了全面云原生化，扛住了史上最大流量洪峰，向业界传达出了“云原生正在大规模落地”的信号。这里包含着诸多阿里 "云原生的第一次”，其中非常关键的一点是 80% 核心业务部署在阿里云容器 ACK 上，可在 1 小时内扩展超百万容器。

可以说，以 Kubernetes 为代表的容器技术正成为云计算新界面。容器提供了应用分发和交付标准，将应用与底层运行环境进行解耦。Kubernetes 作为资源调度和编排的标准，屏蔽底层架构差异性，帮助应用平滑运行在不同基础设施上。CNCF Kubernetes 的一致性认证，进一步确保不同云厂商 Kubernetes 实现的兼容性，这也让更多的企业愿意采用容器技术来构建云时代的应用基础设施。

云原生容器新界面的崛起

作为容器编排的事实标准，Kubernetes 支持 IaaS 层不同类型的计算、存储、网络等能力，不论是 CPU、GPU、FPGA 还是专业的 ASIC 芯片，都可以统一调度、高效使用异构算力的资源，同时完美支撑各种开源框架、语言和各类型应用。

伴随着 Kubernetes 成为新操作系统的事实，以云原生容器为主的技术，已经成为云计算的新界面。

1. 云原生容器界面特征

云原生容器界面具有以下三个典型特征：

• 向下封装基础设施，屏蔽底层架构的差异性。
• 拓展云计算新边界，云边端一体化管理。
• 向上支撑多种工作负载和分布式架构。

1）向下封装基础设施，屏蔽底层差异性

• 统一技能栈降低人力成本：Kubernetes 可以在 IDC、云端、边缘等不同场景进行统一部署和交付，通过云原生提倡的 DevOps 文化和工具集的使用有效提升技术迭代速度，因此整体上可以降低人力成本。
• 统一技术栈提升资源利用率：多种计算负载在 Kubernetes 集群统一调度，可以有效提升资源利用率。Gartner 预测“未来 3 年，70% 的 AI 任务运行在容器和 Serverless 上” ，而 AI 模型训练和大数据计算类工作负载更加需要 Kubernetes 提供更低的调度延迟、更大的并发调度吞吐和更高的异构资源利用率。
• 加速数据服务的云原生化：由于计算存储分离具备巨大的灵活性和成本优势，数据服务的云原生化也逐渐成为趋势。容器和 Serverless 的弹性可以简化对计算任务的容量规划。结合分布式缓存加速（比如 Alluxio 或阿里云 Jindofs）和调度优化，也可以大大提升数据计算类和 AI 任务的计算效率。
• 安全能力进一步加强：随着数字经济的发展，企业的数据资产成为新“石油”，大量数据需要在云端进行交换、处理。如何保障数据的安全、隐私、可信成为了企业上云的最大挑战。我们需要用技术手段，建立数字化信任基础，保护数据，帮助企业创建可信任的商业合作关系，促进业务增长。比如基于 Intel SGX 等加密计算技术，阿里云为云上客户提供了可信的执行环境。不过，可信应用开发和使用门槛都很高，需要用户对现有应用进行重构，处理大量的底层技术细节，让这项技术落地非常困难。

2）拓展云计算新边界，云边端一体化管理

随着边缘计算的场景和需求不断增加，“云边协同”、“边缘云原生”正在逐渐成为新的技术焦点。Kubernetes 具有强大的容器编排、资源调度能力，可以满足边缘/IoT 场景中，对低功耗、异构资源适配、云边网络协同等方面的独特需求。为了推动云原生和边缘计算交叉领域的协同发展，阿里巴巴于 2020 年 5 月正式对外开源边缘计算云原生项目 OpenYurt，推动“云边一体化”概念落地，通过对原生 Kubernetes 进行扩展的方式完成对边缘计算场景需求的支持，其主要特性有：

• “零”侵入的边缘云原生方案：提供完整的 Kubernetes 兼容性，支持所有原生工作负载和扩展技术（Operator/CNI/CSI 等）；可以轻松实现原生 Kubernetes 集群一键转化为 OpenYurt 集群。
• 节点自治：具备云边弱网或断网环境下的边缘节点自治、自愈能力，保障业务连续性。
• 针对海量边缘节点的应用交付，可提供高效、安全、可控的应用发布和管理方式。

2019 年 KubeCon 上阿里云发布边缘容器服务 ACK@Edge，OpenYurt 正是其核心框架。短短一年，ACK@Edge 已经应用于音视频直播、云游戏、工业互联网、交通物流、城市大脑等场景中，并服务于盒马、优酷、阿里视频云和众多互联网、新零售企业。同时，作为 ACK@Edge 的开源版本 OpenYurt，已经成为 CNCF 的沙箱项目，推动 Kubernetes 上游社区兼顾边缘计算的需求，欢迎各位开发者一起共建，迎接万物智联的新时代。

3）向上支撑多种工作负载和分布式架构

企业在 IT 转型的大潮中对数字化和智能化的诉求越来越强烈，最突出的需求是如何能快速、精准地从海量业务数据中挖掘出新的商业机会和模式创新，才能更好应对多变、不确定性的业务挑战。

Kubernetes 可以向上支持众多开源主流框架构建微服务、数据库、消息中间件、大数据、AI、区块链等各种类型应用。从无状态应用、到企业核心应用、再到数字智能应用，企业和开发者都可以基于 Kubernetes 顺利地自动部署、扩展和管理容器化应用。

2. 阿里巴巴如何理解云原生容器界面

阿里巴巴将云原生看作未来重要的技术趋势，为了更快加速、更好协同，制定了清晰的经济体云原生技术路线，举集团之力统筹推动云原生。

在云原生容器界面的指引下，阿里巴巴集团以基础设施、运维及其周边系统作为切入点，掀起全面云原生化的浪潮，陆续将系统改造为适配云原生架构的新方案，推动集团内部使用的技术框架、工具等被云可接受的标准产品或云产品替代；进一步转变运维思路和工作方式，兼容适配新的运维模式。例如：DevOps 需要改变传统虚拟机时代的运维思想，容器运行时的组件要改为支持 Kubernetes Pod 下的新模式，容器内日志、监控等各类运维组件都需要变化、运维模式也随之变化。

在计算、网络、存储方面，用户通过 Kubernetes 的统一管理，可以充分利用阿里云的 IaaS 能力，让每个业务拥有自己独立的弹性网卡和云盘，对网络和存储性能有着高低不同需求的业务，也有能力部署在同一台宿主机上，并保证互相不被干扰的隔离性。传统非云物理机机型决定业务部署类型，会导致的弹性不足问题，也得到了很好的解决。因此，用户在提升资源利用率、降低成本的同时，也极大提升了业务的稳定性。

在节点资源层，用户可充分利用 Kubernetes 的底座扩展能力，让节点管理实现云原生化；在架构层面，通过节点生命周期控制器、自愈控制器和组件升级控制器等，可实现节点自愈、流转、交付、环境组件变更的节点生命周期的完全闭环，让容器层完全屏蔽底层节点感知，完全改变了节点的运维管理模式。基于强大的云原生节点管理模式，阿里巴巴内部将集团之前相对割裂的节点资源整合为一体，真正实现了资源池从点形成面，将内核、环境组件、机型规格等进行统一标准整合，资源池的大一统并结合统一调度形成巨大的弹性能力，这也是云原生节点管理中的『书同文，车同轨，度同制，行同伦，地同域』，让节点资源从诸侯格局变成了大一统的云原生资源池。

新兴的生态和业务，基于 ACK（阿里云容器服务）提供的云原生土壤，如 Service Mesh、Serverless、Faas 等，也非常快速地在集团内落地，并得到蓬勃发展。

在应用 PaaS 层，云原生的应用交付模式走向了更为彻底的容器化，充分利用了 Kubernetes 的自动化调度能力，基于 OAM Trait 的标准定义来构建集团内统一的 PaaS 运维能力，基于 GitOps 研发模式让基础设施和云资源代码化、可编程。

阿里集团向云原生容器界面的演进

为了支撑阿里集团庞大而复杂的业务，十年之间，众多技术工程师走出了一条深深浅浅的容器之旅。 那么，在阿里集团内部，容器界面是如何演进的呢？

在过去十年，阿里集团内的容器技术，经历了从自研 LXC（Linux Container）容器 T4，到富容器，再到 Kubernetes 云原生轻量级容器的演进历程。每一次转变升级，都是基于不同时期的业务背景，所做出的技术迭代和自我革新。

第一阶段：基于 LXC 的容器 T4 尝试

受困于虚拟机 KVM 的巨大开销，以及 KVM 编排管理的复杂度，阿里集团在 2011 年时发起对 LXC 和 Linux Kernel 的定制，在内部上线了基于 LXC 的 T4 容器。但相比后面出现的 Docker, T4 容器在技术上存在一些不足，比如没有实现镜像提取和应用描述。T4 诞生后的多年，阿里持续尝试在 T4 之上构建复杂的基线定义，但屡屡遭遇问题。

第二阶段：引入容器镜像机制的 AliDocker，实现大规模分发

2015 年，阿里引入 Docker 的镜像机制，将 Docker 和 T4 的功能取长补短互相整合，即：让 T4 具备 Docker 镜像能力，同时又让 Docker 具备了 T4 对内部运维体系的友好性，并在此基础上形成内部产品 AliDocker。

过程中，阿里引入 P2P 镜像分发机制，随着电商核心应用逐步全面升级到 AliDocker，通过宿主机的环境隔离性和移植性，屏蔽了底层环境差异，为云化/统一调度/混部/存储计算分离等后续基础架构变革打下了基础，镜像机制的优势得以体现。其中，孵化的 P2P 镜像分发是 2018 年 10 月加入 CNCF 的 Dragonfly。

第三阶段：完全自主产权的容器 Pouch，阿里内部全面容器化

随着容器技术的规模化铺开，AliDocker 化的优势得以体现，阿里完全自主产权的 Pouch 得以展开并逐渐替代 AliDocker。同时，阿里集团 100% Pouch 化也一直在快速推进，2016 年 双11 前，已经实现了全网的容器化。

Pouch 寓意是一个神奇的育儿袋，为里面的应用提供贴心的服务。因为 Pouch 统一了集团在线应用的运行时，应用开发人员就无需关注底层基础设施的变化。接下来的数年，底层基础设施发生了云化、混部、网络 VPC 化、存储无盘化、内核升级、调度系统升级等各种技术演进，但 Pouch 容器运行时使绝大部分底层变化对应用无感知，屏蔽了对上层应用的影响。Pouch 自身也把运行时从 LXC 切换到了 runC，并将其核心技术反哺给开源社区，同时集团也逐步将过去的存量 AliDocker 实例无缝切换为开源的 Pouch 实现。

过程中富容器模式的存在，一方面让用户和应用能够无缝平滑地切换到容器化，另一方面应用依赖的各种运维、监控、日志收集等运维系统，基于富容器模式也得以跟随容器化平滑迁移。

但富容器也有着较多缺点。由于富容器中可以存在多个进程，并且允许应用开发和运维人员登录到容器中，这违反了容器的“单一功能”原则，也不利于不可变基础设施的技术演进。例如：Serverless 演进过程中，调度插入的代理进程实际上是与应用无关的，一个容器中有太多的功能也不利于容器的健康检查和弹性。

容器化是云原生的必经之路。阿里集团正是通过这种方式，快速走完了容器化这一步，极大加速了云原生的进一步演进。全面容器化后，云原生的大势已经不可阻挡，越来越多新的理念和应用架构在容器生态中成长起来，基于容器和镜像的应用打包、分发、编排、运维的优势被越多的人看到、接受和拥抱，各种运维系统开始适配云原生架构。

第四阶段：调度系统兼收并蓄及 ACK 的演进

随着以 Kubernetes 为代表的容器技术成为云计算的新界面，阿里自研的 Sigma 也在持续探索 Kubernetes 的落地实践，并借助集团全面上云的契机，最终实现了从 Sigma 管控到 ACK 的全面迁移。

2018 年，集团调度系统开始了从内部定制的 Sigma 到  ACK 的逐步演进，容器轻量化成为一个重要的演进目标。云原生浪潮下，集团内部的运维生态也随之快速演进。轻量化容器的解决思路是用 Kubernetes 的 Pod 来拆分容器，剥离出独立的运维容器，并将众多与应用无关的运维进程逐个转移至运维容器。

Sigma 诞生之初致力于将阿里集团众多割裂的在线资源池整合统一，在此基础上，不断探索新的资源混跑形态，包括在离线混部、离在线混部、Job 调度、CPUShare、VPA 等众多技术。通过提升阿里集团数据中心整体资源利用率，带来巨大的成本节约效益。基于全托管免运维 Sigma Master、公共大资源池、应用额度服务，提供 Serverless 的资源交付和最佳的用户体验。Sigma 调度也加速了 T4 到 Pouch 的全面容器化进程，通过应用研发自定义的 Dockerfile 标准化容器，以及透明化基础设施的 Sigma 调度引擎，业务研发已无需关心底层运维，工作重心得以聚焦于业务本身。

从 Sigma 到 ACK 的升级，是希望 ACK 领先的云产品能力得以赋能阿里集团，使得 Sigma 可以加速享受云计算的能力，包括异构资源的统一管理、面向全球化的安全合规等。但实际上，迁移 ACK 的过程并非一帆风顺：

首先，围绕着核心管控链路，阿里原有的规模和复杂场景能力、原有的庞大存量容器如何迁移到新的平台，以及容器界面如何兼容并影响现有的庞大生态体系升级，实际上都会成为演进中的包袱和劣势。实现在高速飞行中换引擎并解决存量迁移问题的难度，这在业界都有共鸣。

其次，性能、多集群运维、安全防御、稳定性等众多问题，都是全面迁移 ACK 的挑战。围绕着性能，阿里基于原生 Kubernetes 做了非常多的优化并回馈给社区，如 Cache Index、Watch Bookmark 等，并建设了一整套 Kubernetes 规模化设施，包括安全防御组件、OpenKruise、多集群组件发布等能力等。

围绕 “经济体调度 = ACK + 经济体扩展” 的总体思路，阿里集团内部迁移至 ACK 过程中的积累又能沉淀给云，丰富产品能力，帮助客户形成云上的竞争力。至此，阿里集团内部、阿里云、开源社区形成了非常好的技术合力，自研、商用、开源，三位一体融合互补。

自研、商用、开源，三位一体融合互补

技术和业务是相辅相成的，业务为技术提供场景促进技术进步；技术的进步反过来带动业务更好的发展。复杂而丰富的场景，提供了一个天然肥沃的土壤，进一步推动阿里技术的发展。阿里集团的技术一直持续保持先进。在过去，业内一直非常领先的中间件、容器、调度等各类技术，阿里都率先应用于业务，并将能力沉淀到云产品再输送给客户，助力企业加速数字化转型，产生了广泛的引领者影响力。

但在新云原生时代，如何在云原生标准下持续保持这份影响力，我们看到了更多挑战。上述的阿里容器界面演进简史记录了一线阿里工程师们如何应对这些挑战。更抽象地讲，这些得益于阿里巴巴云原生技术体系自研、商用、开源三位一体的战略决策。

1. 阿里云侧的挑战

阿里云过去面对的用户大部分是普适性用户，而阿里集团内部场景的诉求是需要解决大规模、超高性能等问题，阿里云产品能否很好地兼顾和支撑是非常大的挑战。进一步考虑，如果我们能很好地抽象出大众用户的诉求，阿里集团对阿里云来说又是一个非常好的“试炼场”。

2. 集团内部的挑战

船小好调头，而船大就没那么灵活了。过去业界独有的阿里集团内部庞大规模场景，现在反而是迈向云原生的包袱。问题的根本在于如何让阿里集团的技术能够快速融合和贡献云原生标准，而不是形成技术孤岛。

3. 开源侧的挑战和机遇

开源侧的挑战和机遇：阿里云在云原生开源项目贡献中有着持续投入，推出了 OpenKruise、联合微软推出 OAM、KubeVela 等开源项目，这些都源于阿里巴巴在云原生领域的沉淀， 并且通过开源社区用户的反馈，完善在阿里云原生落地的解决方案。以 OpenKruise 为例， 该项目是阿里巴巴打造的一个基于 Kubernetes 的、面向大规模应用场景的通用扩展引擎，它的开源使每一位 Kubernetes 开发者和阿里云上的用户都能便捷地使用阿里巴巴内部云原生应用统一的部署发布能力。当社区用户或外部企业遇到了 Kubernetes 原生 workload 不满足的困境时，企业内部不需要重复造一套相似的“轮子”，而是可以选择使用 OpenKruise 的成熟能力。而且，阿里集团内部使用的 OpenKruise 和开源社区版本中有 95% 以上的代码是完全一样的。我们希望和每一位参与 OpenKruise 建设的云原生爱好者，共同打造了这个更完善、普适的云原生应用负载引擎。

云原生操作系统的进化

如今，在云原生应用架构界面层，阿里集团的技术体系正在全面切向云原生技术、云产品。

阿里云为客户提供的云原生操作系统， 首先基础设施层是强大的 IaaS 资源，基于第三代神龙架构的计算资源可以更弹性的扩展，以更加优化的成本提供更高的性能；云原生的分布式文件系统，为容器持久化数据而生；云原生网络加速应用交付能力，提供应用型负载均衡与容器网络基础设施。

其次在容器编排层，阿里云容器服务自 2015 年上线来，伴随数千家企业客户，共同实践过各行各业大量生产级场景。越来越多的客户以云原生的方式架构其大部分甚至全量应用，随着业务深入发展，为了满足大中型企业对可靠性、安全性的强烈需求，阿里云推出新品可供赔付 SLA 的容器服务企业版 ACK Pro，并同样支撑了阿里集团内部的众多产品的落地。

容器服务 ACK Pro 版，针对金融、大型互联网、政企客户的需求，支持更大规模集群，更高性能和更加全面的安全防护。

• 首先，基于神龙架构，软硬一体化优化设计，提供卓越性能：

  • 无损 Terway 容器网络，简化数据链路，相比路由网络延迟下降 30%。
  • 支持全球首款持久性内存实例，相比 NVMe，I/O 密集应用 TPS 提升 100%。

• 其次，提供对异构算力和工作负载优化的高效调度：

  • 智能 CPU 调度优化，在保障 SLA 和密度的前提下，Web 应用 QPS 提升 30%。
  • 支持 GPU 算力共享, AI 模型预测成本节省 50% 以上。

• 最后，为企业提供全面安全防护：

  • 支持阿里云安全沙箱容器，满足企业客户对应用的安全、隔离需求，性能相比开源提升 30%。
  • 国内首批通过可信云容器安全先进性认证，支持运行时风险秒级阻断。

同时，阿里云全托管托管服务网格 ASM 正式商用化，这是业内首个全托管 Istio 兼容服务网格 ASM。 ASM 可以实现多种异构应用服务统一治理，提供了对云上虚拟机，容器，弹性容器实例，和 IDC 应用等异构服务的统一管理，提供全链路可观测性和端到端安全防护。帮助您加速企业应用的现代化改造，轻松构建混合云 IT 架构。

阿里云容器服务连续两年国内唯一进入 Gartner《公有云容器服务竞争格局》报告；在 Forrester 首个企业级公共云容器平台报告中，阿里云容器服务位列 Strong Performer, 中国第一。

展望

云计算的未来是云原生，容器新界面是进化中的关键一小步。向下，容器新界面带来的高密度、高频度的能力要求会进一步催熟云计算的端到端优化；向上，基于容器新界面的 Serverless、新一代的中间件、新一代的应用 PaaS 方兴未艾。

云原生技术正成为释放云价值的最短路径，未来，阿里巴巴将会持续在云原生上进行投入，而阿里的云原生技术不仅会在内部大规模普及，也通过阿里云服务全社会。