Collegamento di più VNIC secondarie per il networking pod

Passo 1: verificare i nomi delle risorse estese e la capacità su un nodo

Dopo che il pool di nodi dispone di nodi di lavoro, verificare i nomi e la capacità delle risorse estese in un nodo.

1. Esaminare le risorse estese pubblicate dal nodo:

   kubectl describe node <node-name>

2. Nella sezione Capacity dell'output, identificare le Risorse Estese corrispondenti alle Risorse dell'applicazione (ad esempio oke-application-resource.oci.oraclecloud.com/frontend) e confermare di avere una capacità diversa da zero.

I nodi che espongono le risorse dell'applicazione vengono contaminati con oci.oraclecloud.com/application-resource-only:NoSchedule per impedire che i pod senza richieste esplicite delle risorse dell'applicazione arrivino su di essi.

Aggiungere una tolleranza corrispondente alla specifica pod (in spec.tolerations per un pod o in spec.template.spec.tolerations in una distribuzione):

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

Senza questa tolleranza, lo scheduler rifiuterà il posizionamento anche se la capacità delle risorse esiste.

Nella specifica pod, richiedere la risorsa estesa che corrisponde al profilo VNIC secondario che il pod deve utilizzare (ad esempio, in una distribuzione all'indirizzo spec.template.spec.containers[].resources). Richiedere e limitare esattamente un'unità in modo che lo scheduler riserva la capacità in modo coerente.

Ad esempio:

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

Passo 4: (facoltativo) indirizzare i pool di nodi corretti

Se l'organizzazione utilizza un'etichetta di nodo o una convenzione di selezione per questi nodi (ad esempio, gva_vnic: "yes"), includerlo in modo che i pod non vengano posizionati nei pool di nodi che non dispongono delle risorse necessarie:

nodeSelector:
  gva_vnic: "yes"

NodeSelector è facoltativo quando le richieste e le tolleranze delle risorse dell'applicazione vincolano già la pianificazione. Utilizzare un nodeSelector solo se i nodi di destinazione sono stati etichettati (ad esempio tramite le etichette Kubernetes del pool di nodi).

Dopo la distribuzione:

1. Inserisci:

   kubectl get pods -o wide

2. Per un pod di interesse, immettere:

   kubectl describe pod <pod-name>

3. Verificare che il pod sia in esecuzione e che non vi siano errori di pianificazione (ad esempio, capacità insufficiente per la risorsa richiesta).

Installare Multus prima di creare NAD o distribuire pod multi-interfaccia. Per informazioni sull'installazione di Multus, consultare la documentazione di Multus-CNI su GitHub.

Seguire il processo standard dell'organizzazione per la distribuzione di Multus, quindi verificare che sia in buono stato:

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

Gli esempi in questa sezione utilizzano il plugin CNI ipvlan per l'interfaccia pod aggiuntiva. Assicurarsi che il file binario ipvlan sia presente in /opt/cni/bin/ipvlan su ogni nodo di lavoro in grado di eseguire pod multi-interfaccia.

Oracle consiglia di installare il plugin ipvlan utilizzando uno script di inizializzazione cloud del pool di nodi in modo che il plugin venga installato quando i nodi vengono creati, sostituiti o sottoposti a scale out. Apporre il plugin a una release convalidata per l'ambiente di destinazione, anziché seguire un percorso di download mobile. Nell'esempio seguente viene utilizzata la versione v1.9.0.

Ad esempio:

#!/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 i nodi di lavoro non possono accedere a GitHub, posizionare nell'area intermedia l'archivio dei plugin CNI richiesto nello storage degli oggetti OCI o in un'altra posizione interna approvata e aggiornare l'URL di download nello script di inizializzazione cloud.

I NAD devono essere indirizzati ai nomi effettivi dell'interfaccia host creati dalle VNIC collegate (ad esempio, enp1s0, enp2s0). Verificarli in un nodo di lavoro utilizzando il metodo di accesso standard dell'organizzazione.

Crea:

• un NAD per la rete pod predefinita (per controllare quale interfaccia host esegue il backup di eth0)
• uno o più NAD per interfacce aggiuntive (ad esempio, net1).

La configurazione NAD consente di selezionare un dispositivo utilizzando un deviceSelector (ad esempio, interfaceName o il nome della risorsa applicazione utilizzando appResource se supportato nell'ambiente in uso).

I seguenti esempi NAD utilizzano intenzionalmente spazi di nomi diversi. oci-vcn-native-network è definito in kube-system, mentre ipvlan-network è definito in default. Se il carico di lavoro viene eseguito in un altro spazio di nomi, creare ipvlan-network nello spazio di nomi o aggiornare l'annotazione pod per fare riferimento al nome NAD completamente qualificato.

Il NAD di rete predefinito è collegato a 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
        }
      ]
    }

