面對 Kubernetes 存在的問題以及混合雲旺盛的市場需求。各大公有云廠商紛紛推出自己的混合雲容器服務，一時間，各類產品和解決方案讓人眼花繚亂。在各具優勢的混合雲容器產品中該如何選擇？只要弄清楚混合雲容器服務背後的技術路線，便有助於指導開發者痛苦的技術選型之路。

基於 Kubernetes 的開源專案到底香不香？

當前的混合雲容器服務大致可分為兩類，一類是基於 Kubernetes 的，另一類是不基於 Kubernetes 的自研專案。由於 Kubernetes 已成為容器編排和排程的事實標準，因此，前者是當之無愧的主流。近年來，各大公有云廠商也都先後開源了各自基於 Kubernetes 的混合雲容器服務。這類服務的技術路線主要分為兩類。

第一種是在 Kubernetes 的基礎做減法，打造輕量級的容器編排服務，比較典型的產品 K3s。

K3s 是由 Rancher Lab 於 2019 年推出的輕量級 Kubernetes 發行版。K3s 的名字來源於 K8s-5。為減少 Kubernetes 所需記憶體，Rancher K3s 刪除了舊的、非必須的程式碼、整合正在執行的打包程序、使用 containerd 代替 Docker 作為執行時的容器引擎，此外引入 SQLite 作為可選的資料儲存。從而使得其更好的適配 CI、ARM、邊緣環境、物聯網和測試這五個場景。K3s 所有元件均執行在邊緣，因此不涉及雲邊協同，但從生產的角度 K3s 缺少叢集管理方案，負責跨叢集應用管理、監控等，然而遺憾的是 Rancher 並未對這部分能力進行開源。

以 K3s 為代表的輕量級容器編排產品適合執行在邊緣計算場景中。現有的 Kubernetes 發行版本通常是記憶體密集型的，在邊緣計算環境中顯得過於複雜。這類產品通過降低記憶體，使其能夠在邊緣場景中更好的部署，此外，在邊緣計算場景下，企業需要運維管理的 Kubernetes 叢集數量非常龐大，且通常只有很少量的節點，因此運維人員需要負責大規模的基礎架構。通過這類輕量級容器編排產品，可最大限度的簡化使用者的安裝和操作步驟，降低運維難度。

第二種是對現有的 Kubernetes 架構做出一些改進。在此技術路線下比較具有代表性的開源產品是 KubeEdge 和 OpenYurt。

在目前的 Kubernetes 架構中，整個控制平面跟資料平面對網路要求比較高，因此這類技術路線對場景進行了一些改進，這兩種產品都是在中間提供了一個代理層去維護以及保證不穩定環境下仍能夠提供相對來說比較穩定的運用環境。

KubeEdge 是 2018 年開源的一個邊緣計算平臺，目前由 CNCF 孵化的專案。該專案在 Kubernetes 原生的容器編排和排程能力之上，擴充套件實現來了雲邊協同、計算下沉、海量邊緣裝置管理、邊緣自治等能力。從架構上來看雲端（K8s master) 增加了 Cloud Hub 元件和各類 controller，而在邊緣的（K8s worker) 則是對原生元件進行了重寫 EdgeCore 元件，從架構圖可以看出 EdgeCore 是基於 Kubelet 重構的，為保證輕量化，裁剪了原生 Kubelet 的部分能力，增加了很多適配邊緣場景的能力。儘管相比 Kubernetes，KubeEdge 的確能夠更好的適配邊緣場景，但由於架構的差異，不可避免會帶來一些影響，如對於雲原生生態的相容性將下降。

OpenYurt 相比於 KubeEdge 的開源要稍晚一些，但是它採用非侵入的方式對 Kubernetes 進行增強，即在 Kubernetes 上做加法。在雲端 (K8s Master) 上增加 YurtController ManagerYurtApp Manager 以及 Tunnel Server 元件。而在邊緣端 (K8sWorker) 上增加了 YurtHub 和 TunnelAgent 元件。相比於 Kubernetes，OpenYurt 提升了邊緣單元化、邊緣自治、雲邊協同等能力。同時並未像損失對於雲原生生態的相容能力。然而由於 OpenYurt 始終是在原有架構上做加法，因此輕量化難以保證，此外，原生 Kubernetes 所存在的邊緣節點過多可能導致系統不穩定的問題也依舊存在，並未得到解決。

