Questo documento descrive come configurare Google Distributed Cloud (solo software) per VMware per fornire più interfacce di rete, multi-NIC, per i tuoi pod. La la funzionalità multi-NIC per i pod può aiutare a separare il traffico del piano di controllo dai dati il traffico dei piani, creando isolamento tra i piani. Interfacce di rete aggiuntive abilitare la funzionalità multicast per i pod. La configurazione Multi-NIC per i pod è supportata per i cluster utente, ma non è consentita per i cluster di amministrazione.
Questa pagina è rivolta agli esperti di reti che installano, configurano e supportano le apparecchiature di rete. Per saperne di più sui ruoli comuni e sulle attività di esempio che nei contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.
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 rete 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 il piano di controllo e il piano dati separati.
La configurazione con più interfacce di rete supporta l'associazione delle interfacce di rete con i 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 pool di nodi, puoi creare interfacce aggiuntive per il pool di nodi per migliorare il flusso di traffico.
Configurare più interfacce di rete
In genere, la configurazione di più interfacce di rete per i pod prevede tre passaggi:
Attiva la multi-NIC per il cluster di utenti utilizzando i campi
multipleNetworkInterfaceseenableDataplaneV2nel file di configurazione del cluster.Specifica le interfacce di rete con la sezione
additionalNodeInterfacesnel file di configurazione del cluster e crea una o più risorse personalizzateNetworkAttachmentDefinition.Assegna le interfacce di rete ai pod con l'annotazione
k8s.v1.cni.cncf.io/networks.
Attiva più NIC
Attiva la multi-NIC per i 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 specificare interfacce di rete aggiuntive. I NetworkAttachmentDefinitions corrispondono 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
Assegnare 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 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 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 in NetworkAttachmentDefinition e forza il deployment di tutti i pod a cui la rete gke-network-1 è assegnata ai nodi che hanno 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 l'accesso completo a una rete, pertanto gli amministratori del cluster devono prestare attenzione a fornire l'accesso in fase di creazione, aggiornamento o eliminazione ad altri utenti. Se un determinato NetworkAttachmentDefinition deve essere isolato, puoi specificare uno spazio dei nomi non predefinito durante la creazione, a cui possono accedere solo i pod di quel determinato spazio dei nomi.
Nel seguente diagramma, i pod dello spazio dei nomi default non possono accedere all'interfaccia di rete nello spazio dei nomi privileged.
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:
ipvlanmacvlanbridge
Meta-plug-in:
portmapsbrtuning
Plug-in IPAM:
host-localstaticwhereabouts
Configurazione del route
Un pod a cui sono assegnati uno o più NetworkAttachmentDefinitions ha più interfacce di rete. Per impostazione predefinita, in questa situazione la tabella di routing del pod viene estesa con le interfacce aggiuntive disponibili localmente solo dalle interfacce NetworkAttachmentDefinitions assegnate. 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:
sbrstaticwhereabouts
Ad esempio, potresti voler far passare la maggior parte del traffico attraverso il gateway predefinito, il che significa che il traffico passerà per l'interfaccia di rete predefinita. Tuttavia, vuoi che una parte del traffico specifico vada a 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 utile.
Plug-in SBR
Il plug-in sbr consente all'applicazione di controllare le decisioni di routing. L'applicazione controlla quale viene utilizzato come indirizzo IP di origine della connessione che stabilisce. Se l'applicazione sceglie di utilizzare l'indirizzo IP di NetworkAttachmentDefinition come IP di origine, i pacchetti vengono inviati alla tabella di routing aggiuntiva impostata da sbr. La tabella di routing sbr invia il traffico attraverso il proprio gateway predefinito, che andrà sull'interfaccia di NetworkAttachmentDefinition. L'IP del gateway predefinito all'interno di quella 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 ulteriori informazioni sul plug-in sbr, incluse le informazioni sull'utilizzo, consulta la pagina relativa al 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 in catena 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 di localizzazione
Fondamentalmente, il plug-in whereabouts è un'estensione del plug-in static e entrambi condividono la configurazione del 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 in questo modo il gateway predefinito del pod.
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.
Un unico collegamento di rete utilizzato da più pod:
Più collegamenti di rete utilizzati da un singolo pod:
Più dispositivi di rete collegati alla stessa interfaccia utilizzata da un singolo pod:
Stessa associazione alla rete utilizzata 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 vengono avviati. Questa sezione illustra 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 Whereabout e Multus nelle seguenti località:
/var/log/whereabouts.log/var/log/multus.log
Esamina le interfacce del pod
Utilizza il comando kubectl exec per controllare le interfacce dei pod. Una volta applicati correttamente i NetworkAttachmentDefinitions, le interfacce del pod hanno il seguente aspetto:
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
Recupera stato pod
Utilizza 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