Despliegue de aplicaciones de contenedor de interfaces de red activadas para SR-IOV en OKE mediante el plugin Multus CNI

Introducción

En este tutorial, exploraremos cómo desplegar aplicaciones en contenedores en nodos de trabajador de instancia virtual dentro de Oracle Cloud Infrastructure Kubernetes Engine (OKE), aprovechando capacidades de red avanzadas. En concreto, activaremos la virtualización de E/S de raíz única (SR-IOV) para las interfaces de red de contenedor y configuraremos el complemento Multus CNI para activar la red de hosts múltiples para los contenedores.

Al combinar SR-IOV con Multus, puedes lograr redes de alto rendimiento y baja latencia para cargas de trabajo especializadas como IA, aprendizaje automático y procesamiento de datos en tiempo real. En este tutorial se proporcionarán instrucciones paso a paso para configurar el entorno de OKE, desplegar nodos de trabajador con interfaces activadas para SR-IOV y utilizar Multus CNI para gestionar varias interfaces de red en los pods. Ya sea que esté buscando un procesamiento de paquetes de alta velocidad o necesite ajustar su red de Kubernetes, este tutorial le proporcionará las herramientas y los conocimientos necesarios para comenzar.

Nota:

Al momento de publicar este tutorial, los pods o contenedores no pueden utilizar el CNI SR-IOV en una instancia virtual que forme parte de un cluster de OKE junto con el plugin Multus CNI.

En este tutorial, le mostraremos cómo puede utilizar una interfaz con SR-IOV activada dentro de un pod que se ejecuta en pods o contenedores en una instancia virtual que forma parte de un cluster de OKE moviendo la Tarjetas de interfaz de red virtual (VNIC) (que está en una instancia virtual) en un pod y se puede utilizar con la ayuda del plugin Multus CNI (donde el plugin SR-IOV CNI no se utiliza en absoluto).

El plugin SR-IOV CNI está soportado en una instancia con hardware dedicado que forma parte de un cluster de OKE junto con el plugin Multus CNI. Esto está fuera del alcance de este tutorial.

Objetivos

Despliegue aplicaciones de contenedor en nodos de trabajador de instancia virtual dentro de OKE con interfaces de red activadas para SR-IOV mediante el plugin Multus CNI.

Tarea 1: Despliegue de OKE con un bastión, un operador, tres nodos de trabajador de VM y el plugin CNI de Flannel

Asegúrese de que OKE se despliegue con la siguiente configuración:

Bastion
Operador
3 nodos de trabajador de VM
Plugin CNI de Flannel

Esta configuración se detalla en el tutorial aquí: Despliegue de un cluster de Kubernetes con Terraform con Oracle Cloud Infrastructure Kubernetes Engine.

La siguiente imagen muestra una visión general visual de los componentes con los que trabajaremos a lo largo de este tutorial.

Tarea 2: Activación de la red SR-IOV (asistida por hardware) en cada nodo de trabajador

Nota: Se deben realizar los siguientes pasos en todos los nodos de trabajador que forman parte del cluster de OKE.

En la siguiente imagen se muestra una visión general visual de nuestros nodos de trabajador dentro del cluster de OKE con los que trabajaremos a lo largo de este tutorial.

Activar SR-IOV en la instancia

Conéctese con SSH a la instancia o al nodo de trabajador.
1. Ejecute el comando lspci para verificar qué controlador de red se utiliza actualmente en todas las VNIC.
2. Tenga en cuenta que se utiliza el controlador de red Virtio.
1. Vaya a la página Detalles de instancia de la consola de OCI.
2. Desplazar hacia abajo.
3. Tenga en cuenta que el tipo de asociación NIC ahora es PARAVIRTUALIZED.
1. Vaya a la página Detalles de instancia de la consola de OCI.
2. Haga clic en Más acciones.
3. Haga clic en Editar.
Haga clic en Mostrar las opciones avanzadas.
1. Haga clic en Opciones de inicio y seleccione Red asistida por hardware (SR-IOV) como Tipo de red.
2. Haga clic en Save changes.
Haga clic en Reiniciar instancia para confirmar el reinicio de la instancia.
Tenga en cuenta que el estado de la instancia ha cambiado a STOPPING.
Tenga en cuenta que el estado de la instancia ha cambiado a STARTING.
Tenga en cuenta que el estado de la instancia ha cambiado a RUNNING.
1. Desplazar hacia abajo.
2. Tenga en cuenta que el tipo de asociación NIC ahora es VFIO.
La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 3: Creación de una nueva subred para las VNIC activadas para SR-IOV

Crearemos una subred dedicada que utilizarán nuestras interfaces habilitadas para SR-IOV.

Tarea 3.1: Creación de una Lista de Seguridad

Como ya estamos utilizando listas de seguridad para las otras subredes, pero también necesitamos una lista de seguridad dedicada para la subred SR-IOV recién creada.

Vaya a la consola de OCI.
1. Vaya a Redes virtuales en la nube.
2. Haga clic en la VCN existente.
1. Haga clic en Listas de seguridad.
2. Haga clic en Crear lista de seguridad.
Para la regla de entrada 1, introduzca la siguiente información.
1. Introduzca un nombre.
2. Seleccione CIDR para Tipo de origen.
3. Introduzca 0.0.0.0/0 como CIDR de origen.
4. Seleccione Todos los protocolos en Protocolo IP.
5. Desplazar hacia abajo.
1. Para la regla de salida 1, introduzca la siguiente información.
2. Seleccione CIDR para Tipo de origen.
3. Introduzca 0.0.0.0/0 como CIDR de origen.
4. Seleccione Todos los protocolos en Protocolo IP.
5. Haga clic en Crear lista de seguridad.
Tenga en cuenta que se crea la nueva lista de seguridad.

Tarea 3.2: Creación de una subred

Vaya a la página Virtual Cloud Network Details (Detalles de Red Virtual en la nube).
1. Haga clic en Subredes.
2. Observe las subredes existentes que ya se han creado para el entorno de OKE.
3. Haga clic en Crear subred.
1. Introduzca un nombre.
2. Introduzca el bloque de IPv4 CIDR.
3. Desplazar hacia abajo.
1. Seleccione Subred privada.
2. Desplazar hacia abajo.
1. Seleccione Opciones de DHCP por defecto para Opciones de DHCP.
2. Seleccione la lista de seguridad creada en la tarea 3.1.
3. Haga clic en Crear subred.
Tenga en cuenta que se crea la subred de red.
Nota:
- La subred en sí no tiene ningún componente técnico con SR-IOV activado.
- En este tutorial, estamos utilizando una subred OCI estándar para permitir el transporte de tráfico mediante la tecnología SR-IOV.
La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 4: Agregar una segunda asociación de VNIC

En la siguiente imagen se muestra una visión general visual de cómo los nodos de trabajador tienen una única VNIC que está conectada a la subred de nodos de trabajador antes de agregar una segunda VNIC.

Antes de agregar una segunda asociación de VNIC a los nodos de trabajador, cree un grupo de seguridad de red.

Tarea 4.1: Creación de un grupo de seguridad de red (NSG)

Ya estamos utilizando el NSG para las otras VNIC, pero también necesitamos un NSG dedicado para la VNIC recién creada que agregaremos a una instancia virtual existente que forme parte del cluster de OKE y que desempeñará su papel como nodo de trabajador de Kubernetes. Esta interfaz será una VNIC donde tenemos SR-IOV activado.

Vaya a la página Virtual Cloud Network Details (Detalles de Red Virtual en la nube).
1. Vaya a Network Security Groups.
2. Haga clic en Crear grupo de seguridad de red.
Agregue las siguientes reglas.
1. Ingress:
  - Permitir Tipo de Origen: seleccione CIDR.
  - Origen: introduzca 0.0.0.0/0.
  - Destino: deje el destino en blanco.
  - Protocolo: permite todos los protocolos.
