【編者的話】本文作者利用自己云原生工程師的優(yōu)勢，分享了他對2021年及之后的云原生發(fā)展趨勢的看法，包括云原生IDE、邊緣側(cè)Kubernetes、云原生 + Wasm、FinOps崛起、更多的Rust出現(xiàn)在云原生、GitOps + CD/PD顯著增加、服務(wù)目錄2.0：云本地開發(fā)人員儀表盤、交叉云、主流eBPF等等。

我希望每個(gè)人都度過了一個(gè)美好的假期，因?yàn)?021年1月的頭幾周非常瘋狂，從叛亂到新冠病毒。在云原生（Cloud Native）領(lǐng)域，CNCF最近發(fā)布了年度報(bào)告，包含我們?nèi)ツ晖瓿傻乃泄ぷ?。我建議每個(gè)人有機(jī)會都看一看這份報(bào)告，考慮到病毒大流行的情況，我們度過了頗有收獲的一年。

云原生作為我工作的一部分，相比我共事過的公司和開發(fā)人員，我有獨(dú)特的優(yōu)勢，所以我想分享一下我對2021年及以后的云原生發(fā)展趨勢的看法。

云原生IDE

作為一個(gè)在Eclipse Foundation中花了相當(dāng)一部分時(shí)間在開發(fā)人員工具上的人，我對最新的技術(shù)進(jìn)展感到非常興奮。未來的開發(fā)生命周期（代碼、構(gòu)建、調(diào)試）將主要發(fā)生在云上，而不是你本地的Emacs或VSCode設(shè)置中。最終，你將為每個(gè)pull請求獲得一個(gè)完整的開發(fā)環(huán)境設(shè)置，預(yù)先配置并連接到它們自己的部署，以幫助你開發(fā)和調(diào)試需求。這個(gè)技術(shù)的一個(gè)具體例子是通過GitHub Codespaces和GitPod實(shí)現(xiàn)的。雖然GitHub的Codespaces還在測試階段，但是你可以用GitPod來體驗(yàn)一下，比如Prometheus。在一分鐘左右的時(shí)間內(nèi)，你就擁有了一個(gè)具有編輯器和預(yù)覽環(huán)境的完全實(shí)時(shí)開發(fā)環(huán)境。這個(gè)開發(fā)環(huán)境（工作區(qū)）是用代碼描述的，并且可以像其他代碼工件一樣與團(tuán)隊(duì)中的其他開發(fā)人員共享。

最后，我希望在明年看到云原生IDE領(lǐng)域驚人的創(chuàng)新，特別是隨著GitHub Codespaces進(jìn)入測試階段，并變得更廣泛可用，這樣開發(fā)者就可以體驗(yàn)這個(gè)新概念并愛上它。

邊緣側(cè)Kubernetes

Kubernetes是通過大規(guī)模數(shù)據(jù)中心的使用而誕生的，但Kubernetes將會像Linux在新環(huán)境中所做的那樣不斷發(fā)展。Linux的情況是，最終用戶擴(kuò)展了內(nèi)核，以支持各種新的部署場景，包括移動部署、嵌入式部署等等。我堅(jiān)信Kubernetes將經(jīng)歷類似的演變，我們已經(jīng)看到電信公司（和初創(chuàng)公司）通過將VNFs轉(zhuǎn)換為云原生網(wǎng)絡(luò)功能（CNFs），以及k3s、KubeEdge、k0s、LFEdge、Eclipse ioFog等開源項(xiàng)目，將Kubernetes作為邊緣平臺進(jìn)行探索。推動超規(guī)模云支持電信公司和edge的力量，加上重用云本地軟件的能力，以及在已經(jīng)龐大的生態(tài)系統(tǒng)上構(gòu)建的能力，將在未來幾年鞏固Kubernetes在邊緣計(jì)算領(lǐng)域的主導(dǎo)平臺地位。

云原生 + Wasm

