Korab CenajEngineering case studyAll case studies

Open engineering project · Path snapshots dated 13 July 2026

Kubernetes Service Path Analyzer

A Go diagnostic tool that reconstructs the Kubernetes request path from DNS to application and identifies the first transition where declared configuration, observed state, or a bounded probe no longer agrees.

Project type
Infrastructure Tool
Domain
Networking and service delivery
Language
Go
Status
Validated

Executive summary

Operational problem

A Service can be present while DNS, the load-balancer address, ingress route, target port, EndpointSlice, TLS certificate, or policy prevents traffic from reaching a ready pod. Checking each object in isolation hides the first broken handoff.

Implemented solution

The analyzer walks declared and observed relationships from DNS through MetalLB, Traefik, Service ports and selectors, EndpointSlices, pods, certificates, NetworkPolicy, and Cilium. Optional DNS, TLS, HTTP, and loopback probes test only explicitly enabled routes. Each stage records its result, confidence, and inspection gaps before the next handoff is assessed.

Outcome

A failure becomes a path decision: the report can show whether the mismatch first appears at naming, routing, service selection, endpoint readiness, TLS, policy, or the application probe, rather than presenting a flat list of Kubernetes objects.

Technical and operational context

The path model treats network troubleshooting as testable contracts: names resolve, routes select, ports match, endpoints are ready, policy permits traffic, and an explicitly scoped application probe answers.

Architecture

Typed and dynamic Kubernetes discovery is combined with Go DNS, HTTP, and TLS clients. A path graph feeds stage analyzers, findings, stable JSON/Markdown renderers, and identifier sanitization.

  1. DNS
  2. LoadBalancer
  3. Traefik / Ingress
  4. Service
  5. EndpointSlice
  6. Pod
  7. Application probe

Architecture visual

Kubernetes request path from DNS and ingress through Service, EndpointSlice, Pod, and dependencies

The request path used to structure DNS, TLS, ingress, service, readiness, policy, and probe checks.

Read the diagram notes

Implementation

The analyzer walks declared and observed relationships from DNS through MetalLB, Traefik, Service ports and selectors, EndpointSlices, pods, certificates, NetworkPolicy, and Cilium. Optional DNS, TLS, HTTP, and loopback probes test only explicitly enabled routes. Each stage records its result, confidence, and inspection gaps before the next handoff is assessed.

Key decisions and trade-offs

Follow the path in order

The tool starts at the client-facing name and moves toward the pod, comparing the contract at each handoff. Finding the first divergence is more actionable than listing every downstream symptom, although external DNS and client-side state can still require checks outside Kubernetes.

Keep discovery separate from probing

Kubernetes inspection remains read-only; active HTTP or TLS checks require an explicit option and use bounded timeouts. This avoids unexpected network traffic during inventory collection. The tradeoff is that a discovery-only run cannot prove the application response or the client’s exact route.

Make optional integrations informative

Traefik, Cilium, MetalLB, and cert-manager enrich the diagnosis when their APIs are available. Denial or absence becomes a stage-specific coverage limit rather than aborting the whole report. This keeps the core portable but makes confidence depend on the installed integrations.

Normalize output for review

Stable pseudonyms and ordering make reports comparable in pull requests and incident notes without publishing private topology. Reviewers lose direct operational names, so the local unsanitized run remains necessary when an operator needs to execute the recommended command.

Security, reliability, and observability

Opt-in active probing

Cluster discovery remains read-only. DNS, HTTP, and TLS probes require explicit operator intent and bounded timeouts so inventory does not create unexpected traffic.

TLS without Secret reads

The analyzer inspects certificate metadata and the served handshake rather than reading TLS Secret values, keeping configured state separate from client-observed identity.

Observation boundaries

Declared NetworkPolicy, Cilium coverage, EndpointSlice readiness, and optional Hubble flows are reported as different evidence types; absent runtime flow data remains visible.

Infrastructure concepts demonstrated

Published evidence

Sanitized healthy service path

Sanitized live output
HEALTHY — namespace-3af2e4/resource-1ba899
Confidence: 95%
[PASS] Service → EndpointSlice → Pod
Ready endpoints: 1 · targetPort: 3000
[PASS] Cilium dataplane · agents ready: 5/5

Validation

Checks shown here are project-specific; no portfolio-wide claim is applied automatically.

Evidence and links

Links are limited to public-safe source material and sanitized evidence. Credentials, state, plans, identifiers, private topology, and backup contents are intentionally excluded.

Lessons learned

Limitations

  • Full Cilium L7 conclusions require observed Hubble flow data.
  • DNS results can vary by resolver location and cache state.
  • A successful bounded probe proves only the tested route, protocol, and moment in time.

Next improvement

Correlate optional Hubble flow samples with the declared path while preserving the current no-runtime-dependency CLI design.