無處不在的 Kubernetes，難用的問題解決了嗎？

作者：望宸、木環、溪洋 等

容器本質是一項隔離技術，很好的解決了他的前任 - 虛拟化未解決的問題：運作環境啟動速度慢、資源使用率低，而容器技術的兩個核心概念，Namespace 和 Cgroup，恰到好處的解決了這兩個難題。Namespace 作為看起來是隔離的技術，替代了 Hypervise 和 GuestOS，在原本在兩個 OS 上的運作環境演進成一個，運作環境更加輕量化、啟動快，Cgroup 則被作為用起來是隔離的技術，限制了一個程序隻能消耗整台機器的部分 CPU 和記憶體。

當然，容器技術之是以能流行，更因為他提供了标準化的軟體開發傳遞物 - 容器鏡像。基于容器鏡像，持續傳遞這件事才能夠真正落地。

我們還能羅列出許多使用容器技術的理由，這裡就不再一一贅述。

同時，雲計算解決了基礎資源層的彈性伸縮，卻沒有解決 PaaS 層應用随基礎資源層彈性伸縮而帶來的批量、快速部署問題。于是，容器編排系統應運而生。

從第三方的調研資料看，容器和 Kubernetes 已經成為雲原生時代主流的選擇，但實際落地的時候，卻陷入了困境。我們嘗試去總結了一些共通點，以及應對方案，也許能為正在落地容器技術的企業提供一些參考。

01 難用在哪？

容器和 Kubernetes 的先進性毋庸置疑，但當大量的企業在開始擁抱容器編排領域的事實标準 Kubernetes 時，卻陷入了困境。“K8s 就像一把雙刃劍，既是最佳的容器編排技術，同時也存在相當高的複雜性和應用的高門檻，這個過程中往往會導緻一些常見性錯誤”。就連 Kubernetes 的創立者和核心推動者 Google 本身都承認這個問題。

一次采訪中，阿裡巴巴進階技術專家張磊分析了 Kubernetes 的本質，他指出，“Kubernetes 本身是一個分布式系統而不是一個簡單的 SDK 或者程式設計架構，這本身已經将其複雜度提升到了系統級分布式開源項目的位置。此外，Kubernetes 第一次将聲明式 API 的思想在開源基礎設施領域普及開來，并以此為基礎提出了一系列諸如容器設計模式和控制器模型等使用範式，這些具有一定先進性和前瞻性的設計也使得 Kubernetes 項目被大衆接受時會存在一定的學習周期。”

我們大緻總結了 Kubernetes 的 4 大複雜性。

1、認知複雜：他和原有的後端研發體系不同，延伸出一套全新的理論，并提供了一系列全新的技術概念，并且這些概念，例如 Pod、sidecar、Service、資源管理、排程算法和 CRD 等等，主要是面向平台研發團隊而非應用開發者設計，提供很多強大靈活的能力。但是，這不僅帶來了陡峭的學習曲線，影響了應用開發者的使用體驗，甚至在很多情況下了解不當還會引發錯誤操作，乃至生産故障。

2、開發複雜：K8s 使用聲明式方法來編排和管理容器。為了實作這一點，需要配置一個 YAML 檔案，但再複雜的應用程式中，引入新環節影響了開發者的生産力和靈活性。此外，缺乏内置的程式設計模型，開發者需要依賴第三方庫來處理程式間的依賴關系，這些都會影響到開發效率，并增加不必要的 DevOps 開銷。

3、遷移複雜：将現有的應用程式遷移到 K8s 比較複雜，尤其是非微服務架構，在很多情況下，必須重構特定元件或整個架構，并且需要使用雲原生原理重構應用程式，例如狀态依賴，如寫本地目錄、有順序，網絡依賴，如寫死 IP，數量依賴，如副本固定等等。

4、運維複雜：K8s 的聲明式 API 颠覆了傳統的過程式運維模式，聲明式 API 對應的是面向終态的運維模式。而随着 K8s 叢集規模的增長，徒手基于開源K8s，運維難度也會呈線性增長，呈現在叢集管理、應用釋出、監控、日志等多個環節，叢集穩定性将面臨極高的挑戰。

