Is it a good practice to discover and record containers in the CMDB or should we leave them

[EssnZilla]

Is it a good practice to discover and record containers in the CMDB or should we leave them and discovery only pods, images, services and workloads?

When you discover containers how do you manage stale ones? Is there an default staleness rule in the CMDB or we need to configure one? 
If so anyone can show how?

[Fabian Kunzke]

Hey,
So generally, this depends. As with all other topics on the discovery & the CMDB there is one core question:

Do you have a use-case for it?

If no, then don't do it. The container management is adding a lot of data to the CMDB, but if there is no use for that data, it will run stale no matter what.

If there is a yes for it, then let me dive a bit into how the container discovery works (as it is different from the "normal" discovery): The container discovery is done via API. This enables very frequent scheduling (like every 10 minutes) Reference: https://www.servicenow.com/docs/r/xanadu/it-operations-management/discovery/kubernetes-discovery.htm...

With that the discovery usually takes care of stale containers. As these are virtual items, they follow their own reduced lifecycle. So staleness is not an issue.

What is an issue is usually the orphan topic. Containers & their hosted applications must be related to service instances. Otherwise the data ingested to the CMDB is "just good to know". If you want to manage containers you will need to make sure that virtual resources are indeed related to service instances.

For that you can use tags, naming conventions, API ingestion or even Service Mapping.

So in short: Yes, you can do it. As it works via API you will need to treat it as an API. Hard part is to relate the virtual items to service instances. If you don't have a use-case for it, you will run the risk of investing effort into data which will run stale.

Hope this helps,

Regards

Fabian