—— 數(shù)字時(shí)代下的容器云管理平臺 ——

數(shù)字時(shí)代，市場競爭加劇，業(yè)務(wù)需求日新月異，敏態(tài) IT 建設(shè)被越來越多的企業(yè)納入重點(diǎn)發(fā)展規(guī)劃，以容器、Kubernetes 為核心的云原生是目前敏態(tài) IT 中最熱門的技術(shù)架構(gòu)。

CNCF 把云原生劃分為多個(gè)領(lǐng)域，包括基礎(chǔ)設(shè)施、應(yīng)用開發(fā)與部署、服務(wù)發(fā)布與治理、運(yùn)行時(shí)、網(wǎng)絡(luò)、存儲、觀測與分析、安全與合規(guī)等，每個(gè)領(lǐng)域中都有非常豐富的開源項(xiàng)目。從技術(shù)視角來看，云原生建設(shè)就是在各領(lǐng)域中找到能夠滿足自身需求的技術(shù)，并組合起來，為我們所用。在這個(gè)過程中，我們直面的問題包括：如何選擇合適的技術(shù)？如何對這一技術(shù)組合進(jìn)行統(tǒng)一管理？如何調(diào)整和優(yōu)化這些技術(shù)以實(shí)現(xiàn)高效、穩(wěn)定的運(yùn)行？

對此，容器云管理平臺的概念應(yīng)運(yùn)而生，簡單地說就是提供一系列開箱即用的功能，并圍繞 Kubernetes 提供更多的擴(kuò)展和創(chuàng)新。容器云管理平臺是一個(gè)中間態(tài)的產(chǎn)品，對下能夠?qū)崿F(xiàn)集群的生命周期管理，對上能夠?qū)崿F(xiàn)對 Kubernetes 上運(yùn)行的應(yīng)用的生命周期管理，同時(shí)還需具備企業(yè)所需的功能，如租戶管理、安全管理、用戶認(rèn)證以及權(quán)限管理等。

目前，國內(nèi)有不少廠商專注于這個(gè)領(lǐng)域，提供了很多優(yōu)秀的解決方案，面對琳瑯滿目的產(chǎn)品，我們該如何選擇？

—— 平臺選型 ——

在日常與企業(yè)客戶的交流中我不難們發(fā)現(xiàn)，大家在建設(shè)云原生平臺過程中，討論最多的就是規(guī)劃和選型問題。如果把選型過程比作通關(guān)游戲，那么我們會(huì)遇到性質(zhì)思考、模式思考和能力思考三個(gè)關(guān)卡。

性質(zhì)思考

從企業(yè)實(shí)際應(yīng)用場景來看，容器云管理平臺是一個(gè)跨部門平臺，至少會(huì)涉及基礎(chǔ)設(shè)施部門、研發(fā)部門、安全部門；當(dāng)然，不同企業(yè)對部門的劃分可能會(huì)更細(xì)致。而且，容器云管理平臺和業(yè)務(wù)應(yīng)用又有著緊密的關(guān)聯(lián)性，會(huì)影響業(yè)務(wù)應(yīng)用的構(gòu)建發(fā)布流程和運(yùn)行運(yùn)維方式，所以從整體看來容器云管理平臺具備了 2 個(gè)特點(diǎn)：技術(shù)上的確定性和能力上的特異性。

技術(shù)上的確定性：在建設(shè)容器云管理平臺時(shí)，相關(guān)的技術(shù)?；臼谴_定的，例如容器編排調(diào)度引擎使用 Kubernetes，監(jiān)控使用 Prometheus，日志使用 ELK 或者 Loki，模板商店使用 Helm 等，還有像容器運(yùn)行時(shí)、網(wǎng)絡(luò)、存儲等也都有很清晰的選擇范圍。

能力上的特異性：每個(gè)企業(yè) IT 部門都有自己的工作方式、流程、組織架構(gòu)和內(nèi)部環(huán)境，對容器云管理平臺建設(shè)都有自己的看法。有些企業(yè)的容器云管理平臺相對獨(dú)立；有些可能需要與內(nèi)部的其他系統(tǒng)做集成和聯(lián)動(dòng)，如與內(nèi)部監(jiān)控集成形成統(tǒng)一環(huán)境監(jiān)控，與內(nèi)部日志平臺集成形成統(tǒng)一認(rèn)證，與內(nèi)部用戶認(rèn)證平臺集成實(shí)現(xiàn) sso 單點(diǎn)登錄，需要與組織架構(gòu)相對應(yīng)的多租戶能力等，這就需要不同的能力支持。從這個(gè)角度來講，完全按照自身需求，自研一套容器云管理平臺是企業(yè)的最優(yōu)選擇。