Web Assembly（Wasm）是一項(xiàng)剛剛起步的技術(shù)，但我預(yù)計(jì)它將成為本地云生態(tài)系統(tǒng)中日益增長的實(shí)用程序和工作負(fù)載，特別是隨著WASI的成熟以及Kubernetes更多地用作前面所述的邊緣協(xié)調(diào)器。一個(gè)用例是支持?jǐn)U展機(jī)制，就像Envoy使用過濾器和LuaJIT所做的那樣。與直接處理Lua不同，你可以使用支持多種編程語言的更小的優(yōu)化運(yùn)行時(shí)。Envoy項(xiàng)目目前正處于采用Wasm的過程中，我希望在任何環(huán)境中都能遵循類似的模式，即腳本語言是一種流行的擴(kuò)展機(jī)制，將來會被Wasm全盤取代。

在Kubernetes的前沿，有一些項(xiàng)目，比如來自微軟的Krustlet，正在探索如何在Kubernetes中支持基于wasi的運(yùn)行時(shí)。這并不奇怪，因?yàn)镵ubernetes已經(jīng)通過CRDs和其他機(jī)制進(jìn)行了擴(kuò)展，以運(yùn)行不同類型的工作負(fù)載，如VM （KubeVirt）等。

另外，如果你是Wasm的新手，我推薦這門來自Linux Foundation的新入門課程以及excellection文檔。

FinOps崛起（CFM）

冠狀病毒的爆發(fā)加速了云本地的轉(zhuǎn)變。在危機(jī)期間，至少有一半的公司正在加快其云計(jì)算計(jì)劃……近60%的受訪者表示，由于COVID-19大流行，云計(jì)算使用量將超過之前的計(jì)劃（2020年云計(jì)算狀況報(bào)告）。除此之外，云財(cái)務(wù)管理（或稱FinOps）是許多公司日益關(guān)注的問題，在我過去6個(gè)月與正在進(jìn)行云原生旅程的公司的討論中，有一半都提到了這個(gè)問題。你也可以認(rèn)為云提供商不鼓勵(lì)簡化云財(cái)務(wù)管理，因?yàn)檫@樣客戶將會花費(fèi)更少，然而，在我看來，圍繞云財(cái)務(wù)管理，真正的痛苦是缺乏開源創(chuàng)新和標(biāo)準(zhǔn)化（每家公司做的云成本管理都不同）。在CNCF環(huán)境中，沒有多少開源項(xiàng)目試圖使FinOps變得更容易，有個(gè)KubeCost項(xiàng)目，但它還處于相當(dāng)早期的階段。

另外，Linux基金會最近啟動了“FinOps基金會”來幫助這個(gè)領(lǐng)域的創(chuàng)新，他們在這個(gè)領(lǐng)域有一些很好的介紹性材料。我希望在未來幾年里在FinOps領(lǐng)域看到更多的開源項(xiàng)目和規(guī)范。

更多的Rust出現(xiàn)在云原生

Rust仍然是一門年輕的編程語言，特別是當(dāng)你以Redmonk的編程語言排名為例時(shí)。然而，我的感覺是，在接下來的一年里，你會在更多的云原生項(xiàng)目中看到Rust，因?yàn)橐呀?jīng)有一些利用Rust的CNCF項(xiàng)目出現(xiàn)在有趣的基礎(chǔ)設(shè)施項(xiàng)目中，比如microvm Firecracker。雖然CNCF目前絕大多數(shù)的項(xiàng)目是用Golang編寫的，但我希望隨著Rust社區(qū)的成熟，在幾年內(nèi)基于Rust的項(xiàng)目能夠與基于Go的項(xiàng)目相媲美。

GitOps + CD/PD顯著增加

