Open the cluster → Network tab in my.cubepath.com.
A read-only view of how the cluster is wired. The values here are fixed at creation time, which is exactly why they're worth understanding before you create the next cluster.
What's shown
| Field | What it is |
|---|---|
| API Endpoint | The address kubectl talks to. It's also what's baked into the kubeconfig |
| Pod CIDR | The range pods get addresses from (default 10.42.0.0/16) |
| Service CIDR | The range ClusterIP services get addresses from (default 10.43.0.0/16) |
| Node Network | The range the worker nodes themselves sit on |
| Private Network | The attached private network, with its name and CIDR, if you attached one |
NoteWhile the cluster is still provisioning, the API endpoint reads not available yet. It appears once the control plane is up.
Why the CIDRs matter
These three ranges must not overlap each other, the node network, or anything you plan to reach from inside the cluster. Overlap doesn't fail loudly at creation — it fails later, as traffic to a specific range silently going to the wrong place.
The classic case: your office or another VPC uses 10.42.0.0/16, the cluster's pod range is the same, and pods can no longer reach that network because the cluster routes it internally. Check your existing ranges before you deploy and set custom CIDRs in Advanced Settings if there's a clash.
WarningPod and service CIDRs can't be changed after the cluster is created. Fixing an overlap means rebuilding the cluster.
Public and private workers
Workers get public IPv4 and IPv6 by default. Turning off public IPv6 requires a private network so the nodes stay reachable.
For a cluster with no public worker IPs at all, attach a private network at deploy time and expose services through a load balancer instead. That keeps the workers off the public internet while your apps stay reachable.