Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Red Hat OpenShift with hosted control planes deploys worker nodes into your Azure virtual network and uses a dedicated subnet to establish private connectivity between the hosted control plane and your worker nodes. You must plan your virtual network layout, subnets, and IP address ranges before you create the cluster.
Plan compute capacity
Node pools provide compute capacity. A node pool is a group of worker nodes that share the same VM size, disk configuration, and availability zone. You can create multiple node pools in a single cluster to run different workload types on different hardware. For supported worker node VM sizes, see Supported virtual machine sizes. Several node pool decisions directly affect your network layout, so you must plan your compute capacity before you size your network.
Answering the following questions helps you plan the subnets and IP address ranges for your cluster:
- How many node pools will you run? The number of node pools determines how many subnets you might need. If all pools share the cluster's default worker subnet, one subnet is sufficient. If you assign separate subnets to different pools, each one adds to your virtual network and machine CIDR requirements.
- Will you deploy across availability zones? Each node pool is deployed into a single availability zone. To distribute workloads across zones for high availability, you need a separate node pool and potentially a separate subnet for each zone. More zones means more subnets and a larger machine CIDR.
- Will each node pool use its own subnet? Node pools deploy into the cluster's default worker subnet unless you specify a different subnet. Separate subnets give you network isolation between node pools, but each subnet must fit within your machine CIDR range and virtual network address space.
- How many nodes will you run at peak? The maximum node count, including autoscaling maximums, determines how large each subnet must be. The cluster supports a maximum of 500 nodes total across all pools.
- Will you add more node pools later? The cluster's CIDR ranges can't be changed after creation. If you plan to add node pools with new subnets in the future, your machine CIDR and virtual network must have enough address space to accommodate them.
Tip
Sizing example: A cluster with 3 availability zones, up to 50 nodes per zone, and a separate subnet per zone needs three /26 subnets (64 addresses each, accommodating 50 nodes plus Azure reserved addresses) and one /29 VNet integration subnet.
All four subnets fit within a /24 machine CIDR (256 addresses).
If you plan to add more node pools later, use a larger machine CIDR such as /22 or /16 to leave room for additional subnets.
Subnet requirements
Your virtual network must contain the following components:
- Worker subnet - The default subnet where the cluster's worker nodes are deployed. When you create a node pool, it deploys into this subnet unless you specify a different subnet. If you plan to deploy node pools across multiple availability zones, you can create a separate subnet for each zone. All node pool subnets must be in the same virtual network as the cluster. Size each subnet based on the number of worker nodes you plan to run in it.
- VNet integration subnet - A dedicated subnet that enables private connectivity between the hosted control plane (running in Red Hat's Azure account) and the worker nodes in your subscription. It must meet the following requirements:
- Minimum size of
/29 - Located in the same virtual network as the worker subnet
- Not shared with the worker subnet or any node pool subnets
- Minimum size of
- Network security group - An Azure network security group that you create and associate with the worker subnet. You assign the network security group directly to the subnets, and it's immutable. You don't have the permissions to change it.
CIDR requirements
The following table describes the virtual network and CIDR requirements:
| Network requirement | Default | Description |
|---|---|---|
| Machine CIDR range | 10.0.0.0/16 |
The IP address range for compute nodes. It must encompass all CIDR address ranges for your virtual network subnets, including any subnets you plan to use for additional node pools. Subnets must be contiguous. A minimum of 128 addresses (/25) is supported for single availability zone deployments. A minimum of 256 addresses (/24) is supported for multiple availability zone deployments. |
| Service CIDR range | 172.30.0.0/16 |
The IP address range for Kubernetes service IPs. The range must be large enough to accommodate your workload, and it must not overlap with any external service accessed from within the cluster. |
| Pod CIDR range | 10.128.0.0/14 |
The IP address range for pods. The range must be large enough to accommodate your workload, and it must not overlap with any external service accessed from within the cluster. |
| Host prefix | 23 |
The subnet prefix length allocated to each node for its pods. A value of 23 assigns a /23 subnet (512 IP addresses) per node from the pod CIDR range. |
Use the default values unless they don't meet your requirements. If you need to change any of these values, follow these guidelines:
- The pod, service, and machine CIDRs must not overlap with each other.
- The pod and service CIDRs must not overlap with any address ranges in use on your network or any external services accessed from within the cluster.
- The machine CIDR must encompass all virtual network subnets used by the cluster, including the worker subnet, any additional node pool subnets, and the VNet integration subnet. If you plan to add node pools with separate subnets in the future, make sure the machine CIDR is large enough to include them. For example, if your VNet uses
10.0.0.0/16, the default machine CIDR of10.0.0.0/16covers all subnets. - The pod network uses nonroutable IP addresses and is only used inside the cluster's software-defined network.
Private cluster connectivity
If you choose a private API server, a private default ingress, or both, you must establish private network connectivity between your users' networks and the cluster's virtual network before deploying the cluster. Without this connectivity, administrators, CI/CD pipelines, and end users can't reach the private endpoints.
Common connectivity options include:
- Azure VNet peering - Connect two Azure virtual networks so that resources in each network can communicate with each other.
- Azure VPN Gateway - Connect your on-premises network to the cluster's virtual network over a site-to-site VPN tunnel.
- Azure ExpressRoute - Establish a private, dedicated connection from your on-premises network to Azure through a connectivity provider.
When planning private network connectivity, ensure that the IP address ranges of the peered or connected networks don't overlap with the cluster's machine CIDR, pod CIDR, or service CIDR ranges.