Operador de la función de red

En esta página, se describe el operador especializado de Kubernetes de función de red que se incluye en Google Distributed Cloud. Este operador implementa un conjunto de CustomResourceDefinitions (CRD) que permiten que Distributed Cloud ejecute cargas de trabajo de alto rendimiento.

El operador de función de red y la funcionalidad de SR-IOV no están disponibles en los servidores de Distributed Cloud.

El operador de función de red te permite hacer lo siguiente:

  • Sondear los dispositivos de red existentes en un nodo
  • Consultar la dirección IP y el estado del vínculo físico de cada dispositivo de red en un nodo
  • Aprovisionar interfaces de red adicionales en un nodo
  • Configurar funciones del sistema de bajo nivel en la máquina física del nodo que se requieren para admitir cargas de trabajo de alto rendimiento
  • Usar la virtualización de entrada/salida de raíz única (SR-IOV) en las interfaces de red PCI Express para virtualizarlas en varias interfaces virtuales Luego, puedes configurar tus cargas de trabajo de Distributed Cloud para que usen esas interfaces de red virtuales.

La compatibilidad de Distributed Cloud con SR-IOV se basa en los siguientes proyectos de código abierto:

Requisitos previos

El operador de función de red recupera la configuración de red de la API de Distributed Cloud Edge Network. Para permitir esto, debes otorgar a la cuenta de servicio del operador de función de red el rol de Visualizador de Edge Network (roles/edgenetwork.viewer) con el siguiente comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role roles/edgenetwork.viewer \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[nf-operator/nf-angautomator-sa]"

Reemplaza PROJECT_ID por el ID del proyecto de destino Google Cloud .

Recursos del operador de función de red

El operador de función de red de Distributed Cloud implementa los siguientes CRD de Kubernetes:

  • Network. Define una red virtual que los Pods pueden usar para comunicarse con recursos internos y externos. Debes crear la VLAN correspondiente con la API de Distributed Cloud Edge Network antes de especificarla en este recurso. Para obtener instrucciones, consulta Crea una red.
  • NetworkInterfaceState. Permite el descubrimiento de estados de interfaz de red y la consulta de una interfaz de red para el estado del vínculo y la dirección IP.
  • NodeSystemConfigUpdate. Permite la configuración de funciones del sistema de bajo nivel, como las opciones del kernel y las marcas de Kubelet.
  • SriovNetworkNodePolicy. Selecciona un grupo de interfaces de red virtualizadas de SR-IOV y crea una instancia del grupo como un recurso de Kubernetes. Puedes usar este recurso en un recurso NetworkAttachmentDefinition.
  • SriovNetworkNodeState. Te permite consultar el estado de aprovisionamiento del recurso SriovNetworkNodePolicy en un nodo de Distributed Cloud.
  • NetworkAttachmentDefinition. Te permite conectar Pods de Distributed Cloud a una o más redes lógicas o físicas en tu nodo de Distributed Cloud. Debes crear la VLAN correspondiente con la API de Distributed Cloud Edge Network antes de especificarla en este recurso. Para obtener instrucciones, consulta Crea una red.

El operador de función de red también te permite definir interfaces de red secundarias que no usan funciones virtuales de SR-IOV.

Recurso Network

El recurso Network define una red virtual dentro del rack de Distributed Cloud que los Pods de tu clúster de Distributed Cloud pueden usar para comunicarse con recursos internos y externos.

El recurso Network proporciona los siguientes parámetros configurables para la interfaz de red expuesta como campos de escritura:

  • spec.type: Especifica la capa de transporte de red para esta red. El único valor válido es L2. También debes especificar un valor nodeInterfaceMatcher.interfaceName.
  • spec.nodeInterfaceMatcher.interfaceName: Es el nombre de la interfaz de red física en el nodo de Distributed Cloud de destino que se usará con esta red.
  • spec.gateway4: Es la dirección IP de la puerta de enlace de red para esta red.
  • spec.l2NetworkConfig.prefixLength4: Especifica el rango de CIDR para esta red.

En el siguiente ejemplo, se ilustra la estructura del recurso:

apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vlan200-network
  annotations:
    networking.gke.io/gdce-vlan-id: 200
    networking.gke.io/gdce-vlan-mtu: 1500
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.200
  gateway4: 10.53.0.1

Recurso NetworkInterfaceState

