Nota:

• Este tutorial requiere acceso a Oracle Cloud. Para registrarse en una cuenta gratuita, consulte Introducción a Oracle Cloud Infrastructure Free Tier.
• Utiliza valores de ejemplo para las credenciales, el arrendamiento y los compartimentos de Oracle Cloud Infrastructure. Al finalizar el laboratorio, sustituya estos valores por otros específicos de su entorno en la nube.

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

Introducción

Cuando las cargas de trabajo muy orientadas a la red requieren la configuración de interfaces de red secundarias en los pods, podemos utilizar un meta CNI como Multus para lograrlo. Las interfaces de red secundarias que normalmente están conectadas en estos casos tendrán propiedades o capacidades de red especializadas, como la virtualización de E/S de raíz única (SR-IOV).

En un tutorial anterior: configuración de interfaces SR-IOV para pods con Multus para nodos OKE con hardware dedicado (puede acceder al enlace desde la sección Enlaces relacionados), hemos tratado cómo hacerlo en nodos de Kubernetes con hardware dedicado en Oracle Cloud Infrastructure (OCI), donde puede crear directamente funciones virtuales (VF) en el hardware conectado a la instancia con hardware dedicado.

Este tutorial sigue un enfoque similar para los nodos de máquina virtual en un cluster de Oracle Container Engine for Kubernetes (OKE) y adopta un enfoque similar, con configuraciones y plugins diferentes a los utilizados en los nodos con hardware dedicado. Existen diferencias significativas en cómo se crean y gestionan las interfaces entre hardware dedicado, donde puede tener un control total del hardware y las máquinas virtuales donde un hipervisor abstrae el acceso al hardware subyacente y no tiene tanto control sobre él.

El enfoque descrito aquí utiliza Multus para proporcionar múltiples interfaces a un pod, sin embargo, no se utilizan SR-IOV CNI y el plugin de dispositivo asociado. Esto se debe a que el CNI SR-IOV requiere acceso al hardware subyacente, la función física (PF), que obviamente plantea un desafío en las máquinas virtuales. Para superar este desafío, podemos utilizar las API de redes de OCI para VNIC, para crear una función virtual (VF) en la función física (PF) como en el escenario de hardware dedicado y proporcionar a la máquina virtual acceso directo y sin obstáculos a esta VF. Estas VF se pueden asociar a una instancia informática, incluidos los nodos de OKE, como interfaces de red. Estas interfaces/VF se pueden mover a los espacios de nombres de red para los pods, lo que permite que el pod utilice directa y exclusivamente la VF como interfaz de red. Desde la perspectiva de los pods, no podrá distinguir entre los dos, y en ambos casos tendrá acceso a una VF que puedan utilizar directamente.

Para proporcionar a una máquina virtual acceso directo a una VF, necesitamos iniciar la máquina virtual con el modo de asociación de red VFIO en lugar del modo predeterminado paravirtualized. Esta opción está controlada por el modo de inicio de la instancia informática. Una vez que el modo de asociación de red está definido como VFIO, podemos crear asociaciones de red mediante las API de OCI, que crea VF en el PF subyacente y proporciona VF directamente a la VM. El sistema operativo del host los reconocerá como interfaces de red. Una vez que la VF está disponible para la VM, se puede mover al espacio de nombres de pod. En este modelo, las VF se crean mediante las API de OCI en lugar de los comandos del sistema en el escenario de hardware dedicado.

Objetivo

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

Requisitos

• Un cluster de OKE con un pool de nodos que consta de al menos dos máquinas virtuales.

Nota: Este tutorial se ha validado en clusters de OKE con redes de Flannel (Flannel como CNI principal).

Tarea 1: Configurar los nodos

Cada nodo que requiere acceso a interfaces SR-IOV debe estar preparado para las conexiones de red asistidas por hardware antes de que las puedan utilizar los pods.

