Bridging CMDB and Kubernetes Containers with Init, PostStart, and Event Monitoring

Background

Cloud Native 1.0 defines containers, micro‑services, immutable infrastructure, and declarative APIs. While containers are the ideal vehicle for micro‑services, selecting the appropriate control plane (CP) pattern—registration‑center CP, cloud‑native gateway CP, ServiceMesh CP, or CMDB‑based CP—poses challenges.

In practice, architectures evolve from registration‑center to gateway to ServiceMesh, but many environments lack a registration center or a cloud‑native gateway. Combining micro‑services, CMDB, and a gateway can still achieve service reachability.

How Does Micro‑service Access Work?

Gateway + CMDB handle application routing and system association.

Micro‑service + CMDB link application systems with server resources.

CMDB acts as the bridge in the access chain, providing crucial data support in traditional architectures.

Challenges with Overlay vs. Underlay Networks

Container IP changes and network selection create problems:

Overlay networks require registration‑center or ServiceMesh for east‑west traffic, limiting CMDB integration.

Underlay networks allow container IPs to map directly to business subnets, enabling CMDB to associate business, application systems, and container IPs.

Frequent container lifecycle changes diminish the effectiveness of CMDB agents, making a gradual, open‑ended transition essential.

Proposed Solution: Init Container + PostStart

The Kubernetes pod lifecycle provides three native hooks:

Init container : Runs before application containers; must complete successfully before the pod proceeds.

PostStart hook : Executes immediately after container creation, but not guaranteed before the ENTRYPOINT.

PreStop hook : Invoked before container termination, allowing cleanup.

Using these hooks, container metadata (IP, name, etc.) can be registered to CMDB:

Init containers can register information early, ensuring accuracy.

PostStart can also register data if Init containers are not used.

Readiness and Liveness probes must succeed before the data is considered usable.

If the container fails to start, PreStop can deregister the information.

Key considerations:

Init‑based registration is preferred because PostStart may report before readiness checks, producing noisy data.

Both PostStart and PreStop only support simple command lines; complex JSON arguments are split by commas, leading to errors.

K8s Event Monitoring + MQ

Events are reports of state changes in the cluster; they have limited retention and evolve over time.

Event‑driven architecture involves:

An event‑listener service that periodically syncs events from the kube‑apiserver.

Health checks to ensure only healthy services publish messages to the message queue (MQ).

The listener acts as an MQ producer, customizing event payloads (namespace, IP, port, etc.) and publishing to a topic.

Consumers (written in Go, Python, Java, etc.) read the topic and register/deregister resources in CMDB or other components.

Advantages: flexibility and control.

Drawbacks: increased integration cost, potential instability from added components, and the need to handle message idempotency.

Summary

In containerized environments, a CMDB‑based control plane can coexist with existing architectures, providing a transitional bridge. However, changing the overall architecture requires coordinated effort and cannot be achieved overnight.