CMDB产品是否需要纳管容器信息？

按理说，通常是不需要纳管的，可以通过对接容器管理平台，进行实时的获取，如果需要进行基线处理，可以纳管，前提是场景适配的能力足够。
关于容器是否需要纳管容器信息，需要先说明CMDB在数据方面需要具备的几个特性，分别是灵活性，安全性，准确性和实时性。
灵活性方面， 灵活配置数据字段，现在的系统或者平台多样化，例如：云平台、Docker、物理机、虚拟机等等，这些在数据存储上字段都是有区别的，因此需要灵活配置字段可以兼容这些系统或平台。
安全性方面， 数据的安全是非常重要的，不能随意的去更改，因此一定要注意安全保障，如：设定严格的权限访问控制。
准确性方面， CMDB是数据存储的集合，是建设其他系统的数据基石，因此就需要保证CMDB的数据的准确性，否则会引起一些不必要的问题。
实时性方面，随着CMDB的场景越来越多，数据实时性方面越来越重要，除了 收集、更新数据的实时性方面，CMDB作为全域配置数据的中转中心，数据交互和数据关联的实时性也非常重要。
现在回到是否需要纳管容器信息，我个人认为是不需要的，因为容器的数据不断的变化，且颗粒度很小，而且更新非常频繁，如果通过CMDB纳管容器数据，会造成灵活性降低，且实时性的要求很难达到。但可以通过CMDB对容器的api进行数据层面的对接，在特定的业务场景中，通过服务目录或者自服务的方式进行流程驱动或数据驱动的编排。

容器纳管主要是看配置信息到哪一层级别，配置主要信息和不变的信息即可，变化的部分可忽略，比如主容器镜像名称版本，命名空间，类型，副本数，暴露的端口，容器名称，主要标签等我觉得还是纳管要好一点，具体在哪台主机，全称这些变化的信息也确实没法记录，可以不记录，仅代表个人看法，没有实践，仅供参考

CMDB纳管容器，首先看对数据的使用场景，对数据使用的价值，容器资源原本就有弹性伸缩的特性，针对pod无需纳管。
另外，单独纳管容器相关的资源意义不大，需要与上游应用资源进行联动，才能发挥更高的价值。

您好，
        容器信息变动频繁，没必要对其进行纳管。