Last modified December 13, 2022
A NetworkPool defines a CIDR range for the Control Plane and MachineDeployment nodes of a Cluster.
NetworkPools have been introduced in release 12.7.0 on AWS and are not yet available in KVM or Azure.
The main advantages of using NetworkPools are:
- Extending installation default CIDR range.
- Limit the CIDR range a single cluster can have.
NetworkPools must be created before the cluster is created via Management Cluster Kubernetes API.
NetworkPools can be modified as long as the CIDR doesn’t overlap with other NetworkPools and contains the original CIDR. For example 10.0.0.0/16 could be modified to 10.0.0.0/15 but not to 10.0.0.0/17.
Assigning clusters to NetworkPools
When creating a Cluster, you can assign the NetworkPool in the
.spec.provider.nodes.networkPool attribute like:
apiVersion: infrastructure.giantswarm.io/v1alpha2 kind: NetworkPool metadata: labels: giantswarm.io/organization: giantswarm name: custom namespace: development-networkpool spec: cidrBlock: 192.168.0.0/16
apiVersion: infrastructure.giantswarm.io/v1alpha2 kind: AWSCluster metadata: name: g8kw3 spec: provider: master: availabilityZone: eu-central-1b instanceType: m5.2xlarge nodes: networkPool: development-networkpool pods: cidrBlock: 192.168.1.0/16 ...
Before deleting a NetworkPool you must ensure there are no clusters using it.
NetworkPool YAML format
You can check out the YAML definition in the Management API.
- NetworkPools must be at least /20 in order to be able to create clusters.
- NetworkPools must be created in the same namespace as the cluster.
- NetworkPools can not overlap with each other.
- NetworkPools can not overlap with the installation default CIDR.
- The Pod CIDR must be in the same Private IP Block as the NetworkPool.
Need help, got feedback?
We listen to your Slack support channel. You can also reach us at email@example.com. And of course, we welcome your pull requests!