2. Salida:
  - Permitir Tipo de Origen: seleccione CIDR.
  - Origen: deje el origen en blanco.
  - Destino: introduzca 0.0.0.0/0.
  - Protocolo: permite todos los protocolos.
Tenga en cuenta que se crea el NSG. La aplicaremos a la nueva VNIC (secundaria) que crearemos (en cada nodo de trabajador del cluster de OKE).

Tarea 4.2: Agregar la VNIC

Navegue a cada instancia de nodo de trabajador virtual y agregue una segunda VNIC a cada nodo de trabajador.
1. Navegue a cada instancia de nodo de trabajador virtual y haga clic en VNIC asociadas.
2. Tenga en cuenta que ya hay una VNIC existente.
3. Haga clic en Crear VNIC para agregar una segunda VNIC.
1. Introduzca un nombre.
2. Seleccione la VCN.
3. Seleccione la subred creada en la tarea 3.2.
4. Seleccione Utilizar grupos para controlar el tráfico.
5. Seleccione el NSG creado en la tarea 4.1.
6. Desplazar hacia abajo.
1. Seleccione Asignar automáticamente dirección IPv4 privada.
2. Haga clic en Save changes.
Tenga en cuenta que la segunda VNIC se crea y se asocia a la instancia de nodo de trabajador virtual y también a nuestra subred.
Conéctese con SSH a la instancia o al nodo de trabajador.
1. Ejecute el comando lspci para verificar qué controlador de red se utiliza actualmente en todas las VNIC.
2. Tenga en cuenta que se utiliza el controlador de red de la familia ConnectX de Mellanox Technologies mlx5Gen Virtual Function.
El controlador de red de función virtual de la familia ConnectX mlx5Gen de Mellanox Technologies es el controlador de función virtual (VF) que utiliza SR-IOV. Por lo tanto, la VNIC está activada para SR-IOV con una VF.
La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 5: Asignación de una dirección IP a la nueva segunda VNIC con un gateway por defecto

Ahora que se ha creado la segunda VNIC en la tarea 4 y se ha conectado, debemos asignarle una dirección IP. Al agregar una segunda interfaz a una instancia, puede asignarla a la misma subred que la primera interfaz, o bien seleccionar una nueva subred.

DHCP no está activado para la segunda interfaz, por lo que la dirección IP debe asignarse manualmente.

Existen diferentes métodos para asignar la dirección IP para la segunda interfaz.

Método 1: utilice la interfaz de línea de comandos de Oracle Cloud Infrastructure (CLI de OCI) (paquete oci-utils) para asignar una dirección IP a la segunda interfaz de una instancia de OCI Compute mediante el comando OCI-network-config.
Método 2: utilice la CLI de OCI (paquete oci-utils) para asignar una dirección IP a la segunda interfaz de una instancia de OCI Compute mediante el daemonocid.
Método 3: utilice el script OCI_Multi_VNIC_Setup.
Método 4: cree el archivo de configuración de interfaz manualmente para la nueva VNIC en la carpeta /etc/sysconfig/network-scripts/.

Para todos los nodos de trabajador, hemos asignado una dirección IP a la vNIC secundaria (ens5). Utilizamos el método 3 para asignar una dirección IP a la vNIC secundaria (ens5). Para obtener más información sobre la asignación de una dirección IP a la segunda VNIC, consulte Assign an IP Address to a Second Interface on an Oracle Linux Instance.

Una vez que la dirección IP se ha asignado a una VNIC, debemos verificar si la dirección IP de la segunda VNIC está configurada correctamente. También podemos verificar si hemos activado SR-IOV en todos los nodos de trabajador del pool de nodos.

Nuestro cluster de OKE consta de:

Pool de nodos
NP1	1 x nodo de trabajador
NP2	3 x nodos de trabajador

Verificaremos todos los nodos de trabajador en todos los pools de nodos.

Tarea 5.1: Verificación de todos los nodos del pool de nodos 1 (`np1`)

En el cluster de OKE, haga clic en Nodos.
Haga clic en el primer pool de nodos (np1).
Haga clic en el nodo de trabajador que forma parte de este pool de nodos.
1. Tenga en cuenta que el tipo de asociación NIC es VFIO (esto significa que SR-IOV está activado para este nodo de trabajador de instancia virtual).
2. Tenga en cuenta que la segunda VNIC se crea y se conecta para este nodo de trabajador.

Tarea 5.2: Verificación de todos los nodos del pool de nodos 2 (`np2`)

Haga clic en los nodos uno por uno e inicie la verificación.
1. Tenga en cuenta que el tipo de asociación NIC es VFIO (esto significa que SR-IOV está activado para este nodo de trabajador de instancia virtual).
2. Tenga en cuenta que la segunda VNIC se crea y se conecta para este nodo de trabajador.
Vaya a la página de resumen del pool de nodos 2 (np2). Haga clic en el segundo nodo de trabajador del pool de nodos.
1. Tenga en cuenta que el tipo de asociación NIC es VFIO (esto significa que SR-IOV está activado para este nodo de trabajador de instancia virtual).
2. Tenga en cuenta que la segunda VNIC se crea y se conecta para este nodo de trabajador.
Vaya a la página de resumen del pool de nodos 2 (np2). Haga clic en el tercer nodo de trabajador del pool de nodos.
1. Tenga en cuenta que el tipo de asociación NIC es VFIO (esto significa que SR-IOV está activado para este nodo de trabajador de instancia virtual).
2. Tenga en cuenta que la segunda VNIC se crea y se conecta para este nodo de trabajador.

Conéctese mediante SSH al operador de Kubernetes.

Ejecute el comando kubectl get nodes para recuperar una lista y direcciones IP de todos los nodos de trabajador.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Para facilitar la conexión SSH en todos los nodos de trabajador, hemos creado la siguiente tabla.

Nombre de nodo de trabajador	IP ens3	nodo de trabajador de comando SSH
cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0	10.0.112.134	`ssh -i id_rsa opc@10.0.112.134`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1	10.0.66.97	`ssh -i id_rsa opc@10.0.66.97`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0	10.0.73.242	`ssh -i id_rsa opc@10.0.73.242`
cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2	10.0.89.50	`ssh -i id_rsa opc@10.0.89.50`

Antes de poder utilizar SSH en todos los nodos de trabajador virtual, asegúrese de tener disponible la clave privada correcta.
Ejecute el comando ssh -i <private key> opc@<ip-address> para utilizar SSH en todos los nodos de trabajador.

Ejecute el comando ip a en el nodo de trabajador cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0.

Tenga en cuenta que cuando la dirección IP se ha configurado correctamente, ens5 (segunda VNIC) tiene una dirección IP en el rango de la subred creada en la tarea 3.2 para las interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85530sec preferred_lft 85530sec
   inet6 fe80::17ff:fe00:5958/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.30/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::8106:c09e:61fa:1d2a/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
      valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
   inet6 fe80::74e2:92ff:fead:3740/64 scope link
      valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
   inet6 fe80::989a:fff:fed6:4817/64 scope link
      valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
   inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$

Ejecute el comando ip a en el nodo de trabajador cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1.

Tenga en cuenta que cuando la dirección IP se ha configurado correctamente, ens5 (segunda VNIC) tiene una dirección IP en el rango de la subred creada en la tarea 3.2 para las interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 85859sec preferred_lft 85859sec
   inet6 fe80::17ff:fe00:16ca/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.15/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::87eb:4195:cacf:a6da/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::92:e7ff:fef5:8e29/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
   inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
      valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
   inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
      valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
   inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$