02 是否還有别的解法？

技術總有雙面性，容器革新了雲計算的基礎設施，成為了新的計算界面。而 Kubernetes 則搭建了一個統一的基礎設施抽象層，為平台團隊屏蔽掉了“計算”、“網絡”、“存儲”等過去我們不得不關注的基礎設施概念，使得我們能夠基于 Kubernetes 友善地建構出任何我們想要的垂直業務系統而無需關心任何基礎設施層的細節。這正是 Kubernetes 被稱為雲計算界的 Linux 以及 “Platform for Platforms” 的根本原因。

但直接上手操作 Kubernetes 是否是我們應用容器技術的唯一選擇呢？答案是否定的。在容器技術的演進過程中，我們也發現了不少能夠降低容器編排門檻的開源項目和商業化産品，接下來，我們将從雙手的解放程度由低到高，一一介紹。

01

1、圍繞 Kubernetes 生态的開源工具

OAM/KubeVela 是托管在 CNCF 中的開源項目，旨在降低 K8s 在應用開發和運維上的複雜性，最初由阿裡雲和微軟雲聯合發起。

KubeVela 作為開放應用架構模型 OAM 的标準實作，與底層基礎設施和無關、原生可擴充，而且最重要的是它完全以應用為中心。在 KubeVela 中，“應用”被設計為整個平台的「一等公民」。應用團隊隻需要圍繞元件、運維特征、工作流等幾個跨平台、跨環境的上層抽象來進行應用的傳遞與管理，無需關注任何基礎設施細節和差異性；平台管理者則可以随時以 IaC 的方式配置平台支援的元件類型和運維能力集等特性，以便适配任何應用托管場景。

KubeVela 是完全基于 K8s 建構的，具備天然的被內建能力和普适性，天然透出 K8s 及其生态的所有能力，而不是往上疊加抽象。是以 KubeVela 适用于那些具備一定的 K8s 平台開發和運維能力，同時希望能夠使用到全套 K8s 能力，不斷擴充平台能力的技術團隊。

容器已經從一項隔離技術演進成一個生态，KubeVela 這類可以極大降低 K8s 使用複雜度的開源工具，會逐漸釋放其生命力，使開發人員無需成為 K8s 專家即可享受到雲原生帶來的高效與便捷。

sealer 是一款開源的分布式應用打包傳遞運作的方案，極大的簡化了容器項目的傳遞複雜性和一緻性問題。sealer 建構出來的産物可稱之為"叢集鏡像"，并内嵌了 K8s，該"叢集鏡像"可以 push 到 registry 中共享給其他使用者使用，也可以在官方倉庫中找到非常通用的分布式軟體直接使用。

傳遞是容器生态的另一個難題，面臨着依賴複雜、一緻性的問題，尤其是工業級的 Kubernetes 傳遞項目，傳遞周期變長、傳遞品質要求高，sealer 非常适合于軟體開發商、ISV 等性質的企業，可将部署時間縮短至小時級别。

2、開放、标準化的企業級 Kubernetes 服務

大部分雲廠商提供了 Kubernetes as a Service 的容器平台能力，比如 AWS EKS 和阿裡雲的 ACK，可以大幅簡化 K8s 叢集的部署、運維、網絡存儲、安全管理等能力，提供了通過 CNCF 标準化認證的 K8s服務，可以滿足幾乎全場景的工作負載需求，并提供了豐富的擴充和定制能力。此外，大部分雲廠商會基于開源 Kubernetes 架構，在上層做不同程度的封裝，來适配不同企業背景和不同場景下的需求，以提供發行版和 Pro 版，例如阿裡雲的 ACK Pro 就提供了托管 master 和全托管節點池的能力，全面整合IaaS能力，更加高效、安全、智能，将容器叢集的各種細分場景最佳實踐和全棧優化作為内置服務提供給企業。

從現有使用者規模來看，這是大部分網際網路企業落地容器技術的主流選擇。

更多資訊請移步至：