但是自研的門檻比較高，需要一定的團(tuán)隊(duì)和技術(shù)實(shí)力，大多數(shù)企業(yè)都不具備這樣的能力。商用是更務(wù)實(shí)的選擇，有很多廠商提供了相應(yīng)的平臺產(chǎn)品，但也有不少挑戰(zhàn)。雖然平臺都基于 Kubernetes 搭建，但是不同的產(chǎn)品理念，可能造就了不同的功能側(cè)重點(diǎn)，以及未來不同的發(fā)展和延伸路線；還有一些產(chǎn)品存在不同程度的捆綁，一旦選錯(cuò)可能將深陷泥淖。

綜合來看，選擇開源的、兼容性好的商用產(chǎn)品能夠在一定程度上實(shí)現(xiàn)自研和商用的平衡。一方面，企業(yè)可以通過標(biāo)準(zhǔn)化的產(chǎn)品能力和廠商的專業(yè)技術(shù)支持及賦能，快速培養(yǎng)和提升自身團(tuán)隊(duì)對云原生的認(rèn)知和技術(shù)水平。另一方面，在團(tuán)隊(duì)能力達(dá)標(biāo)，且標(biāo)準(zhǔn)化的能力已經(jīng)無法滿足內(nèi)部需求時(shí)，企業(yè)可以基于開源產(chǎn)品更便捷地進(jìn)行二次開發(fā)。

實(shí)際上，在團(tuán)隊(duì)實(shí)力達(dá)標(biāo)的情況下，我們也不太建議一開始就完全自研平臺，因?yàn)閺?0-1 的建設(shè)可能會(huì)踩很多坑，遇到很多問題，一些功能直接復(fù)用開源產(chǎn)品造好的輪子會(huì)事半功倍。同時(shí)，使用開源產(chǎn)品確保了技術(shù)的延續(xù)性，在購買商業(yè)支持后，可以大幅減少人力成本支出，提升工作效率，有更多的時(shí)間專注于自身的主營業(yè)務(wù)。

模式思考

在明確了性質(zhì)選擇后，我們轉(zhuǎn)角就遇到了第二個(gè)選型問題：應(yīng)該選擇全功能模式還是組合功能模式？

當(dāng)前，各種容器云管理平臺產(chǎn)品豐富，大致可以分為兩類：功能全面型和開放兼容型。

功能全面型：平臺中功能基本覆蓋了云原生所有元素，如包括了 Kubernetes 集群管理、應(yīng)用管理、DevOps、微服務(wù)治理、中間件等各大板塊能力，并且高度封裝。

開放兼容型：平臺中功能以保有核心能力為主，如 Kubernetes 集群管理、應(yīng)用管理，其他能力以開箱即用的插件方式提供，具備高度的可替換性。

功能全面的容器云管理平臺能夠屏蔽掉很多技術(shù)細(xì)節(jié)，企業(yè)可以拿來即用；開放兼容型產(chǎn)品可以提供更靈活的組合方式。

在早期，容器和 Kubernetes 技術(shù)還不是那么普及，功能全面型的產(chǎn)品是比較好的選擇，企業(yè)可以借助其全面的能力快速構(gòu)建，屏蔽掉一些技術(shù)門檻，預(yù)研云原生技術(shù)和帶來的價(jià)值；當(dāng)今，容器和 Kubernetes 技術(shù)已經(jīng)比較普及，整個(gè) CNCF 生態(tài)也進(jìn)入了繁榮時(shí)期，云原生的建設(shè)更多是積木式、集成式的組合。

“專業(yè)的事情交給專業(yè)的人去做”，大而全平臺的問題在于整體功能都是內(nèi)聚的、互相依賴的、標(biāo)準(zhǔn)化的。用戶往往在使用時(shí)發(fā)現(xiàn)，很多地方并不能很好地契合自身需求，還需要替換功能模塊。然而在高內(nèi)聚的布局下，模塊的剝離和替換往往難以實(shí)現(xiàn)，或者成本很高。所以，越來越多的用戶會(huì)選擇開放兼容性好的產(chǎn)品，在需要替換平臺中的某些功能模塊時(shí)，只需要關(guān)閉相應(yīng)模塊，直接進(jìn)行替換或者集成即可。

同時(shí)我們也看到，越來越多功能全面的平臺也開始化整為零，固化必備的基礎(chǔ)能力，周邊能力則以模塊插件方式提供，方便用戶進(jìn)行替換。

能力思考

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

基于與眾多客戶的接觸，我們提煉出兩點(diǎn)：

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

創(chuàng)新是一個(gè)企業(yè)的靈魂，云原生就像是一列飛馳的高鐵，好的產(chǎn)品提供者應(yīng)該能緊跟技術(shù)發(fā)展，并不斷推陳出新。企業(yè)在使用容器云管理平臺的同時(shí)，在不同的階段總會(huì)出現(xiàn)不同的需求場景和問題，能不能走在用戶前面引領(lǐng)用戶，并陪伴用戶成長，也是選型考慮的一個(gè)重要因素。