基於 Kubernetes 的開源專案到底香不香？不可否認，在特定場景如邊緣計算領域，他們彌補了原生 Kubernetes 的不足。但在做出優化的同時，通常也會產生新的問題。由於這兩種技術路線都是在 Kubernetes 架構上做出一些改進，因此均會在不同程度上產生架構差異帶來的影響。此外，由於部分專案對 Kubernetes 系統的入侵式修改，後續跟隨 Kubernetes 社群的演進將會面臨很大的挑戰。

原汁原味保留 Kubernetes 架構，實現效能的優化

既然架構的改進會帶來架構差異的影響，那麼是否可以沿用原汁原味的 Kubernetes 架構？Amazon EKS Anywhere 為 Kubernetes 生態提供了一種全新的思路。

亞馬遜雲科技於今年 9 月全面推出 Amazon EKS Anywhere。Amazon EKS Anywhere 完全採用原生 Kubernetes 架構，不進行任何改動，僅僅在原有基礎上新增一些管理跟維護工具，使其能夠完全相容並且更加方便的部署在使用者自己的資料中心裡。

Amazon EKS Anywhere 是 Amazon EKS 的最新部署選項，以往 Amazon EKS 只能在亞馬遜自己的雲環境之下實現基礎設施相容，但通過 Amazon EKS Anywhere 使用者可以在自有基礎設施上執行 Amazon EKS。因此，Amazon EKS Anywhere 更適合那些已經擁有、並打算繼續使用大規模本地基礎設施的企業使用者。

Amazon EKS Anywhere 通過預設元件配置幫助簡化本地 Kubernetes 叢集的建立和運維，同時提供可實現叢集管理自動化的工具。它是基於 Amazon EKS Distro 的優勢構建的，後者是為亞馬遜雲科技上的 Amazon EKS 提供支援的同一個 Kubernetes 發行版本。亞馬遜雲科技支援所有 Amazon EKS Anywhere 元件，包括整合的第三方軟體，從而讓使用者能夠降低支援成本，同時無需維護冗餘的開源和第三方工具。

此外，Amazon EKS Anywhere 為使用者提供與 Amazon EKS 一致的本地 Kubernetes 操作工具。開發者可以利用 EKS 控制檯通過 EKS 聯結器檢視在任何位置執行的所有 Kubernetes 叢集（包括 EKS Anywhere 叢集）。

雖然 Amazon EKS Anywhere 擁有眾多優勢，但也存在一些限制。根據亞馬遜雲科技目前的官方表述，Amazon EKS Anywhere 還僅適用於在本地使用 VMware vSphere 的自有基礎設施上部署， 對於其它的部署目標如裸金屬環境，將在 2022 年提供支援。另外 Amazon EKS Anywhere 的定位是用於本地資料中心的部署，沒有提供對其它公有云部署的支援。

Kubernetes 生態之外的混合雲容器服務

不過，基於 Kubernetes 研發的 Amazon EKS Anywhere 雖然已經在使用門檻上做了大量的工作，在架構層面具有低侵入性的優勢，但從根本來看，EKS 依然是基於 Kubernetes 的，特徵十分鮮明。對於開發者而言，依然存在較高的入門門檻。

如果企業團隊對 Kubernetes 不甚熟悉，或者沒有時間調研、學習 Kubernetes，又該如何應對混合雲環境下的容器編排和治理問題呢？亞馬遜雲科技於今年 5 月推出的 Amazon  ECS Anywhere，或許能成為另外一個答案。

據介紹，Amazon ECS 是第一項由亞馬遜雲科技管理的容器編排服務。為使用者提供一套易於使用控制平面，可通過虛擬機器例項（Amazon EC2) 或完全無伺服器（Amazon Fargate) 形式輕鬆執行各種容器型工作負載，同時與其他亞馬遜雲科技的託管服務實現原生整合，進而提供服務網格，日誌記錄、指標捕捉等增強功能。

