企業容器雲管理平臺選型指南

數字時代，市場競爭加劇，業務需求日新月異，敏態 IT 建設被越來越多的企業納入重點發展規劃，以容器、Kubernetes 為核心的雲原生是目前敏態 IT 中最熱門的技術架構。

CNCF 把雲原生劃分為多個領域，包括基礎設施、應用開發與部署、服務釋出與治理、執行時、網路、儲存、觀測與分析、安全與合規等，每個領域中都有非常豐富的開源專案。從技術視角來看，雲原生建設就是在各領域中找到能夠滿足自身需求的技術，並組合起來，為我們所用。在這個過程中，我們直面的問題包括：如何選擇合適的技術?如何對這一技術組合進行統一管理?如何調整和最佳化這些技術以實現高效、穩定的執行?

對此，容器雲管理平臺的概念應運而生，簡單地說就是提供一系列開箱即用的功能，並圍繞 Kubernetes 提供更多的擴充套件和創新。容器雲管理平臺是一箇中間態的產品，對下能夠實現叢集的生命週期管理，對上能夠實現對 Kubernetes 上執行的應用的生命週期管理，同時還需具備企業所需的功能，如租戶管理、安全管理、使用者認證以及許可權管理等。

目前，國內有不少廠商專注於這個領域，提供了很多優秀的解決方案，面對琳琅滿目的產品，我們該如何選擇?

平臺選型

在日常與企業客戶的交流中我不難們發現，大家在建設雲原生平臺過程中，討論最多的就是規劃和選型問題。如果把選型過程比作通關遊戲，那麼我們會遇到性質思考、模式思考和能力思考三個關卡。

性質思考

從企業實際應用場景來看，容器雲管理平臺是一個跨部門平臺，至少會涉及基礎設施部門、研發部門、安全部門;當然，不同企業對部門的劃分可能會更細緻。而且，容器雲管理平臺和業務應用又有著緊密的關聯性，會影響業務應用的構建釋出流程和執行運維方式，所以從整體看來容器雲管理平臺具備了 2 個特點：技術上的確定性和能力上的特異性。

技術上的確定性：在建設容器雲管理平臺時，相關的技術棧基本是確定的，例如容器編排排程引擎使用 Kubernetes，監控使用 Prometheus，日誌使用 ELK 或者 Loki，模板商店使用 Helm 等，還有像容器執行時、網路、儲存等也都有很清晰的選擇範圍。

能力上的特異性：每個企業 IT 部門都有自己的工作方式、流程、組織架構和內部環境，對容器雲管理平臺建設都有自己的看法。有些企業的容器雲管理平臺相對獨立;有些可能需要與內部的其他系統做整合和聯動，如與內部監控整合形成統一環境監控，與內部日誌平臺整合形成統一認證，與內部使用者認證平臺整合實現 sso 單點登入，需要與組織架構相對應的多租戶能力等，這就需要不同的能力支援。從這個角度來講，完全按照自身需求，自研一套容器雲管理平臺是企業的最優選擇。

但是自研的門檻比較高，需要一定的團隊和技術實力，大多數企業都不具備這樣的能力。商用是更務實的選擇，有很多廠商提供了相應的平臺產品，但也有不少挑戰。雖然平臺都基於 Kubernetes 搭建，但是不同的產品理念，可能造就了不同的功能側重點，以及未來不同的發展和延伸路線;還有一些產品存在不同程度的捆綁，一旦選錯可能將深陷泥淖。

綜合來看，選擇開源的、相容性好的商用產品能夠在一定程度上實現自研和商用的平衡。一方面，企業可以透過標準化的產品能力和廠商的專業技術支援及賦能，快速培養和提升自身團隊對雲原生的認知和技術水平。另一方面，在團隊能力達標，且標準化的能力已經無法滿足內部需求時，企業可以基於開源產品更便捷地進行二次開發。

實際上，在團隊實力達標的情況下，我們也不太建議一開始就完全自研平臺，因為從 0-1 的建設可能會踩很多坑，遇到很多問題，一些功能直接複用開源產品造好的輪子會事半功倍。同時，使用開源產品確保了技術的延續性，在購買商業支援後，可以大幅減少人力成本支出，提升工作效率，有更多的時間專注於自身的主營業務。

模式思考

在明確了性質選擇後，我們轉角就遇到了第二個選型問題：應該選擇全功能模式還是組合功能模式?

當前，各種容器雲管理平臺產品豐富，大致可以分為兩類：功能全面型和開放相容型。

功能全面型：平臺中功能基本覆蓋了雲原生所有元素，如包括了 Kubernetes 叢集管理、應用管理、DevOps、微服務治理、中介軟體等各大板塊能力，並且高度封裝。

