Anexando Várias VNICs Secundárias para Rede de Pods

Etapa 1: Verificar os nomes e a capacidade do Recurso Estendido em um nó

Depois que o pool de nós tiver nós de trabalho, verifique os nomes e a capacidade do Recurso Estendido em um nó.

1. Revise os Recursos Estendidos anunciados do nó:

   kubectl describe node <node-name>

2. Na seção Capacity da saída, identifique os Recursos Estendidos que correspondem aos Recursos do Aplicativo (por exemplo, oke-application-resource.oci.oraclecloud.com/frontend) e confirme que eles têm capacidade diferente de zero.

Os nós que expõem os Recursos do Aplicativo são contaminados com oci.oraclecloud.com/application-resource-only:NoSchedule para evitar que pods sem solicitações explícitas do Recurso do Aplicativo sejam acessados por eles.

Adicione uma tolerância correspondente à especificação do pod (em spec.tolerations para um Pod ou em spec.template.spec.tolerations em uma Implantação):

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

Sem essa tolerância, o scheduler rejeitará o posicionamento mesmo que exista capacidade de recurso.

Na especificação do pod, solicite o Recurso Estendido que corresponda ao perfil de VNIC secundário que o pod deve usar (por exemplo, em uma Implantação em spec.template.spec.containers[].resources). Solicite e limite exatamente uma unidade para que o scheduler reserve a capacidade de forma consistente.

Por exemplo:

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

Etapa 4: (Opcional) Direcionar os pools de nós corretos

Se sua organização usar uma convenção de rótulo/seletor de nó para esses nós (por exemplo, gva_vnic: "yes"), inclua-a para que os pods não sejam colocados em pools de nós que não tenham os recursos necessários:

nodeSelector:
  gva_vnic: "yes"

Um nodeSelector é opcional quando as solicitações e tolerâncias do Recurso de Aplicativo já restringem a programação. Só use um nodeSelector se você tiver rotulado os nós de destino (por exemplo, por meio de labels do Kubernetes do pool de nós).

Após a implantação:

1. Informar:

   kubectl get pods -o wide

2. Para um pod de interesse, informe:

   kubectl describe pod <pod-name>

3. Confirme se o pod está em Execução e se não há erros de programação (por exemplo, capacidade insuficiente para o recurso solicitado).

Instale o Multus antes de criar NADs ou implantar pods de várias interfaces. Para obter informações sobre como instalar o Multus, consulte a documentação do Multus-CNI no GitHub.

Siga o processo padrão da sua organização para implantar o Multus e verifique se ele está íntegro:

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

Os exemplos nesta seção usam o plug-in CNI ipvlan para a interface de pod adicional. Certifique-se de que o binário ipvlan esteja presente em /opt/cni/bin/ipvlan em cada nó de trabalho que possa executar pods com várias interfaces.

A Oracle recomenda instalar o plug-in ipvlan usando um script cloud-init do pool de nós para que o plug-in seja instalado quando os nós forem criados, substituídos ou expandidos. Fixe o plug-in a uma release validada para o ambiente de destino, em vez de seguir um caminho de download flutuante. O exemplo a seguir usa a versão v1.9.0.

Por exemplo:

#!/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

Se os nós de trabalho não puderem acessar o GitHub, prepare o arquivo compactado de plug-ins CNI necessários no OCI Object Storage ou em outro local interno aprovado e atualize o URL de download no script cloud-init.

Os NADs devem direcionar os nomes reais da interface do host criados pelas VNICs anexadas (por exemplo, enp1s0, enp2s0). Verifique-os em um nó de trabalho usando o método de acesso padrão da sua organização.

Criar:

• um NAD para a rede de pods padrão (para controlar qual interface de host faz backup de eth0)
• um ou mais NADs para interfaces adicionais (por exemplo, net1).

