Asociación de varias VNIC secundarias para redes de pod

Paso 1: Verificar los nombres de recursos ampliados y la capacidad en un nodo

Después de que el pool de nodos tenga nodos de trabajador, verifique los nombres y la capacidad del recurso ampliado en un nodo.

1. Revise los recursos ampliados anunciados del nodo:

   kubectl describe node <node-name>

2. En la sección Capacity de la salida, identifique los recursos ampliados que corresponden a los recursos de aplicación (por ejemplo, oke-application-resource.oci.oraclecloud.com/frontend) y confirme que tienen una capacidad distinta de cero.

Los nodos que exponen los recursos de aplicación están contaminados con oci.oraclecloud.com/application-resource-only:NoSchedule para evitar que los pods sin solicitudes explícitas de recursos de aplicación lleguen a ellos.

Agregue una tolerancia correspondiente a la especificación de pod (en spec.tolerations para un pod o en spec.template.spec.tolerations en un despliegue):

tolerations:
  - key: "oci.oraclecloud.com/application-resource-only"
    operator: "Exists"
    effect: "NoSchedule"

Sin esta tolerancia, el programador rechazará la colocación aunque exista capacidad de recursos.

En la especificación del pod, solicite el recurso ampliado que corresponda al perfil de VNIC secundario que debe utilizar el pod (por ejemplo, en un despliegue en spec.template.spec.containers[].resources). Solicite y limite exactamente una unidad para que el programador reserve capacidad de forma coherente.

Por ejemplo:

containers:
  - name: myapp
    image: <image>
    resources:
      requests:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"
      limits:
        oke-application-resource.oci.oraclecloud.com/frontend: "1"

Paso 4: (Opcional) Dirija los pools de nodos correctos

Si su organización utiliza una convención de etiqueta/selector de nodo para estos nodos (por ejemplo, gva_vnic: "yes"), inclúyala para que los pods no lleguen a pools de nodos que no tengan los recursos necesarios:

nodeSelector:
  gva_vnic: "yes"

Un nodeSelector es opcional cuando las solicitudes y tolerancias de recurso de aplicación ya restringen la programación. Utilice un nodeSelector solo si ha etiquetado los nodos de destino (por ejemplo, mediante etiquetas de Kubernetes del pool de nodos).

Después del despliegue:

1. Introduzca:

   kubectl get pods -o wide

2. Para un pod de interés, introduzca:

   kubectl describe pod <pod-name>

3. Confirme que el pod está en ejecución y que no hay errores de programación (por ejemplo, capacidad insuficiente para el recurso solicitado).

Instale Multus antes de crear NAD o desplegar pods de varias interfaces. Para obtener información sobre la instalación de Multus, consulte la documentación de Multus-CNI en GitHub.

Siga el proceso estándar de su organización para desplegar Multus y, a continuación, verifique que esté en buen estado:

kubectl get pod -l app=multus -n kube-system

Los ejemplos de esta sección utilizan el plugin CNI ipvlan para la interfaz de pod adicional. Asegúrese de que el binario ipvlan esté presente en /opt/cni/bin/ipvlan en cada nodo de trabajador que pueda ejecutar pods de varias interfaces.

Oracle recomienda instalar el plugin ipvlan mediante un script cloud-init del pool de nodos para que el plugin se instale cuando se creen, sustituyan o escalen horizontalmente los nodos. Anclar el plugin a una versión validada para el entorno de destino, en lugar de seguir una ruta de descarga flotante. En el siguiente ejemplo se utiliza la versión v1.9.0.

Por ejemplo:

#!/bin/bash

CNI_VERSION="v1.9.0"
CNI_ARCH="amd64"
CNI_TARBALL="cni-plugins-linux-${CNI_ARCH}-${CNI_VERSION}.tgz"
CNI_URL="https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/${CNI_TARBALL}"
CNI_BIN_DIR="/opt/cni/bin"

wget --fail -O "/tmp/${CNI_TARBALL}" "${CNI_URL}" && \
  tar xvzf "/tmp/${CNI_TARBALL}" -C "${CNI_BIN_DIR}" && \
  rm -f "/tmp/${CNI_TARBALL}"

curl --fail -H "Authorization: Bearer Oracle" -L0 \
  http://169.254.169.254/opc/v2/instance/metadata/oke_init_script \
  | base64 --decode > /var/run/oke-init.sh

bash /var/run/oke-init.sh

Si los nodos de trabajador no pueden acceder a GitHub, almacene provisionalmente el archivo de plugins de CNI necesarios en OCI Object Storage u otra ubicación interna aprobada y actualice la URL de descarga en el script cloud-init.

Los NAD deben tener como destino los nombres de interfaz de host reales creados por las VNIC conectadas (por ejemplo, enp1s0, enp2s0). Verifíquelas en un nodo de trabajador mediante el método de acceso estándar de la organización.

Crear:

• un NAD para la red de pod predeterminada (para controlar qué interfaz de host respalda eth0)
• uno o más NAD para interfaces adicionales (por ejemplo, net1).

La configuración de NAD puede seleccionar un dispositivo mediante deviceSelector (por ejemplo, por interfaceName o por nombre de recurso de aplicación mediante appResource si está soportado en el entorno).

