解读云原生的2021：抢占技术C位，迎来落地大爆发

2021 年 12 月 27 日 InfoQ

作者 | 褚杏娟

审校 | 蔡芳芳

2021年，云原生迎来黄金时代

本文是“2021 InfoQ 年度技术盘点与展望”系列文章之一，由 InfoQ 编辑部制作呈现，重点聚焦云原生领域在 2021 年的重要进展、动态，希望能帮助你准确把握 2021 年云原生领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。

“InfoQ 年度技术盘点与展望”是 InfoQ 全年最重要的内容选题之一，将涵盖架构、AI、大数据、大前端、云计算、数据库、中间件、操作系统、开源、编程语言十大领域，后续将聚合延展成专题、迷你书、直播周、合集页面，在 InfoQ 媒体矩阵陆续放出，欢迎大家持续关注。

特此感谢傅轶、黄玉奇、马若飞、彭涛、彭锋、宋净超、汤志敏（按姓名首字母排序）对本文的贡献，他们的真知灼见，是本文能与大家见面的关键。

数据显示，云原生计算基金会（CNCF ）现在拥有 730 多个成员组织和 100 多个开源云原生项目，整个云原生生态逐步趋于完善。

根据 CNCF 统计，OpenTelemetry 在 CNCF 中拥有第二大贡献社区，仅次于 Kubernetes（下文简称 K8s）；如果把 Argo 和 Flux 项目的发展速度结合起来，那么 GitOps 生态系统在 CNCF 中的发展速度是最快的；Envoy 社区继续保持强大且不断增长，已成为整个 Service Mesh 生态系统中使用最广泛的数据平面之一。专注于开发者体验改进的项目，无论是 Backstage、Dapr 还是 GitOps 生态系统，都在持续增长。

SlashData 最新数据显示，目前已经有 680 万云原生开发人员，其中 460 万人使用容器编排工具，400 万使用 Serverless 平台，同时使用两者的人达 180 万。

开发人员正在考虑如何通过云原生技术，用统一架构、统一技术堆栈来支撑更多类型的工作负载，避免不同负载、不同架构和技术带来的“烟囱”系统、重复投入和运维负担等问题。

此外，2021 年，云原生领域还发生了哪些值得关注的事儿呢？

重要事件回顾

技术动态

2 月 4 日，“策略即代码"项目 Open Policy Agent 正式从 CNCF 毕业，意味着人们对统一授权解决方案越来越感兴趣。同月，Service Mesh 第一届社区会议 IstioCon 召开，展示了 Istio 的实践经验等内容。
3 月，持续交付 (CD) 平台 Flux 进入 CNCF 孵化阶段。Flux v2 提供了全面的 GitOps 解决方案，支持将 git 存储库存到本地或远程集群，自动更新、渐进交付。这在一定程度上意味着会有更多 GitOps 程序出现和成熟。
6 月 22 日，可观测性平台项目 Pixie 成为 CNCF 沙盒项目。
7 月，第一个 Service Mesh 项目 Linkerd 从 CNCF 毕业。Linkerd 可以在不需要更改代码的情况下，为云原生应用程序提供关键的可观测性、安全性和可靠性。
同样在 7 月，Kafka / Spark 宣布 K8s support GA，这意味着大数据生态开始全面拥抱 K8s，大数据平台很快不再需要独立的资源管理。
8 月 26 日，可观测性项目 OpenTelemetry 成为 CNCF 孵化项目。OpenTelemetry 现在在 CNCF 中拥有第二大贡献社区，表明大家对现代可观测性工具和协作的兴趣仍然很重要。
9 月，AWS 发布了 EKS Anywhere，并开源了 EKS Distro 发行版，支持线下异构环境的 K8s 部署。同月，阿里云容器服务全面升级为 ACK Anywhere，并发布 ACK 发行版、ACK 敏捷版和 ACK ONE 分布式云容器平台。两者的目标都是让企业在任何环境都能获得一致的容器基础设施能力。
10 月 13 日，基于 eBPF 的高性能容器网络项目 Cilium 成为 CNCF 孵化项目。Cilium 是 Datadog 网络堆栈的重要组成部分，可以在云供应商之间提供一致的 Kubernetes 网络，以及性能和安全的通信。目前大多数大型云服务提供商都依赖于 Cilium。
11 月，开源微服务构建软件 Dapr 正式加入 CNCF 孵化项目。Dapr 是一个开源、可移植、基于事件驱动的运行时，开发者可以用它构建运行在云端和边缘的具有弹性、无状态、有状态、基于微服务的应用程序。云原生本质上是进行解耦和分布式应用改造，所以在云原生的落地过程中，类似 Dapr 这样的服务变得越发重要。
11 月 2 日，Serverless 项目 Knative 1.0 发布，同月 Google 宣布将 Knative 捐赠给云原生计算基金会 (CNCF)。Knative 提供面向 K8s 标准化 API 进行 Serverless 应用编排能力，支持基于流量的自动弹性、灰度发布、多版本管理、缩容到零、事件驱动 Eventing 等诸多特性，已成为 K8s 上安装最广泛的无服务器层。
11 月 3 日，腾讯云发布云原生操作系统遨驰 Orca。据悉，腾讯云原生操作系统遨驰单集群支持 10 万级服务器、百万级容器规模，管理的 CPU 核数超过 1 亿，计算正式进入亿级时代。