通過以上三個(gè)關(guān)卡，想必大家已經(jīng)有了選型的初步想法。下面讓我們從應(yīng)用場景出發(fā)，再對產(chǎn)品選型能力指標(biāo)做一些考量。

—— 場 景 ——多集群及環(huán)境統(tǒng)一管理

企業(yè)中不同類型的 Kubernetes 集群越來越多，混合管理的需求與日俱增。我們在與客戶聊集群規(guī)劃的時(shí)候經(jīng)常聽到：

我們需要在不同的環(huán)境建設(shè) Kubernetes 集群，包括開發(fā)、測試、UAT、生產(chǎn)。

這些應(yīng)用比較重要，需要單獨(dú)的集群支撐，方便重點(diǎn)運(yùn)維。

我們 X 應(yīng)用是外采的，它的底座也是 Kubernetes 集群，要把平臺管理起來。

我們之前 X 部門走的比較靠前，當(dāng)時(shí)用開源工具部署了一個(gè) Kubernetes，現(xiàn)在需要暫時(shí)管理起來，后續(xù)再考慮新建集群并遷移。

我們除了私有云以外，某公有云上也使用了 Kubernetes 集群（也想在公有云上使用 Kubernetes 集群），能否方便地實(shí)現(xiàn)混合云管理。

我們現(xiàn)在容器和 VM 是共存的狀態(tài)，整體應(yīng)用包含了容器運(yùn)行部分和 VM 運(yùn)行部分，有沒有能統(tǒng)一管理容器和 VM 的方式……

在云原生時(shí)代，隨著企業(yè)的不斷發(fā)展，多云混合云的場景變得越來越普遍。以某零售企業(yè)為例，其 APP 商城平常運(yùn)行在私有數(shù)據(jù)中心，在早期業(yè)務(wù)量不大的時(shí)候，即使在大促時(shí)也完全可以承載和支撐。但隨著企業(yè)的不斷發(fā)展，大促帶來的訪問壓力已經(jīng)到了本地?zé)o法支撐的程度，但是為了應(yīng)對大促而去擴(kuò)大私有數(shù)據(jù)中心規(guī)模的做法又不夠經(jīng)濟(jì)，這會(huì)造成平時(shí)大量的資源閑置。

最終，該企業(yè)采用了混合云方案，在公有云上使用 Kubernetes 集群，通過統(tǒng)一入口管理私有云集群和公有云集群。當(dāng)大促來臨時(shí)，通過公有云臨時(shí)擴(kuò)充集群節(jié)點(diǎn)，應(yīng)對壓力。

由此可以看出，多集群以及環(huán)境的統(tǒng)一管理是考量容器云管理平臺的重要能力指標(biāo)。Kubernetes 作為通用基礎(chǔ)架構(gòu)，可以很好地應(yīng)對多云帶來的差異性，滿足企業(yè)的多云策略需求。從 ROI 的角度看，容器云管理平臺覆蓋的公有云類型越多，就越能增強(qiáng) FinOps 和多云議價(jià)能力。

增強(qiáng)式安全防護(hù)

從前，大家更關(guān)注應(yīng)用如何容器化、怎樣上 Kubernetes；而當(dāng)下，大家越來越關(guān)注安全問題。容器安全處于早期發(fā)展階段，還存在一些問題。從技術(shù)角度看，Kubernetes 自身的安全能力較低，之前版本內(nèi)置了 PSP 功能，但也局限在一些與權(quán)限相關(guān)的防護(hù)上；而且，高版本已經(jīng)廢棄了這一功能。CIS 雖然提供了 Kubernetes 基線掃描，但主要用于檢測 Kubernetes 的配置是否有安全隱患，防護(hù)面很有限。從知識儲備角度看，在多數(shù)企業(yè)內(nèi)，懂云原生的工程師不太懂安全，懂安全的又不太了解云原生，這導(dǎo)致容器安全防護(hù)建設(shè)工作無從下手。

近幾年，云原生相關(guān)安全事件層出不窮，當(dāng)事企業(yè)遭受了不少損失，安全建設(shè)已成為當(dāng)下亟需解決的問題。一個(gè)合格的云原生安全防護(hù)平臺至少應(yīng)具備以下能力：

CICD 嵌入能力：可以在流水線中啟用防護(hù)，比如鏡像打包完成后的掃描，實(shí)現(xiàn)一定程度的安全左移。

準(zhǔn)入控制能力：可以在應(yīng)用部署時(shí)進(jìn)行相應(yīng)防護(hù)，盡量降低不安全因素進(jìn)入集群，如可信倉庫和鏡像白名單、有安全隱患的部署配置阻斷等。

