53 Advanced Network Configuration #

The directed network provisioning workflow allows for specific network configurations in downstream clusters, such as static IPs, bonding, VLANs, IPv6, etc.

The following sections describe the additional steps required to enable provisioning downstream clusters using advanced network configuration.

Requirements

The image generated using EIB has to include the network folder and the script following this section (Section 49.2.6, “Additional script for Advanced Network Configuration”).

Configuration

Before proceeding refer to one of the following sections for guidance on the steps required to enroll and provision the host(s):

Downstream cluster provisioning with Directed network provisioning (single-node) (Chapter 51, Downstream cluster provisioning with Directed network provisioning (single-node))
Downstream cluster provisioning with Directed network provisioning (multi-node) (Chapter 52, Downstream cluster provisioning with Directed network provisioning (multi-node))

Any advanced network configuration must be applied at enrollment time through the BareMetalHost host definition and an associated Secret containing an nmstate formatted networkData block. The following example file defines a secret containing the required networkData that requests a static IP and VLAN for the downstream cluster host:

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: ${CONTROLPLANE_INTERFACE}
      type: ethernet
      state: up
      mtu: 1500
      identifier: mac-address
      mac-address: "${CONTROLPLANE_MAC}"
      ipv4:
        address:
        - ip:  "${CONTROLPLANE_IP}"
          prefix-length: "${CONTROLPLANE_PREFIX}"
        enabled: true
        dhcp: false
    - name: floating
      type: vlan
      state: up
      vlan:
        base-iface: ${CONTROLPLANE_INTERFACE}
        id: ${VLAN_ID}
    dns-resolver:
      config:
        server:
        - "${DNS_SERVER}"
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: "${CONTROLPLANE_GATEWAY}"
        next-hop-interface: ${CONTROLPLANE_INTERFACE}

As you can see, the example shows the configuration to enable the interface with static IPs, as well as the configuration to enable the VLAN using the base interface, once the following variables are replaced with the actual values, according to your infrastructure:

${CONTROLPLANE_INTERFACE} — The control-plane interface to be used for the downstream cluster (for example, eth0). Including identifier: mac-address the naming is inspected automatically by the MAC address so any interface name can be used.
${CONTROLPLANE_IP} — The IP address to be used as an endpoint for the downstream cluster (must match with the kubeapi-server endpoint).
${CONTROLPLANE_PREFIX} — The CIDR to be used for the downstream cluster (for example, 24 if you want /24 or 255.255.255.0).
${CONTROLPLANE_GATEWAY} — The gateway to be used for the downstream cluster (for example, 192.168.100.1).
${CONTROLPLANE_MAC} — The MAC address to be used for the control-plane interface (for example, 00:0c:29:3e:3e:3e).
${DNS_SERVER} — The DNS to be used for the downstream cluster (for example, 192.168.100.2).
${VLAN_ID} — The VLAN ID to be used for the downstream cluster (for example, 100).

Any other nmstate-compliant definition can be used to configure the network for the downstream cluster to adapt to the specific requirements. For example, it is possible to specify a static dual-stack configuration:

apiVersion: v1
kind: Secret
metadata:
  name: controlplane-0-networkdata
type: Opaque
stringData:
  networkData: |
    interfaces:
    - name: ${CONTROLPLANE_INTERFACE}
      type: ethernet
      state: up
      mac-address: ${CONTROLPLANE_MAC}
      ipv4:
        enabled: true
        dhcp: false
        address:
        - ip: ${CONTROLPLANE_IP_V4}
          prefix-length: ${CONTROLPLANE_PREFIX_V4}
      ipv6:
        enabled: true
        dhcp: false
        autoconf: false
        address:
        - ip: ${CONTROLPLANE_IP_V6}
          prefix-length: ${CONTROLPLANE_PREFIX_V6}
    routes:
      config:
      - destination: 0.0.0.0/0
        next-hop-address: ${CONTROLPLANE_GATEWAY_V4}
        next-hop-interface: ${CONTROLPLANE_INTERFACE}
      - destination: ::/0
        next-hop-address: ${CONTROLPLANE_GATEWAY_V6}
        next-hop-interface: ${CONTROLPLANE_INTERFACE}
    dns-resolver:
      config:
        server:
        - ${DNS_SERVER_V4}
        - ${DNS_SERVER_V6}

As for the previous example, replace the following variables with actual values, according to your infrastructure:

${CONTROLPLANE_IP_V4} - the IPv4 address to assign to the host
${CONTROLPLANE_PREFIX_V4} - the IPv4 prefix of the network to which the host IP belongs
${CONTROLPLANE_IP_V6} - the IPv6 address to assign to the host
${CONTROLPLANE_PREFIX_V6} - the IPv6 prefix of the network to which the host IP belongs
${CONTROLPLANE_GATEWAY_V4} - the IPv4 address of the gateway for the traffic matching the default route
${CONTROLPLANE_GATEWAY_V6} - the IPv6 address of the gateway for the traffic matching the default route
${CONTROLPLANE_INTERFACE} - the name of the interface to assign the addresses to and to use for egress traffic matching the default route, for both IPv4 and IPv6
${DNS_SERVER_V4} and/or ${DNS_SERVER_V6} - the IP address(es) of the DNS server(s) to use, which can be specified as single or multiple entries. Both IPv4 and/or IPv6 addresses are supported

Note

You can refer to SUSE Telco Cloud examples repo for more complex examples, including IPv6 only and dual-stack configurations.
Single-stack IPv6 deployments are in tech preview status and not yet officially supported.

Lastly, regardless of the network configuration details, ensure that the secret is referenced by appending preprovisioningNetworkDataName to the BaremetalHost object to successfully enroll the host in the management cluster.

apiVersion: v1
kind: Secret
metadata:
  name: example-demo-credentials
type: Opaque
data:
  username: ${BMC_USERNAME}
  password: ${BMC_PASSWORD}
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-demo
  labels:
    cluster-role: control-plane
spec:
  architecture: x86_64
  online: true
  bootMACAddress: ${BMC_MAC}
  rootDeviceHints:
    deviceName: /dev/nvme0n1
  bmc:
    address: ${BMC_ADDRESS}
    disableCertificateVerification: true
    credentialsName: example-demo-credentials
  preprovisioningNetworkDataName: controlplane-0-networkdata

Note

If you need to deploy a multi-node cluster, the same process must be done for each node.
The Metal3DataTemplate, networkData and Metal3 IPAM are currently not supported; only the configuration via static secrets is fully supported.
Architecture must be either x86_64 or aarch64, depending on the architecture of the bare-metal host to be enrolled.