Ejecute el comando ip a en el nodo de trabajador cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0.

Tenga en cuenta que cuando la dirección IP se ha configurado correctamente, ens5 (segunda VNIC) tiene una dirección IP en el rango de la subred creada en la tarea 3.2 para las interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86085sec preferred_lft 86085sec
   inet6 fe80::17ff:fe00:499c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.14/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::bc31:aa09:4e05:9ab7/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.0/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::282b:cbff:fefb:1582/64 scope link
      valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
   inet6 fe80::c870:83ff:fe13:dced/64 scope link
      valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
   inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$

Ejecute el comando ip a en el nodo de trabajador cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2.

Tenga en cuenta que cuando la dirección IP se ha configurado correctamente, ens5 (segunda VNIC) tiene una dirección IP en el rango de la subred creada en la tarea 3.2 para las interfaces SR-IOV.

[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
   altname enp0s3
   inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
      valid_lft 86327sec preferred_lft 86327sec
   inet6 fe80::17ff:fe00:ac7c/64 scope link
      valid_lft forever preferred_lft forever
3: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
   link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
   altname enp0s5
   inet 10.0.3.16/27 brd 10.0.3.31 scope global noprefixroute ens5
      valid_lft forever preferred_lft forever
   inet6 fe80::91eb:344e:829e:35de/64 scope link noprefixroute
      valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
   link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.128/32 scope global flannel.1
      valid_lft forever preferred_lft forever
   inet6 fe80::a831:9fff:fed0:b33c/64 scope link
      valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
   link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
   inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
      valid_lft forever preferred_lft forever
   inet6 fe80::b00d:c0ff:fede:261/64 scope link
      valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
   inet6 fe80::7893:1dff:fe2a:338c/64 scope link
      valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
   link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
   inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
      valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$

Hemos verificado que todas las direcciones IP están configuradas en la segunda VNIC (ens5), podemos crear la siguiente tabla con la información.

IP ens3	ens3 GW	IP ens5	ens5 GW
10.0.112.134	10.0.64.1	10.0.3.30/27	10.0.3.1
10.0.66.97	10.0.64.1	10.0.3.15/27	10.0.3.1
10.0.73.242	10.0.64.1	10.0.3.14/27	10.0.3.1
10.0.89.50	10.0.64.1	10.0.3.16/27	10.0.3.1

La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 6: Instalación de un CNI de metaplugina (Multus CNI) en el nodo de trabajador

Multus CNI es un plugin de interfaz de red de contenedores (CNI) de Kubernetes que permite asociar varias interfaces de red a un pod.

Cómo funciona Multus CNI

Actúa como un meta-plugin: Multus no proporciona la red en sí, sino que llama a otros plugins CNI.
Crea varias interfaces de red: cada pod puede tener más de una interfaz de red mediante la combinación de varios plugins CNI (por ejemplo, Flannel, Calico, SR-IOV).
Utiliza un archivo de configuración: la red principal se configura mediante el CNI predeterminado y las redes adicionales se conectan según una definición de recursos personalizada (CRD).

Por qué necesitamos Multus CNI

Aislamiento de varias redes: útil para cargas de trabajo que requieren planos de datos y gestión independientes.
Red de alto rendimiento: permite el acceso directo al hardware mediante SR-IOV o DPDK.
Multi-Homing para pods: admite casos de uso de virtualización de funciones de red (NFV) y telecomunicaciones en los que son esenciales varias interfaces de red.

Tarea 6.1: Instalación de Multus CNI mediante el método de instalación delgada

SSH en el operador de Kubernetes.
1. Ejecute el siguiente comando para clonar la biblioteca Multus Git.
```
git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
```
2. Ejecute el siguiente comando para instalar el juego de daemon de Multus mediante el método de instalación Thin.
```
kubectl apply -f deployments/multus-daemonset.yml && cd ..
```

Lo que hace el juego de daemon de Multus

Inicia un juego de daemon de Multus, que ejecuta un pod en cada nodo y coloca un binario de Multus en cada nodo en /opt/cni/bin.
Lee el primer archivo de configuración lexicográficamente (por orden alfabético) en /etc/cni/net.d y crea un nuevo archivo de configuración para Multus en cada nodo como /etc/cni/net.d/00-multus.conf, esta configuración se genera automáticamente y se basa en la configuración de red por defecto (que se supone que es la primera configuración alfabética).
Crea un directorio denominado /etc/cni/net.d/multus.d en cada nodo con información de autenticación para que Multus acceda a la API de Kubernetes.

Tarea 6.2: Validación de la instalación de Multus

Ejecute el siguiente comando (en el operador de Kubernetes) para validar si el juego de daemon de Multus está instalado en todos los nodos de trabajador.
```
kubectl get pods --all-namespaces | grep -i multus
```
También puede verificar si el juego de daemon de Multus está instalado en los propios nodos de trabajador.
1. Ejecute el comando ssh -i id_rsa opc@10.0.112.134 para utilizar SSH en el nodo de trabajador con el siguiente comando.
2. Ejecute el comando cd /etc/cni/net.d/ para cambiar el directorio con el siguiente comando.
3. Ejecute el comando ls -l para mostrar la salida del directorio con el siguiente comando.
4. Tenga en cuenta que se muestran los archivos 00-multus.conf y multus.d.
1. Ejecute el comando sudo more 00-multus.conf para ver el contenido del archivo 00-multus.conf.
2. Observe el contenido del archivo 00-multus.conf.

Tarea 7: Asociación de interfaces de red a pods

En esta tarea, asignaremos o asociaremos una interfaz de contenedor a esta VNIC.

Para conectar interfaces adicionales a los pods, necesitamos una configuración para que se conecte la interfaz.

Esto se encapsula en el recurso personalizado del tipo NetworkAttachmentDefinition.
Esta configuración es esencialmente una configuración CNI empaquetada como un recurso personalizado.

Hay varios plugins CNI que se pueden utilizar junto con Multus para lograr esto. Para obtener más información, consulte Visión general de plugins.

En el enfoque descrito aquí, el objetivo es proporcionar una función virtual SR-IOV (VF) exclusivamente para un solo pod, de modo que el pod pueda aprovechar las capacidades sin interferencias o cualquier capa intermedia.
Para otorgar a un pod acceso exclusivo a la VF, podemos aprovechar el plugin host-dispositivo que le permite mover la interfaz al espacio de nombres del pod para que tenga acceso exclusivo a él. Para obtener más información, consulte host-device.

En el siguiente ejemplo, se muestran los objetos NetworkAttachmentDefinition que configuran la interfaz ens5 secundaria que se agregó a los nodos.

La configuración del plugin ipam determina cómo se gestionan las direcciones IP para estas interfaces.
En este ejemplo, dado que queremos utilizar las mismas direcciones IP que OCI asignó a las interfaces secundarias, utilizamos la configuración estática ipam con las rutas adecuadas.
La configuración ipam también soporta otros métodos como host-local o dhcp para configuraciones más flexibles.

Tarea 7.1: Crear definición de asociación de red

NetworkAttachmentDefinition se utiliza para configurar la asociación de red, por ejemplo, la interfaz secundaria para el pod.

Existen dos modos de configurar NetworkAttachmentDefinition:

NetworkAttachmentDefinition con configuración de CNI de JSON.
NetworkAttachmentDefinition con el archivo de configuración CNI.

Nota: En este tutorial, vamos a utilizar el método mediante el archivo de configuración de CNI.

Tenemos 4 nodos de trabajador x y cada nodo de trabajador tiene una segunda VNIC que asignaremos a una interfaz en un contenedor (pod).

Ejecute los siguientes comandos para crear los archivos de configuración de CNI para todos los nodos de trabajador y las VNIC correspondientes.

ens3	ens5	name	red	comando nano
10.0.112.134	10.0.3.30/27	sriov-vnic-1	10.0.3.0/27	`sudo nano sriov-vnic-1.yaml`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	10.0.3.0/27	`sudo nano sriov-vnic-2.yaml`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	10.0.3.0/27	`sudo nano sriov-vnic-3.yaml`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	10.0.3.0/27	`sudo nano sriov-vnic-4.yaml`

Realice los siguientes pasos en el operador de Kubernetes. Cree un nuevo archivo YAML para el primer nodo de trabajador mediante el comando sudo nano sriov-vnic-1.yaml.
- Asegúrese de que el nombre es único y descriptivo. En este ejemplo, estamos utilizando sriov-vnic-1.
- Utilice la dirección IP del segundo adaptador que acaba de agregar (ens5).
- Asegúrese de que dst network también es correcto, es lo mismo que la subred creada en la tarea 3.2.
sriov-vnic-1.yaml:
```
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-1
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.30/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'
```

Cree un nuevo archivo YAML para el segundo nodo de trabajador mediante el comando sudo nano sriov-vnic-2.yaml.

sriov-vnic-2.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.15/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Cree un nuevo archivo YAML para el tercer nodo de trabajador mediante el comando sudo nano sriov-vnic-3.yaml.

sriov-vnic-3.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-3
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.14/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Cree un nuevo archivo YAML para el cuarto nodo de trabajador mediante el comando sudo nano sriov-vnic-4.yaml.

sriov-vnic-4.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-4
spec:
config: '{
  "cniVersion": "0.3.1",
  "type": "host-device",
  "device": "ens5",
  "ipam": {
  "type": "static",
  "addresses": [
  {
  "address": "10.0.3.16/27",
  "gateway": "0.0.0.0"
  }
  ],
  "routes": [
  { "dst": "10.0.3.0/27", "gw": "0.0.0.0" }
  ]
  }
  }'

