Questo documento descrive come configurare Google Distributed Cloud per fornire più interfacce di rete, multi-NIC, per i tuoi pod. La funzionalità con più NIC per i pod può aiutare a separare il traffico del piano di controllo da quello del piano dati, creando l'isolamento tra i piani. Le interfacce di rete aggiuntive abilitano anche la funzionalità multicast per i pod. I NIC multipli per i pod sono supportati per i cluster utente, i cluster ibridi e i cluster autonomi. Non è consentito per cluster di tipo amministratore.
L'isolamento del piano di rete è importante per i sistemi che utilizzano virtualizzazioni delle funzioni di rete (NFV), come il networking software-defined in una Wide Area Network (SD-WAN), un Cloud Access Security Broker (CASB) e firewall di nuova generazione (NG-FW). Questi tipi di NFV si basano sull'accesso a più interfacce per mantenere separati il piano di gestione e il piano dati durante l'esecuzione come container.
La configurazione con più interfacce di rete supporta l'associazione di interfacce di rete con pool di nodi, il che può offrire vantaggi in termini di prestazioni. I cluster possono contenere una combinazione di tipi di nodi. Quando raggruppi macchine ad alte prestazioni in un pool di nodi, puoi aggiungere altre interfacce al pool di nodi per migliorare il flusso di traffico.
Configurazione di più interfacce di rete
In genere, la configurazione di più interfacce di rete per i tuoi pod richiede tre passaggi:
Abilita più NIC per il tuo cluster con il campo
multipleNetworkInterfacesnella risorsa personalizzata del cluster.Specifica le interfacce di rete con
NetworkAttachmentDefinitionrisorse personalizzate.Assegna le interfacce di rete ai pod con l'annotazione
k8s.v1.cni.cncf.io/networks.
Vengono fornite informazioni aggiuntive per aiutarti a configurare e utilizzare la funzione multi-NIC nel modo più adatto alle tue esigenze di rete.
Attiva più NIC
Abilita più NIC per i tuoi pod aggiungendo il campo multipleNetworkInterfaces alla sezione clusterNetwork della risorsa personalizzata del cluster e impostandolo su true.
...
clusterNetwork:
multipleNetworkInterfaces: true
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/20
...
Specifica le interfacce di rete
Utilizza le risorse personalizzate di NetworkAttachmentDefinition per specificare interfacce di rete aggiuntive. Le risorse personalizzate NetworkAttachmentDefinition corrispondono alle
reti disponibili per i pod. Puoi specificare le risorse personalizzate all'interno della configurazione del cluster, come mostrato nell'esempio seguente, oppure puoi creare direttamente le risorse personalizzate NetworkAttachmentDefinition.
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: my-cluster
namespace: cluster-my-cluster
spec:
type: user
clusterNetwork:
multipleNetworkInterfaces: true
...
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-1
namespace: cluster-my-cluster
spec:
config: '{
"cniVersion":"0.3.0",
"type": "ipvlan",
"master": "enp2342", # defines the node interface that this pod interface would
map to.
"mode": "l2",
"ipam": {
"type": "whereabouts",
"range": "172.120.0.0/24"
}
}'
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: gke-network-2
namespace: cluster-my-cluster
spec:
config: '{
"cniVersion":"0.3.0",
"type": "macvlan",
"mode": "bridge",
"master": "vlan102",
"ipam": {
"type": "static",
"addresses": [
{
"address": "10.10.0.1/24",
"gateway": "10.10.0.254"
}
],
"routes": [
{ "dst": "192.168.0.0/16", "gw": "10.10.5.1" }
]
}
}'
Se specifichi la risorsa personalizzata NetworkAttachmentDefinition nel file di configurazione del cluster, Google Distributed Cloud utilizza questo nome per controllare la risorsa personalizzata NetworkAttachmentDefinition dopo la creazione del cluster.
Google Distributed Cloud considera questa risorsa personalizzata all'interno dello spazio dei nomi del cluster
come origine attendibile e la riconcilia con lo spazio dei nomi default del
cluster di destinazione.
Il seguente diagramma illustra il modo in cui Google Distributed Cloud riconcilia
le risorse personalizzate NetworkAttachmentDefinition dallo spazio dei nomi specifico
del cluster allo spazio dei nomi default.
Sebbene sia facoltativo, ti consigliamo di specificare in questo modo NetworkAttachmentDefinition risorse personalizzate durante la creazione del cluster. I cluster utente sono più utili quando specifichi le risorse personalizzate
durante la creazione del cluster, perché puoi controllare le
NetworkAttachmentDefinition risorse personalizzate dal cluster di amministrazione.
Se scegli di non specificare NetworkAttachmentDefinition risorse personalizzate durante la creazione del cluster, puoi aggiungere NetworkAttachmentDefinition risorse personalizzate direttamente a un cluster di destinazione esistente. Google Distributed Cloud riconcilia NetworkAttachmentDefinition risorse personalizzate definite nello spazio dei nomi del cluster. La riconciliazione avviene anche al momento dell'eliminazione. Quando una risorsa personalizzata NetworkAttachmentDefinition viene rimossa dallo spazio dei nomi del cluster, Google Distributed Cloud rimuove la risorsa personalizzata dal cluster di destinazione.
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 di una risorsa personalizzata NetworkAttachmentDefinition, separati da una
barra (/).
---
apiVersion: v1
kind: Pod
metadata:
name: samplepod
annotations:
k8s.v1.cni.cncf.io/networks: NAMESPACE/NAD_NAME
spec:
containers:
...
Sostituisci quanto segue:
NAMESPACE: lo spazio dei nomi. Utilizzadefaultper lo spazio dei nomi predefinito, che è standard. Per un'eccezione, vedi Problemi di sicurezza.NAD_NAME: il nome della risorsa personalizzataNetworkAttachmentDefinition.
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 risorse personalizzate NetworkAttachmentDefinition, gke-network-1 e gke-network-2, nello spazio dei nomi predefinito del cluster di destinazione.
---
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 pool di nodi
Utilizza l'annotazione k8s.v1.cni.cncf.io/nodeSelector per specificare il pool di nodi per cui è valida una risorsa personalizzata NetworkAttachmentDefinition.
Google Distributed Cloud forza il deployment di tutti i pod che fanno riferimento a questa risorsa personalizzata
su quei nodi specifici. Nell'esempio seguente, Google Distributed Cloud forza il deployment di tutti i pod a cui è assegnata l'interfaccia di rete gke-network-1 al pool di nodi multinicNP.
Google Distributed Cloud etichetta un pool di nodi con
l'etichetta baremetal.cluster.gke.io/node-pool di conseguenza.
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
annotations:
k8s.v1.cni.cncf.io/nodeSelector: baremetal.cluster.gke.io/node-pool=multinicNP
name: gke-network-1
spec:
...
Non puoi utilizzare solo le etichette standard. Puoi creare pool personalizzati dai nodi del cluster applicando un'etichetta personalizzata.
Utilizza il comando kubectl label nodes per applicare un'etichetta personalizzata:
kubectl 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 nome dell'etichetta.
Una volta che il nodo è stato etichettato, applica
l'annotazione baremetal.cluster.gke.io/label-taint-no-sync al nodo per
impedire a Google Distributed Cloud di riconciliare le etichette. Utilizza il comando kubectl get nodes --show-labels per verificare se un nodo è etichettato.
Problemi di sicurezza
Una risorsa personalizzata NetworkAttachmentDefinition fornisce accesso completo a una rete, quindi gli amministratori di cluster devono prestare attenzione quando fornire l'accesso per creazione, aggiornamento o eliminazione ad altri utenti. Se una determinata risorsa personalizzata NetworkAttachmentDefinition deve essere isolata, può essere inserita in uno spazio dei nomi non predefinito da cui solo i pod provenienti da tale spazio dei nomi possono accedervi. Per riconciliare NetworkAttachmentDefinition risorse personalizzate specificate nel file di configurazione del cluster, queste vengono sempre inserite nello spazio dei nomi predefinito.
Nel diagramma seguente, i pod dello spazio dei nomi default non possono accedere all'interfaccia di rete nello spazio dei nomi privileged.
Plug-in CNI supportati
In questa sezione sono elencati i plug-in CNI supportati dalla funzionalità multi-NIC per Google Distributed Cloud. Usa solo i
plug-in seguenti quando specifichi una risorsa personalizzata
NetworkAttachmentDefinition.
Creazione dell'interfaccia:
ipvlanmacvlanbridgesriov
Meta-plug-in:
portmapsbrtuning
Plug-in IPAM:
host-localstaticwhereabouts
Configurazione route
Un pod con una o più risorse personalizzate NetworkAttachmentDefinition assegnate
ha più interfacce di rete. Per impostazione predefinita, in questa situazione la tabella di routing
viene estesa con le interfacce aggiuntive disponibili localmente solo dalle risorse personalizzate
NetworkAttachmentDefinition assegnate. Il gateway predefinito è ancora configurato per utilizzare l'interfaccia master/predefinita del pod, eth0.
Puoi modificare questo comportamento utilizzando i seguenti plug-in CNI:
sbrstaticwhereabouts
Ad esempio, potresti volere che tutto il traffico passi attraverso il gateway predefinito, ovvero l'interfaccia predefinita. Tuttavia, una parte del traffico specifico passa da una delle interfacce non predefinite. Può essere difficile distinguere il traffico in base all'IP di destinazione (routing normale), poiché 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 della risorsa personalizzata NetworkAttachmentDefinition per l'IP di origine, i pacchetti vengono inseriti nella tabella di routing aggiuntiva configurata da sbr. La tabella di routing sbr stabilisce l'interfaccia della risorsa personalizzata NetworkAttachmentDefinition come gateway predefinito. L'IP del gateway predefinito all'interno della tabella è controllato
con il campo gateway all'interno dei plug-in whereabouts o static. Fornisci il plug-in sbr 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 l'impostazione "gateway":"21.0.111.254" in whereabouts e
sbr impostata 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 di localizzazione
Il plug-in whereabouts è fondamentalmente un'estensione del plug-in static e
questi due condividono la configurazione del routing. Per un esempio di configurazione, consulta la pagina sul plug-in per la 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" }] nella risorsa personalizzata 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.
Singolo collegamento di rete utilizzato da più pod
Più collegamenti di rete utilizzati da un 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
Risolvere i problemi
Se altre interfacce di rete non sono configurate correttamente, i pod a cui vengono assegnate non si avviano. Questa sezione illustra come trovare informazioni per la risoluzione dei problemi relativi alla funzione 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 Places e Multus nelle seguenti posizioni:
/var/log/whereabouts.log/var/log/multus.log
Rivedi le interfacce dei pod
Usa il comando kubectl exec per verificare le interfacce dei tuoi pod. Una volta applicate correttamente le NetworkAttachmentDefinition risorse personalizzate, le interfacce dei pod hanno il seguente output:
$ 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 stato del pod
Usa l'kubectl get per recuperare lo stato di 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