Características clave

VNIs estáticas por nodo trabajador

Cuando se crea un clúster Red Hat OpenShift on IBM Cloud basado en bare metal o un nuevo grupo de trabajadores en IBM Cloud VPC, se crean automáticamente dos VNI y se adjuntan estáticamente a cada nodo trabajador bare metal. Una VNI gestiona el tráfico normal de los trabajadores (red de pods, UDNs superpuestas y comunicación maestra). La segunda VNI actúa como portadora de los anexos VNI dinámicos que usted gestiona.

Anexos VNI dinámicos

Puede crear y gestionar VNIs bajo demanda tras la creación del cluster. Las VNI dinámicas pueden adjuntarse a trabajadores específicos o configurarse para flotar entre trabajadores de la misma zona, siguiendo las cargas de trabajo de VM durante la migración en vivo.

Asistencia a la migración en directo

Con las VNI conectadas a nodos de trabajo de metal desnudo, las migraciones en directo de máquinas virtuales basadas en la virtualización de OpenShift pueden conservar las conexiones de red. La VNI flota implícitamente y sigue la carga de trabajo entre instancias de trabajadores bare metal dentro de la misma zona.

Para conocer limitaciones y consideraciones importantes sobre las VNI, consulte Limitaciones y consideraciones.

Vinculación entre cuentas

En Red Hat OpenShift on IBM Cloud, los nodos trabajadores no se aprovisionan en su cuenta, lo que significa que la gestión del ciclo de vida de las VNI es ligeramente diferente de las instancias de metal desnudo de VPC independientes. El administrador del cluster Red Hat OpenShift on IBM Cloud tiene una visibilidad diferente a los adjuntos de las VNIs porque están adjuntas a cargas de trabajo que no son visibles dentro de la cuenta. Las diferencias en la gestión de VNI se tratan en esta documentación.

Para obtener más información sobre las VNI en instancias de VPC bare metal independientes, consulte Acerca de las interfaces de red virtuales.

Creación de una UDN primaria

Para utilizar una red primaria definida por el usuario para los pods o la carga de trabajo de VM, cree primero la propia UDN.

Ejemplo de una red definida por el usuario de clúster que puede utilizarse en varios espacios de nombres:

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

A continuación, cree el espacio o espacios de nombres que lo utilizarán. El espacio de nombres debe contener una etiqueta específica (denominada k8s.ovn.org/primary-user-defined-network) en el momento de su creación para el uso de UDN primarios.

Ejemplo:

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

Una vez que la (C)UDN y los espacios de nombres estén en su lugar, cualquier carga de trabajo creada en este espacio de nombres accederá a la UDN con la ruta predeterminada.

Creación de un UDN secundario

La configuración de la UDN secundaria es similar a la de la UDN primaria, pero con el rol establecido en Secondary. Para más información, consulte la documentación sobre redes múltiples de Red Hat OpenShift.

Instalación del operador NMState

OpenShift Servicio de virtualización Los clústeres tienen el operador NMState preinstalado y gestionado por el complemento « openshift-virtualization ». Omite este paso si utilizas el Servicio de virtualización.

1. Despliegue el Operador NMState desde OperatorHub en la consola Red Hat OpenShift on IBM Cloud o utilizando la CLI.

2. Crear una instancia de NMState con la configuración por defecto.

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

Creación del puente OVS

OpenShift Servicio de virtualización Los clústeres tienen los recursos NNCP necesarios preconfigurados. Solo es necesario crear estos recursos manualmente en el caso de los clústeres estándar de OpenShift con instalación manual de Virtualization OpenShift.

1. Cree un puente OVS dedicado con eth1 conectado a él desplegando el siguiente recurso personalizado NMState.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. Compruebe el estado del recurso personalizado y espere hasta que todos los nodos de clúster aplicables reconcilien la solicitud de creación de puente.

3. Parchea el nuevo puente OVS con el predeterminado creando el siguiente recurso personalizado NMState. Sustituya vpc-vlans por el nombre de red que desee.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. Compruebe el estado del recurso personalizado y espere hasta que todos los nodos de clúster aplicables reconcilien la solicitud de asignación de puentes.

Creación de una red localnet definida por el usuario

Cree una UDN o ClusterUserDefinedNetwork (CUDN) que ponga a disposición el tráfico de las VNI utilizando la VLAN seleccionada.

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

Sustituya los valores siguientes:

• vlan250: El nombre de su CUDN
• default: El espacio de nombres en el que desea utilizar el CUDN
• vpc-vlans: El nombre de la red física que definió en la asignación de puentes
• 250: Su ID de VLAN deseado (rango: 1-500)

Con esto concluye la fontanería de red de una VLAN específica. Se pueden definir varios CUDN utilizando diferentes ID de VLAN y reutilizando las asignaciones de puentes.

Después de completar la configuración localnet UDN, puede adjuntar VNIs al clúster utilizando la consola IBM Cloud o el comando IBM Cloud CLI ks vni. Consulte los ejemplos de las secciones siguientes.

Antes de empezar

1. Cree VNIs en su VPC con la configuración adecuada de subred y dirección IP.

2. Asegúrese de que dispone de los permisos necesarios para gestionar tanto el clúster como las VNI.

Ejemplo

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

Salida de ejemplo

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

Salida de ejemplo

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

Ejemplo

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

¿Por qué no puedo adjuntar pods normales a UDNs de localnet?

Las UDN de Localnet tienen desactivada la gestión de direcciones IP (IPAM) en el lado de OVN, lo que significa que la asignación de direcciones IP estáticas a los pods no se realiza desde OVN. Esta configuración está diseñada para cargas de trabajo VM que utilizan DHCP o configuran IPs estáticas dentro del sistema operativo invitado. Estas opciones no están disponibles para cargas de trabajo pod.

¿Por qué está pendiente la migración en directo entre grupos de trabajadores?

Diferentes grupos de trabajadores pueden tener diferentes tipos de trabajadores con CPUs de diferentes generaciones y capacidades. Si el conjunto completo de funciones de la CPU es visible de forma transparente para la carga de trabajo de VM, no podrá migrar en vivo VM a otro trabajador que no admita todas las funciones de la CPU. Puede limitar las características visibles de la CPU del sistema operativo invitado al principio para obtener más compatibilidad entre los sabores de los trabajadores.

¿Por qué no funcionan las VNI adjuntas dinámicas?

Compruebe los elementos siguientes:

• Compruebe que el ID de VLAN del CUDN coincide con el ID de VLAN del adjunto VNI. El DHCP de la VPC podría seguir funcionando sin más tráfico si la VLAN no coincide.
• Si la flotación no está activada, asegúrese de que la carga de trabajo está programada en el trabajador en el que está conectada la VNI.
• Compruebe que el puente OVS dedicado y la asignación están presentes en los trabajadores. Compruebe el estado del recurso NodeNetworkConfigurationPolicy.