Operador de função de rede

Esta página descreve o operador especializado do Kubernetes de função de rede que o Google Distributed Cloud Connected vem com. Esse operador implementa um conjunto de CustomResourceDefinitions (CRDs) que permitem que o Distributed Cloud Connected execute cargas de trabalho de alta performance.

Com o operador de função de rede, é possível:

  • Faz uma pesquisa de dispositivos de rede em um nó.
  • Consulte o endereço IP e o estado do link físico de cada dispositivo de rede em um nó.
  • Provisione outras interfaces de rede em um nó.
  • Configure os recursos de sistema de baixo nível na máquina física do nó necessários para oferecer suporte a cargas de trabalho de alto desempenho.
  • Use a virtualização de entrada/saída de raiz única (SR-IOV) em interfaces de rede PCI Express para virtualizá-las em várias interfaces virtuais. Em seguida, configure as cargas de trabalho conectadas do Distributed Cloud para usar essas interfaces de rede virtual.

O suporte conectado do Distributed Cloud para SR-IOV é baseado nos seguintes projetos de código aberto:

Perfis de operador de função de rede

O Distributed Cloud Connected oferece os seguintes perfis de funcionalidade do operador de função de rede em cada formato do Distributed Cloud Connected:

  • Os racks conectados do Distributed Cloud oferecem suporte ao perfil completo de funcionalidade do operador de função de rede com os seguintes recursos:

    • As funções de automação de rede permitem automatizar a configuração da rede de pods da sua carga de trabalho. Por exemplo, configurar o peering do BGP e interfaces de rede secundárias.

    • As funções de exportação de estado permitem exportar estados de rede do host para o usuário, incluindo configuração e status da interface de rede.

    • Com as funções de configuração de nós, é possível ajustar o desempenho de um nó para atender às necessidades da sua empresa, incluindo isolamento de CPU, página enorme, kernel em tempo real, parâmetros kubelet e sysctl.

    • As funções de gerenciamento de energia permitem gerenciar o consumo de energia em um nó, incluindo estados P e C de CPUs isoladas.

    • Com as funções de webhook, é possível validar as entradas do usuário.

    • As funções Diversos incluem o automatizador SR-IOV, que configura automaticamente o operador SR-IOV.

  • Os servidores conectados do Distributed Cloud oferecem suporte ao perfil de funcionalidade do operador de função de rede otimizado para desempenho com os seguintes recursos:

    • As funções de automação de rede permitem automatizar a configuração da rede de pods da sua carga de trabalho. Por exemplo, configurar o peering do BGP e interfaces de rede secundárias.

    • As funções de exportação de estado permitem exportar estados de rede do host para o usuário, incluindo configuração e status da interface de rede.

    • Com as funções de webhook, é possível validar as entradas do usuário.

Pré-requisitos

O operador de função de rede busca a configuração de rede na API Distributed Cloud Edge Network. Para permitir isso, conceda à conta de serviço do operador de função de rede o papel de visualizador de rede de borda (roles/edgenetwork.viewer) usando o seguinte comando:

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

Substitua:

  • ZONE_PROJECT_ID com o ID do projeto Google Cloud que contém os recursos da API Distributed Cloud Edge Network.
  • CLUSTER_PROJECT_ID com o ID do projeto Google Cloud que contém o cluster conectado do Distributed Cloud de destino.

Recursos do operador de função de rede

O operador de função de rede conectada do Distributed Cloud implementa os seguintes CRDs do Kubernetes:

  • Network. Define uma rede virtual que os pods podem usar para se comunicar com recursos internos e externos. É preciso criar a VLAN correspondente usando a API Distributed Cloud Edge Network antes de especificá-la neste recurso. Para instruções, consulte Criar uma sub-rede.
  • NetworkInterfaceState. Permite a descoberta de estados de interface de rede e a consulta de uma interface de rede para estado de link e endereço IP.
  • NodeSystemConfigUpdate. Permite a configuração de recursos de sistema de baixo nível, como opções de kernel e flags Kubelet.
  • SriovNetworkNodePolicy. Seleciona um grupo de interfaces de rede virtualizadas SR-IOV e cria uma instância do grupo como um recurso do Kubernetes. Você pode usar esse recurso em um recurso NetworkAttachmentDefinition.
  • SriovNetworkNodeState. Permite consultar o estado de provisionamento do recurso SriovNetworkNodePolicy em um nó do Distributed Cloud.
  • NetworkAttachmentDefinition. Permite anexar pods do Distributed Cloud a uma ou mais redes lógicas ou físicas no nó conectado do Distributed Cloud. É preciso criar a VLAN correspondente usando a API Distributed Cloud Edge Network antes de especificá-la neste recurso. Para instruções, consulte Criar uma sub-rede.

