The Kubernetes Visibility Problem

Kubernetes was supposed to simplify infrastructure. In many ways it has. But for anyone responsible for understanding, documenting, or securing a Kubernetes deployment, K8s introduces a visibility challenge that's arguably worse than what came before.

Consider a typical enterprise cluster:

47 deployments across 12 namespaces
134 services with complex selectors and label matching
23 ingress resources with TLS termination, path rewriting, and backend services
89 config maps and 34 secrets
16 custom resource definitions (CRDs) with custom controllers
Horizontal pod autoscalers, pod disruption budgets, network policies

In a traditional VM-based environment, you could at least SSH into a box and see what was running. In Kubernetes, the control plane manages the compute. If you don't have the right RBAC permissions and tooling, your cluster is a black box.

The average enterprise runs 6.2 Kubernetes clusters according to the CNCF Annual Survey. Many of those clusters were created by different teams, for different purposes, with different configurations. No single person understands the full picture.

Discovery at Scale: How Knowledge Tree Maps K8s

Knowledge Tree's Kubernetes discovery plugin connects to your clusters via kubeconfig or direct API server access and performs a comprehensive inventory. Here's what it discovers:

Cluster-Level Resources

Cluster information: API server version, kubelet versions, node count and health, add-on versions
Nodes: Instance type, capacity, taints, labels, conditions, pods scheduled
Namespaces: Status, resource quotas, limit ranges, network policies

Workload Resources

Deployments: Replica counts (desired, current, available), strategy (RollingUpdate vs Recreate), pod template spec, selector labels, revision history
StatefulSets: Ordinal index, pod management policy, update strategy, persistent volume claims
DaemonSets: Node selector, update strategy, pod template
Jobs and CronJobs: Schedule, concurrency policy, completion history, active deadlines
Pods: Status (Running, Pending, CrashLoopBackOff), resource requests/limits, node assignment, IP addresses, container images, restart count, conditions

Network Resources

Services: Type (ClusterIP, NodePort, LoadBalancer, ExternalName), cluster IP, external IP, ports, selector labels, session affinity
Ingresses: Host rules, TLS configuration, backend services, path types, annotations
NetworkPolicies: Pod selector, ingress/egress rules, policy types, IP block rules

Configuration Resources

ConfigMaps: Data keys, size, namespace, labels
Secrets: Type (Opaque, TLS, dockerconfigjson, etc.), keys, age
ServiceAccounts: Secrets, image pull secrets, automount configuration

The Relationship Graph: Where K8s Discovery Gets Powerful

Individual resources are useful. Relationships are transformative. Knowledge Tree's knowledge graph captures every connection between Kubernetes resources, giving you answers to questions like:

Impact Analysis

"Which services will be affected if we upgrade the nginx-ingress controller?"

The graph traces: Controller → DaemonSet → Pods → Services → Ingresses → Backend Services → Deployments → Pods

You see the full blast radius in seconds.

Configuration Propagation

"Which pods are using ConfigMap 'app-config-v3'?"

The graph shows every deployment, statefulset, and daemonset that mounts that config map — and every pod currently running with those settings.

Network Topology

"How does traffic flow from the internet to the database?"

Internet → Ingress (api.example.com) → Service (api-gateway) 
→ Pod (gateway-v2-7d8f9c) → Service (user-service)
→ Pod (users-v3-4a2b1c) → Service (postgres-primary)
→ StatefulSet Pod (postgres-0)

Each hop is a real connection discovered from your cluster state, not a theoretical diagram.

Real Scenario: The Multi-Cluster Migration

A Knowledge Tree customer managing 14 EKS clusters across 3 AWS accounts needed to migrate from one CNI plugin to another. The team knew the migration would be complex, but they didn't understand how complex until they saw the graph.

What the Graph Revealed

34 services in the "staging" namespace that were actually serving production traffic through a mesh ingress
7 deployments with no resource limits, running in the same node pool as critical workloads
2 ingresses pointing to services that no longer existed (404 errors for users for weeks)
12 config maps with identical data across namespaces (could be consolidated)
A single pod running a database that should have been a statefulset (the infamous "database in a single pod" anti-pattern)

The Migration Outcome

Armed with the knowledge graph, the team:

Cordoned nodes in dependency order, avoiding the cascade failures that would have occurred without the graph
Consolidated config maps from 12 down to 4, reducing configuration drift
Recreated the database as a proper statefulset during the migration window
Completed the migration in 3 days instead of the estimated 2 weeks

Practical Kubernetes Configurations

Here's a real-world example of what Knowledge Tree discovers and maps:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-processor
  namespace: payments
  labels:
    app: payment-processor
    environment: production
    team: payments
spec:
  replicas: 6
  selector:
    matchLabels:
      app: payment-processor
  template:
    spec:
      containers:
      - name: processor
        image: payments/processor:v2.4.1
        ports:
        - containerPort: 8080
        envFrom:
        - configMapRef:
            name: payment-config
        - secretRef:
            name: payment-secrets

Knowledge Tree captures this deployment, then discovers:

It's selected by Service/payment-svc in the same namespace
Ingress/payments.internal.example.com routes to payment-svc
ConfigMap/payment-config has 14 keys, last updated April 15
Secret/payment-secrets was created 8 months ago and should be rotated
The deployment mounts a PVC that's backed by an EBS gp3 volume
The pods are scheduled across 3 nodes in different availability zones

This level of detail, available instantly for every resource in every cluster, is what makes enterprise Kubernetes discovery actually useful.

Best Practices for K8s Discovery

Based on our deployments across enterprise environments, here are the practices that make Kubernetes discovery most effective:

1. Standardize Labeling

Discovery is only as good as your metadata. Ensure every resource has standard labels:

labels:
  app: <service-name>
  environment: production|staging|development
  team: <owner-team>
  tier: frontend|backend|data
  cost-center: <identifier>

2. Use Namespaces for Isolation

Organize by team, environment, or purpose. Discovery becomes far more valuable when namespaces have clear boundaries and ownership.

3. Annotate for Context

Annotations are free-form metadata that discovery tools can surface:

annotations:
  owner: "platform-team@company.com"
  runbook: "https://wiki/runbooks/payment-processor"
  pagerduty-service: "payment-processor-prod"

4. Regular Discovery Cadence

Run discovery on a schedule — Knowledge Tree supports cron-based discovery. Daily for production clusters, weekly for development. The knowledge graph updates incrementally, so you see changes in near real-time.

The Bottom Line

Kubernetes is powerful but complex. The same flexibility that makes K8s great for deployments makes it difficult to understand, secure, and document. Knowledge Tree's Kubernetes discovery gives you the complete picture — every resource, every relationship, every dependency — across all your clusters.

For enterprises running Kubernetes in production, this isn't optional. It's the difference between knowing and guessing.

Ready to see your Kubernetes infrastructure differently? Book a demo with your cluster data or start a free trial today.

Enterprise Kubernetes Discovery: From Chaos to Clarity