Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Configurazione di più interfacce di rete per i pod

Più interfacce di rete (multi-NIC) per i pod in Google Distributed Cloud (solo software) per VMware consentono di separare il traffico del control plane da quello del piano dati. La funzionalità multi-NIC per i pod è supportata per i cluster utente, ma non per i cluster di amministrazione. Questo documento mostra come attivare multi-NIC, specificare interfacce di rete aggiuntive, assegnarle ai pod e risolvere i problemi di configurazione.

Informazioni su multi-NIC per i pod

L'isolamento del piano di rete è importante per i sistemi che utilizzano la virtualizzazione delle funzioni di rete (NFV), come il networking software-defined in una wide area network (SD-WAN), un Cloud Access Security Broker (CASB) e i firewall di nuova generazione (NG-FW). Questi tipi di NFV si basano sull'accesso a più interfacce per mantenere separati i control plane e i piani dati.

La configurazione di più interfacce di rete supporta l'associazione di interfacce di rete ai pool di nodi, il che può offrire 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 unico pool di nodi, puoi creare interfacce aggiuntive per il pool di nodi per migliorare il flusso di traffico.

Configura più interfacce di rete

In genere, la configurazione di più interfacce di rete per i pod prevede tre passaggi:

Abilita multi-NIC per il tuo cluster utente utilizzando i campi multipleNetworkInterfaces e enableDataplaneV2 nel file di configurazione del cluster.
Specifica le interfacce di rete con la sezione additionalNodeInterfaces nel file di configurazione del cluster e crea una o più risorse personalizzate NetworkAttachmentDefinition.
Assegna interfacce di rete ai pod con l'annotazione k8s.v1.cni.cncf.io/networks.

Abilita multi-NIC

Attiva la funzionalità multi-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 interfacce di rete dei nodi aggiuntive nella sezione additionalNodeInterfaces.

Ad esempio, ecco una parte di un file di configurazione del cluster utente che mostra un'interfaccia di rete dei nodi 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. NetworkAttachmentDefinitions corrisponde alle reti disponibili per i tuoi pod. L'esempio seguente mostra un manifest per un 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 NetworkAttachmentDefinition:

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

Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

Assegna 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, al pod samplepod sono assegnate due interfacce di rete. Le interfacce di rete sono specificate dai nomi di due NetworkAttachmentDefinitions, gke-network-1 e gke-network-2, creati nello spazio dei nomi 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 insieme di nodi.

Puoi raggruppare i nodi del cluster utilizzando l'etichetta standard assegnata al nodo o la tua etichetta personalizzata. Puoi quindi specificare l'etichetta del nodo nel manifest NetworkAttachmentDefinition utilizzando l'annotazione k8s.v1.cni.cncf.io/nodeSelector. Google Distributed Cloud forza il deployment di tutti i pod che fanno riferimento a questa risorsa personalizzata sui nodi che hanno 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 sui 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:

USER_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster utente.
NODE_NAME: il nome del nodo a cui stai applicando l'etichetta.
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 l'accesso completo a una rete, quindi gli amministratori del cluster devono prestare attenzione nel fornire l'accesso per la creazione, l'aggiornamento o l'eliminazione ad altri utenti. Se un determinato NetworkAttachmentDefinition deve essere isolato, puoi specificare uno spazio dei nomi non predefinito durante la creazione, in modo che solo i pod di quello spazio dei nomi possano accedervi.

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

Utilizzo di spazi dei nomi per isolare il traffico di rete.

Plug-in CNI supportati

Questa sezione elenca i plug-in CNI supportati dalla funzionalità multi-NIC per Google Distributed Cloud. Utilizza solo i seguenti plug-in quando specifichi un NetworkAttachmentDefinition.

Creazione dell'interfaccia:

ipvlan
macvlan
bridge

Plug-in Meta:

portmap
sbr
tuning

Plug-in IPAM:

host-local
static
whereabouts

Configurazione della route

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

sbr
static
whereabouts

Ad esempio, potresti voler indirizzare la maggior parte del traffico attraverso il gateway predefinito, il che significa che il traffico passerà attraverso l'interfaccia di rete predefinita. Tuttavia, vuoi che un traffico specifico passi attraverso una delle interfacce non predefinite. Può essere difficile disambiguare il traffico 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 di routing. L'applicazione controlla ciò che viene utilizzato come indirizzo IP di origine della connessione che stabilisce. Quando l'applicazione sceglie di utilizzare l'indirizzo IP di NetworkAttachmentDefinition come IP di origine, i pacchetti vengono inseriti nella tabella di routing aggiuntiva configurata da sbr. La tabella di routing sbr invia il traffico tramite il proprio gateway predefinito, che passerà attraverso l'interfaccia di NetworkAttachmentDefinition. L'IP del 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, consulta Plug-in di routing basato sull'origine.

L'esempio seguente mostra "gateway":"21.0.111.254" impostato in whereabouts e sbr impostato come plug-in concatenato dopo 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 Whereabouts

Il plug-in whereabouts è fondamentalmente un'estensione del plug-in static e i due 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:

Singolo collegamento di rete utilizzato da più pod.

Più collegamenti di rete utilizzati da un singolo pod:

Più collegamenti di rete utilizzati da un singolo pod.

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

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

Lo stesso collegamento di rete viene utilizzato più volte da un singolo pod:

Lo stesso collegamento di rete è stato utilizzato più volte da un singolo pod.

Risoluzione dei problemi

Se le interfacce di rete aggiuntive non sono configurate correttamente, i pod a cui sono assegnate non si avviano. Questa sezione spiega come trovare informazioni per la risoluzione dei problemi relativi alla funzionalità multi-NIC.

Controlla gli eventi dei pod

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

kubectl describe pod POD_NAME

Controlla i log

Per ogni nodo, puoi trovare i log di Whereabouts e Multus nelle seguenti posizioni:

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

Interfacce di Review Pod

Utilizza il comando kubectl exec per controllare le interfacce dei pod. Una volta applicati correttamente i NetworkAttachmentDefinitions, le interfacce dei pod hanno un aspetto simile al 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 il comando kubectl get per recuperare lo stato della rete per un determinato pod:

kubectl get pods POD_NAME -oyaml

Ecco 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

Configurazione di più interfacce di rete per i pod Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.