—— 數字時代下的容器云管理平臺 ——

數字時代，市場競爭加劇，業務需求日新月異，敏態 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 更輕松地設計和構建自己的云原生平臺。

審核編輯 ：李倩