Configure multiple DHCP address ranges¶
To facilitate multi-rack and other types of distributed bare metal datacenter topologies, the dnsmasq DHCP server used for host provisioning in Container Cloud supports working with multiple L2 segments through network routers that support DHCP relay.
Container Cloud has its own DHCP relay running on one of the management cluster nodes. That DHCP relay serves for proxying DHCP requests in the same L2 domain where the management cluster nodes are located.
Caution
Networks used for hosts provisioning of a managed cluster must have routes to the PXE network (when a dedicated PXE network is configured) or to the combined PXE/management network of the management cluster. This configuration enables hosts to have access to the management cluster services that are used during host provisioning.
Management cluster nodes must have routes through the PXE network to PXE network segments used on a managed cluster. The following example contains L2 template fragments for a management cluster node:
l3Layout:
# PXE/static subnet for a management cluster
- scope: namespace
subnetName: kaas-mgmt-pxe
labelSelector:
kaas-mgmt-pxe-subnet: "1"
# management (LCM) subnet for a management cluster
- scope: namespace
subnetName: kaas-mgmt-lcm
labelSelector:
kaas-mgmt-lcm-subnet: "1"
# PXE/dhcp subnets for a managed cluster
- scope: namespace
subnetName: managed-dhcp-rack-1
- scope: namespace
subnetName: managed-dhcp-rack-2
- scope: namespace
subnetName: managed-dhcp-rack-3
...
npTemplate: |
...
bonds:
bond0:
interfaces:
- {{ nic 0 }}
- {{ nic 1 }}
parameters:
mode: active-backup
primary: {{ nic 0 }}
mii-monitor-interval: 100
dhcp4: false
dhcp6: false
addresses:
# static address on management node in the PXE network
- {{ ip "bond0:kaas-mgmt-pxe" }}
routes:
# routes to managed PXE network segments
- to: {{ cidr_from_subnet "managed-dhcp-rack-1" }}
via: {{ gateway_from_subnet "kaas-mgmt-pxe" }}
- to: {{ cidr_from_subnet "managed-dhcp-rack-2" }}
via: {{ gateway_from_subnet "kaas-mgmt-pxe" }}
- to: {{ cidr_from_subnet "managed-dhcp-rack-3" }}
via: {{ gateway_from_subnet "kaas-mgmt-pxe" }}
...
To configure DHCP ranges for dnsmasq, create the Subnet
objects
tagged with the ipam/SVC-dhcp-range
label while setting up subnets
for a managed cluster using CLI.
Caution
Support of multiple DHCP ranges has the following limitations:
Using of custom DNS server addresses for servers that boot over PXE is not supported.
The
Subnet
objects for DHCP ranges cannot be associated with any specific cluster, as DHCP server configuration is only applicable to the management cluster where DHCP server is running. Thecluster.sigs.k8s.io/cluster-name
label will be ignored.Note
Before the Cluster release 16.1.0, the
Subnet
object contains thekaas.mirantis.com/region
label that specifies the region where the DHCP ranges will be applied.
Migration of DHCP configuration for existing management clusters¶
Note
This section applies only to existing management clusters that are created before Container 2.24.0.
Caution
Since Container Cloud 2.24.0, you can only remove the deprecated
dnsmasq.dhcp_range
, dnsmasq.dhcp_ranges
, dnsmasq.dhcp_routers
,
and dnsmasq.dhcp_dns_servers
values from the cluster spec
.
The Admission Controller does not accept any other changes in these values.
This configuration is completely superseded by the Subnet
object.
The DHCP configuration automatically migrated from the cluster spec
to
Subnet
objects after cluster upgrade to 2.21.0.
To remove the deprecated dnsmasq parameters from the cluster spec:
Open the management cluster
spec
for editing.In the
baremetal-operator
release values, remove thednsmasq.dhcp_range
,dnsmasq.dhcp_ranges
,dnsmasq.dhcp_routers
, anddnsmasq.dhcp_dns_servers
parameters. For example:regional: - helmReleases: - name: baremetal-operator values: dnsmasq: dhcp_range: 10.204.1.0,10.204.5.255,255.255.255.0
Caution
The
dnsmasq.dhcp_<name>
parameters of thebaremetal-operator
Helm chart values in theCluster
spec
are deprecated since the Cluster release 11.5.0 and removed in the Cluster release 14.0.0.Ensure that the required DHCP ranges and options are set in the
Subnet
objects. For configuration details, see Configure DHCP ranges for dnsmasq.
The dnsmasq configuration options dhcp-option=3
and dhcp-option=6
are absent in the default configuration. So, by default, dnsmasq
will send the DNS server and default route to DHCP clients as defined in the
dnsmasq official documentation:
The netmask and broadcast address are the same as on the host running dnsmasq.
The DNS server and default route are set to the address of the host running dnsmasq.
If the domain name option is set, this name is sent to DHCP clients.
Configure DHCP ranges for dnsmasq¶
Create the
Subnet
objects tagged with theipam/SVC-dhcp-range
label.Caution
For cluster-specific subnets, create
Subnet
objects in the same namespace as the relatedCluster
object project. For shared subnets, createSubnet
objects in thedefault
namespace.To create the
Subnet
objects, refer to Create subnets.Use the following
Subnet
object example to specify DHCP ranges and DHCP options to pass the default route address:apiVersion: "ipam.mirantis.com/v1alpha1" kind: Subnet metadata: name: mgmt-dhcp-range namespace: default labels: ipam/SVC-dhcp-range: "" kaas.mirantis.com/provider: baremetal spec: cidr: 10.11.0.0/24 gateway: 10.11.0.1 includeRanges: - 10.11.0.121-10.11.0.125 - 10.11.0.191-10.11.0.199
Note
Setting of custom nameservers in the DHCP subnet is not supported.
After creation of the above
Subnet
object, the provided data will be utilized to render theDnsmasq
object used for configuration of the dnsmasq deployment. You do not have to manually edit theDnsmasq
object.Verify that the changes are applied to the
Dnsmasq
object:kubectl --kubeconfig <pathToMgmtClusterKubeconfig> \ -n kaas get dnsmasq dnsmasq-dynamic-config -o json
See also
Configure DHCP relay on ToR switches¶
For servers to access the DHCP server across the L2 segment boundaries, for example, from another rack with a different VLAN for PXE network, you must configure DHCP relay (agent) service on the border switch of the segment. For example, on a top-of-rack (ToR) or leaf (distribution) switch, depending on the data center network topology.
Warning
To ensure predictable routing for the relay of DHCP packets, Mirantis strongly advises against the use of chained DHCP relay configurations. This precaution limits the number of hops for DHCP packets, with an optimal scenario being a single hop.
This approach is justified by the unpredictable nature of chained relay configurations and potential incompatibilities between software and hardware relay implementations.
The dnsmasq
server listens on the PXE network of the management
cluster by using the dhcp-lb
Kubernetes Service.
To configure the DHCP relay service, specify the external address of the
dhcp-lb
Kubernetes Service as an upstream address for the relayed DHCP
requests, which is the IP helper address for DHCP. There is the dnsmasq
deployment behind this service that can only accept relayed DHCP requests.
Container Cloud has its own DHCP relay running on one of the management cluster nodes. That DHCP relay serves for proxying DHCP requests in the same L2 domain where the management cluster nodes are located.
To obtain the actual IP address issued to the dhcp-lb
Kubernetes
Service:
kubectl -n kaas get service dhcp-lb