疫情中的2021，云原生会走向哪里

头图 | 付费下载于视觉中国 

翻译 | Daixiang（华为云原生团队）

作者 | Chris Aniszczyk（CNCF CTO）

 

近日，CNCF发布了2020年云原生领域所有工作的年度总结[1]，在疫情流行的形势下，我们度过了坚实的一年，希望读者朋友们阅读该报告。本文将分享我对云原生在2021年及以后发展方向及趋势的想法。

云原生IDE

未来，开发生命周期（代码、构建、调试）将主要发生在云上，而不是本地Emacs或VSCode。每个PR都会有完整的开发和部署环境，以满足开发和调试的需求。

目前，GitHub代码空间和GitPod都是这一技术的具体示例。虽然GitHub代码空间还在测试阶段，但您可以尝试使用GitPod。以Prometheus为例，在大约一分钟左右的时间里，您就拥有了一个完整的在线开发环境，包括编辑器和预览环境。最疯狂的是，这个开发环境（工作区）是用代码来描述的，并且像其他代码中间件一样可以与团队中的其他开发人员共享。 

我期望未来能看到云原生IDE继续不可思议的创新，特别是GitHub代码空间结束测试阶段被广泛使用，这样开发者就可以体验到这个新概念并爱上它。

边缘Kubernetes

Kubernetes诞生于海量数据中心，但Kubernetes会像Linux一样演进到新的环境。Linux的最终结果是，最终用户扩展了内核，以支持不同领域下各种新的部署方案，包括移动端、嵌入式等。

我坚信Kubernetes会经历类似的演进，我们已经看到运行商（和初创企业）将Kubernetes作为边缘平台，通过KubeEdge、k3s、k0s、LFEdge、Eclipse ioFog等开源项目将VNF改造成CNFs(Cloud Native Network Function) 。超大规模云对运营商和边缘场景的支持，对云原生软件的复用能力，以及基于目前庞大的云原生生态系统的构建能力，这些推动力都在巩固着Kubernetes在未来几年作为边缘计算的主导平台的地位。

云原生+WASM

Web汇编（WASM）是一项刚刚起步的技术，但我希望它能成为云原生生态系统中日益重要的角色，特别是随着WASI的成熟，以及Kubernetes更多被用作上文描述的边缘协同器。一个用例是为扩展机制提供动力，就像LuaJIT和Envoy所做的那样。与其直接处理Lua，您可以使用支持多种编程语言的小型优化运行时。

Envoy项目目前正处于采用WASM的征程中，我期望任何环境都遵循类似的模式，而作为流行扩展机制的脚本语言，将来会被WASM完全取代。

在Kubernetes方面，有一些像微软的Krustlet这样的项目正在探索如何在Kubernetes中支持基于WASI的运行时。这应该不会太令人惊讶，因为Kubernetes已经通过CRD和其他机制来扩展，以运行不同类型的工作负载，比如VM (KubeVirt)等。另外，如果您是WASM的新手，我推荐这门来自Linux基金会的入门课程：

https://www.edx.org/course/introduction-to-webassembly-runtime。

FinOps 的崛起（CFM）

新型冠状病毒的爆发加速了向云原生的转变，至少有一半的公司正在危机中加速他们的云计划……近60%的受访者表示，由于COVID-19大流行（2020年云状况报告https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020），云使用率将超过先前的计划。最重要的是，云财务管理（FinOps）是一个日益增长的问题，也是许多公司所关心的问题。

老实说，在过去六个月中，我和一些公司在云原生旅程中进行了大约一半的讨论。你也可以说，云提供商并没有被激励去简化云财务管理，因为那样会让客户更轻松地减少开支。真正痛苦的是云财务管理缺乏开源创新和标准化（所有云的成本管理方式都不一样），CNCF中没有多少开源项目试图让FinOps更简单，目前的KubeCost项目还很年轻。

 此外，Linux基金会最近推出了FinOps基金会，推动该领域的创新，他们在这个领域有许多介绍材料值得一读（https://www.edx.org/course/introduction-to-finops）。我希望在未来几年里，在FinOps领域看到更多的开源项目和规范。

