Kubernetes?的學習路徑，容器混合云到底有沒有?“easy mode”

近年來，兼具公有云和私有云優(yōu)勢的混合云模式逐漸成為主流。Flexera 發(fā)布的 2021 云狀態(tài)報告顯示，92% 的企業(yè)在 IT 架構上選擇多云戰(zhàn)略, 其中 82% 的企業(yè)選擇混合云。隨著混合云的應用越來越廣泛，越來越多用戶發(fā)現(xiàn)在復雜的混合云環(huán)境完成容器編排并不容易。雖然 Kubernetes 已成為容器編排和調度的事實標準，但是 Kubernetes 操作復雜，且只專注于單集群租戶管理，在多集群管理，尤其是涉及跨云的多集群管理方面并不完善。此外，Kubernetes 為云數(shù)據(jù)中心設計在邊緣計算場景中也有一定的局限性。

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

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

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

K3s 是由 Rancher Lab 于 2019 年推出的輕量級 Kubernetes 發(fā)行版。K3s 的名字來源于 K8s-5。為減少 Kubernetes 所需內存，Rancher K3s 刪除了舊的、非必須的代碼、整合正在運行的打包進程、使用 containerd 代替 Docker 作為運行時的容器引擎，此外引入 SQLite 作為可選的數(shù)據(jù)存儲。從而使得其更好的適配 CI、ARM、邊緣環(huán)境、物聯(lián)網(wǎng)和測試這五個場景。K3s 所有組件均運行在邊緣，因此不涉及云邊協(xié)同，但從生產的角度 K3s 缺少集群管理方案，負責跨集群應用管理、監(jiān)控等，然而遺憾的是 Rancher 并未對這部分能力進行開源。

以 K3s 為代表的輕量級容器編排產品適合運行在邊緣計算場景中?，F(xiàn)有的 Kubernetes 發(fā)行版本通常是內存密集型的，在邊緣計算環(huán)境中顯得過于復雜。這類產品通過降低內存，使其能夠在邊緣場景中更好的部署，此外，在邊緣計算場景下，企業(yè)需要運維管理的 Kubernetes 集群數(shù)量非常龐大，且通常只有很少量的節(jié)點，因此運維人員需要負責大規(guī)模的基礎架構。通過這類輕量級容器編排產品，可最大限度的簡化用戶的安裝和操作步驟，降低運維難度。

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

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

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

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

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

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

亞馬遜云科技于今年 9 月全面推出 Amazon EKS Anywhere。Amazon EKS Anywhere 完全采用原生 Kubernetes 架構，不進行任何改動，僅僅在原有基礎上添加一些管理跟維護工具，使其能夠完全兼容并且更加方便的部署在用戶自己的數(shù)據(jù)中心里。

Amazon EKS Anywhere 是 Amazon EKS 的最新部署選項，以往 Amazon EKS 只能在亞馬遜自己的云環(huán)境之下實現(xiàn)基礎設施兼容，但通過 Amazon EKS Anywhere 用戶可以在自有基礎設施上運行 Amazon EKS。因此，Amazon EKS Anywhere 更適合那些已經(jīng)擁有、并打算繼續(xù)使用大規(guī)模本地基礎設施的企業(yè)用戶。

Amazon EKS Anywhere 通過默認組件配置幫助簡化本地 Kubernetes 集群的創(chuàng)建和運維，同時提供可實現(xiàn)集群管理自動化的工具。它是基于 Amazon EKS Distro 的優(yōu)勢構建的，后者是為亞馬遜云科技上的 Amazon EKS 提供支持的同一個 Kubernetes 發(fā)行版本。亞馬遜云科技支持所有 Amazon EKS Anywhere 組件，包括集成的第三方軟件，從而讓用戶能夠降低支持成本，同時無需維護冗余的開源和第三方工具。

此外，Amazon EKS Anywhere 為用戶提供與 Amazon EKS 一致的本地 Kubernetes 操作工具。開發(fā)者可以利用 EKS 控制臺通過 EKS 連接器查看在任何位置運行的所有 Kubernetes 集群（包括 EKS Anywhere 集群）。

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

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

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

據(jù)介紹，Amazon ECS 是第一項由亞馬遜云科技管理的容器編排服務。為用戶提供一套易于使用控制平面，可通過虛擬機實例（Amazon EC2) 或完全無服務器（Amazon Fargate) 形式輕松運行各種容器型工作負載，同時與其他亞馬遜云科技的托管服務實現(xiàn)原生集成，進而提供服務網(wǎng)格，日志記錄、指標捕捉等增強功能。

Amazon ECS Anywhere 功能的出現(xiàn)，使得用戶能夠在非亞馬遜環(huán)境中部署各類 Amazon ECS 任務。以此為基礎，客戶能夠在特定亞馬遜區(qū)域之內利用同一套易于使用的管理層定義并管理集群內的一切資源，而無需考慮集群位于哪里，執(zhí)行環(huán)境如何。

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

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

從 2021 年起，所有云環(huán)境下的開發(fā)者，已經(jīng)不能忽視云邊端一體化的大趨勢，未來將有超過 50% 的數(shù)據(jù)跑在各類型的 ?IoT 終端上，Amazon ECS Anywhere 是對這種趨勢的擬合與最佳適配。

此外，開發(fā)者只需將 Amazon ECS Anywhere 部署在亞馬遜基礎設施之外的容器服務當中，使用 External 啟動類型，就能使同 Amazon 區(qū)域中 Amazon ECS 集群內的云服務實現(xiàn)類似同一環(huán)境下的彼此交互，并且，外部容器負載還能充分發(fā)揮所處物理位置上本地的方式為系統(tǒng)服務，借此實現(xiàn)內部視頻文件的規(guī)?；幚淼纫酝y以在云端完成的高強度工作。

由于 Amazon ECS Anywhere 強調基礎設施的完全中立性，因此只要開發(fā)者制定的操作系統(tǒng)能夠運行 Amazon ECS 和 System Manager 代理，即可對各類機器或設備進行注冊，極低的注冊門檻有助于幫助開發(fā)者輕松在亞馬遜環(huán)境之外，包括邊緣位置部署微服務用例，完全不受數(shù)據(jù)中心的運營要求限制。

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

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

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

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

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

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

其次，過去容器相對來說采用比較集中化的部署方式，比如過去要么是在公有云上部署使用，要么在自己的數(shù)據(jù)中心使用，這種方式隨著混合云的架構，會有很大的改變；

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