O operador de função de rede também permite definir interfaces de rede secundárias que não usam funções virtuais SR-IOV.

Network recurso

O recurso Network define uma rede virtual no rack conectado do Distributed Cloud que os pods no cluster conectado do Distributed Cloud podem usar para se comunicar com recursos internos e externos.

O recurso Network fornece os seguintes parâmetros configuráveis para a interface de rede exposta como campos graváveis:

  • spec.type: especifica a camada de transporte de rede para essa rede. O único valor válido é L2. Também é necessário especificar um valor de nodeInterfaceMatcher.interfaceName.
  • spec.nodeInterfaceMatcher.interfaceName: o nome da interface de rede física no nó conectado do Distributed Cloud de destino a ser usado com essa rede.
  • spec.gateway4: o endereço IP do gateway de rede para essa rede.
  • spec.l2NetworkConfig.prefixLength4: especifica o intervalo CIDR para essa rede.
  • annotations.networking.gke.io/gdce-per-node-ipam-size: especifica o tamanho da máscara de sub-rede para um nó individual. Se isso for omitido, o tamanho da máscara de sub-rede será definido como o valor do campo cluster-cidr-config-per-node-mask-size no ConfigMap nf-operator-defaults no namespace nf-operator.
  • annotations.networking.gke.io/gdce-vlan-id: especifica o ID da VLAN para esta rede.
  • annotations.networking.gke.io/gdce-vlan-mtu: (opcional) especifica o valor da MTU para essa rede. Se omitido, herda o valor da MTU da interface principal.
  • annotations.networking.gke.io/gdce-lb-service-vip-cidr: especifica o intervalo de endereços IP virtuais para o serviço de balanceamento de carga. O valor pode ser um bloco CIDR ou um valor de intervalo de endereços explícito. Essa anotação é obrigatória para o balanceamento de carga da camada 3 e opcional para a camada 2.

O exemplo a seguir ilustra a estrutura do 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
    networking.gke.io/gdce-lb-service-vip-cidrs: "10.1.1.0/24"
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.200
  gateway4: 10.53.0.1

Para especificar vários intervalos de endereços IP virtuais para o serviço de balanceamento de carga, use a anotação networking.gke.io/gdce-lb-service-vip-cidrs. É possível fornecer os valores dessa anotação como uma lista separada por vírgulas ou como um payload JSON. Exemplo:

[
  {
    "name": "test-oam-3",
    "addresses": ["10.235.128.133-10.235.128.133"],
    "autoAssign": false
  }
  ,
  {
    "name": "test-oam-4",
    "addresses": ["10.235.128.134-10.235.128.134"],
    "autoAssign": false
  },
  {
    "name": "test-oam-5",
    "addresses": ["10.235.128.135-10.235.128.135"],
    "autoAssign": false
  }
]

Se você optar por usar um payload JSON, recomendamos que use o formato JSON condensado. Exemplo:

apiVersion: networking.gke.io/v1
  kind: Network
  metadata:
    annotations:
      networking.gke.io/gdce-lb-service-vip-cidrs: '[{"name":"test-oam-3","addresses":["10.235.128.133-10.235.128.133"],"autoAssign":false},{"name":"test-oam-4","addresses":["10.235.128.134-10.235.128.134"],"autoAssign":false},{"name":"test-oam-5","addresses":["10.235.128.135-10.235.128.135"],"autoAssign":false}]'
      networking.gke.io/gdce-vlan-id: "81"
    name: test-network-vlan81
  spec:
    IPAMMode: Internal
    dnsConfig:
      nameservers:
      - 8.8.8.8
    gateway4: 192.168.81.1
    l2NetworkConfig:
      prefixLength4: 24
    nodeInterfaceMatcher:
      interfaceName: gdcenet0.81
    type: L2