運(yùn)行時(shí)防護(hù)能力：可以在容器運(yùn)行態(tài)上進(jìn)行相應(yīng)防護(hù)，如網(wǎng)絡(luò)防護(hù)、進(jìn)程防護(hù)、文件防護(hù)。

以零信任為核心的安全防護(hù)理念：可以實(shí)現(xiàn)零日攻擊防護(hù)以及一些未知的攻擊行為。

目前有不少廠商專注這一領(lǐng)域，提供的產(chǎn)品也各有特色，可以有效幫助我們補(bǔ)強(qiáng) Kubernetes 安全能力不足的問題。綜合考慮使用體驗(yàn)、易用性以及統(tǒng)一管理等方面，如果容器云管理平臺能提供足夠的安全防護(hù)能力，那將是最佳的選擇。

數(shù)據(jù)中心到邊緣

邊緣計(jì)算是近兩年的熱門領(lǐng)域，很多企業(yè)都在積極布局，利用容器和 Kubernetes 技術(shù)充分發(fā)揮云邊協(xié)同的效能。業(yè)界對邊緣的定義至今沒有統(tǒng)一，不同的企業(yè)由于不同的業(yè)態(tài)對邊緣的定義也不盡相同，對于銀行來說邊緣可以是網(wǎng)點(diǎn)也可以是各種金融終端設(shè)備，對于制造業(yè)來說邊緣可以是工廠側(cè)也可以是產(chǎn)線側(cè)。

對于有邊緣應(yīng)用場景的企業(yè)來說，選型時(shí)首先要考慮平臺是否具備實(shí)現(xiàn)云邊協(xié)同的能力，還要考慮云邊協(xié)同的方案是否有延展性，大能適應(yīng)各類服務(wù)器，小能覆蓋各類小型計(jì)算資源設(shè)備，另外還要考慮能否實(shí)現(xiàn)高度的自動(dòng)化交付從而提升效率。

比如現(xiàn)在邊端有海量的設(shè)備，一般的部署流程大致是：

安裝操作系統(tǒng) ? 安裝相應(yīng)的 Kubernetes 發(fā)行版 ? 部署邊端集群并注冊到云端管理平臺 ? 部署各類應(yīng)用

目前熱門的邊緣計(jì)算交付方式分為兩個(gè)步驟：

Day1: 設(shè)備通過定制鏡像自動(dòng)部署操作系統(tǒng)及集群，并實(shí)現(xiàn)自動(dòng)注冊

Day2: 按照編排需求，GitOps 自動(dòng)同步各類應(yīng)用到不同邊緣集群

可以看出，后者通過自動(dòng)化極大簡化了交付過程，從而提升了整體效率。如果平臺能夠提供足夠彈性的云邊協(xié)同方案以及高度自動(dòng)化交付，將為企業(yè)帶來強(qiáng)勁的邊緣計(jì)算建設(shè)助力。

現(xiàn)在，在實(shí)施大多數(shù)邊緣計(jì)算方案的時(shí)候，還需要在邊緣端投入不少的人力進(jìn)行前期工作，如操作系統(tǒng)安裝，半自動(dòng)化的 Kubernetes 發(fā)行版安裝以及云端注冊等，自動(dòng)化程度越高就越能降低人力成本。

—— 寫在最后 ——

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

以 Rancher 為例，作為最早的一款全開源的容器管理平臺，其 1.x 版本陪伴用戶走過了 docker swarm、mesos 和 Kubernetes 的三國鼎立時(shí)期；2.x 版本則緊跟社區(qū)和技術(shù)發(fā)展，專注于 Kubernetes 管理。一路走來，Rancher 積累了大量用戶，一直是全球使用人數(shù)最多的容器云管理平臺，它將始終致力于幫助用戶管理任意位置的 Kubernetes 集群，實(shí)現(xiàn)無處不在的計(jì)算。

在此過程中，我們也在不斷總結(jié)用戶的需求和痛點(diǎn)，圍繞 Kubernetes 推出了很多開源產(chǎn)品，如存儲產(chǎn)品 Longhorn，邊緣計(jì)算產(chǎn)品 K3s 和 Elemental，持續(xù)交付產(chǎn)品 Fleet，超融合產(chǎn)品 Harvester，個(gè)人使用產(chǎn)品 Rancher Desktop，安全產(chǎn)品 NeuVector。此外，我們?nèi)栽诓粩喾趸庐a(chǎn)品，如 CICD 產(chǎn)品 EPINIO，AiOps 產(chǎn)品 OPNI，旨在幫助用戶解決更多問題，通過 Rancher 更輕松地設(shè)計(jì)和構(gòu)建自己的云原生平臺。

審核編輯 ：李倩