Il NAD della rete secondaria è stato collegato a enp2s0:

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

Il NAD predefinito utilizza i plugin oci-ipvlan e oci-ptp specifici di OCI perché tale interfaccia partecipa al percorso di rete predefinito nativo per la VCN OKE. Il NAD aggiuntivo utilizza il plugin ipvlan standard perché Multus collega un'interfaccia aggiuntiva su una NIC host specifica, mentre OCI IPAM fornisce ancora l'allocazione IP dipendente dalla subnet.

deviceSelector può indirizzare interfacce con campi quali:

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

Il blocco deviceSelector consente all'IPAM OCI di scegliere l'interfaccia di destinazione o la VNIC utilizzata per l'allocazione dell'IP pod. È possibile selezionare un dispositivo utilizzando uno o più dei seguenti campi:

• appResource: seleziona il profilo VNIC GVA in base al nome della risorsa applicazione.

• interfaceName: seleziona un'interfaccia host specifica, ad esempio enp1s0.

• interfaceNamePrefix: seleziona un'interfaccia in base al prefisso, ad esempio enp.

• macAddress: seleziona un'interfaccia in base all'indirizzo MAC.

Quando appResource è impostato nel selettore di dispositivi NAD, il plugin IPAM OCI utilizza tale risorsa applicazione per decidere quale profilo VNIC GVA deve fornire l'indirizzo IP pod e fungere da dispositivo padre per tale interfaccia. Ciò consente a diversi NAD nello stesso pod di eseguire il mapping a diversi profili VNIC, ad esempio:

• NAD1 -> Application Resource: vnic-a

• NAD2 -> Application Resource: vnic-b

• NAD3 -> Application Resource: vnic-c

Se un pod utilizza tutti e tre i NAD, ogni interfaccia può essere collegata tramite il profilo VNIC corrispondente.

Negli esempi di nome interfaccia mostrati in questo documento:

• Il NAD oci-vcn-native-network utilizza interfaceName: enp1s0 in modo che OCI IPAM allochi l'IP di rete predefinito del pod dall'interfaccia enp1s0 dell'host.

• Il NAD ipvlan-network utilizza interfaceName: enp2s0 in modo che l'IPAM OCI allochi l'IP di interfaccia aggiuntivo dall'interfaccia enp2s0 dell'host.

Questo è anche il motivo per cui l'esempio pod imposta:

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

L'annotazione v1.multus-cni.io/default-network garantisce che eth0 utilizzi il NAD oci-vcn-native-network. Senza selezionare esplicitamente quella rete predefinita, OCI IPAM può eseguire l'allocazione da qualsiasi interfaccia host idonea, il che rende l'interfaccia pod primaria meno prevedibile. L'impostazione del NAD predefinito garantisce che eth0 utilizzi l'interfaccia prevista e la mantenga isolata dal collegamento di rete aggiuntivo.

Non combinare queste annotazioni pod Multus con richieste di risorse applicative a livello di pod nella stessa specifica pod. Se un pod multi-interfaccia richiede la selezione della VNIC GVA, definire tale selezione all'interno della configurazione NAD deviceSelector.appResource per ogni interfaccia invece di utilizzare una richiesta di risorse applicative a livello di pod.

Applicare i NAD:

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

kubectl apply -f ipvlan-network.yaml

Annotare il pod per selezionare il NAD di rete predefinito e collegare NAD di rete aggiuntivi, ad esempio:

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

1. Descrivere il pod e controllare le annotazioni sullo stato della rete Multus (se presenti):

   kubectl describe pod <pod-name>

2. Se consentito nell'ambiente, eseguire il pod e ispezionare le interfacce (ad esempio, ifconfig o ip addr) per confermare che il pod dispone delle interfacce previste (eth0, net1, …) e degli indirizzi IP.