1. Iniciar los nodos en modo VFIO

   • Cree un pool de nodos y un juego de nodos del cluster.

   • Una vez creados los nodos, edite las propiedades de la instancia.

     

   • En las propiedades de la instancia, haga clic en Mostrar opciones avanzadas para ver las propiedades adicionales. En el separador Opciones de inicio, seleccione Red asistida por hardware (SR-IOV) para el tipo de red.

     

     Nota: Una vez que se ha cambiado una instancia de asociaciones de red paravirtualizadas al modo asistido por hardware (SR-IOV o VFIO), ya no son elegibles para migración en directo para el mantenimiento de la infraestructura.

   • El flujo de trabajo de actualización le pedirá que reinicie la instancia. Después del reinicio, la instancia tendrá asociaciones de red VFIO. Se puede verificar en la consola.

     

   • Otro método para verificar si las instancias utilizan asociaciones de red SR-IOV es utilizar SSH en el nodo y utilizar lspci para mostrar los dispositivos PCI en la máquina virtual. Debería poder ver la función virtual subyacente directamente en la máquina virtual en lugar de un dispositivo mediante un controlador virtio (como el controlador de almacenamiento en la imagen siguiente).

     

   • En este punto, el nodo tiene una sola asociación de VNIC, que es la VNIC principal utilizada para todas las comunicaciones con el nodo. Dado que la instancia utiliza asociaciones de red asistidas por hardware, la conexión de red es visible para el nodo como una función virtual en el hardware subyacente. Para que los pods tengan el uso exclusivo de una función virtual (VF), necesitamos VF adicionales en la máquina virtual. Se puede proporcionar mediante la consola o la API para agregar asociaciones de VNIC adicionales a la instancia. Estas asociaciones de VNIC son VF en el PF subyacente. Se pueden verificar con lspci.

2. Agregar asociaciones de VNIC adicionales

   • En la página de instancia, seleccione VNIC asociadas y haga clic en Crear VNIC.

     

   • Configure la VNIC mediante la VCN y la subred necesarias.

     

   • Verifique si la VNIC se puede ver en el host como una función virtual como antes, mediante SSH en el nodo y ejecutando lspci.

     

   • Al agregar una VNIC secundaria a una instancia de máquina virtual de Linux, se agrega una nueva interfaz (es decir, un dispositivo Ethernet) a la instancia y el sistema operativo la reconoce automáticamente. Sin embargo, DHCP no está activo para la VNIC secundaria y debe configurar la interfaz con la dirección IP estática y la ruta predeterminada.

3. Configuración del sistema operativo para VNIC secundarias

   • OCI proporciona documentación y un script para configurar el sistema operativo para VNIC secundarias. Para configurar la VNIC secundaria, descargue el script en el nodo y ejecútelo según las instrucciones proporcionadas en la documentación de OCI.

     Nota: Las VNIC secundarias de cada nodo se deben configurar repitiendo estos pasos para cada nodo. De manera opcional, estos pasos se pueden automatizar mediante una secuencia de comandos cloud_init personalizada para los nodos.

   • Verifique que la interfaz esté ahora conectada, con su dirección IP y ruta predeterminada. Para comprobarlo, utilice el comando ip addr o nmcli.

     

   • De manera opcional, verifique el enrutamiento mediante un ping para alcanzar las direcciones IP secundarias entre sí. En las imágenes siguientes, 10.0.10.238 es la IP secundaria en un segundo nodo del cluster.

     

     

Tarea 2: Instalación de un CNI Meta-Plugin (Multus)

Multus es un metacomplemento que puede proporcionar la información de VF a un CNI descendente como el complemento SR-IOV CNI para que maneje la conexión de recursos de red al tiempo que activa pods o pods "de hosts múltiples" con varias interfaces de red.

Nota: Multus 4.0 en adelante, Multus introdujo un nuevo despliegue de estilo cliente-servidor denominado "plugin grueso". El nuevo plugin grueso admite funciones adicionales, como métricas que no se admitían anteriormente. Este documento utiliza el plugin 'thin' ya que consume menos recursos.

1. Para instalar Multus, ejecute los siguientes comandos.

   git clone https://github.com/k8snetworkplumbingwg/multus-cni.git && cd multus-cni
   kubectl apply -f deployments/multus-daemonset.yml && cd ..
   

Nota: En la instalación, la imagen por defecto utilizada por el conjunto de datos con la etiqueta stable necesita que el núcleo sea v1.20.x. Si realiza la instalación en un cluster más antiguo, edite el deamonset en el manifiesto y utilice la etiqueta de imagen de varios v3.7.1.

Este manifiesto crea una nueva CRD para kind:NetworkAttachmentDefinition y proporciona el binario Multus en todos los nodos mediante un daemonset. Puede verificar la instalación asegurándose de que el daemonset de Multus se está ejecutando en los nodos.

Tarea 3: Asociación de varias interfaces a pods

• Para conectar interfaces adicionales a los pods, necesitamos una configuración para que la interfaz se conecte. Se encapsula en el tipo de recurso personalizado NetworkAttachmentDefinition. Esta configuración es esencialmente una configuración de CNI empaquetada como un recurso personalizado.

• Hay varios plugins CNI que se pueden utilizar junto con Multus para lograr esto. En el enfoque descrito aquí, el objetivo es proporcionar una función virtual SR-IOV exclusivamente para un único pod, de modo que el pod pueda aprovechar las capacidades sin interferencia o cualquier capa entre ellas. Para otorgar acceso exclusivo a un pod a la VF, podemos aprovechar el complemento host-device que le permite mover la interfaz al espacio de nombres del pod para que tenga acceso exclusivo al mismo.

