Kubernetes in a VPC
You can deploy a Managed Kubernetes cluster inside an existing Virtual Private Cloud (VPC) so that its worker nodes run on a private subnet behind your VPC gateway instead of being directly internet-exposed. This is an alternative placement to the default edge cluster, where each worker node has its own public address. Choose in-VPC placement when you want private worker nodes, a single controlled egress point, and integration with the gateway firewall, NAT, and load balancing you already run in the VPC.
Edge clusters vs in-VPC clusters
Both cluster types run the same managed control plane. The difference is where the worker nodes live and how they reach the network.
| Aspect | Edge cluster | In-VPC cluster |
|---|---|---|
| Worker node addressing | Each node has a public IP | Private single-NIC nodes on the VPC subnet |
| Egress to the internet | Direct from each node | Through the VPC gateway (NAT) |
| Inbound to nodes | Reachable at node public IPs | Not directly reachable; front with gateway rules or a Load Balancing add-on |
| Load Balancing add-on | Not available | Available (in-VPC only) |
| DNS add-on | Available | Available |
| Storage add-on | Available | Available |
| Placement | Any supported location | A single existing VPC and its location |
Networking model
An in-VPC cluster is built around private worker nodes and one shared egress path:
- Private single-NIC workers. Each worker node has one network interface on the VPC private subnet and no public address of its own. Nodes talk to each other and to in-VPC VMs over that subnet.
- Egress via the VPC gateway NAT. When a node or a workload needs to reach the internet, traffic leaves through the VPC gateway and is source-translated to the gateway public address. The gateway is the single controlled egress point for the whole cluster.
- API server on a public VIP, dialed outbound. The managed control plane is reachable at a public virtual IP so you can run
kubectlfrom anywhere. Private worker nodes join the control plane by dialing outbound through the gateway, so no inbound path to the nodes is required for them to register. - Pod egress SNAT to the node IP. Pod traffic leaving a node is source-translated to that node's private VPC address, then translated again at the gateway on the way out. Inside the VPC, traffic from a pod appears to come from the node that hosts it.
Prerequisites
- An existing VPC in the same location and the same account as the cluster you want to create. In-VPC placement attaches the cluster to a VPC that already exists; you cannot create the VPC as part of cluster creation.
- Capacity in that location for the worker node sizes you plan to run.
Create an in-VPC cluster
You create an in-VPC cluster from the same wizard as an edge cluster, with one extra selection.
- Navigate to Infrastructure -> Kubernetes and click Add Cluster.
- Choose the CPU type, location, cluster name, and Kubernetes version as usual. Pick the location that matches the VPC you want to use.
- In the cluster wizard, use the VPC selector to attach the cluster to an existing VPC in that location. Selecting a VPC places the worker nodes on that VPC's private subnet. Leaving it unset creates a standard edge cluster.
- Configure worker nodes, tagging, and deploy as described in Deploying a Kubernetes Cluster.
When the build completes, download your kubeconfig from the Access tab and connect with kubectl exactly as you would for an edge cluster. The API endpoint is the public VIP, so no bastion or VPN is needed to run kubectl. You can also drive cluster lifecycle with the Kubernetes endpoints in the API v3 Reference.
Custom pod and service CIDRs
An in-VPC cluster must not overlap the address space of the VPC it joins or of other clusters in your account. If the defaults would collide, set your own ranges at create time. See Custom Pod and Service CIDRs for the defaults, constraints, and the portal fields.
Limitations
- Single location. A cluster and its VPC live in one location. Worker nodes cannot span locations.
- Immutable networking. VPC placement, pod CIDR, and service CIDR are fixed at create time and cannot be changed afterward. To change them, create a new cluster.
- No migrate-in. An existing edge cluster cannot be moved into a VPC, and an in-VPC cluster cannot be moved out. Placement is chosen once, at creation.
Related pages
- Custom Pod and Service CIDRs - defaults and constraints for cluster addressing
- Managed Add-ons - Storage, DNS, and Load Balancing add-ons for your cluster
- Cloud - deploy and manage the VPC your cluster joins
Need Help?
Contact support@netactuate.com or open a support ticket from the portal.