El recurso NetworkInterfaceState es un recurso de solo lectura que te permite descubrir interfaces de red físicas en el nodo y recopilar estadísticas de tiempo de ejecución sobre el tráfico de red que fluye a través de esas interfaces. Distributed Cloud crea un recurso NetworkInterfaceState para cada nodo de un clúster.

La configuración predeterminada de las máquinas de Distributed Cloud incluye una interfaz de red vinculada en la tarjeta hija de red de selección de rack (rNDC) llamada gdcenet0. Esta interfaz vincula las interfaces de red eno1np0 y eno2np1. Cada una de ellas está conectada a un conmutador ToR de Distributed Cloud, respectivamente.

El recurso NetworkInterfaceState proporciona las siguientes categorías de información de la interfaz de red expuestas como campos de estado de solo lectura.

Información general:

  • status.interfaces.ifname: Es el nombre de la interfaz de red de destino.
  • status.lastReportTime: Es la hora y la fecha del último informe de estado de la interfaz de destino.

Información de configuración de la dirección IP:

  • status.interfaces.interfaceinfo.address: Es la dirección IP asignada a la interfaz de destino.
  • status.interfaces.interfaceinfo.dns: Es la dirección IP del servidor DNS asignada a la interfaz de destino.
  • status.interfaces.interfaceinfo.gateway: Es la dirección IP de la puerta de enlace de red que entrega la interfaz de destino.
  • status.interfaces.interfaceinfo.prefixlen: Es la longitud del prefijo IP.

Información de hardware:

  • status.interfaces.linkinfo.broadcast: Es la dirección MAC de transmisión de la interfaz de destino.
  • status.interfaces.linkinfo.businfo: Es la ruta del dispositivo PCIe en formato bus:slot.function.
  • status.interfaces.linkinfo.flags: Son las marcas de la interfaz, por ejemplo, BROADCAST.
  • status.interfaces.linkinfo.macAddress: Es la dirección MAC de unidifusión de la interfaz de destino.
  • status.interfaces.linkinfo.mtu: Es el valor de MTU para la interfaz de destino.

Estadísticas de recepción:

  • status.interfaces.statistics.rx.bytes: Son los bytes totales recibidos por la interfaz de destino.
  • status.interfaces.statistics.rx.dropped: Son los paquetes totales descartados por la interfaz de destino.
  • status.interfaces.statistics.rx.errors: Son los errores totales de recepción de paquetes para la interfaz de destino.
  • status.interfaces.statistics.rx.multicast: Son los paquetes totales de multidifusión recibidos por la interfaz de destino.
  • status.interfaces.statistics.rx.overErrors: Son los errores totales de recepción de paquetes para la interfaz de destino.
  • status.interfaces.statistics.rx.packets: Son los paquetes totales recibidos por la interfaz de destino.

Estadísticas de transmisión:

  • status.interfaces.statistics.tx.bytes: Son los bytes totales transmitidos por la interfaz de destino.
  • status.interfaces.statistics.tx.carrierErrors: Son los errores totales de operador que encontró la interfaz de destino.
  • status.interfaces.statistics.tx.collisions: Son las colisiones totales de paquetes que encontró la interfaz de destino.
  • status.interfaces.statistics.tx.dropped: Son los paquetes totales descartados por la interfaz de destino.
  • status.interfaces.statistics.tx.errors: Son los errores totales de transmisión para la interfaz de destino.
  • status.interfaces.statistics.tx.packets: Son los paquetes totales transmitidos por la interfaz de destino.

En el siguiente ejemplo, se ilustra la estructura del recurso:

apiVersion: networking.gke.io/v1
kind: NetworkInterfaceState
metadata:
  name: MyNode1