Aplique NetworkAttachmentDefinition a los nodos de trabajador.

Ejecute el comando kubectl apply -f sriov-vnic-1.yaml para el primer nodo.
Ejecute el comando kubectl apply -f sriov-vnic-2.yaml para el segundo nodo.
Ejecute el comando kubectl apply -f sriov-vnic-3.yaml para el tercer nodo.
Ejecute el comando kubectl apply -f sriov-vnic-4.yaml para el cuarto nodo.

Si NetworkAttachmentDefinition se aplica correctamente, verá algo similar a la salida.

[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-1.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-2.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-3.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 created
[opc@o-sqrtga ~]$ kubectl apply -f sriov-vnic-4.yaml
networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 created
[opc@o-sqrtga ~]$

Ejecute el comando kubectl get network-attachment-definitions.k8s.cni.cncf.io para verificar si NetworkAttachmentDefinitions se ha aplicado correctamente.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   96s
sriov-vnic-2   72s
sriov-vnic-3   60s
sriov-vnic-4   48s
[opc@o-sqrtga ~]$

Ejecute el comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml para obtener el NetworkAttachmentDefinition aplicado para el primer nodo de trabajador.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-1","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.30/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:03:55Z"
generation: 1
name: sriov-vnic-1
namespace: default
resourceVersion: "22915413"
uid: 2d529130-2147-4f49-9d78-4e5aa12aea62
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.30/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Ejecute el comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml para obtener el NetworkAttachmentDefinition aplicado para el segundo nodo de trabajador.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-2","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.15/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:19Z"
generation: 1
name: sriov-vnic-2
namespace: default
resourceVersion: "22915508"
uid: aec5740c-a093-43d3-bd6a-2209ee9e5c96
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.15/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Ejecute el comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml para obtener el NetworkAttachmentDefinition aplicado para el tercer nodo de trabajador.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-3","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.14/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:31Z"
generation: 1
name: sriov-vnic-3
namespace: default
resourceVersion: "22915558"
uid: 91b970ff-328f-4b6b-a0d8-7cdd07d7bca3
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.14/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'

Ejecute el comando kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml para obtener el NetworkAttachmentDefinition aplicado para el cuarto nodo de trabajador.

[opc@o-sqrtga ~]$ kubectl get networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4 -o yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
   kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"k8s.cni.cncf.io/v1","kind":"NetworkAttachmentDefinition","metadata":{"annotations":{},"name":"sriov-vnic-4","namespace":"default"},"spec":{"config":"{ \"cniVersion\": \"0.3.1\", \"type\": \"host-device\", \"device\": \"ens5\", \"ipam\": { \"type\": \"static\", \"addresses\": [ { \"address\": \"10.0.3.16/27\", \"gateway\": \"0.0.0.0\" } ], \"routes\": [ { \"dst\": \"10.0.3.0/27\", \"gw\": \"0.0.0.0\" } ] } }"}}
creationTimestamp: "2024-12-18T09:04:43Z"
generation: 1
name: sriov-vnic-4
namespace: default
resourceVersion: "22915607"
uid: 383fd3f0-7e5e-46ec-9997-29cbc9a2dcea
spec:
config: '{ "cniVersion": "0.3.1", "type": "host-device", "device": "ens5", "ipam":
   { "type": "static", "addresses": [ { "address": "10.0.3.16/27", "gateway": "0.0.0.0"
   } ], "routes": [ { "dst": "10.0.3.0/27", "gw": "0.0.0.0" } ] } }'
[opc@o-sqrtga ~]$

La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 7.2: Creación de pods con `NetworkDefinitionAttachment` asociado

En esta tarea, vincularemos NetworkAttachmentDefinitions a un contenedor o pod real.

En la siguiente tabla, hemos creado una asignación en qué pod queremos alojar en qué nodo de trabajador.

IP de nodo de trabajador (principal)	ens5	name	nombre de pod	finalizado
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	SÍ
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	SÍ
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	SÍ
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	SÍ

Tarea 7.3: Creación de pods con afinidad de nodos

Por defecto, Kubernetes decidirá dónde se colocarán los pods (nodo de trabajador). En este ejemplo, esto no es posible porque NetworkAttachmentDefinition está enlazado a una dirección IP y esta dirección IP está enlazada a una VNIC y esta VNIC está enlazada a un nodo de trabajador específico. Por lo tanto, debemos asegurarnos de que los pods que creamos terminarán en el nodo de trabajador que deseamos y esto es necesario cuando asociamos NetworkAttachmentDefinition a un pod.

Si no lo hacemos, puede ocurrir que un pod termine en un punto diferente donde la dirección IP esté disponible para el pod. Por lo tanto, el pod no podrá comunicarse mediante la interfaz activada para SR-IOV.

Obtenga todos los nodos disponibles mediante el comando kubectl get nodes.

[opc@o-sqrtga ~]$ kubectl get nodes
NAME           STATUS   ROLES   AGE   VERSION
10.0.112.134   Ready    node    68d   v1.30.1
10.0.66.97     Ready    node    68d   v1.30.1
10.0.73.242    Ready    node    68d   v1.30.1
10.0.89.50     Ready    node    68d   v1.30.1
[opc@o-sqrtga ~]$

Asigne una etiqueta al nodo de trabajador 1 mediante el comando kubectl label node 10.0.112.134 node_type=testpod1.
Asigne una etiqueta al nodo de trabajador 2 mediante el comando kubectl label node 10.0.66.97 node_type=testpod2.
Asigne una etiqueta al nodo de trabajador 3 mediante el comando kubectl label node 10.0.73.242 node_type=testpod3.
Asigne una etiqueta al nodo de trabajador 4 mediante el comando kubectl label node 10.0.89.50 node_type=testpod4.

