Make the networking model easy to reason about: a single Gateway receives HTTPS on *.nip.io and routes to internal Services. TLS is terminated at the edge; cert-manager provisions the wildcard cert.

Big picture

Detailed Networking Architecture

This diagram shows the complete network path from external clients through Cilium CNI to backend pods.

Network Flow Explanation

External clients connect to NodePort (30443) on any cluster node where Cilium CNI handles pod networking using eBPF datapath and the NodePort Service forwards traffic to the Gateway implementation. The GatewayClass defines how Gateways are implemented (cilium-nodeport), the Gateway resource creates an HTTPS listener on .nip.io with TLS termination, and HTTPRoute resources define hostname-based routing to backend Services. cert-manager automates the certificate lifecycle where ClusterIssuer uses internal CA (idp-demo-ca) and a wildcard certificate (.nip.io) is issued and mounted into the Gateway. Services provide stable ClusterIP endpoints while pods implement the actual application logic.

NetworkPolicies

Cilium supports NetworkPolicies for L3/L4 and L7 network segmentation. This platform has Cilium configured but NetworkPolicies are not yet implemented.

Planned NetworkPolicy strategy:

The roadmap includes a default-deny stance in production namespaces, with explicit allow rules for required communication. L7 policies will enforce HTTP-specific controls, such as restricting methods to GET or POST.

See Security & Policy Model for the security roadmap.

Decision: Gateway API over Ingress

The platform uses Gateway API, not traditional Ingress resources, for a few reasons:

Gateway API separates infrastructure concerns (listeners, TLS, IPs) from application routing, allowing HTTPRoute objects to be owned by teams. It offers first-class support for advanced routing like header matching and traffic weighting without relying on vendor-specific annotations. Since Cilium provides a native implementation, no additional ingress controller is needed, aligning with the Kubernetes ecosystem’s convergence on this standard.

For low‑level details and configuration knobs, see the Gateway API component documentation.

What to remember

The Gateway serves as the single public entry point, using host-based routes to keep URLs predictable (e.g., https://argocd.${DNS_SUFFIX}). TLS is terminated at the edge, with internal mTLS planned via Cilium policies.

Practical notes

A single Gateway named idp-gateway and its corresponding GatewayClass (cilium-nodeport) reside in kube-system. The DNS suffix is automatically computed from the LAN IP but can be overridden in config.toml. New services are exposed by adding an HTTPRoute for each hostname.