了解產(chǎn)品詳情請(qǐng)戳-->嘉為藍(lán)鯨配置管理中心?鯨石(CMDB)

摘要：本文詳細(xì)介紹了企業(yè)中“容器”的概念、形態(tài)及作用，并探討了CMDB納管容器在云原生時(shí)代存在的必要性、CMDB應(yīng)不應(yīng)該納管容器、應(yīng)該納管什么信息、怎么納管，以及納管之后的數(shù)據(jù)價(jià)值是什么，并提出了企業(yè)CMDB建設(shè)建議。

涉及關(guān)鍵詞：容器、CMDB、k8s、CMDB建設(shè)

CMDB納管容器這個(gè)話題的有趣點(diǎn)在于，一個(gè)已經(jīng)誕生了幾十年老概念，在新的云原生時(shí)代真的還有存在的必要么？給一個(gè)我個(gè)人的結(jié)論——某些場(chǎng)景下是需要的。

01. 容器的存在形態(tài)與作用

在討論這個(gè)話題之前，我們先來看看“容器”這個(gè)概念在企業(yè)中的存在形態(tài)和它的作用。

容器的誕生無(wú)疑是一次重大的變革，稱它顛覆了傳統(tǒng)，重塑了軟件世界，至于容器的優(yōu)勢(shì)這里就不一一細(xì)舉了（環(huán)境一致性、跨平臺(tái)、快速部署等等），但是需要關(guān)注的是，容器的出現(xiàn)改變團(tuán)隊(duì)的交付效率和協(xié)作模式，Iac（基礎(chǔ)設(shè)施即代碼）屏蔽了底層復(fù)雜架構(gòu)，快速標(biāo)準(zhǔn)的部署運(yùn)行，讓研發(fā)人員更加聚焦業(yè)務(wù)邏輯，運(yùn)維團(tuán)隊(duì)也只需要聚焦與k8s本身的運(yùn)維。（當(dāng)然新技術(shù)也帶來更高的學(xué)習(xí)成本、新的架構(gòu)復(fù)雜性等，也是對(duì)運(yùn)維團(tuán)隊(duì)新的挑戰(zhàn)）。

當(dāng)團(tuán)隊(duì)開始使用容器時(shí)，為了更加高效、高可用的使用和管理容器，k8s應(yīng)運(yùn)而生。隨后，人們會(huì)發(fā)現(xiàn)應(yīng)用運(yùn)行在容器上存在一系列的問題，如多個(gè)k8s怎么調(diào)度管理、k8s本身沒有應(yīng)用的概念、鏡像倉(cāng)庫(kù)如何管理等。于是容器管理平臺(tái)出現(xiàn)了。

當(dāng)我們把相應(yīng)的注冊(cè)中心、配置中心、監(jiān)控運(yùn)維、開發(fā)框架、部署發(fā)布等微服務(wù)搬上k8s，面對(duì)云原生微服務(wù)應(yīng)用的解決方案需求迫切了。所以容器在企業(yè)中慢慢地長(zhǎng)大并且融入到具體的解決場(chǎng)景中：docker、k8s、容器管理平臺(tái)（TKE、ACK等）、云原生解決方案（騰訊云TSF、阿里云SOFA等）

02. CMDB如何納管容器

講完容器的現(xiàn)狀，回到最初的話題，CMDB如何納管容器。這個(gè)話題其實(shí)可以拆分成四個(gè)子話題：CMDB應(yīng)不應(yīng)該納管容器？納管什么信息？怎么納管？納管之后的數(shù)據(jù)價(jià)值是什么？

Q1：CMDB在什么情況下需要納管容器？

當(dāng)容器的形態(tài)在企業(yè)內(nèi)頻繁變化且不統(tǒng)一時(shí)需要在CMDB中達(dá)成統(tǒng)一。換個(gè)角度而言，如果我們只使用騰訊云的TSF進(jìn)行容器應(yīng)用的開發(fā)運(yùn)維、只使用TKE提供的容器服務(wù)，沒有自建k8s或者獨(dú)立運(yùn)行的docker，那么這種情況下無(wú)需CMDB解決標(biāo)準(zhǔn)化和連接的問題，而如果企業(yè)同時(shí)使用TKE和ACK時(shí)，需要一個(gè)系統(tǒng)去抹平兩者之間對(duì)于應(yīng)用的描述不一致的差異問題，這個(gè)系統(tǒng)不一定非的是CMDB，但是CMDB是最佳人選之一。

Q2：CMDB需要納管容器的什么信息？

應(yīng)用（邏輯的）和資源（實(shí)體的），CMDB本質(zhì)納管的對(duì)象劃分就是邏輯的對(duì)象（以應(yīng)用為大頭）和實(shí)體的對(duì)象（虛機(jī)、物理機(jī)、網(wǎng)絡(luò)設(shè)備等），并且建立它們之間的關(guān)系。容器的場(chǎng)景也是如此，只不過我們需要考慮容器不同形態(tài)下的特征設(shè)計(jì)不同的建模。