《阿裡雲容器服務多項重磅釋出：高效智能、安全無界的新一代平台》

 。

3、向 Serverless 演進的 Kubernetes 服務

傳統的 Kubernetes 采用以節點為中心的架構設計：節點是 Pod 的運作載體，Kubernetes 排程器在工作節點池中選擇合适的 node 來運作 Pod。

而對于 Serverless Kubernetes 而言，最重要的一個概念是将容器的運作時和具體的節點運作環境解耦。使用者無需關注 node 運維和安全，降低運維成本；而且極大簡化了容器彈性實作，無需按照容量規劃，按需建立容器應用 Pod 即可；此外 Serverless 容器運作時可以被整個雲彈性計算基礎設施所支撐，保障整體彈性的成本和規模。

衆多雲廠商也将容器和 Serverless 做進一步的融合：例如阿裡雲的 Serverless 容器服務 ASK、Google GKE 的 AutoPilot，以免運維的方式降低了客戶在 K8s 節點和叢集上的操作複雜度，無需購買伺服器即可直接部署容器應用；同時，仍然可以通過 K8s 指令行和 API 來部署容器應用，充分利用了 K8s 的編排能力，并且根據應用配置的 CPU 和記憶體資源量進行按需付費。

這類服務非常善于處理一些 Job 類的任務，例如 AI 領域的算法模型訓練，同時擁有在 K8s 環境下比較一緻的開發體驗，是容器服務生态非常好的補充。

更多資訊可以移步至：《

Serverless Kubernetes：理想，現實與未來

》。

04

4、容器和 Serverless 技術加持的新一代 PaaS 服務

企業級市場的需求總是分層的、多樣化的，這和技術人才的分布緊密相關，并不是每家企業都能建立一個技術實力足夠強的團隊，尤其是在非北上廣深的城市，并且落地一項新技術時，總是分階段規劃的，這就給更多的産品形态孕育了市場空間。

K8s 雖然提供了容器應用的全生命周期管理，但是太豐富、太複雜、太靈活，這既是一種優勢，有時候也是一種劣勢。尤其是對于習慣了在虛拟機時代，以應用為視角來管理應用的研發運維人員而言，即便像 AWS EKS、阿裡雲 ASK 等已經在一定程度上降低了 K8s 的操作複雜度，他們仍然希望通過某種方式，可以進一步降低容器技術的使用門檻。

容器和 K8s 并非一定要捆綁使用，在一些新型的 PaaS 服務中，例如阿裡雲的 Serverless應用引擎（SAE），底層将虛拟化技術改造成容器技術，充分利用了容器的隔離技術，來提升啟動時間和資源使用率，而在應用管理層，則保留了原有的微服務應用的管理範式，使用者不必學習龐大而複雜的 K8s 來管理應用。這類新型的 PaaS 服務通常還會内置全套微服務治理能力，客戶無需考慮架構選型、更無需考慮資料隔離、分布式事務、熔斷設計、限流降級等，也無需擔心社群維護力度有限二次定制開發的問題。

此外，底層計算資源池化後，其天然的 Serverless 屬性使得使用者不必再單獨購買和持續保有伺服器，而是按 CPU 和記憶體資源量來配置所需的計算資源，讓容器 + Serverless + PaaS 得以合三為一，使得技術先進性、資源使用率優化、不變的開發運維體驗可以融合在一起。是以，相比于本文中的其他方案，這類方案的特色是提供了PaaS 體驗，讓新技術落地更加平穩。

大部分傳統行業、一些技術能力偏向于業務層的網際網路企業、和一些不希望因受制于後端而影響業務快遞疊代的創業公司，大多都會傾向于 PaaS 形态的産品，抛開企業屬性，PaaS 類的服務在處理以下場景更具傳遞優勢：

• 上線了一個新的項目，想快速驗證，不要出故障，同時控制人力的投入成本；
• 業務體量上升快，使用者越來越多，業務穩定性有點 hold 不住，新版本釋出、線上應用管理等環節開始有點畏手畏腳，但技術儲備還無法及時應對目前變化；
• 決定要把原有的單體架構更新成微服務架構，但由于團隊缺少微服務專家，評估完項目發現更新風險比較高。