[opc@o-sqrtga ~]$ kubectl label node 10.0.112.134 node_type=testpod1
node/10.0.112.134 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.73.242 node_type=testpod3
node/10.0.73.242 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.66.97 node_type=testpod2
node/10.0.66.97 labeled
[opc@o-sqrtga ~]$ kubectl label node 10.0.89.50 node_type=testpod4
node/10.0.89.50 labeled
[opc@o-sqrtga ~]$

La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Cree un archivo YAML para testpod1 mediante el comando sudo nano testpod1-v2.yaml.

Observe la sección annotations en la que enlazamos NetworkAttachmentDefinition que hemos creado anteriormente (sriov-vnic-1) a este pod de prueba.
Observe la sección spec:affinity:nodeAffinity en la que enlazamos el pod de prueba a un nodo de trabajador específico con la etiqueta testpod1.

sudo nano testpod1-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Cree un archivo YAML para testpod2 mediante el comando sudo nano testpod2-v2.yaml.

Observe la sección annotations en la que enlazamos NetworkAttachmentDefinition que hemos creado anteriormente (sriov-vnic-2) a este pod de prueba.
Observe la sección spec:affinity:nodeAffinity en la que enlazamos el pod de prueba a un nodo de trabajador específico con la etiqueta testpod2.

sudo nano testpod2-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod2
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod2
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Cree un archivo YAML para testpod3 mediante el comando sudo nano testpod3-v2.yaml.

Observe la sección annotations en la que enlazamos NetworkAttachmentDefinition que hemos creado anteriormente (sriov-vnic-3) a este pod de prueba.
Observe la sección spec:affinity:nodeAffinity en la que enlazamos el pod de prueba a un nodo de trabajador específico con la etiqueta testpod3.

sudo nano testpod3-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod3
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-3
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod3
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Cree un archivo YAML para testpod4 mediante el comando sudo nano testpod4-v2.yaml.

Observe la sección annotations en la que enlazamos NetworkAttachmentDefinition que hemos creado anteriormente (sriov-vnic-4) a este pod de prueba.
Observe la sección spec:affinity:nodeAffinity en la que enlazamos el pod de prueba a un nodo de trabajador específico con la etiqueta testpod4

sudo nano testpod4-v2.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod4
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-4
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod4
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Cree el archivo testpod1 aplicando el archivo YAML mediante el comando kubectl apply -f testpod1-v2.yaml.
Cree el archivo testpod2 aplicando el archivo YAML mediante el comando kubectl apply -f testpod2-v2.yaml.
Cree el archivo testpod3 aplicando el archivo YAML mediante el comando kubectl apply -f testpod3-v2.yaml.
Cree el archivo testpod4 aplicando el archivo YAML mediante el comando kubectl apply -f testpod4-v2.yaml.

[opc@o-sqrtga ~]$ kubectl apply -f testpod1-v2.yaml
pod/testpod1 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod2-v2.yaml
pod/testpod2 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod3-v2.yaml
pod/testpod3 created
[opc@o-sqrtga ~]$ kubectl apply -f testpod4-v2.yaml
pod/testpod4 created
[opc@o-sqrtga ~]$

Verifique si los pods de prueba se crean con el comando kubectl get pod. Tenga en cuenta que todos los pods de prueba se crean y tienen el valor Running STATUS.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          40d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          40d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          40d
mysql-6d7f5d5944-dlm78     1/1     Running   12         35d
testpod1                   1/1     Running   0          2m29s
testpod2                   1/1     Running   0          2m17s
testpod3                   1/1     Running   0          2m5s
testpod4                   1/1     Running   0          111s
[opc@o-sqrtga ~]$

Verifique si testpod1 se está ejecutando en el nodo de trabajador 10.0.112.134 con la etiqueta testpod1 mediante el comando kubectl get pod testpod1 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod1 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE           NOMINATED NODE   READINESS GATES
testpod1   1/1     Running   0          3m41s   10.244.1.6   10.0.112.134   <none>           <none>

Verifique si testpod2 se está ejecutando en el nodo de trabajador 10.0.66.97 con la etiqueta testpod2 mediante el comando kubectl get pod testpod2 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod2 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod2   1/1     Running   0          3m33s   10.244.1.133   10.0.66.97   <none>           <none>

Verifique si testpod3 se está ejecutando en el nodo de trabajador 10.0.73.242 con la etiqueta testpod3 mediante el comando kubectl get pod testpod3 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod3 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP           NODE          NOMINATED NODE   READINESS GATES
testpod3   1/1     Running   0          3m25s   10.244.0.5   10.0.73.242   <none>           <none>

Verifique si testpod4 se está ejecutando en el nodo de trabajador 10.0.89.50 con la etiqueta testpod4 mediante el comando kubectl get pod testpod4 -o wide.

[opc@o-sqrtga ~]$ kubectl get pod testpod4 -o wide
NAME       READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
testpod4   1/1     Running   0          3m22s   10.244.0.133   10.0.89.50   <none>           <none>

La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 7.4: Verificación de la dirección IP en los pods de prueba

Verifique la dirección IP de testpod1 para la interfaz de pod net1 mediante el comando kubectl exec -it testpod1 -- ip addr show.

Tenga en cuenta que la dirección IP de la interfaz net1 es 10.0.3.30/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ca:28:e4:5f:66:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.132/25 brd 10.244.0.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::c828:e4ff:fe5f:66c4/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:4c:0d brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.30/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:4c0d/64 scope link
	valid_lft forever preferred_lft forever

Verifique la dirección IP de testpod2 para la interfaz de pod net1 mediante el comando kubectl exec -it testpod2 -- ip addr show.

Tenga en cuenta que la dirección IP de la interfaz net1 es 10.0.3.15/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether da:ce:84:22:fc:29 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.132/25 brd 10.244.1.255 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::d8ce:84ff:fe22:fc29/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:7b:4f brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.15/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:7b4f/64 scope link
	valid_lft forever preferred_lft forever

Verifique la dirección IP de testpod3 para la interfaz de pod net1 mediante el comando kubectl exec -it testpod3 -- ip addr show.

Tenga en cuenta que la dirección IP de la interfaz net1 es 10.0.3.14/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether de:f2:81:10:04:b2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.0.4/25 brd 10.244.0.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::dcf2:81ff:fe10:4b2/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:b7:51 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.14/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:b751/64 scope link
	valid_lft forever preferred_lft forever

Verifique la dirección IP de testpod4 para la interfaz de pod net1 mediante el comando kubectl exec -it testpod4 -- ip addr show.

Tenga en cuenta que la dirección IP de la interfaz net1 es 10.0.3.16/27.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default
	link/ether ea:63:eb:57:9c:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
	inet 10.244.1.5/25 brd 10.244.1.127 scope global eth0
	valid_lft forever preferred_lft forever
	inet6 fe80::e863:ebff:fe57:9c99/64 scope link
	valid_lft forever preferred_lft forever
3: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:d4:a2 brd ff:ff:ff:ff:ff:ff
	inet 10.0.3.16/27 brd 10.0.3.31 scope global net1
	valid_lft forever preferred_lft forever
	inet6 fe80::17ff:fe00:d4a2/64 scope link
	valid_lft forever preferred_lft forever
[opc@o-sqrtga ~]$

En la siguiente tabla, se muestra una visión general de todas las direcciones IP de las interfaces net1 para todos los pods de prueba.

nombre de pod	IP net1
testpod1	10.0.3.30/27
testpod2	10.0.3.15/27
testpod3	10.0.3.14/27
testpod4	10.0.3.16/27

Nota: Estas direcciones IP están en el mismo rango que la subred de OCI que se creó en la tarea 3 para colocar nuestras VNIC activadas para SR-IOV.