O campo autoAssign é definido como false por padrão se for omitido.

NetworkInterfaceState recurso

O recurso NetworkInterfaceState é somente leitura e permite descobrir interfaces de rede físicas no nó e coletar estatísticas de tempo de execução sobre o tráfego de rede que flui por essas interfaces. O Distributed Cloud cria um recurso NetworkInterfaceState para cada nó em um cluster.

A configuração padrão das máquinas conectadas do Distributed Cloud inclui uma interface de rede vinculada na placa filha de rede de seleção de rack (rNDC) chamada gdcenet0. Essa interface vincula as interfaces de rede eno1np0 e eno2np1. Cada um deles está conectado a um switch ToR do Distributed Cloud, respectivamente.

O recurso NetworkInterfaceState fornece as seguintes categorias de informações de interface de rede expostas como campos de status somente leitura.

Informações gerais:

  • status.interfaces.ifname: o nome da interface de rede de destino.
  • status.lastReportTime: a hora e a data do último relatório de status da interface de destino.

Informações de configuração do endereço IP:

  • status.interfaces.interfaceinfo.address: o endereço IP atribuído à interface de destino.
  • status.interfaces.interfaceinfo.dns: o endereço IP do servidor DNS atribuído à interface de destino.
  • status.interfaces.interfaceinfo.gateway: o endereço IP do gateway de rede que atende à interface de destino.
  • status.interfaces.interfaceinfo.prefixlen: o tamanho do prefixo IP.

Informações de hardware:

  • status.interfaces.linkinfo.broadcast: o endereço MAC de transmissão da interface de destino.
  • status.interfaces.linkinfo.businfo: o caminho do dispositivo PCIe no formato bus:slot.function.
  • status.interfaces.linkinfo.flags: as flags da interface. Por exemplo, BROADCAST.
  • status.interfaces.linkinfo.macAddress: o endereço MAC unicast da interface de destino.
  • status.interfaces.linkinfo.mtu: o valor da MTU para a interface de destino.

Estatísticas de recepção:

  • status.interfaces.statistics.rx.bytes: o total de bytes recebidos pela interface de destino.
  • status.interfaces.statistics.rx.dropped: o total de pacotes descartados pela interface de destino.
  • status.interfaces.statistics.rx.errors: o total de erros de recebimento de pacotes para a interface de destino.
  • status.interfaces.statistics.rx.multicast: o total de pacotes multicast recebidos pela interface de destino.
  • status.interfaces.statistics.rx.overErrors: o total de pacotes recebidos em relação a erros na interface de destino.
  • status.interfaces.statistics.rx.packets: o total de pacotes recebidos pela interface de destino.

Estatísticas de transmissão:

  • status.interfaces.statistics.tx.bytes: o total de bytes transmitidos pela interface de destino.
  • status.interfaces.statistics.tx.carrierErrors: o total de erros de operadora encontrados pela interface de destino.
  • status.interfaces.statistics.tx.collisions: o total de colisões de pacotes encontradas pela interface de destino.
  • status.interfaces.statistics.tx.dropped: o total de pacotes descartados pela interface de destino.
  • status.interfaces.statistics.tx.errors: o total de erros de transmissão da interface de destino.
  • status.interfaces.statistics.tx.packets: o total de pacotes transmitidos pela interface de destino.

O exemplo a seguir ilustra a estrutura do 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

Com o recurso NodeSystemConfigUpdate, é possível fazer mudanças na configuração do sistema operacional do nó e modificar flags Kubelet. Mudanças que não sejam de sysctl exigem uma reinicialização do nó. Esse recurso não está disponível em implantações de servidores conectados do Distributed Cloud.

Ao instanciar esse recurso, especifique os nós de destino no campo nodeSelector. Inclua todos os pares de chave-valor para cada nó de destino no campo nodeSelector. Quando você especifica mais de um nó de destino nesse campo, eles são atualizados um por vez.

