Configurazione di più interfacce di rete per i pod

Questo documento descrive come configurare Cluster Anthos su VMware (GKE On-Prem) per fornire più interfacce di rete, multi-NIC, per i tuoi pod. La funzionalità NIC per pod può aiutare a separare il traffico del piano di controllo da quello del piano dati, creando l'isolamento tra i piani. Anche le interfacce di rete aggiuntive abilitano la funzionalità multicast per i tuoi pod. Multi-NIC per i pod è supportato per i cluster utente, non è consentito per i cluster di amministrazione.

L'isolamento del piano di rete è importante per i sistemi che utilizzano le virtualizzazione delle funzioni di rete (NFV), come il networking software-defined in a wide area network (SD-WAN), un cloud access security broker (CASB) e i firewall di nuova generazione (NG-FW). Questi tipi di video nel formato breve si basano sull'accesso a più interfacce per mantenere separati il piano di controllo e quello dei dati.

La configurazione con più interfacce di rete supporta l'associazione delle interfacce di rete a pool di nodi, il che può fornire vantaggi in termini di prestazioni. Ad esempio, un cluster può contenere una combinazione di tipi di nodi. Quando raggruppi macchine ad alte prestazioni in un pool di nodi, puoi creare interfacce aggiuntive al pool di nodi per migliorare il flusso del traffico.

Configurare più interfacce di rete

In genere, i passaggi per configurare più interfacce di rete per i pod prevedono tre passaggi:

  1. Attiva più NIC per il tuo cluster utente utilizzando i campi multipleNetworkInterfaces e enableDataplaneV2 nel file di configurazione del cluster.

  2. Specifica le interfacce di rete con la sezione additionalNodeInterfaces nel file di configurazione del cluster e crea una o più risorse personalizzate (NetworkAttachmentDefinition).

  3. Assegna le interfacce di rete ai pod con l'annotazione k8s.v1.cni.cncf.io/networks.

Attiva più NIC

Attiva più NIC per i tuoi pod impostando i campi multipleNetworkInterfaces e enableDataplaneV2 nel file di configurazione del cluster utente su true.

apiVersion: v1
multipleNetworkInterfaces: true
enableDataplaneV2: true
  ...

Specifica le interfacce di rete

Nel file di configurazione del cluster, specifica altre interfacce di rete dei nodi nella sezione additionalNodeInterfaces.

Ad esempio, ecco una parte di un file di configurazione del cluster utente che mostra un'interfaccia di rete nodo aggiuntiva:

apiVersion: v1
multipleNetworkInterfaces: true
enableDataplaneV2: true
network:
  serviceCIDR: "10.96.0.0/20"
  podCIDR: "192.168.0.0/16"
  vCenter:
    networkName: network-private310
  ...
  # New multiple network configs
  additionalNodeInterfaces:
  - networkName: "gke-network-1"
    ipBlockFilePath: "my-block-yaml"
    type: static

Dopo aver creato un cluster con la configurazione precedente, devi creare una o più risorse personalizzate NetworkAttachmentDefinition (NAD) nel cluster utente, in cui specifichi interfacce di rete aggiuntive. Il NetworkAttachmentDefinitions corrisponde alle reti disponibili per i tuoi pod. L'esempio seguente mostra un manifest per NetworkAttachmentDefinition:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: default
spec:
  config: '{
  "cniVersion":"0.3.0",
  "type": "ipvlan",
  "master": "ens224", # defines the node interface that this Pod interface would map to
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.16.0.0/24"
   }
}'

Salva il manifest come file YAML, ad esempio my-nad.yaml, e crea il NetworkAttachmentDefinition:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f my-nad.yaml

Assegna le interfacce di rete a un pod

Utilizza l'annotazione k8s.v1.cni.cncf.io/networks per assegnare una o più interfacce di rete a un pod. Ogni interfaccia di rete è specificata con uno spazio dei nomi e il nome di un NetworkAttachmentDefinition, separati da una barra (/). Utilizza un elenco separato da virgole per specificare più interfacce di rete.

Nell'esempio seguente, due interfacce di rete sono assegnate al pod samplepod. Le interfacce di rete sono specificate dai nomi di due NetworkAttachmentDefinitions, gke-network-1 e gke-network-2 creati nello spazio dei nomi di default.

