Skip to content

Networking model

This page explains the networking architecture behind Aether clusters. For hands-on instructions, see the Networking guide.

Each cluster runs on its own private network, isolated from every other tenant. Your worker nodes communicate over this private network, and one organization’s clusters cannot reach another’s. The Cilium CNI provides pod networking inside the cluster, and you layer your own NetworkPolicy / CiliumNetworkPolicy rules on top to control pod-to-pod traffic.

The cluster’s Kubernetes API server is private by default — reachable only from within the cluster’s private network where your nodes live. This keeps the control-plane API off the public internet unless you opt in.

You can optionally enable a public API server endpoint, which exposes the API server at a stable public domain:

<cluster>.<org>.<region>.aetherplatform.cloud:6443

The public endpoint is guarded by authorized networks (IP allow-listing) and connection rate limiting, so you decide exactly which source ranges may reach it. Enabling the public endpoint is additive — your nodes keep using the private path regardless. See Connect with kubectl for how to download the matching kubeconfig.

When you create a Kubernetes Service of type LoadBalancer, Aether provisions a managed load balancer with an external IP and wires it to your service — no manual setup. This is how you expose workloads (or an ingress controller) to the outside world. L7 routing and ingress controllers inside the cluster remain your responsibility.

Workloads running on your nodes have outbound internet access — they can pull dependencies, call third-party APIs, and reach external services. Inbound access from the internet only happens where you explicitly create it (a LoadBalancer service, or the optional public API server endpoint).

  • Networking — network policies, load balancers, and ingress in practice.
  • Platform model — tenant isolation overall.