nodeName: MyNode1
status:
  interfaces:
  - ifname: eno1np0
    linkinfo:
      businfo: 0000:1a:00.0
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 1098522811
        errors: 2
        multicast: 190926
        packets: 4988200
      tx:
        bytes: 62157709961
        packets: 169847139
  - ifname: eno2np1
    linkinfo:
      businfo: 0000:1a:00.1
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 33061895405
        multicast: 110203
        packets: 110447356
      tx:
        bytes: 2370516278
        packets: 11324730
  - ifname: enp95s0f0np0
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2bf4
      prefixlen: 64
    linkinfo:
      businfo: 0000:5f:00.0
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:f4
      mtu: 9000
    statistics:
      rx:
        bytes: 37858381
        multicast: 205645
        packets: 205645
      tx:
        bytes: 1207334
        packets: 6542
  - ifname: enp95s0f1np1
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2bf5
      prefixlen: 64
    linkinfo:
      businfo: 0000:5f:00.1
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:f5
      mtu: 9000
    statistics:
      rx:
        bytes: 37852406
        multicast: 205607
        packets: 205607
      tx:
        bytes: 1207872
        packets: 6545
  - ifname: enp134s0f0np0
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2b6c
      prefixlen: 64
    linkinfo:
      businfo: 0000:86:00.0
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:6c
      mtu: 9000
    statistics:
      rx:
        bytes: 37988773
        multicast: 205584
        packets: 205584
      tx:
        bytes: 1212385
        packets: 6546
  - ifname: enp134s0f1np1
    interfaceinfo:
    - address: fe80::63f:72ff:fec4:2b6d
      prefixlen: 64
    linkinfo:
      businfo: 0000:86:00.1
      flags: up|broadcast|multicast
      macAddress: 04:3f:72:c4:2b:6d
      mtu: 9000
    statistics:
      rx:
        bytes: 37980702
        multicast: 205548
        packets: 205548
      tx:
        bytes: 1212297
        packets: 6548
  - ifname: gdcenet0
    interfaceinfo:
    - address: 208.117.254.36
      prefixlen: 28
    - address: fe80::b816:3ff:fe9e:9c87
      prefixlen: 64
    linkinfo:
      flags: up|broadcast|multicast
      macAddress: ba:16:03:9e:9c:87
      mtu: 9000
    statistics:
      rx:
        bytes: 34160422968
        errors: 2
        multicast: 301129
        packets: 115435591
      tx:
        bytes: 64528301111
        packets: 181171964
     .. <remaining interfaces omitted>
   lastReportTime: "2022-03-30T07:35:44Z"

Recurso NodeSystemConfigUpdate

El recurso NodeSystemConfigUpdate te permite realizar cambios en la configuración del sistema operativo del nodo, así como modificar las marcas de Kubelet. Los cambios que no sean cambios de sysctl requieren un reinicio del nodo.

Cuando crees una instancia de este recurso, debes especificar los nodos de destino en el campo nodeSelector. Debes incluir todos los pares clave-valor para cada nodo de destino en el campo nodeSelector. Cuando especificas más de un nodo de destino en este campo, los nodos de destino se actualizan de a uno por vez.

PRECAUCIÓN: El campo nodeName dejó de estar disponible. Si lo usas, se reinician de inmediato los nodos de destino, incluidos los nodos del plano de control local, lo que puede detener las cargas de trabajo críticas.

