Skip to main content

Kubernetes Discovery Is Easy. Knowing What Talks to What Is the Hard Part.

· 2 min read

Listing what runs on a Kubernetes cluster is a solved problem. Point an API token at it and you get every Deployment, Service, and Ingress in seconds.

That's the easy 20%. The 80% that matters in a CMDB is the question the API can't answer: what depends on what?

Here's why that's genuinely hard on Kubernetes — and how we cracked it.

🚫 Reading the node's connection table doesn't work. On a modern CNI, every pod has its own network namespace. The host never sees the pod's outbound sockets. You get half the conversation.

🚫 eBPF syscall tracing (watching connect()) only catches new, outbound, external connections. It's blind to the two things you most need: • Warm connection pools — apps open a connection once at startup and reuse it for hours, so no syscall ever fires for the busiest, most critical dependency. • Intra-cluster traffic — service-A → service-B inside the cluster, the core of your graph, gets filtered out.

✅ The fix: observe the datapath, not the syscall. Cilium Hubble watches packets actually flowing — so warm pools and internal service-to-service calls show up, language-agnostic, whether it's JBoss, Spring Boot, Go, or Node. We aggregate those flows to the Deployment level and write them into the CMDB as real relationships.

Then the payoff — turning that graph into a service map:

🧩 A namespace becomes a Business Service, deterministically. Members from the containment tree. Internal tiers (web → api → cache) from intra-namespace traffic. Service-to-service dependencies from cross-namespace traffic. External & data dependencies — the Oracle RAC, the partner API, the legacy SQL Server on a VM — from the edges leaving the cluster.

🎯 And the highest-value part: the boundary. When you can patch a SQL Server on a Windows VM and instantly see every Kubernetes workload that will feel it — next to the traditional servers that will feel it — that's change impact analysis that finally tells the truth.

Kubernetes discovery is table stakes. The value is the question that comes next: what breaks when this goes down?

That's not a discovery question. It never was.

Full write-up on the blog 👇 www.tripl-i.com

#Kubernetes #CMDB #ITDiscovery #ServiceMapping #AIOps #eBPF #Cilium #Observability #DependencyMapping #PlatformEngineering