8 min read

Learning Objectives

By the end of this module, you will be able to:

  • Explain precisely what a private cluster isolates (the node data plane) and what it does not (the Kubernetes API endpoint), and protect the API correctly.
  • Sequence the two network dependencies (a NAT Gateway and, for cross-VDC node traffic, a Private Cross Connect) that must exist before the cluster is created.
  • Place the control plane in-region for sovereignty and reason about the fields that become permanent at creation.
  • Provision a private cluster and private node pool in the Data Center Designer, reusing the public-cluster pattern from Unit 6.2.

Unit 6.3: Provisioning a Private Cluster

Introduction

A private cluster is the production default for a regulated estate: worker nodes carry no public NICs, so the data plane is reachable only across your private network. That isolation is real but narrower than the name suggests, and the difference is where teams get hurt. This unit makes the boundary honest, fixes the network prerequisites that must exist first, then builds the private variant in the Data Center Designer on top of the public-cluster pattern from Unit 6.2.

1. What "Private" Isolates, and What It Does Not

The private decision applies to the node pool, not the whole service. A private node pool is deployed in a private LAN behind a NAT Gateway: outbound traffic to the internet is permitted through the gateway, inbound is not. The nodes have no public addresses, and node-to-Kubernetes-service traffic stays on your private network. That is the data-plane isolation FinCorp wants for workloads touching account data under GDPR and BSI controls.

What private does not do is hide the Kubernetes API server. The control plane is IONOS-managed and the API endpoint stays internet-facing regardless of node-pool type. Treating "private cluster" as if it also firewalls the API is the central misconception of this unit. The platform gives you a separate control for that: the cluster carries an API IP allowlist (the "Restrict Access by IP" setting), so you protect the API by listing the source ranges allowed to reach it, for example FinCorp's CI/CD egress IPs and the operations team's VPN exit. Isolating the nodes and allowlisting the API are independent decisions; a compliant private cluster needs both.

Two boundaries from Unit 6.1 matter more here. The Service type LoadBalancer is not available on private node pools, so the single-ingress-node pattern is gone; ingress is a separately provisioned load balancer plus an in-cluster ingress controller (the pattern from Unit 6.2). And network security groups bind to worker NICs, not the cluster abstraction, so in-cluster network policies remain your pod-level control.

2. The Two Network Dependencies (Build These First)

A private cluster is networking-first: the create-cluster dialog asks for a gateway IP that must already exist, so the network has to be built before the cluster.

NAT Gateway for egress. Private nodes still need outbound internet for image pulls, package and security updates, NTP, and Backup Service traffic. That path is the Managed NAT Gateway, which is SNAT-only: it provides no inbound (no DNAT), which is exactly the property that keeps the data plane private. The gateway requires a reserved public IPv4 address, and that reserved IP becomes the cluster's Gateway IP. One critical detail: the default route to the gateway is not injected automatically. For private VMs the routing table must be modified so the default route (or a dedicated route per target) points at the NAT Gateway; the private node pool integration handles node egress through the gateway, but you own the reserved IP and the routing intent. A single NAT Gateway can serve up to six private LANs.

Private Cross Connect for cross-VDC node traffic. When nodes must reach resources in another Virtual Data Center (for FinCorp, the private data tier from Module 5 in a separate VDC), that east-west path is a Private Cross Connect. Its constraints are eligibility rules, not options: it is same-region and same-contract only (no cross-region, no cross-contract), every NIC on every connected VDC must share the same IP range, and each LAN can belong to only one Cross Connect connection. Its bandwidth is comparable to a normal private NIC, and it is not free of charge. Establish it before the node pools that depend on cross-VDC reachability come up, or those nodes provision into a network that cannot see their dependencies.

DCD Implementation Walkthrough

Build goal: Build the private variant reusing the public-cluster patterns, networking first.

You will create a private cluster and a private node pool in the Data Center Designer for the FinCorp container platform. This reuses the public-cluster flow from Unit 6.2; the differences are the network prerequisites and three fields that become permanent. The node-pool walkthrough itself (pool settings, node template, server type, storage, attached LAN and reserved IPs) is identical to 6.2 and is not repeated here.

Prerequisites: a reserved IPv4 address for the NAT Gateway (DCD > Menu > Network Services > IP Management); a NAT Gateway attached to the private LAN with the LAN default route pointing at it; and, where nodes need another VDC, a Private Cross Connect in place. The VDC and its region are reused from earlier modules.

