Configura più interfacce di rete per i pod

Questo documento descrive come configurare Anthos clusters on bare metal per fornire più interfacce di rete, multi-NIC, per i tuoi pod. La funzionalità multi-NIC per pod consente di separare il traffico del piano di controllo da quello del piano dati, creando isolamento tra i piani. Anche le interfacce di rete aggiuntive abilitano la funzionalità multicast per i pod. Multi-NIC per pod è supportato per cluster utente, cluster ibridi e cluster autonomi. Non è consentito per i cluster di tipo amministratore.

L'isolamento del piano di rete è importante per i sistemi che utilizzano le virtualizzazione delle funzioni di rete (NFV), come il networking software-defined in un'ampia rete (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 di dati, mentre sono in esecuzione come container.

La configurazione dell'interfaccia di più reti supporta l'associazione delle 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 pool di nodi, puoi aggiungere ulteriori interfacce al pool di nodi per migliorare il flusso di traffico.

Configurare più interfacce di rete

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

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

  2. Specifica le interfacce di rete con NetworkAttachmentDefinition risorse personalizzate.

  3. 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 funzionalità multi-NIC nel modo più adatto alle tue esigenze di networking.

Attiva più NIC

Abilita più NIC per i tuoi pod aggiungendo il campo multipleNetworkInterfaces alla sezione clusterNetwork della risorsa personalizzata del cluster e impostandola su true.

  ...
  clusterNetwork:
    multipleNetworkInterfaces: true
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/12
  ...

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 nella 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, Anthos clusters on bare metal utilizza questo nome per controllare la risorsa personalizzata NetworkAttachmentDefinition dopo la creazione del cluster. Anthos clusters on bare metal considera questa risorsa personalizzata all'interno dello spazio dei nomi del cluster come la fonte di riferimento e la riconcilia con lo spazio dei nomi default del cluster di destinazione.

Il seguente diagramma mostra in che modo Anthos clusters on bare metal riconcilia NetworkAttachmentDefinition le risorse personalizzate dallo spazio dei nomi specifico del cluster allo spazio dei nomi default.

Riconciliazione reti - Collegamento rete

Sebbene sia facoltativo, ti consigliamo di specificare NetworkAttachmentDefinition risorse personalizzate in questo modo, durante la creazione del cluster. I cluster utente hanno maggiori vantaggi 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 NetworkAttachmentDefinition risorse personalizzate durante la creazione del cluster, puoi aggiungere NetworkAttachmentDefinition risorse personalizzate direttamente a un cluster di destinazione esistente. Anthos clusters on bare metal concilia 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 da uno spazio dei nomi del cluster, Anthos clusters on bare metal rimuove la risorsa personalizzata dal cluster di destinazione.

Assegna le 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. Utilizza default per lo spazio dei nomi predefinito, che è standard. In caso di eccezioni, consulta Problemi di sicurezza.
  • NAD_NAME: il nome della risorsa personalizzata NetworkAttachmentDefinition.

Utilizza un elenco separato da virgole per specificare più interfacce di rete.

Nel seguente esempio, al pod samplepod vengono assegnate due interfacce. Le interfacce di rete sono specificate da 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. Anthos clusters on bare metal impone il deployment di tutti i pod che fanno riferimento a questa risorsa personalizzata su nodi specifici. Nell'esempio seguente, Anthos clusters on bare metal forza il deployment di tutti i pod a cui è assegnata l'interfaccia di rete gke-network-1 al pool di nodi multinicNP. Anthos clusters on bare metal 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 è limitato a utilizzare le 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 che il nodo è etichettato, applica l'annotazione baremetal.cluster.gke.io/label-taint-no-sync su quel nodo per impedire ai Anthos clusters on bare metal 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 del cluster devono essere cauti quando forniscono 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, in cui solo i pod di tale spazio possono accedervi. Per riconciliare NetworkAttachmentDefinition risorse personalizzate specificate nel file di configurazione del cluster, vengono sempre posizionate 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 del CNI supportati dalla funzionalità multi-NIC per Anthos clusters on bare metal. Utilizza solo i seguenti plug-in durante la specifica di 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 ha più interfacce di rete. Per impostazione predefinita, la tabella di routing in questa situazione è estesa con le interfacce aggiuntive disponibili localmente solo dalle risorse personalizzate assegnate a NetworkAttachmentDefinition. Il gateway predefinito è ancora configurato per l'utilizzo dell'interfaccia master/predefinita del pod, eth0.

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

  • sbr
  • static
  • whereabouts

Ad esempio, potresti volere che tutto il traffico passi attraverso il gateway predefinito. Tuttavia, una parte del traffico specifico passa su 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 relative al routing. L'applicazione controlla ciò che viene utilizzato come indirizzo IP di origine della connessione stabilita. Quando l'applicazione sceglie di utilizzare l'indirizzo IP della risorsa personalizzata NetworkAttachmentDefinition per il suo IP di origine, i pacchetti vengono inclusi nella tabella di routing aggiuntiva sbr. La tabella di routing sbr stabilisce l'interfaccia della risorsa personalizzata NetworkAttachmentDefinition come gateway predefinito. L'IP 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 scoprire di più sul plug-in sbr, incluse le informazioni sull'utilizzo, consulta il 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 il giorno 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 in cui è disponibile

Il plug-in whereabouts è essenzialmente un'estensione del plug-in static e 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. 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.

Collegamento di rete singolo utilizzato da più pod

Collegamento di rete singolo utilizzato da più pod

Collegamenti di rete multipli utilizzati da un singolo pod

Collegamenti di rete multipli 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

Stesso collegamento di rete utilizzato più volte da un singolo pod

Stesso collegamento di rete utilizzato più volte da un singolo pod

Risolvere i problemi

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

Controlla gli eventi dei pod

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

kubectl describe pod POD_NAME

Controlla i log

Per ciascun nodo, puoi trovare i log Luogo e Multus nelle seguenti località:

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

Esamina le interfacce dei pod

Usa il comando kubectl exec per controllare le interfacce dei pod. Una volta che le risorse personalizzate NetworkAttachmentDefinition sono state applicate correttamente, le interfacce pod hanno il 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 kubectl get per recuperare lo stato della rete per un determinato pod:

kubectl get pods POD_NAME -oyaml

Di seguito è riportato 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