Questo documento descrive come configurare Google Distributed Cloud per fornire più interfacce di rete, multi-NIC, per i tuoi pod. La funzionalità multi-NIC per pod può aiutare a separare il traffico del control plane da quello del piano dati, creando isolamento tra i piani. Le interfacce di rete aggiuntive abilitano anche la funzionalità multicast per i tuoi pod. NIC multiple per i pod sono supportate per i cluster utente, i cluster ibridi e i cluster autonomi. Non è consentito per i cluster di tipo amministratore.
Questa pagina è rivolta agli specialisti di networking che installano, configurano e supportano le apparecchiature di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta la pagina Ruoli e attività comuni degli utenti GKE.
L'isolamento del piano di rete è importante per i sistemi che utilizzano la virtualizzazione delle funzioni di rete (NFV), come le networking software-defined in una rete WAN (SD-WAN), un broker di sicurezza dell'accesso al cloud (CASB) e i firewall di nuova generazione (NG-FW). Questi tipi di NFV si basano sull'accesso a più interfacce per mantenere separati i piani di gestione e dati durante l'esecuzione come container.
La configurazione di più interfacce di rete supporta l'associazione di interfacce di rete a pool di nodi, il che può offrire vantaggi in termini di prestazioni. I cluster possono contenere un mix di tipi di nodi. Quando raggruppi macchine ad alte prestazioni in un unico pool di nodi, puoi aggiungere interfacce aggiuntive al 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:
Attiva più NIC per il cluster con il campo
multipleNetworkInterfaces
nella risorsa personalizzata del cluster.Specifica le interfacce di rete con risorse personalizzate
NetworkAttachmentDefinition
.Assegna interfacce di rete ai pod con l'annotazione
k8s.v1.cni.cncf.io/networks
.
Vengono fornite ulteriori informazioni per aiutarti a configurare e utilizzare la funzionalità multi-NIC nel modo più adatto alle tue esigenze di rete.
Attiva più NIC
Abilita più interfacce di rete 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 NetworkAttachmentDefinition
per specificare interfacce di rete aggiuntive. Le risorse personalizzate NetworkAttachmentDefinition
corrispondono alle
reti disponibili per i tuoi 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" }
]
}
}'
Quando 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 in che modo 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
NetworkAttachmentDefinition
le risorse personalizzate in questo modo durante la creazione del cluster. I cluster utente traggono il massimo vantaggio quando specifichi le risorse personalizzate
durante la creazione del cluster, perché puoi controllare le
risorse personalizzate NetworkAttachmentDefinition
dal cluster di amministrazione.
Se scegli di non specificare le risorse personalizzate NetworkAttachmentDefinition
durante la creazione del cluster, puoi aggiungere le risorse personalizzate NetworkAttachmentDefinition
direttamente a un cluster di destinazione esistente. Google Distributed Cloud
riconcilia le risorse personalizzate NetworkAttachmentDefinition
definite nello spazio dei nomi del cluster. Il riconciliamento avviene anche al momento dell'eliminazione. Quando una risorsa personalizzata NetworkAttachmentDefinition
viene rimossa da uno spazio dei nomi del cluster, Google Distributed Cloud la rimuove 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. Utilizzadefault
per lo spazio dei nomi predefinito, che è standard. Per un'eccezione, consulta la sezione 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:
...
Limitare le interfacce di rete a un NodePool
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 impone il deployment di tutti i pod che fanno riferimento a questa risorsa personalizzata su questi 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 NodePool multinicNP
.
Google Distributed Cloud etichetta un NodePool 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 sei limitato all'utilizzo delle etichette standard. Puoi creare pool personalizzati
dai nodi del cluster applicando un'etichetta personalizzata a questi nodi.
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 etichettato il nodo, applica l'annotazione
baremetal.cluster.gke.io/label-taint-no-sync
a quel 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 l'accesso completo a una rete, pertanto gli amministratori del cluster devono prestare attenzione a fornire l'accesso di 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, a cui possono accedere solo i pod di quello spazio dei nomi. Per riconciliare le risorse personalizzate NetworkAttachmentDefinition
specificate
nel file di configurazione del cluster, queste vengono sempre inserite nello spazio dei nomi
predefinito.
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 una risorsa
personalizzata NetworkAttachmentDefinition
.
Creazione dell'interfaccia:
ipvlan
macvlan
bridge
sriov
Plug-in Meta:
portmap
sbr
tuning
Plug-in IPAM:
host-local
static
whereabouts
Configurazione delle route
Un pod con una o più risorse personalizzate NetworkAttachmentDefinition
assegnate
ha più interfacce di rete. Per impostazione predefinita, la tabella di routing in questa situazione
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:
sbr
static
whereabouts
Ad esempio, potresti voler che tutto il traffico passi attraverso il gateway predefinito, ovvero l'interfaccia predefinita. Tuttavia, alcuni tipi di traffico specifici passano attraverso 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 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 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 di questa 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
,
inclusi i dati di 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 di posizione
Il plug-in whereabouts
è fondamentalmente un'estensione del plug-in static
e
questi due condividono la configurazione del routing. Per un esempio di configurazione, vedi
Plug-in di gestione degli indirizzi IP statici.
Puoi definire un gateway e una route da aggiungere alla tabella di routing del pod. Non puoi, tuttavia, 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ù allegati di rete utilizzati da un singolo pod
Più allegati di rete che puntano alla stessa interfaccia utilizzata da un singolo pod
Lo stesso collegamento di rete utilizzato più volte da un singolo pod
Risoluzione dei problemi
Se le interfacce di rete aggiuntive sono configurate in modo errato, i pod a cui sono assegnate non vengono avviati. Questa sezione evidenzia come trovare informazioni per la risoluzione dei problemi relativi alla funzionalità multi-NIC.
Controllare gli eventi del 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
Controllare i log
Per ogni nodo, puoi trovare i log di Whereabouts e Multus nelle seguenti posizioni:
/var/log/whereabouts.log
/var/log/multus.log
Esaminare le interfacce del pod
Utilizza il comando kubectl exec
per controllare le interfacce del pod. Una volta applicate correttamente le risorse personalizzate
NetworkAttachmentDefinition
, le interfacce del pod
sono simili all'output seguente:
$ 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
Recuperare lo stato del 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