ATENÇÃO: o campo nodeName foi descontinuado. O uso imediato reinicializa os nós de destino, incluindo os nós locais do plano de controle, o que pode interromper cargas de trabalho críticas.

O recurso NodeSystemConfigUpdate fornece os seguintes campos de configuração específicos do Distributed Cloud Connected:

  • spec.containerRuntimeDNSConfig.ip: especifica uma lista de endereços IP para registros de imagens particulares.

  • spec.containerRuntimeDNSConfig: especifica uma lista de entradas DNS personalizadas usadas pelo ambiente de execução de contêiner em cada nó conectado do Distributed Cloud. Cada entrada consiste nos seguintes campos:

    • ip: especifica o endereço IPv4 de destino.
    • domain: especifica o domínio correspondente.
    • interface: especifica a interface de saída de rede pela qual o endereço IP especificado no campo ip pode ser acessado. É possível especificar uma interface definida pelos seguintes recursos: CustomNetworkInterfaceConfig, Network (por anotação), NetworkAttachmentDefinition (por anotação).

  • spec.kubeletConfig.cpuManagerPolicy: especifica a política do CPUManager do Kubernetes. Os valores válidos são None e Static.

  • spec.kubeletConfig.topologyManagerPolicy: especifica a política TopologyManager do Kubernetes. Os valores válidos são None, BestEffort, Restricted e SingleNumaMode.

  • spec.osConfig.cgroupConfig.noKernelMemory: exclui a memória do espaço do kernel do cálculo de uso da memória do pod. Os valores válidos são true e false.

  • spec.osConfig.hugePagesConfig: especifica a configuração de página grande por nó NUMA. Os valores válidos são 2MB e 1GB. O número de páginas enormes solicitadas é distribuído igualmente entre os dois nós NUMA no sistema. Por exemplo, se você alocar 16 páginas enormes de 1 GB cada, cada nó receberá uma pré-alocação de 8 GB.

  • spec.osConfig.isolatedCpusPerSocket: especifica o número de CPUs isoladas por soquete. Obrigatório se cpuManagerPolicy estiver definido como Static. O número máximo de CPUs isoladas precisa ser menor que 80% do total de CPUs no nó.

  • spec.osConfig.cpuIsolationPolicy: especifica a política de isolamento de CPU. A política Default isola apenas tarefas systemd de CPUs reservadas para cargas de trabalho. A política Kernel marca as CPUs como isolcpus e define as flags rcu_nocb, nohz_full e rcu_nocb_poll em cada CPU. A política KernelOptimized marca as CPUs como isolcpus e define as flags rcu_nocb e rcu_nocb_poll em cada CPU, mas não a flag nohz_full.

  • spec.sysctls.NodeLevel: especifica os parâmetros sysctls que podem ser configurados globalmente em um nó usando o operador de função de rede. Os parâmetros configuráveis são os seguintes:

    • 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

    Também é possível definir o escopo dos parâmetros sysctls seguros e não seguros para um pod ou namespace específico usando o plug-in da interface de rede de contêineres (CNI) tuning.

O recurso NodeSystemConfigUpdate fornece os seguintes campos de status gerais somente leitura:

  • status.lastReportTime: a última vez que o status foi informado para a interface de destino.
  • status.conditions.lastTransitionTime: o horário mais recente em que a condição da interface mudou.
  • status.conditions.observedGeneration: denota o valor .metadata.generation em que a condição inicial se baseou.
  • status.conditions.message: uma mensagem informativa que descreve a mudança na condição da interface.
  • status.conditions.reason: um identificador programático que indica o motivo da última mudança na condição da interface.
  • status.conditions.status: o descritor de status da condição. Os valores válidos são True, False e Unknown.
  • status.conditions.type: o tipo de condição em camelCase.

O exemplo a seguir ilustra a estrutura do 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

O recurso SriovNetworkNodePolicy permite alocar um grupo de funções virtuais (VFs) do SR-IOV em uma máquina física conectada ao Distributed Cloud e instanciar esse grupo como um recurso do Kubernetes. Em seguida, use esse recurso em um recurso NetworkAttachmentDefinition. Esse recurso não está disponível em implantações de servidores conectados do Distributed Cloud.