Amazon ECS Anywhere 功能的出現，使得使用者能夠在非亞馬遜環境中部署各類 Amazon ECS 任務。以此為基礎，客戶能夠在特定亞馬遜區域之內利用同一套易於使用的管理層定義並管理叢集內的一切資源，而無需考慮叢集位於哪裡，執行環境如何。

相比於 Kubernetes 最重要的區別是 Amazon ECS 功能更加強大，而且更加簡單易用。儘管 Kubernetes 開源產品生態非常繁榮，但是帶來的問題非常複雜，學習曲線比較陡峭，Amazon ECS 非常簡單易用且跟雲上面很多產品結合非常緊密，用起來很方便。

此外，Amazon ECS Anywhere，非常適合在邊緣計算或者使用者計算資源比較受限制的場景下使用，非常輕便、靈活，沒有太多對於硬體，或者資源方面、網路方面特別嚴格的要求，所以應用的場景非常多。

從 2021 年起，所有云環境下的開發者，已經不能忽視雲邊端一體化的大趨勢，未來將有超過 50% 的資料跑在各型別的  IoT 終端上，Amazon ECS Anywhere 是對這種趨勢的擬合與最佳適配。

此外，開發者只需將 Amazon ECS Anywhere 部署在亞馬遜基礎設施之外的容器服務當中，使用 External 啟動型別，就能使同 Amazon 區域中 Amazon ECS 叢集內的雲服務實現類似同一環境下的彼此互動，並且，外部容器負載還能充分發揮所處物理位置上本地的方式為系統服務，藉此實現內部視訊檔案的規模化處理等以往難以在雲端完成的高強度工作。

由於 Amazon ECS Anywhere 強調基礎設施的完全中立性，因此只要開發者制定的作業系統能夠執行 Amazon ECS 和 System Manager 代理，即可對各類機器或裝置進行註冊，極低的註冊門檻有助於幫助開發者輕鬆在亞馬遜環境之外，包括邊緣位置部署微服務用例，完全不受資料中心的運營要求限制。

開源會是容器未來的主流嗎？

那麼回過頭來看，到底該如何選擇混合雲容器服務呢？在容器治理層面，如果團隊對 Kubernetes 經驗豐富，且已經有成熟的架構體系，當然可以選擇在叢集層面對 Kubernetes 進行深度定製。

但如果需要更高效地推進研發工作，且與雲原生、雲邊端一體化的大趨勢結合在一起，那麼諸如 Amazon EKS Anywhere、Amazon ECS Anywhere 這一類的產品無疑更好上手，更易維護，且遮蔽了底層的複雜性。

也有人提到，容器的未來絕對是開源的，基於開源軟體做定製化，才是面向未來的。

誠然，對於圍繞著容器生態 CNCF 雲原生技術全景圖確實非常龐大，說明整個開源領域的繁榮狀態，並且很多技術確實是由開源推動的，是開源領域大家貢獻發展的結果；但另一方面，容器層畢竟屬於中間層，它對上層能夠優化我們應用開發，促進它的迭代速度。對下層來講它離不開底層網路計算層基礎資源的支撐，在這個層面它沒辦法脫離開，所以在這個層面，公有云上所做的一些技術方面的創新，能夠更好地去執行容器上的應用。

對於容器技術的未來，筆者認為將朝著三個方向進行發展。

首先，容器領域以成為事實上標準的技術，包括 Docker 以及 Kubernetes 將繼續快速發展下去，會有更多傳統企業遷移進來；

其次，過去容器相對來說採用比較集中化的部署方式，比如過去要麼是在公有云上部署使用，要麼在自己的資料中心使用，這種方式隨著混合雲的架構，會有很大的改變；

第三，Serverless 無伺服器跟容器的結合或者說融合，也是將來發展的趨勢。從所謂雲原生成熟度上講，這是更成熟的一種方式，能夠邁進到無伺服器這個領域，所以基於容器的無伺服器技術也是未來發展的一個重要方向。