行业动态

今年 1 月，红帽宣布收购 K8s 原生安全初创公司 Stackrox，计划将其添加到 Red Hat OpenShift 中。OpenShift 对 Windows 容器的支持普遍可用。
4 月，亚马逊云科技将分叉项目 Elasticsearch OpenDistro 重新命名为 OpenSearch，7 月发布了 OpenSearch 1.0 版本。9 月，Amazon Elasticsearch Service 更名为 Amazon OpenSearch Service，并支持 OpenSearch 1.0。
当地时间 7 月 7 日，美国国防部宣布正式取消与微软的 100 亿美元 JEDI 云计算合作，后续计划将此分拆给微软和亚马逊两家公司。云计算领域竞争加剧。
当地时间 8 月 12 日，Google、Microsoft、Isovalent、Facebook 和 Netflix 联合宣布，Linux 基金会旗下的非营利性组织 eBPF 基金会正式成立。该基金会致力于推动开源项目 eBPF 的发展，支持 Linux 和其他开源技术的商业增长。
当地时间 10 月 14 日，全球第二大开源代码托管平台 GitLab 正式在纳斯达克上市，市值接近 150 亿美元。12 月，GitLab 公司宣布收购 Opstrace，用以扩展其 DevOps 平台。
当地时间，12 月 9 日，开源软件公司 HashiCorp（HCP）正式在纳斯达克挂牌上市，成为今年全球市值最高的开源公司。HashiCorp 提供多云基础设施自动化技术，以及一套自动化工具来帮助企业转型为云运营模式。

重点技术演进

云原生领域涵盖的技术类别越来越多，但最关键的三项是容器、Serverless、Service Mesh，因此本文主要围绕这三个领域做了年终回顾和趋势展望。

容器：大规模应用的一年

2021 年可以称得上是容器大规模应用的一年。基于 K8s 来屏蔽异构环境的差异，搭建分布式云架构已经成为企业和云厂商的共识。

“今年，对容器的应用呈现出井喷趋势，我们通过弹性计算、自动漂移等方式对业务容器的云原生进行了改造。”受访专家对 InfoQ 表示。这一现象也体现在了数据上：根据 SlashData 最新报告，现在有 560 万开发者使用 K8s，较去年增长了 67%，尤其在 500 名以上员工的企业中，K8s 和容器的采用率猛增。

总体来看，企业对容器的应用诉求可以分为三个阶段：

第一阶段，降本增效。在这个阶段，企业主要收口线上资源，将 IDC、物理网络、虚拟网络、计算和存储等资源，通过 IaaS 、PaaS 等实现虚拟化封装、切割和再投产的自动化流程。整合后的资源会形成统一的资源池，对特定服务器资源的依赖度大大降低。

第二阶段，增加服务的可扩展性和弹性。在这个阶段，企业在公有云、私有云和专属云等新型动态计算环境中构建和运行可弹性扩展的应用。业务对平台使用声明式 API 调用不可变基础设施、Service Mesh 和容器服务构建容错性好、易于观察的应用系统，同时结合平台的自动化恢复、弹性计算来提高服务的稳定性。

