Se aplica a SUSE Telco Cloud 3.6

53 Configuración de red avanzada #

El flujo de trabajo de aprovisionamiento de red dirigida permite configuraciones de red específicas en clústeres en sentido descendente, como IP estáticas, bonding, VLAN, IPv6, etc.

Las siguientes secciones describen los pasos adicionales necesarios para habilitar el aprovisionamiento de clústeres en sentido descendente mediante la configuración de red avanzada.

Requisitos

La imagen generada mediante EIB debe incluir la carpeta de red y el script que sigue a esta sección (Sección 49.2.6, “Script adicional para la configuración de red avanzada”).

Configuración

Antes de continuar, consulte una de las siguientes secciones para obtener orientación sobre los pasos necesarios para inscribir y aprovisionar el/los host(s):

Aprovisionamiento de clúster en sentido descendente con aprovisionamiento de red dirigida (nodo único) (Capítulo 51, Aprovisionamiento de clústeres en sentido descendente con aprovisionamiento de red dirigida (nodo único))
Aprovisionamiento de clúster en sentido descendente con aprovisionamiento de red dirigida (nodos múltiples) (Capítulo 52, Aprovisionamiento de clúster descendente con aprovisionamiento de red dirigido (multinodo))

Cualquier configuración de red avanzada debe aplicarse en el momento de la inscripción a través de la definición de host BareMetalHost y un Secret asociado que contenga un bloque nmstate con formato networkData. El siguiente archivo de ejemplo define un secret que contiene el networkData necesario que solicita una IP estática y VLAN para el host del clúster en sentido descendente:

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}

Como podéis ver, el ejemplo muestra la configuración para habilitar la interfaz con IPs estáticas, así como la configuración para habilitar la VLAN utilizando la interfaz base, una vez que se sustituyan las siguientes variables por los valores reales, de acuerdo con vuestra infraestructura:

${CONTROLPLANE_INTERFACE} — La interfaz del plano de control que se utilizará para el clúster en sentido descendente (por ejemplo, eth0). Al incluir identifier: mac-address, el nombre se inspecciona automáticamente mediante la dirección MAC, por lo que se puede utilizar cualquier nombre de interfaz.
${CONTROLPLANE_IP} — La dirección IP que se utilizará como punto final para el clúster en sentido descendente (debe coincidir con el punto final de kubeapi-server).
${CONTROLPLANE_PREFIX} — El CIDR que se utilizará para el clúster en sentido descendente (por ejemplo, 24 si deseáis /24 o 255.255.255.0).
${CONTROLPLANE_GATEWAY} — La puerta de enlace que se utilizará para el clúster en sentido descendente (por ejemplo, 192.168.100.1).
${CONTROLPLANE_MAC} — La dirección MAC que se utilizará para la interfaz del plano de control (por ejemplo, 00:0c:29:3e:3e:3e).
${DNS_SERVER} — El DNS que se utilizará para el clúster en sentido descendente (por ejemplo, 192.168.100.2).
${VLAN_ID} — El ID de VLAN que se utilizará para el clúster en sentido descendente (por ejemplo, 100).

Se puede utilizar cualquier otra definición compatible con nmstate para configurar la red del clúster en sentido descendente y adaptarla a los requisitos específicos. Por ejemplo, es posible especificar una configuración de pila dual estática:

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}

Al igual que en el ejemplo anterior, sustituid las siguientes variables por los valores reales, de acuerdo con vuestra infraestructura:

${CONTROLPLANE_IP_V4} - la dirección IPv4 que se asignará al host
${CONTROLPLANE_PREFIX_V4} - el prefijo IPv4 de la red a la que pertenece la IP del host
${CONTROLPLANE_IP_V6} - la dirección IPv6 que se asignará al host
${CONTROLPLANE_PREFIX_V6} - el prefijo IPv6 de la red a la que pertenece la IP del host
${CONTROLPLANE_GATEWAY_V4} - la dirección IPv4 de la puerta de enlace para el tráfico que coincide con la ruta predeterminada
${CONTROLPLANE_GATEWAY_V6} - la dirección IPv6 de la puerta de enlace para el tráfico que coincide con la ruta predeterminada
${CONTROLPLANE_INTERFACE} - el nombre de la interfaz a la que asignar las direcciones y que se utilizará para el tráfico de salida que coincide con la ruta predeterminada, tanto para IPv4 como para IPv6
${DNS_SERVER_V4} y/o ${DNS_SERVER_V6} - la(s) dirección(es) IP del/de los servidor(es) DNS que se utilizará(n), que puede(n) especificarse como una o varias entradas. Se admiten tanto direcciones IPv4 como IPv6

Nota

Puede consultar el repositorio de ejemplos de SUSE Telco Cloud para ver ejemplos más complejos, incluidas configuraciones solo IPv6 y de pila dual.
Las implementaciones de IPv6 de pila única están en fase de vista previa técnica y aún no cuentan con soporte oficial.

Por último, independientemente de los detalles de la configuración de red, aseguraos de que se haga referencia al secreto añadiendo preprovisioningNetworkDataName al objeto BaremetalHost para inscribir correctamente el host en el clúster de gestión.

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

Nota

Si necesitáis desplegar un clúster de varios nodos, debéis realizar el mismo proceso para cada nodo.
Actualmente, Metal3DataTemplate, networkData y Metal3 IPAM no están soportados; solo se admite completamente la configuración mediante secretos estáticos.
La arquitectura debe ser x86_64 o aarch64, dependiendo de la arquitectura del equipo sin sistema operativo que se va a inscribir.