Skip to content

Networking model

Networking is handled almost entirely by Cilium — one eBPF-based component doing the work that would otherwise be split across a CNI, kube-proxy, an ingress controller's plumbing, and a host firewall.

Cilium as CNI and kube-proxy replacement

Cilium provides pod networking and replaces kube-proxy: Service load-balancing is done in eBPF rather than by kube-proxy's iptables rules. The result is less per-node iptables state and lower latency for service traffic. There is no kube-proxy DaemonSet to run or reason about.

The host firewall

Beyond pod-to-pod policy, Cilium can firewall the nodes themselves via clusterwide policies attached to the host endpoint. This is how node-level exposure is controlled — for example, which external sources may reach a NodePort, or which peers may talk to the kubelet. The principle: the node is default-deny at the host level, and each thing that must reach it (the control-plane API, monitoring, a specific NodePort from a specific source range) is an explicit allow.

NodePorts need a source-scoped host rule

Exposing a NodePort isn't just a Service field — the host firewall must also permit the source range on that port. Scope it as tightly as the traffic really needs (e.g. only the upstream load balancer's addresses), not the whole subnet.

Pod-to-pod encryption

Traffic between nodes is transparently encrypted with WireGuard, enabled cluster-wide. This covers confidentiality on the wire without every application having to terminate its own mutual TLS internally.

Network policy: default-deny, additive allow

Namespaces that run workloads are default-deny for ingress and egress, with DNS egress and the specific flows each app needs added back explicitly. Cross-namespace access is declared on both sides — an egress rule on the caller and an ingress rule on the callee. Externally-owned namespaces that ship their own policies get additive allow rules layered on rather than a blanket default-deny that would break them.

North-south vs. east-west

  • North-south (traffic entering from outside) is served through the ingress path at the edge firewall and terminates at the cluster's ingress/gateway.
  • East-west (service-to-service inside the cluster) uses an internal gateway, kept separate from the public path so internal callers never depend on the external one.

Ingress is being standardised on the Gateway API; Gateway-API traffic arrives at backends with the gateway's own identity, which network policies must account for.

See also: Component overview · Architecture · Sealed Secrets.