開放相容型：平臺中功能以保有核心能力為主，如 Kubernetes 叢集管理、應用管理，其他能力以開箱即用的外掛方式提供，具備高度的可替換性。

功能全面的容器雲管理平臺能夠遮蔽掉很多技術細節，企業可以拿來即用;開放相容型產品可以提供更靈活的組合方式。

在早期，容器和 Kubernetes 技術還不是那麼普及，功能全面型的產品是比較好的選擇，企業可以藉助其全面的能力快速構建，遮蔽掉一些技術門檻，預研雲原生技術和帶來的價值;當今，容器和 Kubernetes 技術已經比較普及，整個 CNCF 生態也進入了繁榮時期，雲原生的建設更多是積木式、整合式的組合。

“專業的事情交給專業的人去做”，大而全平臺的問題在於整體功能都是內聚的、互相依賴的、標準化的。使用者往往在使用時發現，很多地方並不能很好地契合自身需求，還需要替換功能模組。然而在高內聚的佈局下，模組的剝離和替換往往難以實現，或者成本很高。所以，越來越多的使用者會選擇開放相容性好的產品，在需要替換平臺中的某些功能模組時，只需要關閉相應模組，直接進行替換或者整合即可。

同時我們也看到，越來越多功能全面的平臺也開始化整為零，固化必備的基礎能力，周邊能力則以模組外掛方式提供，方便使用者進行替換。

能力思考

走到這一步，選型的思路就比較清晰了。我們遇到的最後一個問題是：除了性質和模式，還需要考慮哪些因素呢?

基於與眾多客戶的接觸，我們提煉出兩點：

沉澱包含很多方面，比如產品的迭代歷史、使用人數、行業落地案例等。這些沉澱可以很好地反映產品的成熟度和穩定性，畢竟大家都不想在生產環境中做第一個吃螃蟹的人，更希望有一個成功的參照物可以借鑑。

創新是一個企業的靈魂，雲原生就像是一列飛馳的高鐵，好的產品提供者應該能緊跟技術發展，並不斷推陳出新。企業在使用容器雲管理平臺的同時，在不同的階段總會出現不同的需求場景和問題，能不能走在使用者前面引領使用者，並陪伴使用者成長，也是選型考慮的一個重要因素。

透過以上三個關卡，想必大家已經有了選型的初步想法。下面讓我們從應用場景出發，再對產品選型能力指標做一些考量。

場 景

多叢集及環境統一管理

企業中不同型別的 Kubernetes 叢集越來越多，混合管理的需求與日俱增。我們在與客戶聊叢集規劃的時候經常聽到：

我們需要在不同的環境建設 Kubernetes 叢集，包括開發、測試、UAT、生產。

這些應用比較重要，需要單獨的叢集支撐，方便重點運維。

我們 X 應用是外採的，它的底座也是 Kubernetes 叢集，要把平臺管理起來。

我們之前 X 部門走的比較靠前，當時用開源工具部署了一個 Kubernetes，現在需要暫時管理起來，後續再考慮新建叢集並遷移。

我們除了私有云以外，某公有云上也使用了 Kubernetes 叢集(也想在公有云上使用 Kubernetes 叢集)，能否方便地實現混合雲管理。

我們現在容器和 VM 是共存的狀態，整體應用包含了容器執行部分和 VM 執行部分，有沒有能統一管理容器和 VM 的方式……

在雲原生時代，隨著企業的不斷髮展，多雲混合雲的場景變得越來越普遍。以某零售企業為例，其 APP 商城平常執行在私有資料中心，在早期業務量不大的時候，即使在大促時也完全可以承載和支撐。但隨著企業的不斷髮展，大促帶來的訪問壓力已經到了本地無法支撐的程度，但是為了應對大促而去擴大私有資料中心規模的做法又不夠經濟，這會造成平時大量的資源閒置。

最終，該企業採用了混合雲方案，在公有云上使用 Kubernetes 叢集，透過統一入口管理私有云叢集和公有云叢集。當大促來臨時，透過公有云臨時擴充叢集節點，應對壓力。

由此可以看出，多叢集以及環境的統一管理是考量容器雲管理平臺的重要能力指標。Kubernetes 作為通用基礎架構，可以很好地應對多雲帶來的差異性，滿足企業的多雲策略需求。從 ROI 的角度看，容器雲管理平臺覆蓋的公有云型別越多，就越能增強 FinOps 和多雲議價能力。

增強式安全防護

