了解產品詳情請戳-->嘉為藍鯨配置管理中心?鯨石(CMDB)

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

涉及關鍵詞：容器、CMDB、k8s、CMDB建設

CMDB納管容器這個話題的有趣點在于，一個已經誕生了幾十年老概念，在新的云原生時代真的還有存在的必要么？給一個我個人的結論——某些場景下是需要的。

01. 容器的存在形態與作用

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

容器的誕生無疑是一次重大的變革，稱它顛覆了傳統，重塑了軟件世界，至于容器的優勢這里就不一一細舉了（環境一致性、跨平臺、快速部署等等），但是需要關注的是，容器的出現改變團隊的交付效率和協作模式，Iac（基礎設施即代碼）屏蔽了底層復雜架構，快速標準的部署運行，讓研發人員更加聚焦業務邏輯，運維團隊也只需要聚焦與k8s本身的運維。（當然新技術也帶來更高的學習成本、新的架構復雜性等，也是對運維團隊新的挑戰）。

當團隊開始使用容器時，為了更加高效、高可用的使用和管理容器，k8s應運而生。隨后，人們會發現應用運行在容器上存在一系列的問題，如多個k8s怎么調度管理、k8s本身沒有應用的概念、鏡像倉庫如何管理等。于是容器管理平臺出現了。

當我們把相應的注冊中心、配置中心、監控運維、開發框架、部署發布等微服務搬上k8s，面對云原生微服務應用的解決方案需求迫切了。所以容器在企業中慢慢地長大并且融入到具體的解決場景中：docker、k8s、容器管理平臺（TKE、ACK等）、云原生解決方案（騰訊云TSF、阿里云SOFA等）

02. CMDB如何納管容器

講完容器的現狀，回到最初的話題，CMDB如何納管容器。這個話題其實可以拆分成四個子話題：CMDB應不應該納管容器？納管什么信息？怎么納管？納管之后的數據價值是什么？

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

當容器的形態在企業內頻繁變化且不統一時需要在CMDB中達成統一。換個角度而言，如果我們只使用騰訊云的TSF進行容器應用的開發運維、只使用TKE提供的容器服務，沒有自建k8s或者獨立運行的docker，那么這種情況下無需CMDB解決標準化和連接的問題，而如果企業同時使用TKE和ACK時，需要一個系統去抹平兩者之間對于應用的描述不一致的差異問題，這個系統不一定非的是CMDB，但是CMDB是最佳人選之一。

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

應用（邏輯的）和資源（實體的），CMDB本質納管的對象劃分就是邏輯的對象（以應用為大頭）和實體的對象（虛機、物理機、網絡設備等），并且建立它們之間的關系。容器的場景也是如此，只不過我們需要考慮容器不同形態下的特征設計不同的建模。

下面是k8s形態下CMDB模型的參考，核心兩個對象（應用、資源）的建模與關系：

下面是模型實例的一個DEMO：

我們可以看到有以下幾個特點：

1. k8s的資源對象本身其實是有弱的應用管理的概念，Namespace用于隔離的管理概念，我們可以利用這個作用域來隔離系統、或者環境等概念，看我們如何使用，此處的示例是將Namespace用來隔離應用系統（即一個Namespace獨屬于一個系統），這也是比較推薦的管理方式。
2. 在k8s資源對象中，工作負載是承載應用的，我們將這個概念對應到服務樹中的應用模塊的概念上。這里需要注意一個我們平時認知中的小誤區，對于研發和運維人員而言，「應用模塊」（應用服務、應用組件等，可能存在不同的叫法）這個概念是有區別的。對于研發而言「應用模塊」其實是研發態的對象，對應的本質是一個可以構建打包的工程代碼；而對于運維人員而言，這個「應用模塊」是運行態的，是一組相同代碼相同配置的服務實例的集合。在CMDB中的「應用模塊」指的是運行態。
3. 以上兩點的本質其實是將k8s的資源對象映射為我們日常管理應用的概念（服務樹、或者叫做應用拓撲）。所以上面圖例中虛線左側的兩個部分（應用系統拓撲、k8s資源對象）的核心是，通過規范的命名和管理方式使用k8s集群，將k8s資源數據管理在CMDB中形成應用和資源兩個視角的數據。
4. 右側部分可能讓人感到不解，主要是k8s之上的資源是應用運維關注與使用的對象，本身k8s的基礎運維還是針對組成k8s的節點和k8s本身。從基礎運維的視角而言，我們可以把k8s集群也當成一個重要系統，所以誕生了右側部分拓撲的概念。我們將所有k8s集群放在一起作為一個大的系統，按照k8s集群的維度、節點角色的維度進行服務樹的劃分與管理。

Q3：CMDB怎么納管信息？

面對容器化場景下海量的節點數量，CMDB納管的方式必定需要靠自動化，我們可以通過k8s的apiserver進行獲取k8s內部所有的資源對象信息，或者通過kubectl命令（kubectl本質上也是對接apiserver）行進行獲取。這里需要注意一點，當我們使用容器管理平臺提供容器服務時，本質上容器管理平臺是在k8s之上封裝的管理平臺，部分系統會完全封裝并且構建自己的鑒權體系，但是相關的數據接口和邏輯還是保持原生的k8s接口，例如下面是一個容器管理平臺對外暴露獲取namespace列表的接口：

它與原生k8s的api接口：

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

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

Q4：CMDB納管效益

當我們在CMDB中納管了容器的數據后，我們能獲得什么？

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

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

以上僅僅是一些CMDB建設的經驗，在云原生日益發展的階段，行業內其實并沒有一個非常統一的標準，每個企業的具體情況也不盡相同。如果有任何不同的意見或建議，歡迎交流，共同探討和進步。

03. 配置管理CMDB選型推薦

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