El recurso NodeSystemConfigUpdate proporciona los siguientes campos de configuración específicos de Distributed Cloud:

  • spec.containerRuntimeDNSConfig.ip: Especifica una lista de direcciones IP para los registros de imágenes privadas.

  • spec.containerRuntimeDNSConfig: Especifica una lista de entradas DNS personalizadas que usa el entorno de ejecución de contenedores en cada nodo de Distributed Cloud. Cada entrada consta de los siguientes campos:

    • ip: Especifica la dirección IPv4 de destino.
    • domain: Especifica el dominio correspondiente.
    • interface: Especifica la interfaz de salida de red a través de la cual se puede acceder a la dirección IP especificada en el campo ip. Puedes especificar una interfaz definida a través de los siguientes recursos: CustomNetworkInterfaceConfig, Network (por anotación), NetworkAttachmentDefinition (por anotación). Esta es una función de nivel de vista previa.

  • spec.kubeletConfig.cpuManagerPolicy: Especifica la política de CPUManager de Kubernetes. Los valores válidos son None y Static.

  • spec.kubeletConfig.topologyManagerPolicy: Especifica la política de TopologyManager de Kubernetes. Los valores válidos son None, BestEffort, Restricted y SingleNumaMode.

  • spec.osConfig.hugePagesConfig: Especifica la configuración de páginas enormes por nodo NUMA. Los valores válidos son 2MB y 1GB. La cantidad de páginas enormes solicitadas se distribuye de manera uniforme en ambos nodos NUMA del sistema. Por ejemplo, si asignas 16 páginas enormes de 1 GB cada una, cada nodo recibe una asignación previa de 8 GB.

  • spec.osConfig.isolatedCpusPerSocket: Especifica la cantidad de CPU aisladas por socket. Es obligatorio si cpuManagerPolicy está configurado como Static. La cantidad máxima de CPU aisladas debe ser inferior al 80% de las CPU totales del nodo.

  • spec.osConfig.cpuIsolationPolicy: Especifica la política de aislamiento de CPU. La política Default solo aísla las tareas systemd de las CPU reservadas para las cargas de trabajo. La política Kernel marca las CPU como isolcpus y establece las marcas rcu_nocb, nohz_full y rcu_nocb_poll en cada CPU.

  • spec.sysctls.NodeLevel: Especifica los parámetros sysctls que puedes configurar de forma global en un nodo con el operador de función de red. Los parámetros configurables son los siguientes:

    • fs.inotify.max_user_instances
    • fs.inotify.max_user_watches
    • kernel.sched_rt_runtime_us
    • kernel.core_pattern
    • net.ipv4.tcp_wmem
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_slow_start_after_idle
    • net.ipv4.udp_rmem_min
    • net.ipv4.udp_wmem_min
    • net.ipv4.tcp_rmem
    • net.ipv4.tcp_wmem
    • net.core.rmem_max
    • net.core.wmem_max
    • net.core.rmem_default
    • net.core.wmem_default
    • net.netfilter.nf_conntrack_tcp_timeout_unacknowledged
    • net.netfilter.nf_conntrack_tcp_timeout_max_retrans
    • net.sctp.auth_enable
    • net.sctp.sctp_mem
    • net.ipv4.udp_mem
    • net.ipv4.tcp_mem
    • net.ipv4.tcp_slow_start_after_idle
    • net.sctp.auth_enable
    • vm.max_map_count

    También puedes definir el alcance de los parámetros seguros y no seguros sysctls en un Pod o espacio de nombres específico con el tuning complemento de interfaz de red de contenedor (CNI).

El recurso NodeSystemConfigUpdate proporciona los siguientes campos de estado general de solo lectura:

  • status.lastReportTime: Es la hora más reciente en que se informó el estado de la interfaz de destino.
  • status.conditions.lastTransitionTime: Es la hora más reciente en que cambió la condición de la interfaz.
  • status.conditions.observedGeneration: Denota el valor .metadata.generation en el que se basó la condición inicial.
  • status.conditions.message: Es un mensaje informativo que describe el cambio de la condición de la interfaz.
  • status.conditions.reason: Es un identificador programático que denota el motivo del último cambio de la condición de la interfaz.
  • status.conditions.status: Es el descriptor de estado de la condición. Los valores válidos son True, False y Unknown.
  • status.conditions.type: Es el tipo de condición en camelCase.

En el siguiente ejemplo, se ilustra la estructura del recurso:

apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
  name: node-pool-1-config
  namespace: default
spec:
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
    networking.gke.io/worker-network-sriov.capable: true
  sysctls:
    nodeLevel:
      "net.ipv4.udp_mem" : "12348035 16464042 24696060"
  kubeletConfig:
    topologyManagerPolicy: BestEffort
    cpuManagerPolicy: Static
  osConfig:
    hugePagesConfig:
      "TWO_MB": 0
      "ONE_GB": 16
    isolatedCpusPerSocket:
      "0": 10
      "1": 10

Recurso SriovNetworkNodePolicy

El recurso SriovNetworkNodePolicy te permite asignar un grupo de funciones virtuales (VF) de SR-IOV en una máquina física de Distributed Cloud y crear una instancia de ese grupo como un recurso de Kubernetes. Luego, puedes usar este recurso en un recurso NetworkAttachmentDefinition.

Puedes seleccionar cada VF de destino por su proveedor y su ID de dispositivo PCIe, sus direcciones de dispositivo PCIe o por su nombre de dispositivo enumerado de Linux. El operador de red SR-IOV configura cada interfaz de red física para aprovisionar las VF de destino. Esto incluye actualizar el firmware de la interfaz de red, configurar el controlador del kernel de Linux y reiniciar la máquina de Distributed Cloud, si es necesario.

Para descubrir las interfaces de red disponibles en tu nodo, puedes buscar los NetworkInterfaceState recursos en ese nodo en el nf-operator espacio de nombres.