更多資訊可以移步至：

《打破 Serverless 落地邊界，阿裡雲 SAE 釋出 5 大新特性》

。

5、更為極緻的 Serverless 服務 -  FaaS

FaaS 的出現，讓具備彈性靈活訴求的業務場景，有了更好的選項。越來越多的大中型企業将傳統後端領域對擴容有靈活需求的執行單元剝離出來，運作在 Serverless 架構上。

這使得 FaaS（函數計算）成為容器和 K8s 外，另一種通用算力的選擇。

和 Google Cloud Run、App Runner 等 Serverless 服務一樣，FaaS 的産品形态正變得越來越開放，運作上的限制越來越少，除了适合事件驅動的計算模型，也适合 Web 單體應用、Job 等場景，可以幫助使用者把彈性發揮到極緻，進一步提升計算資源的使用率。

例如，遊戲行業的莉莉絲将函數計算應用于戰鬥校驗，來驗證玩家用戶端上傳的戰鬥是否有作弊的情況。戰鬥校驗一般需要逐幀計算，CPU 消耗會非常高，通常 1 隊 v 1 隊的戰鬥需要 n 毫秒，而 5 隊 v 5 隊的戰鬥則需要相應 5n 毫秒，對彈性要求很高。此外，容器架構下挂載的 SLB，會因為輪詢機制導緻無法感覺 Pod 的實際負載，由此引起的負載不均，産生死循環和穩定性風險。

函數計算的排程系統幫助莉莉絲合理安排每個請求，對于死循環問題，也貼心的提供了逾時殺程序機制，并将排程系統的複雜性下沉到了基礎設施。此外，函數計算深度優化後的冷啟動時延大幅下降，從排程、到擷取計算資源、再到服務啟動，基本在 1 秒+左右。

另外，FaaS 的出現，也極大的解放了創業公司全棧工程師在 DevOps 上花費的精力，來承載小程式、網站等 Web 單體應用，例如，函數計算降低了 Node.js 等前端語言的伺服器維護門檻，隻要會寫 JS 代碼就可以維護 Node 服務。

《跨越行業絆腳石，阿裡雲函數計算釋出 7 大技術突破》

03 适合的才是最好的

需求的越多，投入的也會越多，這是恒古不變的道理。在我們決定引入容器技術後，使用 K8s 之前，需要想清楚為什麼需要 K8s。

如果我們希望充分利用 K8s 的全套能力，并且團隊具備一定的技術儲備，那麼 KubeVela 是理想的開源選型，sealer 還能幫助我們降低傳遞複雜度；如果希望将 K8s 上層不同程度的封裝工作交給雲廠商來處理，以更高效的适配不同業務場景下的需求，那麼雲廠商提供的商業化的容器服務是不錯的選擇；如果容器和 K8s 無法契合彈性業務類的訴求，則可以選擇 FaaS。

但又如果我們的應用并沒有那麼複雜，隻是樸素的希望簡化應用生命周期管理和底層基礎設施，保障業務的高可用，并專注在業務開發上，那麼可能就不需要使用 K8s 來編排容器應用了，畢竟 K8s 是源自 Google 的 Borg，他是用來管理 Google 海量的容器應用的。

參考文章：

1. 《雲計算的前世今生》，劉超
2. 《靈活、高效的雲原生叢集管理經驗：用 K8s 管理 K8s》，淮右、臨石
3. 《複雜性會成為 Kubernetes 的“緻命傷”嗎？》，趙钰瑩

4. 《Simplifying Kubernetes For

   Developers》，Rishidot Research

5. 《KubeVela 正式開源：一個高可擴充的雲原生應用平台與核心引擎》，OAM項目維護者
6. 《KubeVela 1.0 ：開啟可程式設計式應用平台的未來》，OAM項目維護者

相關連結：

1. 項目位址： https://github.com/oam-dev/kubevela
2. https://github.com/alibaba/sealer