下面是k8s形態(tài)下CMDB模型的參考，核心兩個(gè)對(duì)象（應(yīng)用、資源）的建模與關(guān)系：

下面是模型實(shí)例的一個(gè)DEMO：

我們可以看到有以下幾個(gè)特點(diǎn)：

1. k8s的資源對(duì)象本身其實(shí)是有弱的應(yīng)用管理的概念，Namespace用于隔離的管理概念，我們可以利用這個(gè)作用域來隔離系統(tǒng)、或者環(huán)境等概念，看我們?nèi)绾问褂茫颂幍氖纠菍amespace用來隔離應(yīng)用系統(tǒng)（即一個(gè)Namespace獨(dú)屬于一個(gè)系統(tǒng)），這也是比較推薦的管理方式。
2. 在k8s資源對(duì)象中，工作負(fù)載是承載應(yīng)用的，我們將這個(gè)概念對(duì)應(yīng)到服務(wù)樹中的應(yīng)用模塊的概念上。這里需要注意一個(gè)我們平時(shí)認(rèn)知中的小誤區(qū)，對(duì)于研發(fā)和運(yùn)維人員而言，「應(yīng)用模塊」（應(yīng)用服務(wù)、應(yīng)用組件等，可能存在不同的叫法）這個(gè)概念是有區(qū)別的。對(duì)于研發(fā)而言「應(yīng)用模塊」其實(shí)是研發(fā)態(tài)的對(duì)象，對(duì)應(yīng)的本質(zhì)是一個(gè)可以構(gòu)建打包的工程代碼；而對(duì)于運(yùn)維人員而言，這個(gè)「應(yīng)用模塊」是運(yùn)行態(tài)的，是一組相同代碼相同配置的服務(wù)實(shí)例的集合。在CMDB中的「應(yīng)用模塊」指的是運(yùn)行態(tài)。
3. 以上兩點(diǎn)的本質(zhì)其實(shí)是將k8s的資源對(duì)象映射為我們?nèi)粘９芾響?yīng)用的概念（服務(wù)樹、或者叫做應(yīng)用拓?fù)洌?。所以上面圖例中虛線左側(cè)的兩個(gè)部分（應(yīng)用系統(tǒng)拓?fù)?、k8s資源對(duì)象）的核心是，通過規(guī)范的命名和管理方式使用k8s集群，將k8s資源數(shù)據(jù)管理在CMDB中形成應(yīng)用和資源兩個(gè)視角的數(shù)據(jù)。
4. 右側(cè)部分可能讓人感到不解，主要是k8s之上的資源是應(yīng)用運(yùn)維關(guān)注與使用的對(duì)象，本身k8s的基礎(chǔ)運(yùn)維還是針對(duì)組成k8s的節(jié)點(diǎn)和k8s本身。從基礎(chǔ)運(yùn)維的視角而言，我們可以把k8s集群也當(dāng)成一個(gè)重要系統(tǒng)，所以誕生了右側(cè)部分拓?fù)涞母拍睢Ｎ覀儗⑺衚8s集群放在一起作為一個(gè)大的系統(tǒng)，按照k8s集群的維度、節(jié)點(diǎn)角色的維度進(jìn)行服務(wù)樹的劃分與管理。

Q3：CMDB怎么納管信息？

面對(duì)容器化場(chǎng)景下海量的節(jié)點(diǎn)數(shù)量，CMDB納管的方式必定需要靠自動(dòng)化，我們可以通過k8s的apiserver進(jìn)行獲取k8s內(nèi)部所有的資源對(duì)象信息，或者通過kubectl命令（kubectl本質(zhì)上也是對(duì)接apiserver）行進(jìn)行獲取。這里需要注意一點(diǎn)，當(dāng)我們使用容器管理平臺(tái)提供容器服務(wù)時(shí)，本質(zhì)上容器管理平臺(tái)是在k8s之上封裝的管理平臺(tái)，部分系統(tǒng)會(huì)完全封裝并且構(gòu)建自己的鑒權(quán)體系，但是相關(guān)的數(shù)據(jù)接口和邏輯還是保持原生的k8s接口，例如下面是一個(gè)容器管理平臺(tái)對(duì)外暴露獲取namespace列表的接口：

它與原生k8s的api接口：

差別在于密鑰來源于容器管理平臺(tái)，接口地址加入了cluster_id這個(gè)屬性用于容器管理平臺(tái)區(qū)分所納管的多個(gè)k8s集群，而后面的接口地址其實(shí)并沒有變化，返回參數(shù)也與原生的沒有差別。

這里還需要注意一點(diǎn)，CMDB的自動(dòng)化采集邏輯一般都是周期從某個(gè)數(shù)據(jù)源拉取數(shù)據(jù)（因?yàn)镃MDB與監(jiān)控不同，納管的數(shù)據(jù)相對(duì)靜態(tài)，對(duì)于數(shù)據(jù)變化實(shí)時(shí)性要求不高），但是在容器的場(chǎng)景下，容器本身就是具備高可用、快速部署的特性，工作負(fù)載、pod的變化相對(duì)會(huì)比較快，那么在容器的場(chǎng)景下，通過監(jiān)聽 k8s的資源變化事件，在第一次初始化數(shù)據(jù)之后，監(jiān)聽增量的數(shù)據(jù)變化同步到CMDB的這種方案成為了最佳選擇。（k8s也提供了相關(guān)watch的接口）

