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

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

稽核&校對：不瞋、巨集良、張磊、志敏

編輯&排版：酒圓

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

當然，容器技術之所以能流行，更因為他提供了標準化的軟體開發交付物 - 容器映象。基於容器映象，持續交付這件事才能夠真正落地。

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

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

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

難用在哪？

容器和 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，運維難度也會呈線性增長，呈現在叢集管理、應用釋出、監控、日誌等多個環節，叢集穩定性將面臨極高的挑戰。

是否還有別的解法？

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

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

圍繞 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 等性質的企業，可將部署時間縮短至小時級別。

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

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

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

更多資訊請移步至： 《阿里雲容器服務多項重磅釋出：高效智慧、安全無界的新一代平臺》 。

向 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：理想，現實與未來》 。

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

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

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

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

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

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

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

更多資訊可以移步至： 《打破 Serverless 落地邊界，阿里雲 SAE 釋出 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 大技術突破》

合適的才是最好的

需求的越多，投入的也會越多，這是恆古不變的道理。在我們決定引入容器技術後，使用 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專案維護者