Configura più interfacce di rete per i pod

Questo documento descrive come configurare Google Distributed Cloud per fornire più interfacce di rete multiple con più NIC per i tuoi pod. La funzionalità con più NIC per i pod può aiutano 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à multicast per i tuoi pod. I NIC multipli per i pod sono supportati per i cluster utente, i cluster ibridi e cluster autonomi. Non è consentito per cluster di tipo amministratore.

L'isolamento del piano di rete è importante per i sistemi che utilizzano funzioni di rete virtualizzazioni (NFV), come il networking software-defined in un'ampia area (SD-WAN), un CASB (Cloud Access Security Broker) e un servizio di sicurezza firewall (NG-FW). Questi tipi di NFV si basano sull'accesso a più interfacce per mantenere separati il piano di gestione e quello dei dati durante l'esecuzione come container.

La configurazione di più interfacce di rete supporta l'associazione delle reti si interfacciano con i pool di nodi, il che può offrire vantaggi in termini di prestazioni. Cluster può contenere una combinazione di tipi di nodi. Quando raggruppi macchine ad alte prestazioni in in un pool di nodi, puoi aggiungere altre interfacce al pool di nodi per migliorare del traffico di rete.

Configurazione di più interfacce di rete

In genere, sono previsti tre passaggi per configurare più interfacce di rete per il tuo pod:

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

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

3. Assegnare 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 più 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 impostandola 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 NetworkAttachmentDefinition risorse personalizzate per specificare una rete aggiuntiva interfacce. Le NetworkAttachmentDefinition risorse personalizzate corrispondono disponibili per i tuoi pod. Puoi specificare le risorse personalizzate della configurazione del cluster, come mostrato nell'esempio seguente, e creerai direttamente le risorse personalizzate di 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 tuo di configurazione del cluster, Google Distributed Cloud utilizza questo nome per controllare NetworkAttachmentDefinition risorsa personalizzata dopo la creazione del cluster. Google Distributed Cloud tratta questa risorsa personalizzata all'interno dello spazio dei nomi del cluster come origine dati e la riconcilia con lo spazio dei nomi default del cluster di destinazione.

Il seguente diagramma illustra il modo in cui Google Distributed Cloud effettua le riconciliazioni NetworkAttachmentDefinition risorse personalizzate dalla specifica del cluster allo spazio dei nomi default.

Sebbene sia facoltativo, ti consigliamo di specificare NetworkAttachmentDefinition risorse personalizzate in questo modo, durante il cluster per la creazione di contenuti. I cluster utente sono più utili quando specifichi le risorse personalizzate durante la creazione del cluster, perché puoi controllare NetworkAttachmentDefinition risorse personalizzate dal cluster di amministrazione.

Se scegli di non specificare NetworkAttachmentDefinition risorse personalizzate durante la creazione del cluster, puoi aggiungere NetworkAttachmentDefinition delle risorse direttamente a un cluster di destinazione esistente. Google Distributed Cloud riconcilia NetworkAttachmentDefinition risorse personalizzate definite nel cluster nello spazio dei nomi. La riconciliazione avviene anche al momento dell'eliminazione. Quando NetworkAttachmentDefinition risorsa personalizzata è stata rimossa da un cluster dello spazio dei nomi, Google Distributed Cloud rimuove la risorsa personalizzata dalla destinazione in un cluster Kubernetes.

Assegnare interfacce di rete a un pod

Utilizza l'annotazione k8s.v1.cni.cncf.io/networks per assegnare una o più reti a un pod. Ogni interfaccia di rete è specificata con uno spazio dei nomi il nome di una risorsa personalizzata NetworkAttachmentDefinition, separata da un 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 predefinito, che è standard. Consulta Problemi di sicurezza per un'eccezione.
• NAD_NAME: il nome del NetworkAttachmentDefinition risorsa personalizzata.

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

