隨著容器技術大行其道，應用的複雜性只增不減，開發者們開始廣泛使用更先進的工具，比如 Kubernetes。目前 Kubernetes 已經不年輕了，開始逐漸開始 boring，你可能會想問 Kubernetes 之後還有什麼令人興奮的新技術。但云計算是一個快速發展的領域，不太容易精準預測下一個令人興奮的新技術，不如我們將目光聚焦到目前雲計算沒有完全覆蓋的細分領域。
微型虛擬機器 (MicroVM)
在 Kubernetes 之後，有一個前景廣闊的雲技術可能會被廣泛接受，即微型虛擬機器 (MicroVM)。微型虛擬機器與容器的區別在於它不與宿主機共用核心，擁有自己的微核心，提供了與虛擬機器一樣的硬體虛擬化安全性。虛擬機器抽象了記憶體、CPU、網路、儲存和其他計算資源，而微型虛擬機器是圍繞應用程式來對資源進行抽象，只抽象了必要的資源，所以更加高效。
目前最受歡迎的微型虛擬機器就是 AWS Firecracker [1] ，它使用 Rust 語言編寫，記憶體開銷極低，將微型虛擬機器打包到 Kubernetes 叢集中，以提高工作負載的安全性和隔離性。AWS 目前正使用 Firecracker 作為 Serverless 的基礎單元，冷啟動時間延遲極低。
Weaveworks 也開源了一個基於 Firecracker 的虛擬機器管理器 Ignite [2] ，將 Firecracker MicroVM 與 Docker/OCI 映象結合起來，統一了容器和虛擬機器。它以 GitOps 的方式工作，可以像 Kubernetes 和 Terraform 一樣宣告式管理虛擬機器。
還有一些其他專案，例如 slim [3] ，旨在從 Dockerfile 重新構建和執行微型虛擬機器。它的工作原理是從 Dockerfile 中構建並提取 rootfs，然後將該檔案系統與一個線上 RAM 中執行的微核心合併。
隨著越來越多的應用程式被遷移到雲端，以及越來越多的圍繞 5G 技術建立的新業務解決方案，微型虛擬機器將會發揮至關重要的作用。
高效能 WebAssembly
自從 1995 年 Netscape 公司推出 JavaScript 之後，很長一段時間它都是唯一的網路程式語言。之後人們提出了很多替代方案，但都沒有成功，這些替代方案要麼不支援跨平臺，要麼需要瀏覽器外掛。因此，縱然 JavaScript 有它的缺陷性，還是變成了世界上最流行的程式語言之一。
WebAssembly 的出現打破了這個僵局，嚴格來說，它不是一種程式語言，而是一種二進位制指令集。因此它對 JavaScript 沒有威脅，也無意取代 JavaScript，它可以和 JavaScript 協同工作，你也可以將 JavaScript 編譯成 WebAssembly 二進位制格式。
但 WebAssembly 的潛力不僅侷限於瀏覽器層面，全球著名的 CDN 廠商 Fastly 的 CTO 之前在一個影片中完美闡述了 WebAssembly 的價值：
虛擬機器模擬了完整的計算機；容器模擬了完整的作業系統；WebAssembly 僅僅模擬了程序。
容器大家都比較熟悉，它只模擬了完整作業系統的使用者空間，不包含核心空間，也不包含硬體相關的抽象。但是對於微服務和 Serverless 而言，它仍然很重，我只需要啟動一個程序，你卻讓我先啟動一個完整的作業系統再啟動程序。
這時候 WebAssembly 的價值就體現出來了，你只需要啟動一個程序，而我恰好就啟動了程序，沒有作業系統，也沒有硬體虛擬化，只有孤單的程序，只是這個程序被放入了 WebAssembly 的沙盒中。
看到了這一點，眾多工程師開始發揮自己的無限想象力，比如將 WebAssembly 作為 Kubernetes 的 CRI 執行時，代替容器以適應 Serverless 場景。
目前大約有 40 高階程式語言開始支援 WebAssembly，包括 C、C++、Python、Go、Rust、Java 和 PHP，未來可期。
輕量級 Kubernetes 發行版
為了避免 Kubernetes 的安裝部署過於複雜，越來越多的人更願意使用 Kubernetes 的閹割版本，即輕量版。像 K3s [4] 這樣的輕量級發行版更容易透過命令列安裝，它提供了更輕量級的儲存後端，並且所有的元件都打包在一個單一的可執行檔案中，體積更小。由於它只需要極低的資源就可以執行，因此它能夠在任何地方 512MB 記憶體以上的裝置上執行叢集。
邊緣計算與物聯網
伴隨著輕量級 Kubernetes 發行版的發展，適用於邊緣計算和物聯網場景的 Kubernetes 發行版也嶄露頭角，例如 KubeEdge [5] ，提供了邊緣計算所需的輕量級和邊緣自治能力。但 KubeEdge 缺少雲端控制層面的支援，將混合雲容器平臺 KubeSphere [6] 與 KubeEdge 結合，可以解決邊緣節點納管、邊緣工作負載排程和邊緣可觀測性等難題，結合 KubeSphere 已有的多叢集管理將混合多雲管理延伸至邊緣側。
多叢集管理
雖然目前 Kubernetes 中有很多工具可以隔離多租戶工作負載，但有時出於安全與合規原因，使用叢集作為邊界來隔離團隊和應用程式更有意義。
隨著越來越多的團隊和組織在各個雲中執行多個 Kubernetes 叢集，對多個 Kubernetes 叢集的管理和控制變得愈發艱難，像 CiliumMesh [7] 、 Submariner [8] 、 Skupper [9] 、 Istio [10] 和 KubeSphere [11] 這樣的多叢集管理工具將使多叢集 Kubernetes 環境的管理更加方便和高效。
多叢集的另一個好處是減少叢集故障的影響範圍，如果你有強隔離的要求，可以考慮使用多叢集。此外，多叢集也能簡化操作流程，比如在同一個控制平面進行排程和升級。KubeSphere 目前已經支援將工作負載得多個副本按不同比例靈活分發到多個叢集。
跨叢集備份容災
隨著雲原生對 IT 產業的重新洗牌，很多傳統的技術在雲原生的場景下已經不再適用，譬如備份和容災。傳統的備份容災還停留在資料搬運的層次上，備份機制比較固化，以儲存為核心，無法適應容器化的彈性、池化部署場景；而云原生的核心是服務本身，不再以儲存為核心，使用者需要更貼合容器場景的備份容載能力，利用雲原生的編排能力，實現備份容災的高度自動化，同時靈活運用雲原生的彈效能力按需付費，降低成本。