En el siguiente ejemplo, se ilustra la estructura del recurso:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: mlnx6-p2-sriov-en2
  namespace: sriov-network-operator
spec:
  deviceType: netdevice
  isRdma: true
  mtu: 9000
  nicSelector:
    pfNames:
    - enp134s0f1np1
  nodeSelector:
    edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_p2_sriov_en2

En el ejemplo anterior, se crea un máximo de 31 VF desde el segundo puerto de la interfaz de red llamada enp134s0f1np1 con un valor de MTU de 9000 (el valor máximo permitido). Usa la etiqueta del selector de nodos edgecontainer.googleapis.com/network-sriov.capable, que está presente en todos los nodos de Distributed Cloud compatibles con SR-IOV.

Para obtener información sobre el uso de este recurso, consulta SriovNetworkNodeState.

Recurso SriovNetworkNodeState

El recurso de solo lectura SriovNetworkNodeState te permite consultar el estado de aprovisionamiento del recurso SriovNetworkNodePolicy en un nodo de Distributed Cloud. Muestra la configuración completa del recurso SriovNetworkNodePolicy en el nodo, así como una lista de las VF activas en el nodo. El campo status.syncStatus indica si se aplicaron correctamente todos los recursos SriovNetworkNodePolicy definidos para el nodo.

En el siguiente ejemplo, se ilustra la estructura del recurso:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
  name: MyNode1
  namespace: sriov-network-operator
spec:
  dpConfigVersion: "1969684"
  interfaces:
  - mtu: 9000
    name: enp134s0f1np1
    numVfs: 31
    pciAddress: 0000:86:00.1
    vfGroups:
    - deviceType: netdevice
      mtu: 9000
      policyName: mlnx6-p2-sriov-en2
      resourceName: mlnx6_p2_sriov_en2
      vfRange: 0-30
status:

Status:
  Interfaces:
    Device ID:    1015
    Driver:       mlx5_core
    Link Speed:   25000 Mb/s
    Link Type:    ETH
    Mac:          ba:16:03:9e:9c:87
    Mtu:          9000
    Name:         eno1np0
    Pci Address:  0000:1a:00.0
    Vendor:       15b3
    Device ID:    1015
    Driver:       mlx5_core
    Link Speed:   25000 Mb/s
    Link Type:    ETH
    Mac:          ba:16:03:9e:9c:87
    Mtu:          9000
    Name:         eno2np1
    Pci Address:  0000:1a:00.1
    Vendor:       15b3
    Vfs:
  - Vfs:
    - deviceID: 101e
      driver: mlx5_core
      mac: c2:80:29:b5:63:55
      mtu: 9000
      name: enp134s0f1v0
      pciAddress: 0000:86:04.1
      vendor: 15b3
      vfID: 0
    - deviceID: 101e
      driver: mlx5_core
      mac: 7e:36:0c:82:d4:20
      mtu: 9000
      name: enp134s0f1v1
      pciAddress: 0000:86:04.2
      vendor: 15b3
      vfID: 1
      .. <omitted 29 other VFs here>
  syncStatus: Succeeded

Para obtener información sobre el uso de este recurso, consulta SriovNetworkNodeState.

Recurso NetworkAttachmentDefinition

El recurso NetworkAttachmentDefinition te permite conectar Pods de Distributed Cloud a una o más redes lógicas o físicas en tu nodo de Distributed Cloud. Aprovecha el framework de Multus-CNI y el complemento de SRIOV-CNI.

Usa una anotación para hacer referencia al nombre del recurso SriovNetworkNodePolicy adecuado. Cuando crees esta anotación, haz lo siguiente:

  • Usa la clave k8s.v1.cni.cncf.io/resourceName.
  • Usa el prefijo gke.io/ en su valor, seguido del nombre del recurso SriovNetworkNodePolicy de destino.

En el siguiente ejemplo, se ilustra la estructura del recurso:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-net1
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_p2_sriov_en2

spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-network",
  "ipam": {
    "type": "host-local",
    "subnet": "10.56.217.0/24",
    "routes": [{
      "dst": "0.0.0.0/0"
    }],
    "gateway": "10.56.217.1"
  }
}'

Actualiza los recursos NetworkAttachmentDefinition a Distributed Cloud 1.4.0