Los siguientes ejemplos de NAD utilizan intencionadamente diferentes espacios de nombres. oci-vcn-native-network se define en kube-system, mientras que ipvlan-network se define en default. Si la carga de trabajo se ejecuta en otro espacio de nombres, cree ipvlan-network en ese espacio de nombres o actualice la anotación de pod para hacer referencia al nombre de NAD totalmente cualificado.

NAD de red predeterminado fijado en enp1s0:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: oci-vcn-native-network
  namespace: kube-system
spec:
  config: |
    {
      "name": "oci",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "cniVersion": "0.3.1",
          "type": "oci-ipvlan",
          "mode": "l2",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp1s0"
            }
          }
        },
        {
          "cniVersion": "0.3.1",
          "type": "oci-ptp",
          "containerInterface": "ptp-veth0",
          "mtu": 9000
        }
      ]
    }

Red secundaria NAD anclada a enp2s0:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  name: ipvlan-network
  namespace: default
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "ipvlan",
          "mode": "l2",
          "master": "enp2s0",
          "ipam": {
            "type": "oci-ipam",
            "deviceSelector": {
              "interfaceName": "enp2s0"
            }
          }
        }
      ]
    }

El NAD por defecto utiliza los plugins oci-ipvlan y oci-ptp específicos de OCI porque esa interfaz participa en la ruta de red por defecto nativa de la VCN de OKE. El NAD adicional utiliza el plugin ipvlan estándar porque Multus está conectando una interfaz adicional en una NIC de host específica, mientras que OCI IPAM aún proporciona la asignación de IP compatible con la subred.

deviceSelector puede tener como destino interfaces con campos como:

{
  "appResource": "blue",
  "interfaceName": "enp2s0",
  "interfaceNamePrefix": "enp",
  "macAddress": "02:00:17:08:E3:07"
}

El bloque deviceSelector permite a OCI IPAM seleccionar la interfaz de destino o la VNIC utilizada para la asignación de IP de pod. Puede seleccionar un dispositivo mediante uno o varios de estos campos:

• appResource: selecciona el perfil de VNIC de GVA por nombre de recurso de aplicación.

• interfaceName: selecciona una interfaz de host específica, como enp1s0.

• interfaceNamePrefix: selecciona una interfaz por prefijo, como enp.

• macAddress: selecciona una interfaz por dirección MAC.

Cuando se define appResource en el selector de dispositivos NAD, el plugin IPAM de OCI utiliza ese recurso de aplicación para decidir qué perfil de VNIC de GVA debe proporcionar la dirección IP del pod y actuar como dispositivo principal para esa interfaz. Esto permite que diferentes NAD del mismo pod se asignen a diferentes perfiles de VNIC, por ejemplo:

• NAD1 -> Application Resource: vnic-a

• NAD2 -> Application Resource: vnic-b

• NAD3 -> Application Resource: vnic-c

Si un pod utiliza los tres NAD, cada interfaz se puede conectar mediante el perfil de VNIC correspondiente.

En los ejemplos de nombre de interfaz que se muestran en este documento:

• El NAD oci-vcn-native-network utiliza interfaceName: enp1s0, por lo que el IPAM de OCI asigna la IP de red por defecto del pod desde la interfaz enp1s0 del host.

• El NAD ipvlan-network utiliza interfaceName: enp2s0 para que OCI IPAM asigne la IP de interfaz adicional desde la interfaz enp2s0 del host.

Esta es también la razón por la que el ejemplo de pod establece:

annotations:
  v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
  k8s.v1.cni.cncf.io/networks: default/ipvlan-network

La anotación v1.multus-cni.io/default-network garantiza que eth0 utiliza el NAD oci-vcn-native-network. Sin seleccionar explícitamente esa red por defecto, OCI IPAM puede asignar desde cualquier interfaz de host elegible, lo que hace que la interfaz de pod principal sea menos predecible. La configuración del NAD predeterminado garantiza que eth0 utilice la interfaz deseada y la mantiene aislada de la conexión de red adicional.

No combine estas anotaciones de pod de Multus con solicitudes de recurso de aplicación de nivel de pod en la misma especificación de pod. Si un pod de varias interfaces necesita la selección de VNIC de GVA, defina esa selección dentro de la configuración de NAD deviceSelector.appResource para cada interfaz en lugar de utilizar una solicitud de recurso de aplicación de nivel de pod.

Aplique los NAD:

kubectl apply -f oci-vcn-native-network-nad.yaml

kubectl apply -f ipvlan-network.yaml

Anote el pod para seleccionar el NAD de red predeterminado y conectar NAD de red adicionales, por ejemplo:

metadata:
  annotations:
    v1.multus-cni.io/default-network: kube-system/oci-vcn-native-network
    k8s.v1.cni.cncf.io/networks: default/ipvlan-network

1. Describa el pod y compruebe las anotaciones de estado de red de Multus (si están presentes):

   kubectl describe pod <pod-name>

2. Si se permite en el entorno, ejecútelo en el pod e inspeccione las interfaces (por ejemplo, ifconfig o ip addr) para confirmar que el pod tiene las interfaces esperadas (eth0, net1, …) y las direcciones IP.