Tarea 7.5: Verificación de la dirección IP en los nodos de trabajador

Ahora que las interfaces net1 de los pods de prueba tienen una dirección IP, tenga en cuenta que esta dirección IP solía ser la dirección IP de la interfaz ens5 en los nodos de trabajador. Esta dirección IP ahora se mueve de la interfaz de nodo de trabajador ens5 a la interfaz de pod de prueba net1.

Utilice SSH en el primer nodo de trabajador mediante el comando ssh -i id_rsa opc@10.0.112.134.

Obtenga las direcciones IP de todas las interfaces mediante el comando ip a.
Tenga en cuenta que la interfaz ens5 se ha eliminado del nodo de trabajador.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.112.134
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:42:19 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:59:58 brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.112.134/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82180sec preferred_lft 82180sec
	inet6 fe80::17ff:fe00:5958/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 3a:b7:fb:e6:2e:cf brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::38b7:fbff:fee6:2ecf/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether de:35:f5:51:85:5d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.1/25 brd 10.244.1.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::dc35:f5ff:fe51:855d/64 scope link
	valid_lft forever preferred_lft forever
6: veth1cdaac17@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 76:e2:92:ad:37:40 brd ff:ff:ff:ff:ff:ff link-netns 1935ba66-34cc-4468-8abb-f66add46d08b
	inet6 fe80::74e2:92ff:fead:3740/64 scope link
	valid_lft forever preferred_lft forever
7: vethbcd391ab@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 9a:9a:0f:d6:48:17 brd ff:ff:ff:ff:ff:ff link-netns 3f02d5fd-596e-4b9f-8a35-35f2f946901b
	inet6 fe80::989a:fff:fed6:4817/64 scope link
	valid_lft forever preferred_lft forever
8: vethc15fa705@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3a:d2:c8:66:d1:0b brd ff:ff:ff:ff:ff:ff link-netns f581b7f2-cfa0-46eb-b0aa-37001a11116d
	inet6 fe80::38d2:c8ff:fe66:d10b/64 scope link
	valid_lft forever preferred_lft forever
9: vethc663e496@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7e:0b:bb:5d:49:8c brd ff:ff:ff:ff:ff:ff link-netns d3993135-0f2f-4b06-b16d-31d659f8230d
	inet6 fe80::7c0b:bbff:fe5d:498c/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-n7nwqge3zba-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.112.134 closed.

Utilice SSH en el segundo nodo de trabajador mediante el comando ssh -i id_rsa opc@10.0.66.97.

Obtenga las direcciones IP de todas las interfaces mediante el comando ip a.
Tenga en cuenta que la interfaz ens5 se ha eliminado del nodo de trabajador.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.66.97
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:47:55 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:16:ca brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.66.97/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82502sec preferred_lft 82502sec
	inet6 fe80::17ff:fe00:16ca/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 02:92:e7:f5:8e:29 brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::92:e7ff:fef5:8e29/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether f6:08:06:e2:bc:9d brd ff:ff:ff:ff:ff:ff
	inet 10.244.1.129/25 brd 10.244.1.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::f408:6ff:fee2:bc9d/64 scope link
	valid_lft forever preferred_lft forever
6: veth5db97290@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c2:e0:b5:7e:ce:ed brd ff:ff:ff:ff:ff:ff link-netns 3682b5cd-9039-4931-aecc-b50d46dabaf1
	inet6 fe80::c0e0:b5ff:fe7e:ceed/64 scope link
	valid_lft forever preferred_lft forever
7: veth6fd818a5@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 3e:a8:7d:84:d3:b9 brd ff:ff:ff:ff:ff:ff link-netns 08141d6b-5ec0-4f3f-a312-a00b30f82ade
	inet6 fe80::3ca8:7dff:fe84:d3b9/64 scope link
	valid_lft forever preferred_lft forever
8: veth26f6b686@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:bf:36:ca:52:cf brd ff:ff:ff:ff:ff:ff link-netns f533714a-69be-4b20-be30-30ba71494f7a
	inet6 fe80::acbf:36ff:feca:52cf/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-1 ~]$ exit
logout
Connection to 10.0.66.97 closed.

Utilice SSH en el tercer nodo de trabajador mediante el comando ssh -i id_rsa opc@10.0.73.242.

Obtenga las direcciones IP de todas las interfaces mediante el comando ip a.
Tenga en cuenta que la interfaz ens5 se ha eliminado del nodo de trabajador.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.73.242
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 20:08:31 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:49:9c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.73.242/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82733sec preferred_lft 82733sec
	inet6 fe80::17ff:fe00:499c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether 9a:c7:1b:30:e8:9a brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.0/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::98c7:1bff:fe30:e89a/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether 2a:2b:cb:fb:15:82 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.1/25 brd 10.244.0.127 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::282b:cbff:fefb:1582/64 scope link
	valid_lft forever preferred_lft forever
6: veth06343057@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ca:70:83:13:dc:ed brd ff:ff:ff:ff:ff:ff link-netns fb0f181f-7c3a-4fb6-8bf0-5a65d39486c1
	inet6 fe80::c870:83ff:fe13:dced/64 scope link
	valid_lft forever preferred_lft forever
7: veth8af17165@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether c6:a0:be:75:9b:d9 brd ff:ff:ff:ff:ff:ff link-netns c07346e6-33f5-4e80-ba5e-74f7487b5daa
	inet6 fe80::c4a0:beff:fe75:9bd9/64 scope link
	valid_lft forever preferred_lft forever
8: veth170b8774@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether e6:c9:42:60:8f:e7 brd ff:ff:ff:ff:ff:ff link-netns edef0c81-0477-43fa-b260-6b81626e7d87
	inet6 fe80::e4c9:42ff:fe60:8fe7/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-0 ~]$ exit
logout
Connection to 10.0.73.242 closed.

Utilice SSH en el cuarto nodo de trabajador mediante el comando ssh -i id_rsa opc@10.0.89.50.

Obtenga las direcciones IP de todas las interfaces mediante el comando ip a.
Tenga en cuenta que la interfaz ens5 se ha eliminado del nodo de trabajador.

[opc@o-sqrtga ~]$ ssh -i id_rsa opc@10.0.89.50
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Dec 18 19:49:27 2024 from 10.0.0.11
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
	link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
	inet 127.0.0.1/8 scope host lo
	valid_lft forever preferred_lft forever
	inet6 ::1/128 scope host
	valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
	link/ether 02:00:17:00:ac:7c brd ff:ff:ff:ff:ff:ff
	altname enp0s3
	inet 10.0.89.50/18 brd 10.0.127.255 scope global dynamic ens3
	valid_lft 82976sec preferred_lft 82976sec
	inet6 fe80::17ff:fe00:ac7c/64 scope link
	valid_lft forever preferred_lft forever
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UNKNOWN group default
	link/ether aa:31:9f:d0:b3:3c brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.128/32 scope global flannel.1
	valid_lft forever preferred_lft forever
	inet6 fe80::a831:9fff:fed0:b33c/64 scope link
	valid_lft forever preferred_lft forever
5: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue state UP group default qlen 1000
	link/ether b2:0d:c0:de:02:61 brd ff:ff:ff:ff:ff:ff
	inet 10.244.0.129/25 brd 10.244.0.255 scope global cni0
	valid_lft forever preferred_lft forever
	inet6 fe80::b00d:c0ff:fede:261/64 scope link
	valid_lft forever preferred_lft forever
6: vethb37e8987@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether 7a:93:1d:2a:33:8c brd ff:ff:ff:ff:ff:ff link-netns ab3262ca-4a80-4b02-a39f-4209d003f148
	inet6 fe80::7893:1dff:fe2a:338c/64 scope link
	valid_lft forever preferred_lft forever
