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

Note

The kaas.mirantis.com/region label is removed from all Container Cloud objects in 2.26.0 (Cluster releases 17.1.0 and 16.1.0). Therefore, do not add the label starting these releases. On existing clusters updated to these releases, or if manually added, this label will be ignored by Container Cloud.

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:

After creation, the new machine will use the alternative L2 template that uses the new-lcm-network subnet linked by L3Layout.

Optional. Configure an additional IP address pool for MetalLB:

Since Container Cloud 2.27.0 (Cluster releases 17.2.0 and 16.2.0)

Configure the additional extension IP address pool for the metallb load balancer service.

Open the MetalLBConfig object of the management cluster for editing:
```
kubectl edit metallbconfig <MetalLBConfigName>
```

In the ipAddressPools section, add:

...
spec:
  ipAddressPools:
  - name: extension
    spec:
      addresses:
      - <pool_start_ip>-<pool_end_ip>
      autoAssign: false
      avoidBuggyIPs: false
...

In the snippet above, replace the following parameters:

<pool_start_ip> - first IP address in the required range
<pool_end_ip> - last IP address in the range

Add the extension IP address pool name to the L2Advertisements definition. You can add it to the same L2 advertisement as the default IP address pool, or create a new L2 advertisement if required.

...
spec:
  l2Advertisements:
  - name: default
    spec:
      interfaces:
      - k8s-lcm
      ipAddressPools:
      - default
      - extension
...

Save and exit the object to apply changes.

Before Container Cloud 2.27.0 (Cluster releases 17.2.0 and 16.2.0) ^Deprecated

Define additional address ranges for MetalLB. For details, see the optional step for the MetalLB service in Create subnets for a managed cluster using CLI.

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 the following objects in Example of a complete L2 templates configuration for cluster creation:
- Since 2.27.0: managed-ns_MetalLBConfig-lb-managed.yaml
- Before 2.27.0: managed-ns_Subnet_metallb-public-for-managed.yaml