La versión 1.4.0 de Distributed Cloud reemplaza la interfaz bond0 por una nueva interfaz llamada gdcenet0. La interfaz gdcenet0 te permite usar la tarjeta de interfaz de red (NIC) de administración del host en cada máquina de Distributed Cloud de tu rack para tus cargas de trabajo, mientras mantienes completamente separado el tráfico de red de administración y del plano de control de Distributed Cloud. Para aprovechar esta funcionalidad, completa los pasos de esta sección para volver a configurar tus NetworkAttachmentDefinition recursos y, luego, sigue las instrucciones en Configura las herramientas de redes de Distributed Cloud para aprovisionar las redes y subredes adecuadas.

Para cada clúster de Distributed Cloud en el que implementaste uno o más recursos NetworkAttachmentDefinition, se aplican las siguientes reglas de migración:

  • Para cada recurso NetworkAttachmentDefinition nuevo, usa gdcenet0 en lugar de bond0 como el valor del campo master. Si aplicas un recurso que usa bond0 o un valor vacío para este campo, Distributed Cloud reemplaza el valor por gdcenet0 y, luego, almacena y aplica el recurso al clúster.
  • Para cada recurso NetworkAttachmentDefinition existente, reemplaza bond0 por gdcenet0 como el valor del campo master y, luego, vuelve a aplicar el recurso al clúster para restablecer la conectividad de red completa a los Pods afectados.

Para obtener información sobre el uso de este recurso, consulta NetworkAttachmentDefinition.

Configura una interfaz secundaria en un Pod con VF de SR-IOV

Después de configurar un recurso SriovNetworkNodePolicy y un recurso NetworkAttachmentDefinition correspondiente, puedes configurar una interfaz de red secundaria en un Pod de Distributed Cloud con funciones virtuales de SR-IOV.

Para ello, agrega una anotación a la definición de tu Pod de Distributed Cloud de la siguiente manera:

  • Clave: k8s.v1.cni.cncf.io/networks
  • Valor: nameSpace/<NetworkAttachmentDefinition1,nameSpace/NetworkAttachmentDefinition2...

En el siguiente ejemplo, se ilustra esta anotación:

apiVersion: v1
kind: Pod
metadata:
  name: sriovpod
  annotations:
    k8s.v1.cni.cncf.io/networks: mynamespace/sriov-net1
spec:
  containers:
  - name: sleeppodsriov
    command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
    image: alpine
    securityContext:
      capabilities:
        add:
          - NET_ADMIN

Configura una interfaz secundaria en un Pod con el controlador MacVLAN

Distributed Cloud también admite la creación de una interfaz de red secundaria en un Pod con el controlador MacVLAN. Solo la interfaz gdcenet0 admite esta configuración y solo en los Pods que ejecutan cargas de trabajo en contenedores.

Para configurar una interfaz para usar el controlador MacVLAN, haz lo siguiente:

  1. Configura un recurso NetworkAttachmentDefinition como se muestra en el siguiente ejemplo:

     apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
   name: macvlan-b400-1
   annotations:
     networking.gke.io/gdce-vlan-id: 400
 spec:
   config: '{
   "type": "macvlan",
   "master": "gdcenet0.400",
   "ipam": {
     "type": "static",
     "addresses": [
       {
         "address": "192.168.100.20/27",
         "gateway": "192.168.100.1"
       }
     ]
   ...
   }
 }'

  2. Agrega una anotación a la definición de tu Pod de Distributed Cloud de la siguiente manera:

     apiVersion: v1
 kind: Pod
 metadata:
   name: macvlan-testpod1
   annotations:
     k8s.v1.cni.cncf.io/networks: macvlan-b400-1

Configura una interfaz secundaria en un Pod con varias redes de Distributed Cloud

Distributed Cloud admite la creación de una interfaz de red secundaria en un Pod con su función de varias redes. Para ello, completa los siguientes pasos:

  1. Configura un recurso Network. Por ejemplo:

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: vlan200-network
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: vlan200-interface
  gateway4: 10.53.0.1

  2. Agrega una anotación a la definición de tu Pod de Distributed Cloud de la siguiente manera:

    apiVersion: v1
kind: Pod
metadata:
  name: myPod
  annotations:
    networking.gke.io/interfaces: [{"interfaceName":"eth1","network":"vlan200-network"}]
    networking.gke.io/default-interface: eth1
...

    ¿Qué sigue?