GitOps是云本地技術(shù)的操作模型，提供了一套統(tǒng)一部署、管理和監(jiān)控應(yīng)用程序的最佳實(shí)踐（最初由來自Weaveworks的Alexis Richardson創(chuàng)造）。GitOps最重要的方面是通過聲明的方式描述所需的在Git中版本化的系統(tǒng)狀態(tài)，這本質(zhì)上允許正確應(yīng)用一組復(fù)雜的系統(tǒng)更改，然后驗(yàn)證（通過Git和其他工具啟用的漂亮的審計(jì)日志）。從實(shí)用的角度來看，GitOps改善了開發(fā)者的體驗(yàn)，隨著Argo、GitLab、Flux等項(xiàng)目的發(fā)展，我預(yù)計(jì)GitOps工具今年將更多地沖擊企業(yè)。如果你看看來自GitLab的數(shù)據(jù)，你會發(fā)現(xiàn)，GitOps仍然是一個(gè)新興的實(shí)踐，大多數(shù)公司還沒有探索它，但隨著越來越多的公司開始大規(guī)模采用云本地軟件，在我看來，GitOps將會自然而然地跟進(jìn)。如果你有興趣了解更多關(guān)于這個(gè)領(lǐng)域的信息，我建議你查看CNCF中新成立的GitOps工作組。

服務(wù)目錄2.0：云本地開發(fā)人員儀表盤

服務(wù)目錄的概念并不新鮮，對于我們這些在ITIL時(shí)代長大的老年人來說，可能還記得CMDB（恐怖）之類的東西。然而，隨著微服務(wù)和云原生開發(fā)的興起，記錄服務(wù)和索引各種實(shí)時(shí)服務(wù)元數(shù)據(jù)的能力對于推動開發(fā)人員自動化至關(guān)重要。這可以包括使用服務(wù)目錄來了解所有權(quán)，以處理事件管理、管理SLO等。

在未來，你將看到開發(fā)人員儀表盤的趨勢，它不僅是一個(gè)服務(wù)目錄，還提供了通過各種自動化特性在一個(gè)地方擴(kuò)展儀表盤的能力。最典型的開源例子是來自Lyft的Backstage和Clutch，然而，任何擁有相當(dāng)現(xiàn)代的本地云部署的公司都傾向于擁有一個(gè)平臺基礎(chǔ)架構(gòu)團(tuán)隊(duì)，試圖構(gòu)建類似的東西。伴隨著一個(gè)大型插件生態(tài)系統(tǒng)，開源開發(fā)人員儀表盤將更成熟，你將看到各地的平臺工程團(tuán)隊(duì)加速采用儀表盤。

交叉云變得更加現(xiàn)實(shí)

Kubernetes和云本地運(yùn)動已經(jīng)證明了云本地和多云方法在生產(chǎn)環(huán)境中是可能的，數(shù)據(jù)清楚地表明“93%的企業(yè)有一個(gè)戰(zhàn)略，使用多個(gè)供應(yīng)商，如微軟Azure、亞馬遜Web服務(wù)和谷歌云”（2020年云報(bào)告狀態(tài)）。Kubernetes多年來隨著云市場的成熟，有望開啟可編程的跨云管理服務(wù)。這種方法的一個(gè)具體例子體現(xiàn)在Crossplane項(xiàng)目中，該項(xiàng)目提供了一個(gè)開源的跨云控制平面，利用Kubernetes API的可擴(kuò)展性來支持跨云工作負(fù)載管理（參見《GitLab部署跨云控制平面來提供多云部署》）。

主流eBPF

eBPF允許你在Linux內(nèi)核中運(yùn)行程序，而無需更改內(nèi)核代碼或加載模塊，你可以將其視為一種沙箱擴(kuò)展機(jī)制。eBPF允許新一代軟件擴(kuò)展Linux內(nèi)核的行為，以支持改進(jìn)的網(wǎng)絡(luò)、監(jiān)控和安全等各種不同的東西。從歷史上看，eBPF的缺點(diǎn)是它需要一個(gè)現(xiàn)代的內(nèi)核版本來利用它，在很長一段時(shí)間里，這對許多公司來說都不是一個(gè)現(xiàn)實(shí)的選擇。然而，情況正在發(fā)生變化，甚至RHEL的新版本最終也支持eBPF，因此你將看到更多的項(xiàng)目從中受益。如果你看一下Sysdig最新的容器報(bào)告，你會發(fā)現(xiàn)Falco的使用率最近有所上升，盡管該報(bào)告可能有點(diǎn)偏向Sysdig，但它反映在生產(chǎn)使用中。所以請繼續(xù)關(guān)注并期待未來更多基于eBPF的項(xiàng)目！
責(zé)編AJX