Sua configuração NAD pode selecionar um dispositivo usando um deviceSelector (por exemplo, por interfaceName ou pelo nome do Recurso do Aplicativo usando appResource, se suportado em seu ambiente).

Os exemplos de NAD a seguir usam intencionalmente diferentes namespaces. oci-vcn-native-network é definido em kube-system, enquanto ipvlan-network é definido em default. Se a carga de trabalho for executada em outro namespace, crie ipvlan-network nesse namespace ou atualize a anotação de pod para fazer referência ao nome NAD totalmente qualificado.

NAD de rede padrão fixado em 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
        }
      ]
    }

Rede secundária NAD fixada em 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"
            }
          }
        }
      ]
    }

O NAD padrão usa os plug-ins oci-ipvlan e oci-ptp específicos do OCI porque essa interface participa do caminho de rede padrão nativo da VCN do OKE. O NAD adicional usa o plug-in ipvlan padrão porque o Multus está anexando uma interface extra em uma NIC de host específica, enquanto o OCI IPAM ainda fornece a alocação de IP com reconhecimento de sub-rede.

deviceSelector pode direcionar interfaces com campos como:

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

O bloco deviceSelector permite que o OCI IPAM escolha a interface de destino ou a VNIC usada para alocação de IP de pod. Ele pode selecionar um dispositivo usando um ou mais destes campos:

• appResource: Seleciona o perfil da VNIC GVA por nome do Recurso da Aplicação.

• interfaceName: Seleciona uma interface de host específica, como enp1s0.

• interfaceNamePrefix: Seleciona uma interface por prefixo, como enp.

• macAddress: Seleciona uma interface por endereço MAC.

Quando appResource é definido no seletor de dispositivos NAD, o plug-in do OCI IPAM usa esse Recurso de Aplicativo para decidir qual perfil de VNIC GVA deve fornecer o endereço IP do pod e atuar como o dispositivo pai dessa interface. Isso permite que diferentes NADs no mesmo pod sejam mapeados para diferentes perfis de VNIC, por exemplo:

• NAD1 -> Application Resource: vnic-a

• NAD2 -> Application Resource: vnic-b

• NAD3 -> Application Resource: vnic-c

Se um pod usar todos os três NADs, cada interface poderá ser anexada por meio do perfil de VNIC correspondente.

Nos exemplos de nome de interface mostrados neste documento:

• O NAD oci-vcn-native-network usa interfaceName: enp1s0 para que o OCI IPAM aloque o IP de rede padrão do pod da interface enp1s0 do host.

• O NAD ipvlan-network usa interfaceName: enp2s0 para que o OCI IPAM aloque o IP de interface adicional da interface enp2s0 do host.

É também por isso que os exemplos de pods são definidos:

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

A anotação v1.multus-cni.io/default-network garante que eth0 use o NAD oci-vcn-native-network. Sem selecionar explicitamente essa rede padrão, o OCI IPAM pode alocar de qualquer interface de host elegível, o que torna a interface de pod principal menos previsível. A definição do NAD padrão garante que eth0 use a interface pretendida e a mantenha isolada do anexo de rede adicional.

Não combine essas anotações de pod Multus com solicitações de Recurso de Aplicativo no nível de pod na mesma especificação de pod. Se um pod com várias interfaces precisar da seleção de VNIC GVA, defina essa seleção dentro da configuração NAD deviceSelector.appResource para cada interface, em vez de usar uma solicitação de Recurso de Aplicativo no nível do pod.

Aplique os NADs:

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

kubectl apply -f ipvlan-network.yaml

Anote o pod para selecionar o NAD de rede padrão e anexe NADs de rede adicionais, por exemplo:

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

1. Descreva o pod e verifique as anotações de status da rede Multus (se houver):

   kubectl describe pod <pod-name>

2. Se permitido em seu ambiente, execute o pod e inspecione as interfaces (por exemplo, ifconfig ou ip addr) para confirmar se o pod tem as interfaces esperadas (eth0, net1, …) e endereços IP.