Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Solución de problemas de Redes Declarativas

Dado el siguiente registro de ejemplo:

Ejemplo de MachineRegistration utilizando redes declarativas
Unresolved include directive in modules/es/pages/troubleshooting/troubleshooting-network.adoc - include::example$network/machineregistration.yaml[]

Podemos esperar que cada Máquina Elemental se configure utilizando la plantilla definida nm-configurator _all.yaml.

En el primer arranque, el elemental-register intentará contactar la API de Rancher para registrar un nuevo MachineInventory.

En esta etapa, la red de la máquina no está configurada y se utilizará DHCP por defecto. Es un requisito que la máquina pueda contactar la API de Rancher en esta configuración, de lo contrario, no se podrá realizar el registro.

Una vez que el MachineInventory ha sido registrado por primera vez, el elemental-operator va a reclamar un IPAddress para cada referencia IPPool definida en la configuración de red.

En el MachineInventory, se verá de la siguiente manera:

apiVersion: elemental.cattle.io/v1beta1
kind: MachineInventory
metadata:
  finalizers:
  - machineinventory.elemental.cattle.io
  name: m-e5331e3b-1e1b-4ce7-b080-235ed9a6d07c
  namespace: fleet-default
spec:
  ipAddressClaims:
    inventory-ip:
      apiVersion: ipam.cluster.x-k8s.io/v1beta1
      kind: IPAddressClaim
      name: m-e5331e3b-1e1b-4ce7-b080-235ed9a6d07c-inventory-ip
      namespace: fleet-default
      uid: 78f2d07a-7b6d-4b58-b615-c4108b7964b9
  ipAddressPools:
    inventory-ip:
      apiGroup: ipam.cluster.x-k8s.io
      kind: InClusterIPPool
      name: elemental-inventory-pool
  network:
    config:
      dns-resolver:
        config:
          search: []
          server:
          - 192.168.122.1
      interfaces:
      - description: Main-NIC
        ipv4:
          address:
          - ip: "{inventory-ip}"
            prefix-length: 24
          dhcp: false
          enabled: true
        ipv6:
          enabled: false
        name: eth0
        state: up
        type: ethernet
      routes:
        config:
        - destination: 0.0.0.0/0
          metric: 150
          next-hop-address: 192.168.122.1
          next-hop-interface: eth0
          table-id: 254
    ipAddresses:
      inventory-ip: 192.168.122.150
status:
  conditions:
  - lastTransitionTime: "2024-07-30T11:50:47Z"
    message: NetworkConfig is ready
    reason: ReconcilingNetworkConfig
    status: "True"
    type: NetworkConfigReady

Notaréis que el MachineInventory lleva el mismo network.config que el MachineRegistration, sin embargo, en lugar de referenciar Grupos de Direcciones IP, ahora tenemos un mapa de Direcciones IP reales:

    ipAddresses:
      inventory-ip: 192.168.122.150

Este inventory-ip será sustituido en el archivo de configuración del nm-configurator siempre que se haya definido {inventory-ip}.

También tened en cuenta que el MachineInventory referencia y posee cada IPAddressClaim asociado a él. Cada reclamación sigue la predecible convención de nombres $MachineInventoryName-$IPPoolRefKey: m-e5331e3b-1e1b-4ce7-b080-235ed9a6d07c-inventory-ip.

Estas reclamaciones seguirán el ciclo de vida del objeto MachineInventory y se eliminarán en cascada, por ejemplo, durante el flujo de trabajo de reinicio.

Si el IPAddresses no puede ser reclamado, la condición del NetworkConfigReady será False, impidiendo que la máquina complete la instalación. Esto puede ser el caso si el IPPool no tiene más IPAddresses disponibles.

En el lado de la máquina

Durante la fase de instalación, el proceso elemental-register que se ejecuta en la máquina recibirá el archivo de configuración nm-configurator _all.yaml y la lista de Direcciones IP reclamadas con sus claves. Esta información se convertirá en una configuración nm-configurator aplicable:

config:
  dns-resolver:
    config:
      search: []
      server:
      - 192.168.122.1
  interfaces:
  - description: Main-NIC
    ipv4:
      address:
      - ip: "192.168.122.150"
        prefix-length: 24
      dhcp: false
      enabled: true
    ipv6:
      enabled: false
    name: eth0
    state: up
    type: ethernet
  routes:
    config:
    - destination: 0.0.0.0/0
      metric: 150
      next-hop-address: 192.168.122.1
      next-hop-interface: eth0
      table-id: 254

El elemental-register invocará entonces nmc generate y nmc apply para aplicar esta configuración en el sistema en ejecución.

Desde este momento hasta el reinicio, la máquina siempre utilizará la configuración aplicada.

También tened en cuenta que fuera de la instalación y el reinicio, nm-configurator ya no se utiliza, ya que el elemental-register persistirá los archivos /etc/NetworkManager/system-connection/*.nmconnection generados por nmc en lugar de la configuración nmc en sí.

Por ejemplo, en cualquier sistema en funcionamiento, encontraréis un archivo de configuración yip (/oem/elemental-network.yaml) para aplicar el nmconnections deseado, por ejemplo:

name: Apply network config
stages:
    initramfs:
        - files:
            - path: /etc/NetworkManager/system-connections/Wired connection 1.nmconnection
              permissions: 384
              owner: 0
              group: 0
              content: |
                [connection]
                id=Wired connection 1
                uuid=d26b4ae4-d525-3cbf-a557-33feb60343c0
                type=ethernet
                autoconnect-priority=-999
                interface-name=eth0
                timestamp=1722340245

                [ethernet]

                [ipv4]
                address1=192.168.122.150/24
                dhcp-timeout=2147483647
                dns=192.168.122.1;
                dns-options=
                dns-priority=40
                method=manual
                route1=0.0.0.0/0,192.168.122.1,150
                route1_options=table=254

                [ipv6]
                addr-gen-mode=eui64
                dhcp-timeout=2147483647
                method=disabled

                [proxy]

                [user]
                nm-configurator.interface.description=Main-NIC
              encoding: ""
              ownerstring: ""

Durante el reinicio

Siempre que se active reinicio, el elemental-register que se ejecuta en la máquina borrará cualquier archivo /etc/NetworkManager/system-connection/*.nmconnection y reiniciará la pila de red. La máquina debería entonces volver a DHCP y, después de eso, confirmar al elemental-operator en el lado de gestión que el reinicio ha tenido éxito.

Tened en cuenta que esto solo se aplica siempre que el valor MachineInventory.spec.network.configurator sea diferente de none. De lo contrario, no se tomará ninguna acción para reiniciar la red durante la fase de reinicio de la máquina.

Tras el reinicio de la red, la máquina debería reiniciarse en modo de recuperación, realizar el reinicio real y recibir una nueva configuración de red que se aplicará. Potencialmente, esto será lo mismo que antes (si el MachineRegistration no ha sido actualizado), o puede tener IPs diferentes ya que las anteriores pueden haber sido reclamadas por otras máquinas en el ínterin.

Si volver a DHCP falla o la máquina no puede contactar de ninguna manera con la API de Rancher para la confirmación, notaréis que el MachineInventory no será eliminado, a pesar de tener una marca de tiempo de eliminación. Dado que la máquina ahora tiene un problema de red, no será posible solucionarlo de forma remota.

Tened la opción de acceder físicamente a la máquina o, por cualquier medio, arreglar la configuración de red impulsada por DHCP, o alternativamente podéis eliminar el finalizador machineinventory.elemental.cattle.io del MachineInventory, para permitir la eliminación, si tenéis la intención de desmantelar la máquina.