第三阶段，“混合部署”成为常态。这个阶段中，企业需要做好服务依赖的梳理和定义。所依赖的基础组件、基础服务云原生化服务完全不需要关心底层资源、机房、运行和供应商。企业利用开放的生态和标准的云原生应用模型，完成跨地域、跨云的自动化灾备自举。

目前，大多数企业已经进行到第二、三阶段。随着更大规模的应用，企业对容器核心技术的启动效率、资源开销、调度效率也有了更高的要求。

全链路的云原生化是目前比较核心的需求，也是落地场景比较难的课题。具体体现在以下几个方面：

落地难。整体来说，基于云原生概念构建复杂的生产环境业务是一个任重道远的过程。从基础组件的云原生化、到基础设施的全链路支持，再到公司内已有服务的云原生改造，都需要企业投入大量的时间和精力。虽然业界总体上在 CNCF 基金会的主导下趋于统一，但不同公有云厂商的标准实现起来仍有差异。这个问题关系到了企业能从云原生上具体获得哪些长效收益来支撑企业长期投入。
集中式云计算中心很难支撑起对实时要求高的业务。业务的解耦程度越高，相互的调用时延也越长，时延放大到客户端就会带来用户体验的下降。这类问题是集中式云计算中心的通病。这个问题的解决将会让企业在现行计算模型下获得成本和用户体验上的极大改善。
随着接入的服务越来越多，K8s 的配置复杂度随之上升。K8s 本意是想解放生产力，但相关的配置浩如烟海，开发人员需要了解很多概念。而面向终态的 API 设计和面向命令式的 API 设计之间存在思维方式冲突，往往需要加入第三方组件来协调，例如 Service Mesh 接管了流量等。

2022 年，容器技术将持续发挥其高效调度和弹性能力，通过与最新节能数据中心技术、芯片等结合，帮助企业实现上下游的全栈优化。企业会构建出更多插件来扩展 K8s 平台的能力。大型分布式应用都会面向 K8s 编程，整个 K8s 生态开始发生体系化的演进。

容器的智能化运维体系建立也是一个重点。复杂容器集群和应用也带来了一系列管理问题，为此，增强 K8s master、组件和节点的自愈自恢复能力，提供更加友好的异常诊断、K8s 配置推荐、弹性预测等能力是很有必要的。

另外，安全合规问题越来越被大家重视。StackRox 报告显示，55% 的受访者出于安全考虑推迟了将 K8s 应用程序部署到生产环境中。安全问题将促进 DevOps 向 DevSecOps 的全面演进，具体包括面向 Helm、Operator 等 OCI Artifacts 优化整体的安全定义、签名、同步和三方交付；加固容器的南北向和东西向的网络隔离和治理，推进零信任的链路安全；进一步提升安全容器和机密计算容器的性能和可观测能力等。

Serverless：应用更加理性

Serverless 在 2019 年取得了重大发展，如今两年过去，企业对 Serverless 的使用变得更加谨慎。根据 SlashData 最新报告，参与 Serverless 架构的开发人员比例从 27% 下降到了 24%。

企业对 Serverless 的使用各有不同。有的企业选择自研 Serverless 平台，有的在开源项目如 Knative 等上面自建平台，有的则直接采购商用平台。Serverless 是要解决容器和 Kubernetes 未能解决的问题，如开发部署效率提升、运维自动化、事件触发与编排等。但是，不同的方向对 Serverless 有不同的出发点和需求。

比如对前端来说，Serverless 可以减少其对运维等不太擅长领域的依赖，解放出更多精力在 SSR 服务端渲染、小程序和 H5 开发、BFF 接口聚合服务等方面进行深入探索。同时 Serverless 的自动扩缩容等特性可以在前端经常涉及的活动页面、长尾应用上提供很大帮助，减少前端在部署、运维层面的人力成本。对于批量任务、离线算法类操作，需要人为调整算法所需资源，没办法做到弹性自动化扩缩容，而 Serverless 平台自动扩缩容特性可以减轻日常运维压力。

Serverless 涵盖了很多技术，基本分为两类：FaaS（Function as a Service，函数即服务）和 BaaS（Backend as a Service，后端即服务）。在语言和环境方面，FaaS 函数就是常规的应用程序。业务代码下沉至函数级、运维能力集成平台统一提供，或将带领云原生进入下一个发展阶段。