É possível selecionar cada VF de destino pelo fornecedor e ID do dispositivo PCIe, pelos endereços do dispositivo PCIe ou pelo nome do dispositivo enumerado do Linux. O operador de rede SR-IOV configura cada interface de rede física para provisionar as VFs de destino. Isso inclui atualizar o firmware da interface de rede, configurar o driver do kernel do Linux e reiniciar a máquina conectada do Distributed Cloud, se necessário.

Para descobrir as interfaces de rede disponíveis no seu nó, procure os recursos NetworkInterfaceState nesse nó no namespace nf-operator.

O exemplo a seguir ilustra a estrutura do 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

O exemplo anterior cria um máximo de 31 VFs da segunda porta na interface de rede chamada enp134s0f1np1 com um valor de MTU de 9000 (o valor máximo permitido). Use o rótulo do seletor de nós edgecontainer.googleapis.com/network-sriov.capable, que está presente em todos os nós conectados do Distributed Cloud compatíveis com SR-IOV.

Para informações sobre como usar esse recurso, consulte SriovNetworkNodeState.

SriovNetworkNodeState recurso

O recurso somente leitura SriovNetworkNodeState permite consultar o estado de provisionamento do recurso SriovNetworkNodePolicy em um nó conectado do Distributed Cloud. Ele retorna a configuração completa do recurso SriovNetworkNodePolicy no nó, bem como uma lista de VFs ativas no nó. O campo status.syncStatus indica se todos os recursos SriovNetworkNodePolicy definidos para o nó foram aplicados corretamente. Esse recurso não está disponível em implantações de servidores conectados do Distributed Cloud.

O exemplo a seguir ilustra a estrutura do 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 informações sobre como usar esse recurso, consulte SriovNetworkNodeState.

NetworkAttachmentDefinition recurso

O recurso NetworkAttachmentDefinition permite anexar pods do Distributed Cloud a uma ou mais redes lógicas ou físicas no nó conectado do Distributed Cloud. Ele usa o framework Multus-CNI e os seguintes plug-ins:

Use uma anotação para fazer referência ao nome do recurso SriovNetworkNodePolicy apropriado. Ao criar essa anotação, faça o seguinte:

  • Use a chave k8s.v1.cni.cncf.io/resourceName.
  • Use o prefixo gke.io/ no valor, seguido pelo nome do recurso SriovNetworkNodePolicy de destino.

Use a anotação networking.gke.io/gdce-vlan-id para especificar o ID da VLAN da rede de destino. Essa anotação é obrigatória.

Os exemplos a seguir ilustram a estrutura do recurso. Para rede IPv4.

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
    networking.gke.io/gdce-vlan-id: 225

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"
  }
}'

Para rede IPv6:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-210-den102
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_p0_sriov_en
    networking.gke.io/gdce-vlan-id: 225
spec:
  config: '{
  "type": "sriov",
  "cniVersion": "0.3.1",
  "name": "sriov-210-den102",
  "vlan": 210,
  
  "ipam": {
    "type": "host-local",
    "rangeStart": "2001:4860:1025:102:ffff:0220::2",
    "rangeEnd": "2001:4860:1025:102:ffff:0220::F",
    "subnet": "2001:4860:1025:102:ffff:0220::/96",
    "routes": [{
      "dst": "::/0"
    }],
    "gateway": "2001:4860:1025:102:ffff:0220::1"
  }
}'

Configurar uma interface secundária em um pod usando VFs SR-IOV

Depois de configurar um recurso SriovNetworkNodePolicy e um recurso NetworkAttachmentDefinition correspondente, é possível configurar uma interface de rede secundária em um pod do Distributed Cloud usando funções virtuais SR-IOV.

Para fazer isso, adicione uma anotação à definição do pod do Distributed Cloud da seguinte maneira:

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

O exemplo a seguir ilustra essa anotação:

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

Configurar uma interface secundária em um pod usando o driver MacVLAN

