本文详细介绍了企业中“容器”的概念、形态及作用，并探讨了CMDB纳管容器在云原生时代存在的必要性、

应不应该纳管容器、应该纳管什么信息、怎么纳管，以及纳管之后的数据价值是什么，并提出了企业CMDB建设建议。

CMDB纳管容器这个话题的有趣点在于，一个已经诞生了几十年老概念，在新的云原生时代真的还有存在的必要么？给一个我个人的结论——某些场景下是需要的。

在讨论这个话题之前，我们先来看看

“容器”这个概念在企业中的存在形态和它的作用。

容器的诞生无疑是一次重大的变革，称它颠覆了传统，重塑了软件世界，至于容器的优势这里就不一一细举了（环境一致性、跨平台、快速部署等等），但是需要关注的是，容器的出现改变团队的交付效率和协作模式，Iac（基础设施即代码）屏蔽了底层复杂架构，快速标准的部署运行，让研发人员更加聚焦业务逻辑，运维团队也只需要聚焦与k8s本身的运维。（当然新技术也带来更高的学习成本、新的架构复杂性等，也是对运维团队新的挑战）。

当团队开始使用容器时，为了更加高效、高可用的使用和管理容器，k8s应运而生。随后，人们会发现应用运行在容器上存在一系列的问题，如多个k8s怎么调度管理、k8s本身没有应用的概念、镜像仓库如何管理等。于是容器管理平台出现了。

当我们把相应的注册中心、配置中心、监控运维、开发框架、部署发布等微服务搬上k8s，面对云原生微服务应用的解决方案需求迫切了。所以容器在企业中慢慢地长大并且融入到具体的解决场景中：docker、k8s、容器管理平台（TKE、ACK等）、云原生解决方案（腾讯云TSF、阿里云SOFA等）

讲完容器的现状，回到最初的话题，CMDB如何纳管容器。这个话题其实可以拆分成四个子话题：CMDB应不应该纳管容器？纳管什么信息？怎么纳管？纳管之后的数据价值是什么？

Q1：CMDB在什么情况下需要纳管容器？

当容器的形态在企业内频繁变化且不统一时需要在CMDB中达成统一。换个角度而言，如果我们只使用腾讯云的TSF进行容器应用的开发运维、只使用TKE提供的容器服务，没有自建k8s或者独立运行的docker，那么这种情况下无需CMDB解决标准化和连接的问题，而如果企业同时使用TKE和ACK时，需要一个系统去抹平两者之间对于应用的描述不一致的差异问题，这个系统不一定非的是CMDB，但是CMDB是最佳人选之一。

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

应用（逻辑的）和资源（实体的），CMDB本质纳管的对象划分就是逻辑的对象（以应用为大头）和实体的对象（虚机、物理机、网络设备等），并且建立它们之间的关系。容器的场景也是如此，只不过我们需要考虑容器不同形态下的特征设计不同的建模。

下面是k8s形态下CMDB模型的参考，核心两个对象（应用、资源）的建模与关系：

我们可以看到有以下几个特点：

面对容器化场景下海量的节点数量，CMDB纳管的方式必定需要靠自动化，

我们可以通过k8s的apiserver进行获取k8s内部所有的资源对象信息，或者通过kubectl命令（kubectl本质上也是对接apiserver）行进行获取。这里需要注意一点，当我们使用容器管理平台提供容器服务时，本质上容器管理平台是在k8s之上封装的管理平台，部分系统会完全封装并且构建自己的鉴权体系，但是相关的数据接口和逻辑还是保持原生的k8s接口，例如下面是一个容器管理平台对外暴露获取namespace列表的接口：

差别在于密钥来源于容器管理平台，接口地址加入了cluster_id这个属性用于容器管理平台区分所纳管的多个k8s集群，而后面的接口地址其实并没有变化，返回参数也与原生的没有差别。

CMDB的自动化采集逻辑一般都是周期从某个数据源拉取数据

（因为CMDB与监控不同，纳管的数据相对静态，对于数据变化实时性要求不高），但是在容器的场景下，容器本身就是具备高可用、快速部署的特性，工作负载、pod的变化相对会比较快，那么在容器的场景下，通过监听 k8s的资源变化事件，在第一次初始化数据之后，监听增量的数据变化同步到CMDB的这种方案成为了最佳选择。（k8s也提供了相关watch的接口）

当我们在CMDB中纳管了容器的数据后，我们能获得什么？

最后提醒一下，容器能够屏蔽底层基础架构的特性其实是让研发与运维的工作分界那条线右移了，研发一定程度上在镜像中解决了基础环境的一致性，但是这会让运维一定程度上失去了对基础资源的掌控。举个例子，在容器化的场景下，研发会递过来一个黑盒子，运维接过来后他根本不知道黑盒子里面是什么（不知道里面是否用了rabbitmq、是否用了redis，用了什么tomcat版本等等）。那么在安全、架构性能等过往运维深度考虑的因素时，因为容器这个隔离的特性，运维将失去直接的掌控。这对研发团队的技能就有了要求，研发需要具备相关的运维知识，并且能够将镜像内的关键信息通过label或者注解的方式维护在k8s中，不能让pod成为彻底的黑盒，避免在业务运转中的故障排查中起到负面作用。

以上仅仅是一些CMDB建设的经验，在云原生日益发展的阶段，行业内其实并没有一个非常统一的标准，每个企业的具体情况也不尽相同。如果有任何不同的意见或建议，欢迎交流，共同探讨和进步。

嘉为蓝鲸配置管理中心・鲸石 (CMDB)以应用为中心，以配置消费为目的，构建新一代配置管理数据库系统，为企业IT运维体系提供可信有效的数据支撑。嘉为蓝鲸CMDB采用四层架构设计，深度自动发现支持各类IT资源的自动发现和数据采集；无缝流程联动与ITSM天然融合，实现流程数据自动同步；灵活数据消费提供120+API 接口，支持多场景数据消费；闭环数据治理建立完整的数据质量保障体系。核心功能包括配置数据维护、配置数据报表、配置可视化拓扑、配置权限管控和配置数据采集五大模块，具备高性能海量实践（支持2000W+实例管理）、异构兼容纳管、自动化覆盖率80%以上、闭环数据治理等亮点特性。产品全面支持信创生态，接入 AI 运维大模型工具，已在广州公交集团、鹏华基金、福田汽车、北京移动、苏州市信息中心等众多行业客户中成功应用，助力企业实现数字化运维转型。

CMDB纳管容器技术拆解：覆盖Docker/K8s，容器资产统一管控指南

本文将带领大家探索CMDB纳管容器在云原生时代的重要性。助力企业理清如何运用CMDB统一管理多平台，通过建立应用与资源映射，建立自动化采集及事件监听等，提升企业运维效率。

市场

云计算

运维

架构设计

探讨企业CMDB在云原生时代如何纳管容器，分析容器形态变化带来的管理挑战，提出CMDB应纳管应用与资源信息，通过自动化采集k8s数据实现统一管理，解决多容器平台标准不统一问题，建立应用连接关系，提升运维效率。

容器服务

应用管理

数据接口

数据管理

数据治理

云原生

虚拟机

数据库

Docker

容器

AI驱动 智领未来

腾讯云BI新客户首次购买9.9元起！


tencentdb-catalog

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

CMDB纳管容器技术拆解：覆盖Docker/K8s，容器资产统一管控指南

CMDB纳管容器技术拆解：覆盖Docker/K8s，容器资产统一管控指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