但是，目前 Serverless 最核心的挑战是更广义层面的推广和实际落地。

企业内部基础架构部门研发的 Serverless 平台，想要真正帮助业务部门解决实际痛点就需要和应用场景更充分地结合。Serverless 的应用场景多样化是很明显的一个特点，但是难点在于，一个好的 Serverless 平台既要避免太多定制化功能，还保持技术上的通用性和可复用性。

对于企业来说，Serverless 平台的搭建是直接采购商业化的项目还是完全自研，亦或是基于开源项目做定制化开发？这也是困扰很多企业的问题。

目前 Serverless 领域并没有一个被大规模使用的开源组件，市面上的很多项目或多或少存在一些不成熟或者不能满足需求的情况。正如 SlashData 最新报告中分析，Serverless 研发人员比例下降可能是由于 Serverless 解决方案缺乏灵活性，公司担心被锁定在特定供应商中。尽管 Google Cloud Run 已经获得了很多拥护者，但目前有 53% 的 Serverless 开发者在使用 AWS Lambda ，其仍是目前最受欢迎的 Serverless 解决方案。

Serverless 的标准不统一也是个问题。虽然 CNCF 已经推出了 Serverless Workflow 规范，但目前各大云厂商和开源项目基本都是有着自己的标准，很少互相适配，造成了事件编排使用上的割裂以及厂商锁定和平台迁移困境。因此，Serverless 还需要朝着更开放、更友好的方向发展。

Serverless 生态，来源CNCF

接下来，Serverless 还需要做到更加智能地快速扩缩容。很多 Serverless 平台的自动扩容算法需要用户填写一些预估参数，但用户往往并不清楚自身服务的 Qps 或者并发请求数，这导致用户接入存在障碍。因此，Serverless 平台一方面需要采集更多的指标数据，另一方面需要聚合全方位的指标后提出更智能的算法，减少用户接入和使用成本。

从技术角度看，Serverless 还面临的挑战有：企业内部的 Serverless 平台面对混合云场景时，如何扩展到公有云上，实现更加灵活的 Serverless 架构；Serverless 技术实现上需要考虑与重视与 Service Mesh 融合、与现有微服务网关打通、与服务治理等能力适配问题；Serverless 快速扩缩容特性也会对网络、存储、中间件等提出更高的稳定性要求。

“Serverless 已经广为人知，各大厂商对其宣传也愈演愈烈。但开发者还是需要冷静思考自身的需求，避免被 Serverless 的各种概念引导和束缚。”受访专家提醒道。

Service Mesh：落地问题尚待解决

今年，Service Mesh 的落地越来越多，尤其是在银行电信等传统行业和中小企业中。“去年 Service Mesh 使用增长率在 50% 左右，虽然今年的统计还没出来，但我认为今年可能还是会大幅度提升。”受访专家表示。

随着 Istio、Linkerd 和 Kuma 等开源项目逐渐成熟，企业对 Service Mesh 的兴趣越来越大。Service Mesh 是云原生网络基础设施，企业对于 Service Mesh 的需求主要体现在以下几点：

统一的服务治理方案。这个方案对系统是无侵入的，同时不受技术栈的制约。比如使用 Spring Cloud 必须受限于 Java 语言，但异构系统或多技术栈的综合性系统并不希望受此限制。
流量管理的云原生实现。比如灰度发布、动态路由、弹性设计等无侵入的方案。
较低的维护成本和学习成本。现有技术栈的使用方案，如 Spring Cloud 等的维护、学习成本等较高，都不利于落地。

Service Mesh 生态，来源 CNCF

近一两年内，Service Mesh 仍需聚焦在一些落地问题的解决上。以 Istio 为例，大家对其最大的疑问是 Istio 是否会影响应用性能、扩展性是否足够好。此外，Istio 太过复杂、旧服务迁移成本高，业界经验少、学习曲线陡峭也是很多开发者的顾虑。

现在，Istio 的架构已经稳定，也被很多企业应用，但整个生态还处于萌芽之中。今年，Istio 的开源生态有明显的向上发展趋势，例如网易轻舟定位于 Service Mesh 智能管理器的开源项目 Slime 和基于 lstio Envoy 构建的云原生 API 网关 Hango，以及腾讯云为 Istio 提供的一种非侵入式的协议扩展解决方案 Aeraki 等。可以看出，Istio 生态的发展也是围绕具体落地问题来进行的。