O Distributed Cloud Connected também oferece suporte à criação de uma interface de rede secundária em um pod usando o driver MacVLAN. Somente a interface gdcenet0 é compatível com essa configuração e apenas em pods que executam cargas de trabalho em contêineres.

Para configurar uma interface para usar o driver MacVLAN:

  1. Configure um recurso NetworkAttachmentDefinition conforme mostrado nos exemplos a seguir. Para rede IPv4:

     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"
       }
     ]
   ...
   }
 }'

    Para rede IPv6:

     apiVersion: "k8s.cni.cncf.io/v1"
 kind: NetworkAttachmentDefinition
 metadata:
   name: macvlan-bond0-210-den402
   annotations:
       networking.gke.io/gdce-vlan-id
 spec:
   config: '{
   "type": "macvlan",
   "cniVersion": "0.3.1",
   "name": "bond0-210",
   "master": "bond0.210",

   "ipam": {
     "type": "host-local",
     "rangeStart": "2001:4860:1025:102:0001:0210::2",
     "rangeEnd": "2001:4860:1025:102:0001:0210::F",
     "subnet": "2001:4860:1025:102:0001:0210::/96",
     "routes": [{
       "dst": "::/0"
     }],
     "gateway": "2001:4860:1025:102:0001:0210::1"
   }
 }'

  2. Adicione uma anotação à definição do pod do Distributed Cloud da seguinte maneira. Para rede IPv4:

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

    Para rede IPv6:

     apiVersion: v1
 kind: Pod
 metadata:
   name: vlan210-1
   namespace: default
   annotations:
     k8s.v1.cni.cncf.io/networks: default/macvlan-bond0-210-den402

Configurar uma interface secundária em um pod usando a multirrede do Distributed Cloud

O Distributed Cloud Connected permite criar uma interface de rede secundária em um pod usando o recurso de várias redes. Para isso, siga estas etapas:

  1. Configure um recurso Network. Exemplo:

    apiVersion: networking.gke.io/v1
kind: Network
metadata:
  name: my-network-410
  annotations:
      networking.gke.io/gdce-vlan-id: "410"
      networking.gke.io/gdce-lb-service-vip-cidrs: '[{"name":"myPool","addresses":["10.100.63.130-10.100.63.135"],"avoidBuggyIPs":false,"autoAssign":true}]'
spec:
  type: L2
  nodeInterfaceMatcher:
    interfaceName: gdcenet0.410
  gateway4: 10.100.63.129
  l2NetworkConfig:
    prefixLength4: 27

    A anotação networking.gke.io/gdce-lb-service-vip-cidrs especifica um ou mais pools de endereços IP para essa rede virtual. A primeira metade do CIDR especificado aqui precisa incluir endereços IP virtuais de serviço (SVIPs). O Distributed Cloud Connected aplica esse requisito por meio de verificações de webhook da seguinte maneira:

    • O intervalo de endereços SVIP precisa estar dentro do intervalo CIDR da VLAN correspondente, e
    • O intervalo de endereços SVIP só pode abranger até a primeira metade do intervalo de CIDR da VLAN.

  2. Adicione uma anotação à definição do pod do Distributed Cloud da seguinte maneira:

    apiVersion: v1
kind: pod
metadata:
  name: myPod
  annotations:
    networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"pod-network"}, {"interfaceName":"eth1","network":"my-network-410"}]'
    networking.gke.io/default-interface: eth1

    Essa anotação configura a interface eth0 como primária e a interface eth1 como secundária com balanceamento de carga da camada 2 com o MetalLB.

A configuração da interface secundária, conforme descrito nesta seção, resulta na criação automática dos seguintes recursos personalizados:

  • Um recurso IPAddressPool, que permite a atribuição automática de endereços SVIP a pods. Exemplo:
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: test-410-pool
  namespace: kube-system
  annotations:
    networking.gke.io/network:my-network-410
    …
  spec:
  addresses:
  - 10.100.63.130-10.100.63.135
  autoAssign: true
  • Um recurso L2Advertisement, que permite a publicidade dos endereços SVIP especificados. Exemplo:
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advertise-410
  namespace: kube-system
spec:
  ipAddressPools:
  - test-410-pool
  interfaces:
  - gdcenet0.410

A seguir