• En los siguientes ejemplos se muestran objetos NetworkAttachmentDefinition que configuran la interfaz ens5 secundaria agregada a los nodos. La configuración del plugin ipam determina cómo se gestionan las direcciones IP para estas interfaces. En este ejemplo, como queremos utilizar las mismas direcciones IP asignadas a las interfaces secundarias por OCI, 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.

  
  ## network attachment for the first node. Note the IPaddress assignment in the `ipam` configuration.
  
  cat << EOF | kubectl create -f -
  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.10.93/24",
                          "gateway": "0.0.0.0"
                      }
                  ],
                  "routes": [
                      { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                  ]
              }
            }'
  EOF
  
  ## network attachment for the second node. Note the IPaddress assignment in the `ipam` configuration.
  
  cat << EOF | kubectl create -f -
  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.10.238/24",
                          "gateway": "0.0.0.0"
                      }
                  ],
                  "routes": [
                      { "dst": "10.0.10.0/24", "gw": "0.0.0.0" }
                  ]
              }
            }'
  EOF
  

Tarea 4: Despliegue pods con varias interfaces y pruebas

Los pod ahora pueden solicitar interfaces adicionales mediante una anotación. La anotación permite que el metadispositivo (Multus) sepa qué NetworkAttachmentDefinition (configuración de CNI) utilizar para proporcionar interfaces adicionales cuando se crea el pod.

Nota: Al utilizar una configuración estática como la que se muestra en este ejemplo, los pods deben tener definida la afinidad de nodos, de modo que el pod se programe en el nodo donde está disponible el dispositivo host deseado.

• A continuación, se muestra un ejemplo con un pod de prueba:

  ## Create the first pod
  cat << EOF | kubectl create -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: testpod1
    annotations:
      k8s.v1.cni.cncf.io/networks: sriov-vnic-1
  spec:
    containers:
    - name: appcntr1
      image: centos/tools
      imagePullPolicy: IfNotPresent
      command: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 300000; done;" ]
  
  EOF
  
  ## Create a second pod
  cat << EOF | kubectl create -f -
  apiVersion: v1
  kind: Pod
  metadata:
    name: testpod2
    annotations:
      k8s.v1.cni.cncf.io/networks: sriov-vnic
  spec:
    containers:
    - name: appcntr1
      image: centos/tools
      imagePullPolicy: IfNotPresent
      command: [ "/bin/bash", "-c", "--" ]
      args: [ "while true; do sleep 300000; done;" ]
  
  EOF
  
  

• Con dos pods creados, deberíamos ver que ambos se están ejecutando. Deberíamos ser capaces de ver que se crearon interfaces de red adicionales durante la creación de los pods. Multus proporcionará la interfaz eth0 respaldada por el CNI por defecto (Flannel en este ejemplo) y una interfaz net1 adicional que es la función virtual SR-IOV. Puede describe los pods y observar la sección Events de la salida para ver los distintos eventos, incluidas las interfaces que se están adjuntando al pod.

  

• Una vez iniciados los pods, podemos realizar una prueba rápida.

  ## Verify that both pods have two interfaces. An `eth0` on the overlay and a `net1` which is the VF, along with the IP address for the secondary VNIC.
  kubectl exec -it testpod1 -- ip addr show
  kubectl exec -it testpod2 -- ip addr show
  

• La salida debe ser similar a las siguientes imágenes.

  

  

• También podemos verificar la comunicación entre los dos pods en estas interfaces secundarias.

  ## test communication
  kubectl exec -it testpod1 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
  kubectl exec -it testpod2 -- ping -I net1  <ip address for secondary vnic on the other pod/node>
  
  

• La salida debe ser similar a las siguientes imágenes.

  

  

• También podemos validar que los pods se pueden enrutar mediante sus asociaciones de red, intentando conectarlos desde las máquinas virtuales o desde cualquier otro origen de la VCN.

  ## Test that the pod is routable from outside Kubernetes. This is executed from node1.
  ping 10.0.10.238
  
  ## similarly, from node 2
  ping 10.0.10.93
  
  

• La salida debe ser similar a las siguientes imágenes.

  

  

Enlaces relacionados

• Configuración de interfaces SR-IOV para pods mediante Multus para nodos OKE con hardware dedicado

• Multus

• SRIOV-CNI

• Plugins de CNI en entornos virtuales

Agradecimientos

• Autor: Jeevan Joseph (mánager de productos principal)

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 los productos, visite Oracle Help Center.

---

Título e Información de Copyright

Configure SR-IOV interfaces for pods using Multus for VM-based Oracle Container Engine for Kubernetes nodes

F80585-01

May 2023

Copyright © 2023, Oracle and/or its affiliates.