Steps (in the Data Center Designer):

  1. Reserve an IPv4 address under Menu > Network Services > IP Management. This becomes the Gateway IP, so reserve it before opening the cluster dialog.
  2. Build the NAT Gateway: select the data center, ensure a private network with the worker LAN exists, add the NAT Gateway, connect its source interface to that private LAN, and assign the reserved public IP in the Inspector > Settings tab. Set the private LAN's default route to point at the gateway.
  3. Go to Menu > Containers > Managed Kubernetes and select + Create Cluster. Enter a Name following the Kubernetes naming convention (max 63 characters, alphanumeric start and end).
  4. Select the Kubernetes Version from the drop-down.
  5. In the Node pool type field, choose Private.
  6. Select a Region from the drop-down. You can only create the private cluster's VDCs in the same region as the cluster, so this fixes sovereignty placement now.
  7. In Gateway IP, select the reserved IP assigned to your NAT Gateway.
  8. (Optional) Define a Subnet for the private LAN: a /16 CIDR that must not intersect the cluster's pod and service networks (for Kubernetes 1.30 and above, 100.96.0.0/12 and 100.64.0.0/18; for older versions, 10.208.0.0/12 and 10.233.0.0/18).
  9. Select + Create Cluster. Once the cluster is active, add the private node pool exactly as in Unit 6.2: a node pool requires a Data Center in the same location as the cluster, plus an attached private LAN and reserved IPs.
  10. Set the API IP allowlist (Restrict Access by IP) to the source ranges allowed to reach the Kubernetes API, then retrieve the kubeconfig to connect with kubectl.

Common mistakes:

  • Treating "private" as protecting the API. It protects the nodes; the API stays managed and internet-reachable. Set the IP allowlist separately, or the control plane is open to the world.
  • Creating the cluster before the NAT Gateway. The Gateway IP field needs a reserved IP that already exists on a deployed gateway.
  • Assuming egress just works. The NAT default route is not auto-injected; set the private LAN's default route to the gateway or image pulls and updates silently fail.
  • Choosing a US region for the control plane on a sovereignty-bound workload. For a private cluster the control plane is created in the chosen datacenter, so region selection is the sovereignty decision.
  • Banking on a LoadBalancer Service. It is unavailable on private node pools; use a separately provisioned load balancer plus an in-cluster ingress controller.
  • Forgetting the fields are permanent. Region, Gateway IP, and Subnet cannot be changed after provisioning, and the node-pool type cannot be switched between private and public.

3. Control-Plane Placement and Immutability

For a private cluster the control plane is created in the datacenter you choose, so control-plane metadata stays in the chosen region. Choosing the German (Frankfurt) location keeps FinCorp's control-plane data in Germany and preserves EU/German sovereignty; node-pool workloads and data always remain in the chosen region regardless. This is the practical lever behind Unit 1.4's sovereignty-as-placement principle, and it differs from a public cluster, whose managed control plane runs in Frankfurt or one of three US datacenters.

Several creation-time choices are permanent design decisions, not console defaults. The node-pool type (private vs public) is immutable after creation, and the private cluster's Region, Gateway IP, and Subnet cannot be changed once provisioned. You can still switch a node pool's server type between Dedicated Core and vCPU, but the type and network anchoring are fixed. Get region and the network prerequisites right before you click create; the only remedy afterwards is rebuilding the cluster.

Summary

A private cluster isolates the node data plane behind a SNAT-only NAT Gateway while leaving the IONOS-managed API endpoint internet-reachable, so a compliant build pairs private node pools with an explicit API IP allowlist. The build is networking-first: a reserved IP and NAT Gateway (with the default route set), and a same-region same-contract Private Cross Connect for cross-VDC node traffic, must exist before the cluster is created. Placing the control plane in the chosen German region preserves sovereignty, and because node-pool type, region, gateway IP, and subnet are all fixed at creation, the decisions here are permanent.

Key Points:

  • Private isolates the nodes, not the API; protect the API endpoint with the IP allowlist as a separate, mandatory step.
  • The NAT Gateway (egress, SNAT-only, reserved IP, manual default route) and the Private Cross Connect (cross-VDC, same-region and same-contract only) are prerequisites, not later additions.
  • For a private cluster the control plane sits in the chosen region, so region selection is the sovereignty decision.
  • Region, Gateway IP, Subnet, and node-pool type are immutable after creation; the node pool walkthrough itself is the same as Unit 6.2.