Ingress, Egress, and the Borders of the Mesh

Doctrine

Traffic is authority. Whoever controls ingress and egress controls exposure, identity, and failure modes.

Kubblai doctrine: borders must be explicit, monitored, and deliberately constrained.

Ingress is a controller, not a YAML object

Ingress resources are declarations. The real system is the ingress controller: its configuration model, its reload behavior, its failure semantics, and its capacity under load.

Treat the ingress controller like any other critical system component: observe it, scale it, and test it under failure.

• Know your ingress class and how it maps to controllers.
• Understand configuration reload and whether it is disruptive.
• Budget for TLS and request processing overhead.

Egress: the ungoverned perimeter

Most clusters start with effectively unrestricted egress. At small scale, it feels productive. At real scale, it is how secrets leave, malware phones home, and data exfiltration becomes plausible.

If you enforce ingress but ignore egress, you have governed half a boundary.

• Prefer explicit egress allow-lists for sensitive namespaces.
• Instrument DNS and egress destinations; visibility precedes control.
• Treat outbound proxying as a platform component with SLOs.

Operational failure modes

Border systems fail in recognizable ways; design for them.

• Ingress 503s due to readiness/endpoint mismatch; don’t debug at L7 first—prove endpoints.
• Controller overload: config reload storms, CPU saturation, queueing latency.
• TLS certificate rotation failures; treat cert lifecycle as operations, not ceremony.
• Egress restrictions that break dependencies; roll out with telemetry.