7: veth73a651ce@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether ae:e4:97:89:ba:6e brd ff:ff:ff:ff:ff:ff link-netns 9307bfbd-8165-46bf-916c-e1180b6cbd83
	inet6 fe80::ace4:97ff:fe89:ba6e/64 scope link
	valid_lft forever preferred_lft forever
8: veth42c3a604@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8950 qdisc noqueue master cni0 state UP group default
	link/ether f2:e6:ba:72:8f:b2 brd ff:ff:ff:ff:ff:ff link-netns a7eb561c-8182-49b2-9e43-7c52845620a7
	inet6 fe80::f0e6:baff:fe72:8fb2/64 scope link
	valid_lft forever preferred_lft forever
[opc@oke-cwe6rhf2leq-ng556bw23ra-slsqe2jfnpa-2 ~]$ exit
logout
Connection to 10.0.89.50 closed.
[opc@o-sqrtga ~]$

La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 8: Realización de pruebas de ping entre varios pods

Todos los pods tienen una dirección IP de la subred de OCI donde se conectan las VNIC activadas para SR-IOV, podemos realizar algunas pruebas de ping para verificar si la conectividad de red funciona correctamente.

En la siguiente tabla se proporcionan los comandos para conectarse a los pods de prueba desde el operador de Kubernetes.

Necesitamos esto en exec en cada pod para realizar una prueba de ping o para ver la tabla de rutas.

ens3	net1	name	nombre de pod	Comando
10.0.112.134	10.0.3.30/27	sriov-vnic-1	testpod1	`kubectl exec -it testpod1 -- /bin/bash`
10.0.66.97	10.0.3.15/27	sriov-vnic-2	testpod2	`kubectl exec -it testpod2 -- /bin/bash`
10.0.73.242	10.0.3.14/27	sriov-vnic-3	testpod3	`kubectl exec -it testpod3 -- /bin/bash`
10.0.89.50	10.0.3.16/27	sriov-vnic-4	testpod4	`kubectl exec -it testpod4 -- /bin/bash`

Ejecute el comando kubectl exec -it testpod1 -- route -n para ver la tabla de enrutamiento directamente desde el terminal del operador de Kubernetes para testpod1.

Tenga en cuenta que la tabla de enrutamiento de testpod1 tiene un gateway por defecto para eth0 y para net1, que es nuestra interfaz activada para SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.0.129    255.255.0.0     UG    0      0        0 eth0
10.244.0.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Ejecute el comando kubectl exec -it testpod2 -- route -n para ver la tabla de enrutamiento directamente desde el terminal del operador de Kubernetes para testpod2.

Tenga en cuenta que la tabla de enrutamiento de testpod2 tiene un gateway por defecto para eth0 y para net1, que es nuestra interfaz activada para SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod2 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.129    0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.129    255.255.0.0     UG    0      0        0 eth0
10.244.1.128    0.0.0.0         255.255.255.128 U     0      0        0 eth0

Ejecute el comando kubectl exec -it testpod3 -- route -n para ver la tabla de enrutamiento directamente desde el terminal del operador de Kubernetes para testpod3.

Tenga en cuenta que la tabla de enrutamiento de testpod3 tiene un gateway por defecto para eth0 y para net1, que es nuestra interfaz activada para SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod3 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.0.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
10.244.0.0      10.244.0.1      255.255.0.0     UG    0      0        0 eth0

Ejecute el comando kubectl exec -it testpod4 -- route -n para ver la tabla de enrutamiento directamente desde el terminal del operador de Kubernetes para testpod4.

Tenga en cuenta que la tabla de enrutamiento de testpod4 tiene un gateway por defecto para eth0 y para net1, que es nuestra interfaz activada para SR-IOV.

[opc@o-sqrtga ~]$ kubectl exec -it testpod4 -- route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.244.1.1      0.0.0.0         UG    0      0        0 eth0
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.0.3.0        0.0.0.0         255.255.255.224 U     0      0        0 net1
10.244.0.0      10.244.1.1      255.255.0.0     UG    0      0        0 eth0
10.244.1.0      0.0.0.0         255.255.255.128 U     0      0        0 eth0
[opc@o-sqrtga ~]$

Para realizar la prueba de ping desde el operador de Kubernetes directamente desde los pods de prueba, necesitamos el comando ping.

En la siguiente tabla, hemos proporcionado todos los comandos de ping para todos los pods de prueba. El comando hará ping desde un pod de prueba concreto a todos los demás pods de prueba, incluida su dirección IP net1.

Nombre de pod de origen	Comando
testpod1	`kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4`
testpod2	`kubectl exec -it testpod2 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod2 -- ping -I net1 10.0.3.16 -c 4`
testpod3	`kubectl exec -it testpod3 -- ping -I net1 10.0.3.14 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod3 -- ping -I net1 10.0.3.16 -c 4`
testpod4	`kubectl exec -it testpod4 -- ping -I net1 10.0.3.16 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.30 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.15 -c 4` `kubectl exec -it testpod4 -- ping -I net1 10.0.3.14 -c 4`

Nota: En este ejemplo, estamos utilizando testpod1 para hacer ping a todas las demás direcciones IP net1 de los pods de prueba.

Ejecute el comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4 para hacer ping de testpod1 a testpod1.

Tenga en cuenta que el ping tiene 4 packets transmitted, 4 received, 0% packet loss. El ping es exitoso.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.30 -c 4
PING 10.0.3.30 (10.0.3.30) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.30: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 10.0.3.30: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 10.0.3.30: icmp_seq=3 ttl=64 time=0.037 ms
64 bytes from 10.0.3.30: icmp_seq=4 ttl=64 time=0.026 ms

--- 10.0.3.30 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3087ms
rtt min/avg/max/mdev = 0.024/0.032/0.043/0.009 ms

Ejecute el comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4 para hacer ping de testpod1 a testpod2.

Tenga en cuenta que el ping tiene 4 packets transmitted, 4 received, 0% packet loss. El ping es exitoso.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.15 -c 4
PING 10.0.3.15 (10.0.3.15) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.15: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from 10.0.3.15: icmp_seq=2 ttl=64 time=0.113 ms
64 bytes from 10.0.3.15: icmp_seq=3 ttl=64 time=0.114 ms
64 bytes from 10.0.3.15: icmp_seq=4 ttl=64 time=0.101 ms

--- 10.0.3.15 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3109ms
rtt min/avg/max/mdev = 0.101/0.177/0.383/0.119 ms

Ejecute el comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4 para hacer ping de testpod1 a testpod3.

Tenga en cuenta que el ping tiene 4 packets transmitted, 4 received, 0% packet loss. El ping es exitoso.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.14 -c 4
PING 10.0.3.14 (10.0.3.14) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.14: icmp_seq=1 ttl=64 time=0.399 ms
64 bytes from 10.0.3.14: icmp_seq=2 ttl=64 time=0.100 ms
64 bytes from 10.0.3.14: icmp_seq=3 ttl=64 time=0.130 ms
64 bytes from 10.0.3.14: icmp_seq=4 ttl=64 time=0.124 ms

--- 10.0.3.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3057ms
rtt min/avg/max/mdev = 0.100/0.188/0.399/0.122 ms

Ejecute el comando kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4 para hacer ping de testpod1 a testpod4.

Tenga en cuenta que el ping tiene 4 packets transmitted, 4 received, 0% packet loss. El ping es exitoso.