Q4：CMDB納管效益

當(dāng)我們?cè)贑MDB中納管了容器的數(shù)據(jù)后，我們能獲得什么？

1. 統(tǒng)一的規(guī)范：在不同的容器管理平臺(tái)中，對(duì)于應(yīng)用、服務(wù)等的描述其實(shí)并不相同，但是底層的k8s資源對(duì)象是一致的，將數(shù)據(jù)匯聚在CMDB中可以消除因?yàn)椴煌w系的概念差異進(jìn)而造成的協(xié)作損耗。
2. 建立應(yīng)用的連接：應(yīng)用和容器在CMDB進(jìn)行連接，我總算能夠清楚我的應(yīng)用系統(tǒng)容器化程度如何，它運(yùn)行在哪些云的容器服務(wù)上，哪些服務(wù)運(yùn)行在虛擬機(jī)上，為日常的變更、故障排查提供有力的支撐。

最后提醒一下，容器能夠屏蔽底層基礎(chǔ)架構(gòu)的特性其實(shí)是讓研發(fā)與運(yùn)維的工作分界那條線右移了，研發(fā)一定程度上在鏡像中解決了基礎(chǔ)環(huán)境的一致性，但是這會(huì)讓運(yùn)維一定程度上失去了對(duì)基礎(chǔ)資源的掌控。舉個(gè)例子，在容器化的場(chǎng)景下，研發(fā)會(huì)遞過來一個(gè)黑盒子，運(yùn)維接過來后他根本不知道黑盒子里面是什么（不知道里面是否用了rabbitmq、是否用了redis，用了什么tomcat版本等等）。那么在安全、架構(gòu)性能等過往運(yùn)維深度考慮的因素時(shí)，因?yàn)槿萜鬟@個(gè)隔離的特性，運(yùn)維將失去直接的掌控。這對(duì)研發(fā)團(tuán)隊(duì)的技能就有了要求，研發(fā)需要具備相關(guān)的運(yùn)維知識(shí)，并且能夠?qū)㈢R像內(nèi)的關(guān)鍵信息通過label或者注解的方式維護(hù)在k8s中，不能讓pod成為徹底的黑盒，避免在業(yè)務(wù)運(yùn)轉(zhuǎn)中的故障排查中起到負(fù)面作用。

以上僅僅是一些CMDB建設(shè)的經(jīng)驗(yàn)，在云原生日益發(fā)展的階段，行業(yè)內(nèi)其實(shí)并沒有一個(gè)非常統(tǒng)一的標(biāo)準(zhǔn)，每個(gè)企業(yè)的具體情況也不盡相同。如果有任何不同的意見或建議，歡迎交流，共同探討和進(jìn)步。

03. 配置管理CMDB選型推薦

嘉為藍(lán)鯨配置管理中心?鯨石 (CMDB)以應(yīng)用為中心，以配置消費(fèi)為目的，構(gòu)建新一代配置管理數(shù)據(jù)庫(kù)系統(tǒng)，為企業(yè)IT運(yùn)維體系提供可信有效的數(shù)據(jù)支撐。嘉為藍(lán)鯨CMDB采用四層架構(gòu)設(shè)計(jì)，深度自動(dòng)發(fā)現(xiàn)支持各類IT資源的自動(dòng)發(fā)現(xiàn)和數(shù)據(jù)采集；無(wú)縫流程聯(lián)動(dòng)與ITSM天然融合，實(shí)現(xiàn)流程數(shù)據(jù)自動(dòng)同步；靈活數(shù)據(jù)消費(fèi)提供120+API 接口，支持多場(chǎng)景數(shù)據(jù)消費(fèi)；閉環(huán)數(shù)據(jù)治理建立完整的數(shù)據(jù)質(zhì)量保障體系。核心功能包括配置數(shù)據(jù)維護(hù)、配置數(shù)據(jù)報(bào)表、配置可視化拓?fù)?、配置?quán)限管控和配置數(shù)據(jù)采集五大模塊，具備高性能海量實(shí)踐（支持2000W+實(shí)例管理）、異構(gòu)兼容納管、自動(dòng)化覆蓋率80%以上、閉環(huán)數(shù)據(jù)治理等亮點(diǎn)特性。產(chǎn)品全面支持信創(chuàng)生態(tài)，接入 AI 運(yùn)維大模型工具，已在廣州公交集團(tuán)、鵬華基金、福田汽車、北京移動(dòng)、蘇州市信息中心等眾多行業(yè)客戶中成功應(yīng)用，助力企業(yè)實(shí)現(xiàn)數(shù)字化運(yùn)維轉(zhuǎn)型。