# Networking and request path

## Purpose and scope

This diagram orders the checks for a Kubernetes request from client name to
application response. It is a diagnostic route, not a claim that every request
uses every optional component or that a depicted failure exists now.

**Source:** `sources/request-path.mmd`  
**Generated:** `generated/request-path.svg`

![Kubernetes request path](generated/request-path.svg)

## Components and trust boundaries

DNS, public/local addressing, and TLS cross the external boundary. MetalLB and
Traefik own address advertisement and ingress routing. Services, selectors,
EndpointSlices, readiness, NetworkPolicy/Cilium, Pods, storage, and external
dependencies sit inside or beyond the workload boundary. Optional HTTP/TLS
probes leave the Kubernetes metadata boundary and must be explicitly enabled.

## Data flow and failure paths

Follow client → DNS → address → MetalLB → ingress → Service → EndpointSlice →
ready Pod → application. Check TLS/SNI, host/path, port mapping, selector,
endpoint readiness, policy/CNI, storage/dependencies, and response at the point
they influence the path. Stop at the first unsupported handoff; downstream
symptoms do not repair an upstream mismatch.

## Omissions and verification

Hostnames, addresses, certificate contents, credentials, probe targets, and
private findings are omitted. Healthy and broken read-only cluster path
snapshots are dated 13 July 2026. Active probing was disabled in the published
cluster snapshot; probe behavior was tested separately with loopback fixtures.

Related: [service-path analyzer](service-path-analyzer.md) and the ingress runbook.

**Validation:** `npm run diagrams:check`.