[opc@o-sqrtga ~]$ kubectl exec -it testpod1 -- ping -I net1 10.0.3.16 -c 4
PING 10.0.3.16 (10.0.3.16) from 10.0.3.30 net1: 56(84) bytes of data.
64 bytes from 10.0.3.16: icmp_seq=1 ttl=64 time=0.369 ms
64 bytes from 10.0.3.16: icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from 10.0.3.16: icmp_seq=3 ttl=64 time=0.155 ms
64 bytes from 10.0.3.16: icmp_seq=4 ttl=64 time=0.163 ms

--- 10.0.3.16 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3110ms
rtt min/avg/max/mdev = 0.154/0.210/0.369/0.092 ms
[opc@o-sqrtga ~]$

Nota: No hemos incluido todas las demás salidas de ping para todos los demás pods de prueba, pero se tiene la idea.

La siguiente imagen muestra una visión general visual de lo que hemos configurado hasta ahora.

Tarea 9: (Opcional) Despliegue de pods con varias interfaces

Hasta ahora, solo hemos preparado una VNIC (que admite SR-IOV) y hemos movido esta VNIC a un pod. Hemos hecho esto para cuatro pods de prueba diferentes.

¿Y si queremos agregar o mover más VNIC a un pod concreto? Debe repetir estos pasos:

Crear una nueva subred de OCI.
Cree una nueva VNIC y asigne la dirección IP.
Cree un nuevo NetworkAttachmentDefinitions.
Actualice el archivo YAML del pod de prueba agregando nuevas anotaciones.

En esta tarea, encontrará un ejemplo en el que crearemos una subred adicional, VNIC, asignaremos la dirección IP, NetworkAttachmentDefinition y la agregaremos al archivo YAML de creación de pods para testpod1.

Ésta es la NetworkAttachmentDefinition para una nueva interfaz ens6 con una dirección IP 10.0.4.29/27 en la red 10.0.4.0/27.

Tenga en cuenta que este es otro NetworkAttachmentDefinition que el que teníamos antes para la interfaz ens5 con una dirección IP 10.0.3.30/27 en la red 10.0.3.0/27.

sriov-vnic-2-new.yaml:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-vnic-2-new
spec:
config: '{
		"cniVersion": "0.3.1",
		"type": "host-device",
		"device": "ens6",
		"ipam": {
				"type": "static",
				"addresses": [
					{
						"address": "10.0.4.29/27",
						"gateway": "0.0.0.0"
					}
				],
				"routes": [
					{ "dst": "10.0.4.0/27", "gw": "0.0.0.0" }
				]
			}
		}'

Este es el archivo YAML (actualizado) para testpod1.

Observe la línea adicional en annotations donde se hace referencia al nuevo NetworkAttachmentDefinition; sriov-vnic-2-new.

sudo nano testpod1-v3.yaml

apiVersion: v1
kind: Pod
metadata:
name: testpod1
annotations:
	k8s.v1.cni.cncf.io/networks: sriov-vnic-1
	k8s.v1.cni.cncf.io/networks: sriov-vnic-2-new
spec:
affinity:
	nodeAffinity:
	requiredDuringSchedulingIgnoredDuringExecution:
		nodeSelectorTerms:
		- matchExpressions:
		- key: node_type
			operator: In
			values:
			- testpod1
containers:
- name: appcntr1
	image: centos/tools
	imagePullPolicy: IfNotPresent
	command: [ "/bin/bash", "-c", "--" ]
	args: [ "while true; do sleep 300000; done;" ]

Tarea 10: Eliminar todos los despliegues de pod y `NetworkAttachmentDefinitions`

Si desea volver a empezar o desea limpiar los contenedores con NetworkAttachmentDefinitions, siga los pasos:

Obtenga todos los pods mediante el comando kubectl get pod.

[opc@o-sqrtga ~]$ kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
my-nginx-576c6b7b6-6fn6f   1/1     Running   3          105d
my-nginx-576c6b7b6-k9wwc   1/1     Running   3          105d
my-nginx-576c6b7b6-z8xkd   1/1     Running   6          105d
mysql-6d7f5d5944-dlm78     1/1     Running   12         100d
testpod1                   1/1     Running   0          64d
testpod2                   1/1     Running   0          64d
testpod3                   1/1     Running   0          64d
testpod4                   1/1     Running   0          64d
[opc@o-sqrtga ~]$

Suprima los pods de prueba con los siguientes comandos.

kubectl delete -f testpod1-v2.yaml

kubectl delete -f testpod2-v2.yaml

kubectl delete -f testpod3-v2.yaml

kubectl delete -f testpod4-v2.yaml

Obtenga todos los NetworkAttachmentDefinitions mediante el comando kubectl get network-attachment-definitions.k8s.cni.cncf.io.

[opc@o-sqrtga ~]$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME           AGE
sriov-vnic-1   64d
sriov-vnic-2   64d
sriov-vnic-3   64d
sriov-vnic-4   64d
[opc@o-sqrtga ~]$

Suprima NetworkAttachmentDefinitions con los siguientes comandos.

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-1

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-2

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-3

kubectl delete networkattachmentdefinition.k8s.cni.cncf.io/sriov-vnic-4

Configurar interfaces SR-IOV para pods mediante Multus para nodos de Oracle Container Engine for Kubernetes basados en VM

Acuses de recibo

Autor: Iwan Hoogendoorn (especialista en redes OCI)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

Título e Información de Copyright

Deploy SR-IOV Enabled Network Interfaces Container Apps on OKE Using Multus CNI Plugin

G28054-02

Despliegue de aplicaciones de contenedor de interfaces de red activadas para SR-IOV en OKE mediante el plugin Multus CNI

Introducción

Objetivos

Tarea 1: Despliegue de OKE con un bastión, un operador, tres nodos de trabajador de VM y el plugin CNI de Flannel

Tarea 2: Activación de la red SR-IOV (asistida por hardware) en cada nodo de trabajador

Tarea 3: Creación de una nueva subred para las VNIC activadas para SR-IOV

Tarea 3.1: Creación de una Lista de Seguridad

Tarea 3.2: Creación de una subred

Tarea 4: Agregar una segunda asociación de VNIC

Tarea 4.1: Creación de un grupo de seguridad de red (NSG)

Tarea 4.2: Agregar la VNIC

Tarea 5: Asignación de una dirección IP a la nueva segunda VNIC con un gateway por defecto

Tarea 5.1: Verificación de todos los nodos del pool de nodos 1 (np1)

Tarea 5.2: Verificación de todos los nodos del pool de nodos 2 (np2)

Tarea 6: Instalación de un CNI de metaplugina (Multus CNI) en el nodo de trabajador

Tarea 6.1: Instalación de Multus CNI mediante el método de instalación delgada

Tarea 6.2: Validación de la instalación de Multus

Tarea 7: Asociación de interfaces de red a pods

Tarea 7.1: Crear definición de asociación de red

Tarea 7.2: Creación de pods con NetworkDefinitionAttachment asociado

Tarea 7.3: Creación de pods con afinidad de nodos

Tarea 7.4: Verificación de la dirección IP en los pods de prueba

Tarea 7.5: Verificación de la dirección IP en los nodos de trabajador

Tarea 8: Realización de pruebas de ping entre varios pods

Tarea 9: (Opcional) Despliegue de pods con varias interfaces

Tarea 10: Eliminar todos los despliegues de pod y NetworkAttachmentDefinitions

Enlaces relacionados

Acuses de recibo

Más recursos de aprendizaje

Tarea 5.1: Verificación de todos los nodos del pool de nodos 1 (`np1`)

Tarea 5.2: Verificación de todos los nodos del pool de nodos 2 (`np2`)

Tarea 7.2: Creación de pods con `NetworkDefinitionAttachment` asociado

Tarea 10: Eliminar todos los despliegues de pod y `NetworkAttachmentDefinitions`