Operador de la función de red

En esta página, se describe el operador especializado de Kubernetes para funciones 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 funciones de red y la funcionalidad de SR-IOV no están disponibles en los servidores de Distributed Cloud.

El operador de funciones de red te permite hacer lo siguiente:

  • Sondea los dispositivos de red existentes en un nodo.
  • Consulta la dirección IP y el estado del vínculo físico de cada dispositivo de red en un nodo.
  • Aprovisiona interfaces de red adicionales en un nodo.
  • Configura las 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.
  • Usa la virtualización de entrada/salida de raíz única (SR-IOV) en 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 la 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 funciones de red el rol de visualizador de redes perimetrales (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 Google Cloud de destino.

Recursos del operador de la función de red

El operador de funciones 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 la interfaz de red y la consulta de una interfaz de red para obtener el estado del vínculo y la dirección IP.
  • NodeSystemConfigUpdate: Permite configurar funciones del sistema de bajo nivel, como opciones del kernel y marcas Kubelet.
  • SriovNetworkNodePolicy: Selecciona un grupo de interfaces de red virtualizadas con 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 antes de especificarla en este recurso. 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 funciones de red también te permite definir interfaces de red secundarias que no usan funciones virtuales de SR-IOV.

Network recurso

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 de 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

NetworkInterfaceState recurso

El recurso NetworkInterfaceState es de solo lectura y 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 secundaria de red de selección de rack (rNDC) llamada gdcenet0. Esta interfaz vincula las interfaces de red eno1np0 y eno2np1. Cada uno de ellos está conectado 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 fecha y hora 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 asignado 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 de IP.

Información del 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 de acceso 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 la 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: Es la cantidad total de paquetes 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 de multidifusión totales que recibió la interfaz de destino.
  • status.interfaces.statistics.rx.overErrors: Es la cantidad total de errores en la recepción de paquetes para la interfaz de destino.
  • status.interfaces.statistics.rx.packets: Son los paquetes totales que recibió 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 del 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: Es la cantidad total de paquetes descartados por la interfaz de destino.
  • status.interfaces.statistics.tx.errors: Son los errores de transmisión totales 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"

NodeSystemConfigUpdate recurso

El recurso NodeSystemConfigUpdate te permite realizar cambios en la configuración del sistema operativo del nodo, así como modificar las marcas Kubelet. Los cambios que no sean 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. Este campo reemplaza al campo nodeName.

PRECAUCIÓN: El campo nodeName dejó de estar disponible. Si lo usas, se reiniciarán 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 privados.
  • spec.containerRuntimeDNSConfig: Especifica una lista de entradas de DNS personalizadas que utiliza el entorno de ejecución del contenedor 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 versión preliminar.
  • 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 entre los dos nodos NUMA del sistema. Por ejemplo, si asignas 16 páginas enormes de 1 GB cada una, cada nodo recibirá una asignación previa de 8 GB.

  • spec.osConfig.isolatedCpusPerSocket: Especifica la cantidad de CPU aisladas por socket. Se requiere si cpuManagerPolicy se establece en Static.

  • spec.osConfig.cpuIsolationPolicy: Especifica la política de aislamiento de la CPU. La política Default solo aísla las tareas de 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 de 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 sysctls seguros y no seguros para un Pod o un espacio de nombres específicos con el complemento de la interfaz de red de contenedor (CNI) tuning.

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

  • status.lastReportTime: Es la fecha y hora más recientes en que se informó el estado de la interfaz de destino.
  • status.conditions.lastTransitionTime: Es la hora más reciente en la que cambió el estado de la interfaz.
  • status.conditions.observedGeneration: Denota el valor de .metadata.generation en el que se basó la condición inicial.
  • status.conditions.message: Es un mensaje informativo que describe el cambio en la condición de la interfaz.
  • status.conditions.reason: Es un identificador programático que denota el motivo del último cambio en 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

SriovNetworkNodePolicy recurso

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 ID de dispositivo y proveedor de PCIe, sus direcciones de dispositivo PCIe o su nombre de dispositivo enumerado de Linux. El operador de red de 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 recursos de NetworkInterfaceState en ese nodo en el espacio de nombres nf-operator.

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 crean hasta 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.

SriovNetworkNodeState recurso

El recurso de solo lectura SriovNetworkNodeState te permite consultar el estado de aprovisionamiento del recurso SriovNetworkNodePolicy en un nodo de Distributed Cloud. Devuelve 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 todos los recursos SriovNetworkNodePolicy definidos para el nodo se aplicaron correctamente.

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.

NetworkAttachmentDefinition recurso

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 Multus-CNI y el complemento 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 de 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, a la vez que mantiene completamente separado el tráfico de red del plano de control y administración de Distributed Cloud. Para aprovechar esta funcionalidad, completa los pasos de esta sección para volver a configurar tus recursos de NetworkAttachmentDefinition y, luego, sigue las instrucciones en Configura las 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 de 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 del 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 que use 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 redes múltiples 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?