L2 template example for automatic multiple subnet creation¶
This section contains an exemplary L2 template for automatic multiple
subnet creation as described in Automate multiple subnet creation using SubnetPool. This template
also contains the L3Layout
section that allows defining the Subnet
scopes and enables auto-creation of the Subnet
objects from the
SubnetPool
objects. For details about auto-creation of the Subnet
objects see Automate multiple subnet creation using SubnetPool.
For details on how to create L2 templates, see Create L2 templates.
Caution
Do not assign an IP address to the PXE nic 0
NIC explicitly
to prevent the IP duplication during updates.
The IP address is automatically assigned by the
bootstrapping engine.
Example of an L2 template for multiple subnets:
apiVersion: ipam.mirantis.com/v1alpha1
kind: L2Template
metadata:
name: test-managed
namespace: managed-ns
spec:
clusterRef: managed-cluster
autoIfMappingPrio:
- provision
- eno
- ens
- enp
l3Layout:
- subnetName: lcm-subnet
scope: namespace
- subnetName: subnet-1
subnetPool: kaas-mgmt
scope: namespace
- subnetName: subnet-2
subnetPool: kaas-mgmt
scope: cluster
npTemplate: |
version: 2
ethernets:
onboard1gbe0:
dhcp4: false
dhcp6: false
match:
macaddress: {{mac 0}}
set-name: {{nic 0}}
# IMPORTANT: do not assign an IP address here explicitly
# to prevent IP duplication issues. The IP will be assigned
# automatically by the bootstrapping engine.
# addresses: []
onboard1gbe1:
dhcp4: false
dhcp6: false
match:
macaddress: {{mac 1}}
set-name: {{nic 1}}
ten10gbe0s0:
dhcp4: false
dhcp6: false
match:
macaddress: {{mac 2}}
set-name: {{nic 2}}
addresses:
- {{ip "2:subnet-1"}}
ten10gbe0s1:
dhcp4: false
dhcp6: false
match:
macaddress: {{mac 3}}
set-name: {{nic 3}}
addresses:
- {{ip "3:subnet-2"}}
bridges:
k8s-lcm:
interfaces: [onboard1gbe0]
addresses:
- {{ip "k8s-lcm:lcm-subnet"}}
gateway4: {{gateway_from_subnet "lcm-subnet"}}
nameservers:
addresses: {{nameservers_from_subnet "lcm-subnet"}}
In the template above, the following networks are defined
in the l3Layout
section:
lcm-subnet
- the subnet name to use for the LCM network in thenpTemplate
. This subnet is shared between the project clusters because it has thenamespaced
scope.Since a subnet pool is not in use, create the corresponding
Subnet
object before machines are attached to cluster manually. For details, see Create subnets for a managed cluster using CLI.Mark this
Subnet
with theipam/SVC-k8s-lcm
label. The L2 template must contain the definition of the virtual Linux bridge (k8s-lcm
in the L2 template example) that is used to set up the LCM network interface. IP addresses for the defined bridge must be assigned from the LCM subnet, which is marked with theipam/SVC-k8s-lcm
label.Since Container Cloud 2.20.0 and 2.20.1 for MOSK 22.4, each node of every cluster must have only one IP address in the LCM network that is allocated from one of the
Subnet
objects having theipam/SVC-k8s-lcm
label defined. Therefore, allSubnet
objects used for LCM networks must have theipam/SVC-k8s-lcm
label defined.Before Container Cloud 2.20.0 and since MOSK 22.2, you can use any interface name for the LCM network traffic. The
Subnet
objects for the LCM network must have theipam/SVC-k8s-lcm
label. For details, see Service labels and their life cycle.
subnet-1
- unless already created, this subnet will be created from thekaas-mgmt
subnet pool. The subnet name must be unique within the project. This subnet is shared between the project clusters.subnet-2
- will be created from thekaas-mgmt
subnet pool. This subnet has thecluster
scope. Therefore, the real name of theSubnet
CR object consists of the subnet name defined inl3Layout
and the cluster UID. But thenpTemplate
section of the L2 template must contain only the subnet name defined inl3Layout
. The subnets of thecluster
scope are not shared between clusters.
Caution
Using the l3Layout
section, define all subnets that are used
in the npTemplate
section.
Defining only part of subnets is not allowed.
If labelSelector
is used in l3Layout
, use any custom
label name that differs from system names. This allows for easier
cluster scaling in case of adding new subnets as described in
Expand IP addresses capacity in an existing cluster.
Mirantis recommends using a unique label prefix such as
user-defined/
.