The cluster was sealed. No Wi-Fi, no internet, no bridge to the outside world. Yet data still needed to flow—in and out—without ever breaking the air gap.
Ingress resources in air-gapped environments are a quiet challenge. You can’t just open a port and let the world in. When nothing connects, every connection must be designed, not assumed. Kubernetes in an air-gapped setup forces you to rethink control, security, and distribution from the ground up.
The problem starts with the simple fact: ingress is built for connected networks. The classic controllers, load balancers, and DNS integrations reach out to APIs, perform automated certificate retrieval, and hook into managed services. None of that works when your cluster can’t touch the public internet. Each dependency on an external service becomes a point you must internalize.
In an air-gapped ingress design, you manage your own certificate authority. You run your own DNS zone. You package controllers—like NGINX Ingress Controller or Traefik—with all images stored in a private registry you own. You decide how updates are delivered. You are the operator, the provider, and the safety net.
Security is both harder and stronger here. Harder, because every feature you take for granted—automatic TLS renewals, cloud-native firewall rules, API-driven scaling—must be hand-rolled. Stronger, because no public endpoint exists to exploit. Each ingress point is a deliberate doorway, guarded within your own perimeter.