---
apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: default/gke-network-1,default/gke-network-2
spec:
  containers:
  ...

Limita le interfacce di rete a un insieme di nodi

Se non vuoi che un NetworkAttachmentDefinition sia applicabile a un intero cluster, puoi limitarne la funzionalità a un set di nodi.

Puoi raggruppare i nodi del cluster utilizzando l'etichetta standard assegnata al nodo o alla tua etichetta personalizzata. Puoi quindi specificare l'etichetta del nodo nel manifest NetworkAttachmentDefinition utilizzando l'annotazione k8s.v1.cni.cncf.io/nodeSelector. Cluster Anthos su VMware forza il deployment di qualsiasi pod che fa riferimento a questa risorsa personalizzata sui nodi con questa etichetta.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/nodeSelector: LABEL_KEY=LABEL_VALUE
  name: gke-network-1
spec:
...

L'esempio seguente mostra l'etichetta my-label=multinicNP indicata su NetworkAttachmentDefinition e forza il deployment di tutti i pod a cui è assegnata la rete gke-network-1 ai nodi con questa etichetta.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    k8s.v1.cni.cncf.io/nodeSelector: my-label=multinicNP
  name: gke-network-1
spec:
...

Per applicare un'etichetta personalizzata a un nodo, utilizza il comando kubectl label nodes:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Sostituisci quanto segue:

  • NODE_NAME: il nome del nodo che stai etichettando.
  • LABEL_KEY: la chiave da utilizzare per l'etichetta.
  • LABEL_VALUE: il valore dell'etichetta.

In questo esempio, al nodo my-node viene assegnata l'etichetta environment=production:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] label nodes my-node environment=production

Problemi di sicurezza

Un NetworkAttachmentDefinition fornisce accesso completo a una rete, quindi gli amministratori del cluster devono essere cauti quando forniscono accesso di creazione, aggiornamento o eliminazione ad altri utenti. Se un NetworkAttachmentDefinition specifico deve essere isolato, puoi specificare uno spazio dei nomi non predefinito quando lo crei, dove solo i pod di questo spazio dei nomi possono accedere.

Nel seguente diagramma, i pod dello spazio dei nomi default non possono accedere all'interfaccia di rete nello spazio dei nomi privileged.

Utilizzo degli spazi dei nomi per isolare il traffico di rete

Plug-in CNI supportati

In questa sezione sono elencati i plug-in del CNI supportati dalla funzionalità multi-NIC per Cluster Anthos su VMware. Per specificare un NetworkAttachmentDefinition, utilizza solo i seguenti plug-in.

Creazione dell'interfaccia:

  • ipvlan
  • macvlan
  • bridge

Plug-in Meta:

  • portmap
  • sbr
  • tuning

Plug-in IPAM:

  • host-local
  • static
  • whereabouts

Configurazione delle route

Un pod a cui sono assegnati uno o più elementi NetworkAttachmentDefinitions ha più interfacce di rete. Per impostazione predefinita, la tabella di routing del pod in questa situazione viene estesa con le interfacce aggiuntive disponibili localmente solo di NetworkAttachmentDefinitions. I pacchetti associati al gateway predefinito sono ancora configurati per l'utilizzo dell'interfaccia predefinita del pod eth0. Puoi modificare questo comportamento utilizzando i seguenti plug-in CNI:

  • sbr
  • static
  • whereabouts

Ad esempio, potresti volere che la maggior parte del traffico passi attraverso il gateway predefinito, il che significa che il traffico passa attraverso l'interfaccia di rete predefinita. Tuttavia, vuoi che una parte del traffico specifico passi su una delle interfacce non predefinite. Il traffico può essere difficile da distinguere in base all'IP di destinazione (routing normale), perché lo stesso endpoint è disponibile su entrambi i tipi di interfaccia. In questo caso, il routing basato sull'origine (SBR) può essere d'aiuto.

Plug-in SBR

