【CMDB系列】CMDB纳管容器详解

了解产品详情请戳-->嘉为蓝鲸配置管理中心•鲸石(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 运维大模型工具，已在广州公交集团、鹏华基金、福田汽车、北京移动、苏州市信息中心等众多行业客户中成功应用，助力企业实现数字化运维转型。