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.
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.
DNS
LoadBalancer
Traefik / Ingress
Service
EndpointSlice
Pod
Application probe
Architecture visual
The request path used to structure DNS, TLS, ingress, service, readiness, policy, and probe checks.
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.
Walks DNS, load-balancer allocation, ingress routing, Service selectors/ports, EndpointSlice readiness, and pod state
Checks served TLS, SNI, trust, expiry, protocol, and cert-manager status without reading Secret values
Reports NetworkPolicy and Cilium coverage without making optional APIs mandatory
Runs bounded HTTP/TLS probes only when an operator asks for active probing
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.
Checks shown here are project-specific; no portfolio-wide claim is applied automatically.
Healthy read-only cluster snapshot dated 13 July 2026; active probing disabled
Broken read-only cluster snapshot dated 13 July 2026; active probing disabled
Synthetic path fixtures
Loopback HTTP and TLS probe tests
Source review of unit and race-test coverage
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.