從前，大家更關注應用如何容器化、怎樣上 Kubernetes;而當下，大家越來越關注安全問題。容器安全處於早期發展階段，還存在一些問題。從技術角度看，Kubernetes 自身的安全能力較低，之前版本內建了 PSP 功能，但也侷限在一些與許可權相關的防護上;而且，高版本已經廢棄了這一功能。CIS 雖然提供了 Kubernetes 基線掃描，但主要用於檢測 Kubernetes 的配置是否有安全隱患，防護面很有限。從知識儲備角度看，在多數企業內，懂雲原生的工程師不太懂安全，懂安全的又不太瞭解雲原生，這導致容器安全防護建設工作無從下手。

近幾年，雲原生相關安全事件層出不窮，當事企業遭受了不少損失，安全建設已成為當下亟需解決的問題。一個合格的雲原生安全防護平臺至少應具備以下能力：

CICD 嵌入能力：可以在流水線中啟用防護，比如映象打包完成後的掃描，實現一定程度的安全左移。

准入控制能力：可以在應用部署時進行相應防護，儘量降低不安全因素進入叢集，如可信倉庫和映象白名單、有安全隱患的部署配置阻斷等。

執行時防護能力：可以在容器執行態上進行相應防護，如網路防護、程式防護、檔案防護。

以零信任為核心的安全防護理念：可以實現零日攻擊防護以及一些未知的攻擊行為。

目前有不少廠商專注這一領域，提供的產品也各有特色，可以有效幫助我們補強 Kubernetes 安全能力不足的問題。綜合考慮使用體驗、易用性以及統一管理等方面，如果容器雲管理平臺能提供足夠的安全防護能力，那將是理想選擇。

資料中心到邊緣

邊緣計算是近兩年的熱門領域，很多企業都在積極佈局，利用容器和 Kubernetes 技術充分發揮雲邊協同的效能。業界對邊緣的定義至今沒有統一，不同的企業由於不同的業態對邊緣的定義也不盡相同，對於銀行來說邊緣可以是網點也可以是各種金融終端裝置，對於製造業來說邊緣可以是工廠側也可以是產線側。

對於有邊緣應用場景的企業來說，選型時首先要考慮平臺是否具備實現雲邊協同的能力，還要考慮雲邊協同的方案是否有延展性，大能適應各類伺服器，小能覆蓋各類小型計算資源裝置，另外還要考慮能否實現高度的自動化交付從而提升效率。

比如現在邊端有海量的裝置，一般的部署流程大致是：

安裝作業系統 ➞ 安裝相應的 Kubernetes 發行版 ➞ 部署邊端叢集並註冊到雲端管理平臺 ➞ 部署各類應用

目前熱門的邊緣計算交付方式分為兩個步驟：

Day1: 裝置透過定製映象自動部署作業系統及叢集，並實現自動註冊

Day2: 按照編排需求，GitOps 自動同步各類應用到不同邊緣叢集

可以看出，後者透過自動化極大簡化了交付過程，從而提升了整體效率。如果平臺能夠提供足夠彈性的雲邊協同方案以及高度自動化交付，將為企業帶來強勁的邊緣計算建設助力。

現在，在實施大多數邊緣計算方案的時候，還需要在邊緣端投入不少的人力進行前期工作，如作業系統安裝，半自動化的 Kubernetes 發行版安裝以及雲端註冊等，自動化程度越高就越能降低人力成本。

寫在最後

本文站在行業大視角，為大家提供了一些普遍適用的容器雲管理平臺考量要素。雲原生領域可選擇的平臺很多，有開源也有閉源，雖然表面上看產品功能有同質化趨勢，但其底蘊和理念是不同的。

以 Rancher 為例，作為最早的一款全開源的容器管理平臺，其 1.x 版本陪伴使用者走過了 docker swarm、mesos 和 Kubernetes 的三國鼎立時期;2.x 版本則緊跟社群和技術發展，專注於 Kubernetes 管理。一路走來，Rancher 積累了大量使用者，一直是全球使用人數最多的容器雲管理平臺，它將始終致力於幫助使用者管理任意位置的 Kubernetes 叢集，實現無處不在的計算。

在此過程中，我們也在不斷總結使用者的需求和痛點，圍繞 Kubernetes 推出了很多開源產品，如儲存產品 Longhorn，邊緣計算產品 K3s 和 Elemental，持續交付產品 Fleet，超融合產品 Harvester，個人使用產品 Rancher Desktop，安全產品 NeuVector。此外，我們仍在不斷孵化新產品，如 CICD 產品 EPINIO，AiOps 產品 OPNI，旨在幫助使用者解決更多問題，透過 Rancher 更輕鬆地設計和構建自己的雲原生平臺。