不要自建Kubernetes

這是“如何高效使用雲服務”系列文章的首篇分享。可能有朋友好奇為什麼不是從雲計算最基礎的服務--計算資源 ECS / EC2 講起呢？在 Cloud Native 已經被越來越接受的今天，基于 Kubernetes 部署、編排應用的方式已經是業界的事實标準。無論是網際網路巨頭，傳統500強企業，還是創業團隊都在使用或規劃使用 作為應用程式的自動化部署、可擴充管理平台。在雲計算平台，虛拟機越來越不需要單獨的管理，在絕大多數的業務場景下，它們隻是作為容器叢集所管理的計算資源。甚至虛拟機的建立到銷毀整個生命周期管理都可以由

根據叢集的負載來自動完成。

所有主流的雲計算廠商都在解決方案中力推托管的

， AWS 的 EKS Azure 上的 AKS ，當然少不了Google家 GCP Kubernetes Engine 。國内 阿裡雲 騰訊雲 等每一個公有雲玩家也都基于開源 推出了托管服務。如果一家雲計算廠商在提供托管 這一服務上沒跟上業界的步伐，将來極大可能被淘汰出這個市場。

托管的Kubernetes類型

以國内的阿裡雲為例，目前提供了兩大類三種不同的

Kubernetes托管服務

。

• 經典Dedicated Kubernetes模式。這種模式下使用者可以選擇主控端執行個體規格和作業系統，指定Kubernetes版本、自定義Kubernetes特性開關設定等。使用者需要手動維護叢集，例如更新Kubernetes版本，内置元件版本等。可以手動或自動伸縮叢集節點數目。目前該模式下有兩種類型，第一種叢集主節點需要使用使用者的ECS，使用者可遠端登入或管理這些ECS。另一種是，主節點也由雲廠商托管，使用者隻能通過API Server管理Kubernetes。在費用方面，無論是否托管叢集主節點，叢集服務免費，按使用的ECS執行個體及計費方式收費。
• Serverless 模式(目前公測中，暫時免費)。無需建立底層虛拟化資源，可以利用 Kubernetes 指令指明應用容器鏡像、CPU和記憶體要求以及對外服務方式，直接啟動應用程式。按容器使用的CPU和記憶體資源量計費。這種模式下應該是在一個叢集内實作多租戶，目前有些 features不被支援 。例如，部署不支援DaemonSet，Ingress不支援NodePort類型，存儲不支援PV和PVC等。

使用者可以根據自己的業務類型來選擇适合的托管Kubernetes叢集。如果部署的應用是

無狀态的Web服務

，可以選擇Serverless Kubernetes叢集，進一步減少運維工作量。

如果使用者部署的應用有狀态，需要挂載外部存儲，例如MongDB叢集，MQ叢集，可以選擇經典Dedicated Kubernetes模式。如果使用者需要通過Kubernetes元件擴充或自定義實作某些功能，這些需求雲廠商的标準版并沒有提供，這時可以選擇經典Dedicated Kubernetes模式，利用Kubernetes高度靈活的擴充機制來滿足自定義需求。

托管Kuberentes的優勢

國内的阿裡雲有篇技術文檔對比

阿裡雲Kubernetes vs. 自建Kubernetes

，文章看起來雖然有廠商自賣自誇的嫌疑。作為

阿裡雲K8S

的客戶，在使用托管K8S近一年來，深切的體會到雲廠商托管K8S帶來的種種好處，文檔中提到的種種優勢确實是言之鑿鑿。

接下來具體看看雲廠商托管K8S到底有哪些優勢。

便捷

• 通過Web界面/API一鍵建立Kubernetes叢集，叢集更新。
• Web界面/API實作叢集的擴容或縮容。

叢集的安裝，更新檔以及正常版本更新在運維工作中屬于體力活。在規模不大的時候，使用人工實作需要花費不少時間準備環境測試驗證，且易錯。如果叢集體量不夠大的話，開發自動化運維腳本又浪費人力成本。雲計算廠商的托管K8S叢集将提供專業、穩定的技術運維服務，和幾乎為零的人力成本。

從效率和人力成本上看，托管K8S叢集完勝自建Kubernetes叢集。