更多的云原生Rust项目

Rust仍然是一种年轻而小众的编程语言，特别是如果你以Redmonk的编程语言排名为例。然而，我的感觉是，在未来一年，你会看到Rust在更多的云原生项目中，因为已经有少数CNCF项目开始利用Rust的优势，如microvm Firecracker。虽然CNCF目前绝大部分的项目是用Golang编写的，但我期望在Rust社区成熟后的几年内，基于Rust的项目将与基于Go的项目持平。

GitOps + CD/PD大幅增长

GitOps是云原生技术的运营模型，提供一套统一应用部署、管理和监控的最佳实践（最初由来自Weaveworks的Alexis Richardson提出）。

GitOps最重要的方面是描述通过声明方式在Git中进行版本化的期望系统状态，这实际上使一组复杂的系统更改能够正确应用，然后进行验证（通过Git和其他工具启用的审计日志）。

从实用的角度来看， GitOps提升了开发者体验，随着Argo、GitLab、Flux等项目的不断增长，我预计GitOps工具今年将会对企业产生更多冲击。如果你看看GitLab的数据，GitOps仍然是一个新兴的实践，大多数公司尚未探索它，但随着越来越多的公司开始大规模采用云原生软件，GitOps的发展自然会如我所言。

服务目录2.0：云原生开发者看板

服务目录的概念并不是什么新东西，对于我们这些在ITIL时代长大的老人们来说，你可能会记得CMDB之类的东西，但是随着微服务的兴起和云原生的发展，对服务和各种实时服务元数据进行编目和索引的能力对于推动开发人员自动化至关重要。这可能包括使用服务目录来了解处理事件管理、管理SLO等的所有权。

将来，您将看到开发人员仪表板不仅仅是一个服务目录，而且能够通过各种自动化功能来扩展。典型的开源例子是Lyft的Backstage和Clutch，但是，任何应用云原生的公司往往都有一个试图构建类似的东西的平台基础架构团队。随着拥有大型插件生态系统的开源仪表盘的成熟，您将会看到越来越多平台工程团队加速使用他们。

跨云不再是梦想

Kubernetes和云原生运动已经证明，在生产环境中，云原生和多云方法是可能的。数据表明，93%的企业有使用微软、亚马逊和谷歌等多个云厂商的服务（2020年云状况报告https://info.flexera.com/SLO-CM-REPORT-State-of-the-Cloud-2020）。

随着云市场的不断成熟，Kubernetes有望开启编程式的跨云管理服务。一个具体例子体现在Crossplane项目中，它利用Kubernetes API的扩展性，提供一个开源的跨云控制平面，实现跨云工作负载管理（参见https://thenewstack.io/gitlab-deploys-the-crossplane-control-plane-to-offer-multicloud-deployments）。

eBPF成为主流

eBPF允许您在Linux内核中运行程序，而无需更改内核代码或加载模块，您可以将其视为沙箱扩展机制。eBPF允许新一代软件扩展Linux内核的行为，以支持各种不同的功能，包括改进的网络、监控和安全。eBPF的缺点是，它需要一个高版本的内核版本来利用它，而且在很长一段时间里，这对许多公司来说并不是一个现实的选择。

然而，情况正在改变，甚至较新版本的RHEL开始支持eBPF ，您将看到更多的项目使用它。如果你看看Sysdig的最新容器报告（https://sysdig.com/blog/sysdig-2021-container-security-usage-report/），你可以看到利用eBPF进行容器安全检查的Falco使用率正在大幅增长。因此，请继续关注并寻找更多基于eBPF的项目！

相关链接：

[1] CNCF 2020年度报告原文： 

https://www.cncf.io/blog/2020/12/29/2020-cncf-annual-report

更多阅读推荐

• 分布式架构的王者？Kubernetes凭什么

• Mendix入局中国低代码，开发者们你准备好了吗

• 信息如何实现病毒式传播？一文看懂Gossip协议

• 看穿容器的外表，Linux容器实现原理演示

• 用三国杀讲分布式算法，舒适了吧？

• 云原生体系下的技海浮沉