Expand IP addresses capacity in an existing cluster¶

If the subnet capacity on your existing cluster is not enough to add new machines, use the l2TemplateSelector feature to expand the IP addresses capacity:

Create new Subnet object(s) to define additional address ranges for new machines.
Set up routing between the existing and new subnets.
Create new L2 template(s) with the new subnet(s) being used in l3Layout.
Set up l2TemplateSelector in the Machine objects for new machines.

To expand IP addresses capacity for an existing cluster:

Verify the capacity of the subnet(s) currently associated with the L2 template(s) used for cluster deployment:

If labelSelector is not used for the given subnet, use the namespace value of the L2 template and the subnetName value from the l3Layout section:
```
kubectl get subnet -n <namespace> <subnetName>
```

If labelSelector is used for the given subnet, use the namespace value of the L2 template and comma-separated key-value pairs from the labelSelector section for the given subnet in the l3Layout section:

kubectl get subnet -n <namespace> -l <key1=value1>[<,key2=value2>...]

Example command:

kubectl get subnet -n test-ns -l cluster.sigs.k8s.io/cluster-name=managed123,user-defined/purpose=lcm-base

Example of system response:

NAME             AGE  CIDR            GATEWAY      CAPACITY  ALLOCATABLE  STATUS
old-lcm-network  8d   192.168.1.0/24  192.168.1.1  253       0            OK

Create new objects:

Subnet with the user-defined/purpose: lcm-additional label.
L2Template with the alternative-template: “1” label. The L2 template should reference the new Subnet object using the user-defined/purpose: lcm-additional label in the labelSelector field.

Note

The label name user-defined/purpose is used for illustration purposes. Use any custom label name that differs from system names. Use of a unique prefix such as user-defined/ is recommended.

You can also reference the new Subnet object by using its name in the l3Layout section of the alternative-template L2 template.

Set up IP routing between the existing and new subnets using the tools of your cloud network infrastructure.
In the providerSpec section of the new Machine object, define the alternative-template label for l2TemplateSelector:
Snippet example of the new Machine object
apiVersion: cluster.k8s.io/v1alpha1 kind: Machine metadata: labels: cluster.sigs.k8s.io/cluster-name: managed123 kaas.mirantis.com/provider: baremetal kaas.mirantis.com/region: region-one name: additional-machine namespace: test-ns spec: ... providerSpec: value: ... l2TemplateSelector: label: alternative-template
Note

The kaas.mirantis.com/region label is removed from all Container Cloud and MOSK objects in 24.1.

Therefore, do not add the label starting with these releases. On existing clusters updated to these releases, or if added manually, Container Cloud ignores this label.
After creation, the new machine will use the alternative L2 template that uses the new-lcm-network subnet linked by L3Layout.

Deprecated since MOSK 24.2. Define additional address ranges for MetalLB. For details, see the optional step for the MetalLB service in Create subnets.

You can create one or several Subnet objects to extend the MetalLB address pool with additional ranges. When the MetalLB traffic is routed through the default gateway, you can add the MetalLB address ranges that belong to different CIDR subnet addresses.

For example:

Verify the created objects for MetalLB.

For reference, use managed-ns_Subnet_metallb-public-for-managed.yaml in Container Cloud documentation: Example of a complete L2 templates configuration for cluster creation.