功能更強大

作為一個容器編排系統，開源版本中許多元件沒有預設實作或實作有限，需要跟運作環境(如托管K8S的雲平台)內建。例如，存儲，Load Balancer，網絡等核心元件。官方文檔

Internal load balancer

就提供了在不同的雲廠商環境中的使用示例。部署一個強大且完整的K8S叢集需要同許多雲計算的基礎元件內建(且隻能通過API完成)，這往往是雲計算廠商的強項。

雲廠商托管的K8S可以在以下方面提供強大的雲計算平台支援，

網絡

• 高性能 VPC 網絡插件。
• 支援 network policy 和流控。

負載均衡

支援建立公網或内網負載均衡執行個體，或者複用已有執行個體。支援指定帶寬大小、計費方式、4層或7層協定代理等雲廠商負載均衡功能。對應用運維來說可以把負載均衡的配置通過代碼實作，并且支援版本控制。對比傳統的雲端部署，也可以将應用部署和應用運維內建在一起統一管理，避免應用釋出和運維配置的割裂，減少人為運維失誤。

阿裡雲托管K8S的負載均衡詳細配置可以參考這個

文檔

，AWS上見此

存儲

內建了雲廠商的雲盤、檔案存儲NAS、塊存儲等存儲方案，基于标準的

FlexVolume

驅動，提供了最佳的無縫內建。

如果是在雲廠商的虛拟機上自建

叢集，預設無法使用雲上的存儲資源。如果需要利用雲廠商提供的存儲方案，例如對象存儲，就需要自行開發基于

的驅動。在廠商托管K8S已經完美解決了存儲內建的問題，何必自己又去費時費力的定制開發呢？

可以看到，雲廠商托管的K8S叢集在網絡、負載均衡和存儲上有許多天然的優勢。在其他幾個次元，托管的K8S叢集同樣也優于自建的K8S，

運維

• 內建廠商的日志服務，監控服務。
• K8S叢集cluster autoscaler自動利用雲廠商的彈性伸縮擴縮容叢集節點。

鏡像倉庫

• 高可用，支援大并發。
• 支援鏡像加速。
• 支援 p2p 分發。
• 可內建雲平台的使用者權限。
• 部分廠商目前免費且不限容量。

高可用

• 提供多可用區支援。
• 支援備份和容災。

技術支援

• 專門的技術團隊保障容器的穩定性。
• 每個 Linux 版本，每個 Kubernetes 版本都會在經過嚴格測試之後之後才會提供給使用者。
• 提供 Kubernetes 更新能力，新版本一鍵更新。
• 為開源軟體提供兜底，無論是K8S、Docker甚至Linux自身的問題提供支援。

專業的技術團隊是提供穩定K8S服務必不可少的。但絕大多數企業是無法做到有專業的技術團隊來維護K8S、提供K8S或容器技術自身的各種最佳實踐、發現以及修複開源軟體Bug。

在筆者的使用托管K8S的時候就遇到這樣的狀況。其中一個叢集更新到新版本

後，内置DNS元件從

KubeDNS

被替換為全新的

CoreDNS

，而當時的

版本在

Service ExternalName

支援上有Bug，導緻已有的這種Service無法提供服務。在同雲廠商的技術團隊溝通後，先用workaround将問題快速繞過，不影響業務的使用。同時，雲廠商的技術人員（也是K8S社群committer）繼續調研，發現該問題是

的Bug。在為開源

項目建立Issue後，同時提供Patch，又在CoreDNS committer建議下完善了測試用例，推動了該問題快速在CoreDNS中被修複。CoreDNS包含Fix的版本釋出後，雲廠商技術支援團隊将更完美的解決方案提供給了我們。作為K8S服務的使用者，這種體驗是極好的。當時我們的技術團隊既沒有精力也沒有能力快速發現并修複開源軟體中的這類問題，而雲廠商的服務間接幫我們實作了這種能力。

這其實是一種非常好的共赢商業模式，雲廠商有能力且有動力投入頂尖技術團隊将開源技術商業化，雲廠商的使用者則用最小的代價獲得了最優的基礎服務來為核心業務賦能。