Nell'esempio seguente, due interfacce di rete sono assegnate a samplepod all'interno del pod. Le interfacce di rete sono specificate dai nomi di due NetworkAttachmentDefinition risorse personalizzate, 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 i quali è valida una risorsa personalizzata NetworkAttachmentDefinition. Google Distributed Cloud impone a tutti i pod che fanno riferimento a questa risorsa personalizzata di essere di cui è stato eseguito il deployment in quei nodi specifici. Nell'esempio seguente, Google Distributed Cloud forza il deployment di tutti i pod a cui è assegnato interfaccia di rete gke-network-1 al pool di nodi multinicNP. Google Distributed Cloud etichetta un pool di nodi con baremetal.cluster.gke.io/node-pool etichetta 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 ai 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 baremetal.cluster.gke.io/label-taint-no-sync su quel nodo per impedisce a Google Distributed Cloud di riconciliare le etichette. Utilizza la kubectl get nodes --show-labels per verificare se un nodo è etichettato.

Problemi di sicurezza

Una risorsa personalizzata NetworkAttachmentDefinition fornisce l'accesso completo a un quindi gli amministratori di cluster devono fare attenzione a fornire aggiornare o eliminare l'accesso di altri utenti. Se un determinato NetworkAttachmentDefinition risorsa personalizzata deve essere isolata. Può essere e viene inserito in uno spazio dei nomi non predefinito, dove solo i pod di quello spazio dei nomi possono per accedervi. Per riconciliare NetworkAttachmentDefinition risorse personalizzate specificate nel file di configurazione del cluster, vengono sempre inseriti nel nello spazio dei nomi.

Nel diagramma seguente, i pod dello spazio dei nomi default non possono accedere allo a riga di comando nello spazio dei nomi privileged.

Plug-in CNI supportati

In questa sezione sono elencate le plug-in CNI supportato dalla funzionalità multi-NIC per Google Distributed Cloud. Utilizza solo i seguenti plug-in quando specifichi un parametro NetworkAttachmentDefinition risorsa.

Creazione dell'interfaccia:

• ipvlan
• macvlan
• bridge
• sriov

Meta-plug-in:

• portmap
• sbr
• tuning

Plug-in IPAM:

• host-local
• static
• whereabouts

Configurazione 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 è esteso alle interfacce aggiuntive disponibili localmente Solo NetworkAttachmentDefinition risorse personalizzate. 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, se vuoi che tutto il traffico passi attraverso il gateway predefinito, l'interfaccia predefinita. Tuttavia, una parte del traffico specifico passa per uno dei interfacce non predefinite. Può essere difficile distinguere il traffico in base a IP di destinazione (routing normale), perché lo stesso endpoint è disponibile 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. La controlla quello che viene utilizzato come indirizzo IP di origine della connessione stabilisce. Se l'applicazione sceglie di utilizzare Indirizzo IP di NetworkAttachmentDefinition risorsa personalizzata per il rispettivo IP di origine, vengono inseriti nella tabella di routing aggiuntiva sbr. Instradamento 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 parametro Plug-in sbr come plug-in concatenato. Per ulteriori informazioni sul plug-in sbr, incluse le informazioni sull'utilizzo, vedi Plug-in di routing basato sull'origine.

L'esempio seguente mostra l'impostazione "gateway":"21.0.111.254" impostata 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 localizzazione

Il plug-in whereabouts è fondamentalmente un'estensione del plug-in static e e condividono la configurazione del routing. Per un esempio di configurazione, consulta plug-in per la gestione degli indirizzi IP statici. Puoi definire un gateway e una route da aggiungere alla tabella di routing del pod. Non puoi, ma modifica il gateway predefinito del pod in questo modo.

L'esempio seguente mostra l'aggiunta di "routes": [{ "dst": "172.31.0.0/16" }] in NetworkAttachmentDefinition risorsa personalizzata:

# 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 da la funzione 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

Risoluzione dei problemi

Se le interfacce di rete aggiuntive non sono configurate correttamente, i pod a cui vengono non si avviano. Questa sezione illustra come trovare informazioni su risoluzione dei problemi relativi alla funzionalità multi-NIC.

Controlla gli eventi dei pod

Multo segnala gli errori tramite gli eventi dei pod Kubernetes. Utilizza quanto segue 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 Whereabout e Multus in: località:

• /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 NetworkAttachmentDefinition risorse personalizzate sono state applicate correttamente, il pod il seguente aspetto è l'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