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

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

[[379818]]

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

云原生IDE

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

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

邊緣側(cè)Kubernetes

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

云原生 + Wasm

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

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

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

FinOps崛起(CFM)

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

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

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

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

GitOps + CD/PD顯著增加

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

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

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

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

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

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

主流eBPF

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