Il plug-in sbr consente all'applicazione di controllare le decisioni relative al routing. L'applicazione controlla quale indirizzo viene utilizzato come indirizzo IP di origine della connessione che stabilisce. Quando l'applicazione sceglie di utilizzare l'indirizzo IP di NetworkAttachmentDefinition per il suo IP di origine, i pacchetti vengono inclusi nella tabella di routing aggiuntiva sbr configurata. La tabella di routing di sbr invia il traffico attraverso il proprio gateway predefinito, che passa sopra l'interfaccia di NetworkAttachmentDefinition. L'IP gateway predefinito all'interno della tabella è controllato con il campo gateway all'interno dei plug-in whereabouts o static. Il plug-in sbr viene eseguito come plug-in concatenato. Per saperne di più sul plug-in sbr, incluse le informazioni sull'utilizzo, vedi Plug-in di routing basato su origine.

L'esempio seguente mostra "gateway":"21.0.111.254" impostato in whereabouts e sbr impostato come plug-in concatenato dopo il giorno ipvlan:

# ip route
default via 192.168.0.64 dev eth0  mtu 1500
192.168.0.64 dev eth0 scope link
# ip route list table 100
default via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1

Plug-in statici e in cui è disponibile

Il plug-in whereabouts è essenzialmente un'estensione del plug-in static e condividono la configurazione di routing. Per un esempio di configurazione, consulta il plug-in di gestione degli indirizzi IP statici. Puoi definire un gateway e una route da aggiungere alla tabella di routing del pod. Tuttavia, non puoi modificare il gateway predefinito del pod in questo modo.

L'esempio seguente mostra l'aggiunta di "routes": [{ "dst": "172.31.0.0/16" }] in NetworkAttachmentDefinition:

# ip route
default via 192.168.0.64 dev eth0  mtu 1500
172.31.0.0/16 via 21.0.111.254 dev net1
21.0.104.0/21 dev net1 proto kernel scope link src 21.0.111.1
192.168.0.64 dev eth0 scope link

Esempi di configurazione

Questa sezione illustra alcune delle configurazioni di rete comuni supportate dalla funzionalità multi-NIC.

Collegamento di rete singolo utilizzato da più pod:

Collegamento di rete singolo utilizzato da più pod

Più collegamenti di rete utilizzati da un singolo pod:

Collegamenti di rete multipli utilizzati da un singolo pod

Più collegamenti di rete che puntano alla stessa interfaccia utilizzata dal singolo pod:

Più collegamenti di rete che puntano alla stessa interfaccia utilizzata da un singolo pod

Stesso collegamento di rete utilizzato più volte da un singolo pod:

Stesso collegamento di rete utilizzato più volte da un singolo pod

Risolvere i problemi

Se le interfacce di rete aggiuntive non sono configurate correttamente, i pod a cui sono assegnati non si avviano. Questa sezione mette in evidenza come trovare informazioni per la risoluzione dei problemi con la funzionalità multi-NIC.

Controlla gli eventi dei pod

Multus segnala errori tramite gli eventi del pod Kubernetes. Utilizza il comando kubectl describe seguente per visualizzare gli eventi per un determinato pod:

kubectl describe pod POD_NAME

Controlla i log

Per ciascun nodo, puoi trovare i log Luogo e Multus nelle seguenti località:

  • /var/log/whereabouts.log
  • /var/log/multus.log

Esamina le interfacce dei pod

Usa il comando kubectl exec per controllare le interfacce dei pod. Dopo aver applicato correttamente NetworkAttachmentDefinitions, le interfacce dei pod hanno il seguente output:

user@node1:~$ kubectl exec samplepod-5c6df74f66-5jgxs -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 00:50:56:82:3e:f0 brd ff:ff:ff:ff:ff:ff
    inet 21.0.103.112/21 scope global net1
       valid_lft forever preferred_lft forever
38: eth0@if39: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 36:23:79:a9:26:b3 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.2.191/32 scope global eth0
       valid_lft forever preferred_lft forever

Ottieni lo stato del pod

Utilizza kubectl get per recuperare lo stato della rete di un determinato pod:

kubectl get pods POD_NAME -oyaml

Di seguito è riportato un output di esempio che mostra lo stato di un pod con più reti:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "",
          "interface": "eth0",
          "ips": [
              "192.168.1.88"
          ],
          "mac": "36:0e:29:e7:42:ad",
          "default": true,
          "dns": {}
      },{
          "name": "default/gke-network-1",
          "interface": "net1",
          "ips": [
              "21.0.111.1"
          ],
          "mac": "00:50:56:82:a7:ab",
          "dns": {}
      }]
    k8s.v1.cni.cncf.io/networks: gke-network-1