Configurare più interfacce di rete per i pod

Questo documento descrive come configurare Google Distributed Cloud per fornire più interfacce di rete (multi-NIC) per i pod. La funzionalità multi-NIC per i pod può contribuire a separare il traffico del piano di controllo da quello del piano dati, creando isolamento tra i piani. Le interfacce di rete aggiuntive abilitano anche la funzionalità di multicast per i pod. La configurazione Multi-NIC per i pod è supportata per i cluster utente, i cluster ibridi e i cluster autonomi. Non è consentito per i cluster di tipo amministratore.

Questa pagina è rivolta agli esperti di Networking che installano, configurano e supportano equipment di rete. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

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 rete wide area (SD-WAN), un broker di sicurezza per l'accesso al cloud (CASB) e 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 di dati, mentre vengono eseguiti come contenitori.

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. I cluster possono contenere una combinazione 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.

Configurare più interfacce di rete

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

  1. Attiva più NIC per il tuo cluster con il campo multipleNetworkInterfaces nella risorsa personalizzata del cluster.

  2. Specifica le interfacce di rete con le risorse personalizzateNetworkAttachmentDefinition.

  3. Assegna le 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 in modo che si adatti al meglio alle tue esigenze di rete.

Attiva più NIC

Abilita la multi-NIC per i 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 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 tratta questa risorsa personalizzata all'interno dello spazio dei nomi del cluster come fonte attendibile e la riconcilia con lo spazio dei nomi default del cluster di destinazione.

Il seguente diagramma illustra come Google Distributed Cloud riconcilia le risorse personalizzate NetworkAttachmentDefinition dallo spazio dei nomi specifico del cluster allo spazio dei nomi default.

Riconciliazione di NetworkAttachmentDefinition

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 dalla specifica delle risorse personalizzate durante la creazione del cluster, perché in questo modo 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 aggiungerle direttamente a un cluster di destinazione esistente.NetworkAttachmentDefinition Google Distributed Cloud consente di riconciliare le risorse personalizzate NetworkAttachmentDefinition definite nello spazio dei nomi del cluster. La riconciliazione avviene anche in caso di eliminazione. Quando una risorsa personalizzata NetworkAttachmentDefinition viene rimossa dall'ambito di un 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, separata 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. Utilizza default per lo spazio dei nomi predefinito, che è standard. Per un'eccezione, consulta 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, al pod samplepod vengono assegnate due interfacce di rete. 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 node per i quali è valida una risorsa personalizzata NetworkAttachmentDefinition. Google Distributed Cloud forza 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'gke-network-1 interfaccia di rete 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 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 l'accesso completo a una rete, pertanto gli amministratori del cluster devono prestare attenzione a concedere l'accesso in fase di creazione, aggiornamento o eliminazione ad altri utenti. Se una determinata risorsa personalizzataNetworkAttachmentDefinition deve essere isolata, può essere inserita in uno spazio dei nomi non predefinito, a cui possono accedere solo i pod di quel determinato 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.

Utilizzo degli 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 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 del 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 principale/predefinita del pod, eth0.

Puoi modificare questo comportamento utilizzando i seguenti plug-in CNI:

  • sbr
  • static
  • whereabouts

Ad esempio, potresti voler far passare tutto il traffico attraverso il gateway predefinito, ovvero l'interfaccia predefinita. Tuttavia, parte del traffico specifico passa 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 utile.

Plug-in SBR

Il plug-in sbr consente all'applicazione di controllare le decisioni di routing. L'applicazione controlla cosa 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'indirizzo 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 in catena. Per ulteriori informazioni 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 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 relativi alla posizione

Il plug-in whereabouts è fondamentalmente un'estensione del plug-in static e condivide 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 in questo modo il gateway predefinito del pod.

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.

Un unico collegamento di rete utilizzato da più pod

Un unico collegamento di rete utilizzato da più pod

Più dispositivi di rete utilizzati da un singolo pod

Più dispositivi di rete utilizzati da un singolo pod

Più dispositivi di rete collegati che rimandano alla stessa interfaccia utilizzata da un singolo pod

Più dispositivi di rete collegati che rimandano alla stessa interfaccia utilizzata da un singolo pod

Lo stesso attacco di rete utilizzato più volte da un singolo pod

Lo stesso attacco 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 si avviano. Questa sezione illustra come trovare informazioni per risolvere i problemi relativi alla funzionalità multi-NIC.

Controlla gli eventi del pod

Multus segnala gli errori tramite gli eventi dei pod Kubernetes. Utilizza il seguente kubectl describe comando 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 località:

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

Esamina 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 avranno il seguente aspetto:

$ 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 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ù emittenti:

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