总体来说，Service Mesh 产品的成熟度还有待加强。首先，Service Mesh 产品需要解决易用性问题，从部署方式、使用方式等各方面着手，尽可能地降低开发者的学习和使用成本；其次，Service Mesh 需要有更高的性能，比如在延迟性上，有些业务对几毫秒延迟没有感知，但有些特殊业务就非常敏感，要求相对也更高；另外，虽然 Service Mesh 现有解决方案的流控是相对比较完整的，但也比较粗粒度，不够精细和完善。

“从技术角度来说，今年不是一个有剧烈变化或者重大突破的年份，更多还是在稳步发展的阶段。”受访专家表示。明年，Service Mesh 还是会继续按需迭代、稳步发展。

随着云原生技术领域里各种技术的发展，基于 Serverless 部署的应用、Service Mesh、现有微服务网关打通和服务治理等等，如何更好地适配、更高效地发挥作用，都对技术提出了更高的要求。

值得关注的“新”技术

这里的“新“技术，并非指那些最新的研发成果，而是新加入云原生体系、用来解决新问题的技术，这些技术或许会对云原生的发展起到重要作用。

边缘计算

随着 5G、IoT、音视频、直播、CDN 等发展，企业开始将更多的算力和业务下沉到距离数据源或者终端用户更近的地方，从而来获得更短的响应时间并降低成本。这就是区别于传统中心式的云计算模式——边缘计算。

边缘计算的正式概念是在 2003 年由 IBM 和 Akamai 共同提出来的。作为云计算的延伸，边缘计算广泛应用在混合云 / 分布式云、IoT 等场景，用来补齐算力集中的云计算在面对“低时延、大带宽、大链接、本地化、安全”等需求场景下的短板。

当前，边缘计算还在不断发展中。从 Gartner 预测报告来看，边缘计算还处于上升阶段，需要 2~5 年才能达到平稳期。当前业界对边缘计算的理解和应用主要分成五种：

传统的 CDN 厂商（如 Akamai，国内的帝联、蓝汛等），对于边缘计算的研究主要是以降低计算访问延迟为主。
云厂商（如亚马逊、腾讯、阿里），主要是为了丰富自己的云计算产品，将用户的计算任务部署在云上，降低云服务的访问延迟。
小米、华为等智能家居厂商，是最极端的边缘计算，从计算的发起到在网络上只需要“一跳”，通过边缘计算建立本地的计算中心。
以 Google、Facebook 为首的互联网厂商，将边缘计算作为 AR、VR 的基座进行开发，主要是利用边缘计算来降低计算时延和提升计算可靠性。
以运营商为主的厂商则主要希望通过边缘计算来支撑更多的设备接入，降低带宽传输。

目前，边缘计算的挑战有很多。首先，不同的场景下的设备接入标准、预期等都不一样，很难有一个标准化的落地方案，这对边缘计算平台的设计能力是非常大的考验。其次，与集中式云计算不同，边缘端系统最需要考虑的就是在弱网甚至断网环境下如何提供服务，这很考验设备的的接入速度。再者，通常情况下，边缘节点不像云计算中心有大批量的资源冗余，往往节点很少，可靠性和可用性不高。如何让这部分计算任务无损平滑地完成是一个难度很高的课题。最后，边缘端系统接入的服务类型很多，比如智能驾驶接入边缘要完成视频解析，AR/VR 要求完成实时渲染等，所以通用平台的建设很重要。

针对边缘计算云原生架构和技术体系，具体需要解决以下问题：云边运维协同、弹性协同、网络协同、边缘 IoT 设备管理、轻量化、成本优化等。

机器学习

在数字化转型浪潮下，企业需要处理的数据量越来越大。2015 年，许多公司在初步尝试实现“大数据”的承诺时，建立了大型的本地数据湖。但在那个时候，云原生 AI 平台还没有成熟到足以激励企业将数据密集型 ML 项目迁移到云环境。

随着云计算和人工智能的不断发展，两种技术的协同将为创新公司带来显著的竞争优势。企业内部使用容器的范围从最初的在线业务正在逐渐向 AI、大数据演进，对 GPU 等异构资源的管理和 AI 任务和作业的管理需求也越来越多。

