MetalLB configuration guidelines for subnets¶
Note
Consider this section as deprecated since Container Cloud 2.27.0
(Cluster releases 17.2.0 and 16.2.0) due to the MetalLBConfigTemplate
object deprecation. For details, see Deprecation notes.
Caution
This section also applies to management cluster bootstrap
procedure with the following difference: instead of creating the Subnet
object, add its configuration to templates/bm/ipam-objects.yaml.template
.
The Kubernetes Subnet
object is created for a management cluster from
templates during bootstrap.
Each Subnet
object can be used to define either a MetalLB address range or
MetalLB address pool. A MetalLB address pool may contain one or several
address ranges. The following rules apply to creation of address ranges or
pools:
To designate a subnet as a MetalLB address pool or range, use the
ipam/SVC-MetalLB
label key. Set the label value to"1"
.The object must contain the
cluster.sigs.k8s.io/<cluster-name>
label to reference the name of the target cluster where the MetalLB address pool is used.You may create multiple subnets with the
ipam/SVC-MetalLB
label to define multiple IP address ranges or multiple address pools for MetalLB in the cluster.The IP addresses of the MetalLB address pool are not assigned to the interfaces on hosts. This subnet is virtual. Do not include such subnets to the L2 template definitions for your cluster.
If a
Subnet
object defines a MetalLB address range, no additional object properties are required.You can use any number of
Subnet
objects with each defining a single MetalLB address range. In this case, all address ranges are aggregated into a single MetalLB L2 address pool namedservices
having the auto-assign policy enabled.Intersection of IP address ranges within any single MetalLB address pool is not allowed.
The bare metal provider verifies intersection of IP address ranges. If it detects intersection, the MetalLB configuration is blocked and the provider logs contain corresponding error messages.
Use the following labels to identify the Subnet
object as a MetalLB
address pool and configure the name and protocol for that address pool.
All labels below are mandatory for the Subnet
object that configures
a MetalLB address pool.
Label |
Description |
---|---|
Labels to link |
|
|
Defines that the |
|
Every address pool must have a distinct name. The |
|
Configures the auto-assign policy of an address pool. Boolean. Caution For the address pools defined using the MetalLB Helm chart
values in the For any service that does not have a specific MetalLB annotation
configured, MetalLB allocates external IPs from arbitrary address
pools that have the auto-assign policy set to Only for the service that has a specific MetalLB annotation with
the address pool name, MetalLB allocates external IPs from the address
pool having the auto-assign policy set to |
|
Sets the address pool protocol.
The only supported value is |
Caution
Do not set the same address pool name for two or more
Subnet
objects. Otherwise, the corresponding MetalLB address pool
configuration fails with a warning message in the bare metal provider log.
Caution
For the auto-assign policy, the following configuration rules apply:
At least one MetalLB address pool must have the auto-assign policy enabled so that unannotated services can have load balancer IPs allocated for them. To satisfy this requirement, either configure one of address pools using the
Subnet
object withmetallb/address-pool-auto-assign: "true"
or configure address range(s) using theSubnet
object(s) withoutmetallb/address-pool-*
labels.When configuring multiple address pools with the auto-assign policy enabled, keep in mind that it is not determined in advance which pool of those multiple address pools is used to allocate an IP for a particular unannotated service.