Network ranges

STACKIT Kubernetes Engine (SKE) clusters rely on three distinct IP address spaces: Pod CIDR, Service CIDR, and Node CIDR. Understanding how these address spaces work and interact is essential for planning, sizing, and deploying your Kubernetes workloads.

Introduction

Kubernetes manages internal networking by isolating application endpoints while providing internal routing mechanisms:

• Pod IPs:
  Assigned dynamically to each Pod running in the cluster. Pod IP addresses are valid and routable only internally within your cluster. Depending on the Container Network Interface (CNI) selected for your cluster:
  • Calico uses IP-in-IP encapsulation to route traffic between nodes.
  • Cilium uses native routing for pod-to-pod communication. For more details on CNI options, see Container Networking.
• Service IPs (ClusterIPs):
  Assigned to Kubernetes Services to provide a stable, internal access point for a set of Pods. ClusterIP addresses are virtual IPs and are only valid inside the cluster. They are not routable from outside the cluster. For more information on Kubernetes service routing, refer to the upstream Kubernetes networking documentation.
• Node IPs:
  Assigned to the underlying virtual machines that act as cluster worker nodes, providing host-level connectivity within the underlying infrastructure network.

Network range constraints

When planning network ranges for your SKE cluster, consider the following constraints:

• Allowed address spaces:
  CIDRs must be selected exclusively from the Carrier-Grade NAT (CGNAT) address space (100.64.0.0/10) or standard RFC 1918 private IPv4 address spaces (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16).
• No overlapping CIDRs:
  The CIDR blocks for Nodes, Pods, and Services must never overlap with each other, nor with any peered or connected customer networks (such as on-premises networks connected through a STACKIT Network Area).
• Single range per type:
  Currently, SKE supports specifying only one CIDR block per type (one range for Pods and one range for Services).
• Immutability:
  CIDR ranges cannot be changed after cluster creation.

Network ranges are immutable after cluster creation. Sizing CIDRs incorrectly can limit your cluster scalability or prevent new nodes and pods from scheduling. Always calculate your expected capacity before creating a cluster.

Default CIDR ranges and supported sizes

SKE provides default CIDR configurations while allowing custom ranges within supported subnet mask bounds:

Component	Default CIDR	Allowed subnet mask	Allocation details
Node CIDR	10.250.0.0/16 (Public projects)	Defined by project network	Assigned from the default subnet in public projects, or from the provided network in a STACKIT Network Area (SNA) project.
Pod CIDR	100.64.0.0/13	/11 to /22	Each worker node is automatically assigned a /24 subnet slice from this range.
Service CIDR	100.82.0.0/16	/12 to /24	Defines the IP pool for Kubernetes Services (ClusterIP).

Capacity planning and sizing calculations

The maximum scale of an SKE cluster depends on the interplay between the Node CIDR, the Pod CIDR, and the node allocation mask:

• Node CIDR capacity:
  Defines the underlying infrastructure subnet from which cluster nodes receive their primary IP addresses. The maximum number of usable host IPs is calculated as 2^(32 - prefix) - 2. For example, a /23 range provides 510 usable host IPs, meaning the cluster cannot exceed 510 nodes because additional instances cannot obtain a host IP address.
• Pod CIDR capacity:
  SKE allocates a /24 subnet mask to each worker node by default. The maximum number of nodes supported by your Pod CIDR is calculated as 2^(24 - prefix). Each node receives 256 IP addresses (2^(32 - 24)), which serve Pod IP allocations on that specific host.

Example calculation

Consider a cluster configured with the following parameters:

Component	Example CIDR	Capacity calculation	Resulting limit
Node CIDR	100.83.128.0/23	232 - 23 - 2	510 maximum nodes
Pod CIDR	100.80.0.0/15	224 - 15	512 supported node subnets
Node Mask	/24 (default)	232 - 24	256 IPs per node

In this scenario:

• The Node CIDR allows up to 510 nodes.
• The Pod CIDR allows up to 512 nodes (each receiving a /24 slice).
• The cluster bottleneck is the Node CIDR, restricting total physical growth to 510 nodes. If the Pod CIDR had been set to /16 instead, it would only support 256 node subnets (2^(24 - 16)), making the Pod network the limiting factor instead.

Specify network ranges during cluster creation

You can configure custom network ranges when creating an SKE cluster through the SKE API or the STACKIT CLI.

Via API

Send a PUT request to the cluster endpoint in the SKE API v2:

PUT /v2/projects/{projectId}/regions/{region}/clusters

In the request body, define podAddressRanges and serviceAddressRanges as arrays under the network object:

{
  "network": {
    "podAddressRanges": ["100.80.0.0/15"],
    "serviceAddressRanges": ["100.82.0.0/16"]
  }
}

Via CLI

You can generate a starter payload template using the CLI:

stackit ske cluster generate-payload

Edit the network block in the resulting JSON file with your desired CIDR ranges, then pass the file via the --payload flag when creating the cluster:

stackit ske cluster create -p <PROJECT_ID> <CLUSTER_NAME> --payload @cluster-configuration.json

For more details on managing clusters via JSON payloads, refer to the STACKIT CLI documentation.

Check network ranges after cluster creation

You can verify the configured network ranges on an existing cluster using the STACKIT CLI, the SKE API, or directly via kubectl.

Via API

Send a GET request to retrieve the cluster configuration via the SKE API v2:

GET /v2/projects/{projectId}/regions/{region}/clusters/{clusterName}

The response includes the configured network object:

{
  "network": {
    "podAddressRanges": ["100.80.0.0/15"],
    "serviceAddressRanges": ["100.82.0.0/16"]
  }
}

Via CLI

Use stackit ske cluster describe to view cluster details, or output JSON to inspect the network block directly:

stackit ske cluster describe -p <PROJECT_ID> <CLUSTER_NAME> -o json | jq '.network'

Example output:

{
  "podAddressRanges": ["100.80.0.0/15"],
  "serviceAddressRanges": ["100.82.0.0/16"]
}