深度学习、AI 任务成为社区寻求云原生技术支撑的重要工作负载之一。AI 要成为企业生产力，必须以工程化的技术来进行模型开发、部署、管理、预测、推理等全链路生命周期管理。目前，AI 工程化领域有三大亟待推进的事情：数据和算力的云原生化、调度和编程范式的规模化、开发和服务的标准化普惠化。

这三件事情的实现，需要持续优化 GPU 等异构架构的高效调度，结合 Kubeflow Arena 的 AI 任务流水线和生命周期管理能力和分布式缓存、分布式数据集加速等技术。业内认为，云原生和 AI 的融合将在提高算法模型的开发效率和提升交付、部署、运维环节的效率并降低 TCO 等方面，起到很大作用。

可观测性

不管是容器、Serverless 还是 Service Mesh，监控、日志还是链路追踪，真正在生产环境中部署还需要可观测性的支撑。由于传统主机和 K8s 在很多方面存在较大差异，如何搭建一套适合云原生的可观测性体系是企业发展道路上必须面对的问题。

对于 K8s 集群下的 Pod 日志采集，目前主要分为 DaemonSet 和 Sidecar 两个流派，不同的 Agent 部署方式在用户体验和运维形态上有较大区别。对业务应用部署方式是否有侵入，使用 emtyDir、hostPath 还是 pv 来挂载日志目录，如何注入 K8s 的 namespace、Pod 等元信息，对下游带来的吞吐压力如何等，很多没有相关经验的企业都被这些问题困扰，而社区始终没有统一的答案。

相比日志的百花齐放，Prometheus 提供了比较统一和标准化的监控，基于各类 Exporter、AlertManager 和 Grafana 生态搭建一个基础的云原生监控平台对很多企业来说挑战不算大，甚至能够进一步在 Prometheus-Operator 的基础上加速达到更加云原生化的体验。但大部分企业长期停留在了这一阶段，基本可用和期望中的稳定、易用、智能化存在一定距离。

统一的可观测性平台能够将 log、monitor 和 trace 结合起来，这对很多企业都有很大的吸引力。国内外云厂商和提供可观测性服务的公司，一直在可观测性的融合上发力，同时 CNCF 在持续推行 OpenTelemetry 及其标准，也在这个方向添了一把火。

一定程度上，可观测性更多是关于组织的文化转变，而不仅仅是使用行业正在融合的一些技术、工具和平台。

写在最后

回顾这一年，云原生技术稳步发展，也更加注重解决落地实践上遇到的具体问题，未来方向也是如此。我们期待 2022 年云原生领域有更多的技术进展，整个生态更加繁荣。

采访嘉宾介绍（按姓名首字母排序）：

傅轶，网易数帆架构师，轻舟日志平台负责人；
黄玉奇（花名：徙远），阿里云高级技术专家，Kubernetes Member，CNCF 边缘计算云原生项目 OpenYurt 负责人；
彭涛，同程旅行容器云平台负责人、架构师，Kubernetes Flink 代码贡献者；
彭锋，智领云联合创始人兼 CEO，拥有 20 余年软件开发、大数据及云计算经验；
宋净超（Jimmy Song），Tetrate 布道师，云原生社区创始人；
马若飞，Freewheel 首席工程师，《云原生应用架构》作者，AWS container hero；
汤志敏，阿里云资深技术专家，目前负责阿里云容器技术相关后端产品和研发工作。

12月27日晚上8点，我们邀请了阿里云资深技术专家、云原生应用平台产品负责人李国强（崭岩）做客 InfoQ 视频号，详细解读云原生领域在2022年，有哪些值得关注的趋势。2021 InfoQ 年度技术展望直播周将在元旦前后两周持续输出精彩内容，关注 InfoQ 视频号，与行业技术大牛连麦~

如果你对云原生技术的发展有其他观察和看法，欢迎在文末留言，或点击【阅读原文】加入 InfoQ 写作平台话题讨论。

后续，迷你书、专题将集合发布与 InfoQ 官网，登录 InfoQ 官网：https://www.infoq.cn/ 注册并将 InfoQ 添加进收藏夹，精彩不错过。

我们还准备了 2021 年度技术盘点交流群，欢迎各位小伙伴进群讨论！