Configurare il supporto di più reti per i pod

Questa pagina mostra come abilitare più interfacce su nodi e pod in un cluster Google Kubernetes Engine (GKE) utilizzando il supporto di più reti per i pod.

Prima di leggere questa pagina, assicurati di conoscere i concetti di rete generali, la terminologia e i concetti specifici di questa funzionalità, nonché i requisiti e le limitazioni per il supporto multi-rete per i pod.

Per ulteriori informazioni, consulta Informazioni sul supporto di più reti per i pod.

Requisiti e limitazioni

Il supporto di più reti per i pod presenta i seguenti requisiti e limitazioni:

Requisiti

• GKE versione Standard 1.28 o successive.
• GKE Autopilot versione 1.29.5-gke.1091000 e successive o versione 1.30.1-gke.1280000 e successive.
• Il supporto di più reti per i pod utilizza le stesse specifiche a livello di VM della funzionalità multi-NIC per Compute Engine.
• Il supporto di più reti per i pod richiede GKE Dataplane V2.
• Il supporto di più reti per i pod è disponibile per Container-Optimized OS. Il supporto di Ubuntu è disponibile sui nodi che eseguono la versione GKE 1.32.3-gke.1785000 o successive.

Limitazioni generali

• Il supporto di più reti per i pod non funziona per i cluster abilitati per il networking dual-stack.
• Il VPC condiviso è supportato solo su GKE versione 1.28 o successive.
• Multi-Pod CIDR è supportato solo su GKE versione 1.29 o successive e solo per la rete Pod predefinita.
• Le reti di pod in un singolo cluster GKE non possono avere intervalli CIDR sovrapposti.
• Quando abiliti il supporto di più reti per i pod, non puoi aggiungere o rimuovere interfacce di rete dei nodi o reti di pod dopo aver creato un pool di nodi. Per modificare queste impostazioni, devi ricreare ilpool di nodil.
• Per impostazione predefinita, l'accesso a internet non è disponibile sulle interfacce aggiuntive delle reti di pod all'interno del pod. Tuttavia, puoi abilitarlo manualmente utilizzando Cloud NAT.
• Non puoi modificare il gateway predefinito all'interno di un pod con più interfacce tramite l'API. Il gateway predefinito deve essere connesso alla rete pod predefinita.
• La rete pod predefinita deve sempre essere inclusa nei pod, anche se crei interfacce o reti pod aggiuntive.
• Non puoi configurare la funzionalità multi-rete quando è stato configurato Managed Hubble.
• Per utilizzare il VPC condiviso, assicurati che il cluster GKE esegua la versione 1.28.4 o successive.
• Per i deployment VPC condivisi, tutte le interfacce di rete (NIC) collegate ai nodi devono appartenere allo stesso progetto del progetto host.
• Il nome degli oggetti di rete digitati del dispositivo non può superare i 41 caratteri. Il percorso completo di ogni socket di dominio UNIX è composto, incluso il nome di rete corrispondente. Linux ha una limitazione sulla lunghezza del percorso del socket (inferiore a 107 byte). Tenendo conto della directory, del prefisso del nome file e dell'estensione .sock, il nome della rete è limitato a un massimo di 41 caratteri.
• Non puoi modificare gli oggetti Network e GKENetworkParamSet. Per aggiornare questi oggetti, eliminali e ricreali.

Limitazioni del kit di sviluppo del piano dati e del dispositivo (DPDK)

• Una NIC VM passata a un pod come NIC di tipo Device non è disponibile per altri pod sullo stesso nodo.
• I pod che utilizzano la modalità DPDK devono essere eseguiti in modalità con privilegi per accedere ai dispositivi VFIO.
• La modalità Autopilot non supporta DPDK.
• In modalità DPDK, un dispositivo viene trattato come una risorsa del nodo e viene collegato solo al primo container (non init) del pod. Se vuoi dividere più dispositivi DPDK tra i container nello stesso pod, devi eseguire questi container in pod separati.
• Sui nodi Ubuntu, le reti DPDK-VFIO sono supportate solo con GKE versione 1.33.1-gke.1959000 e successive.

Limitazioni di scalabilità

GKE fornisce un'architettura di rete flessibile che ti consente di scalare il cluster. Puoi aggiungere altre reti di nodi e reti di pod al tuo cluster. Puoi scalare il tuo cluster nel seguente modo:

• Puoi aggiungere fino a otto reti di nodi aggiuntive a ogni pool di nodi GKE. Si tratta dello stesso limite di scalabilità per le VM di Compute Engine.
• A ogni pod devono essere collegate meno di 8 reti aggiuntive.
• Puoi configurare fino a 35 pod-network nelle 8 node-network all'interno di un singolo pool di nodi. Puoi suddividerlo in diverse combinazioni, ad esempio:
  • 7 reti di nodi con 5 reti di pod ciascuna
  • 5 reti di nodi con 7 reti di pod ciascuna
  • 1 rete di nodi con 30 reti di pod. Il limite per gli intervalli secondari per subnet è 30.
• Puoi configurare fino a 50 reti pod per cluster.
• Puoi configurare fino a un massimo di 32 pod multi-rete per nodo.
• Puoi avere fino a 5000 nodi con più interfacce.
• Puoi avere fino a 100.000 interfacce aggiuntive in tutti i Pod.

Esegui il deployment di pod multi-rete

Per eseguire il deployment di pod multi-rete:

1. Prepara un VPC aggiuntivo, una subnet (node-network) e intervalli secondari (Pod-network).
2. Crea un cluster GKE abilitato per più reti utilizzando il comando Google Cloud CLI.
3. Crea un nuovo node pool GKE che sia connesso alla rete di nodi e alla rete di pod aggiuntive utilizzando il comando Google Cloud CLI.
4. Crea la rete pod e fai riferimento agli intervalli VPC, subnet e secondari corretti negli oggetti multirete utilizzando l'API Kubernetes.
5. Nella configurazione del workload, fai riferimento all'oggetto Kubernetes Network preparato utilizzando l'API Kubernetes.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

• Esamina i requisiti e le limitazioni.

Prepara un VPC aggiuntivo

Trusted Cloud by S3NS crea una rete di pod predefinita durante la creazione del cluster associata alpool di nodil GKE utilizzato durante la creazione iniziale del cluster GKE. La rete di pod predefinita è disponibile su tutti i nodi e i pod del cluster. Per facilitare le funzionalità multi-rete all'interno del pool di nodi, devi preparare VPC esistenti o nuovi che supportino reti di tipo Layer 3 e Device.

Per preparare un VPC aggiuntivo, considera i seguenti requisiti:

• Rete di tipo Layer 3 e Netdevice:

  • Crea un intervallo secondario se utilizzi reti di tipo Layer 3.
  • Assicurati che le dimensioni del CIDR per l'intervallo secondario siano sufficienti a soddisfare il numero di nodi nel pool di nodi e il numero di pod per nodo che vuoi avere.
  • Analogamente alla rete di pod predefinita, le altre reti di pod utilizzano il provisioning eccessivo degli indirizzi IP. L'intervallo di indirizzi IP secondari deve avere il doppio di indirizzi IP per nodo rispetto al numero di pod per nodo.

• Requisiti di rete di tipo Device: crea una subnet normale su un VPC. Non è necessaria una subnet secondaria.

Per abilitare le funzionalità multirete nel pool di nodi, devi preparare i VPC a cui vuoi stabilire connessioni aggiuntive. Puoi utilizzare un VPC esistente o crearne uno nuovo appositamente per il pool di nodi.

Crea una rete VPC che supporti il dispositivo di tipo Layer 3

Per creare una rete VPC che supporti un dispositivo di tipo Layer 3, procedi nel seguente modo:

• Assicurati che le dimensioni CIDR per l'intervallo secondario siano sufficienti a soddisfare il numero di nodi nel pool di nodi e il numero di pod per nodo che vuoi avere.

• Analogamente alla rete pod predefinita, le altre reti pod utilizzano il provisioning eccessivo dell'indirizzo IP. L'intervallo di indirizzi IP secondari deve avere il doppio degli indirizzi IP per nodo rispetto al numero di pod per nodo.

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Crea una rete VPC che supporti dispositivi di tipo Netdevice o DPDK

gcloud compute networks subnets create SUBNET_NAME \
    --project=PROJECT_ID \
    --range=SUBNET_RANGE \
    --network=NETWORK_NAME \
    --region=REGION \
    --secondary-range=SECONDARY_RANGE_NAME=<SECONDARY_RANGE_RANGE>

Crea un cluster GKE con funzionalità multi-rete

L'abilitazione del networking multiplo per un cluster aggiunge le CustomResourceDefinitions (CRD) necessarie all'API server per quel cluster. Inoltre, esegue il deployment di un network-controller-manager, responsabile della riconciliazione e della gestione degli oggetti multi-rete. Non puoi modificare la configurazione del cluster dopo la creazione.

Crea un cluster GKE Autopilot con funzionalità multi-rete

Crea un cluster GKE Autopilot con funzionalità multi-rete:

gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-multi-networking

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster.
• CLUSTER_VERSION: la versione del cluster.

Il flag --enable-multi-networking abilita le definizioni di risorse personalizzate (CRD) di networking multiplo nell'API server per questo cluster e implementa un network-controller-manager che contiene la riconciliazione e la gestione del ciclo di vita per gli oggetti di networking multiplo.

Crea un cluster GKE Standard con funzionalità multi-rete

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=CLUSTER_VERSION \
    --enable-dataplane-v2 \
    --enable-ip-alias \
    --enable-multi-networking

Crea un pool di nodi GKE Standard connesso a VPC aggiuntivi

Crea un pool di nodi che includa nodi connessi alla rete di nodi (VPC e subnet) e alla rete di pod (intervallo secondario) creati in Crea rete di pod.

Per creare il nuovo pool di nodi e associarlo alle reti aggiuntive nel cluster GKE:

gcloud container node-pools create POOL_NAME \
  --cluster=CLUSTER_NAME \
  --additional-node-network network=NETWORK_NAME,subnetwork=SUBNET_NAME \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=POD_IP_RANGE,max-pods-per-node=NUMBER_OF_PODS \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Note:

• Se vengono specificate più pod-reti aggiuntive all'interno della stessa node-network, queste devono trovarsi nella stessa subnet.
• Non puoi fare riferimento più volte allo stesso intervallo secondario di una subnet.

Esempio L'esempio seguente crea un pool di nodi denominato pool-multi-net che collega due reti aggiuntive ai nodi, datapalane (rete di tipo Layer 3) e highperformance (rete di tipo netdevice). Questo esempio presuppone che tu abbia già creato un cluster GKE denominato cluster-1:

gcloud container node-pools create pool-multi-net \
  --project my-project \
  --cluster cluster-1 \
  --location us-central1-c \
  --additional-node-network network=dataplane,subnetwork=subnet-dp \
  --additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
  --additional-node-network network=highperformance,subnetwork=subnet-highperf

Per specificare interfacce di rete del nodo e del pod aggiuntive, definisci i parametri --additional-node-network e --additional-pod-network più volte, come mostrato nell'esempio seguente:

--additional-node-network network=dataplane,subnetwork=subnet-dp \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-blue,max-pods-per-node=8 \
--additional-pod-network subnetwork=subnet-dp,pod-ipv4-range=sec-range-green,max-pods-per-node=8 \
--additional-node-network network=managementdataplane,subnetwork=subnet-mp \
--additional-pod-network subnetwork=subnet-mp,pod-ipv4-range=sec-range-red,max-pods-per-node=4

Per specificare reti di pod aggiuntive direttamente sull'interfaccia VPC principale del pool di nodi, come mostrato nell'esempio seguente:

--additional-pod-network subnetwork=subnet-def,pod-ipv4-range=sec-range-multinet,max-pods-per-node=8

Crea rete di pod

Definisci le reti di pod a cui i pod accederanno definendo gli oggetti Kubernetes e collegandoli alle risorse Compute Engine corrispondenti, come VPC, subnet e intervalli secondari.

Per creare una rete di pod, devi definire gli oggetti CRD di rete nel cluster.

Configura la rete VPC Layer 3

Configura la rete DPDK

Configura la rete netdevice

Per il VPC netdevice, crea oggetti Network e GKENetworkParamSet.

Configurazione delle route di rete

La configurazione della route di rete consente di definire route personalizzate per una rete specifica, che vengono configurate sui pod per indirizzare il traffico all'interfaccia corrispondente all'interno del pod.

Fai riferimento al Network preparato.

Nella configurazione del workload, fai riferimento all'oggetto Kubernetes Network preparato utilizzando l'API Kubernetes.

Connettere il pod a reti specifiche

Per connettere i pod alle reti specificate, devi includere i nomi degli oggetti Network come annotazioni all'interno della configurazione del pod. Assicurati di includere sia default Network sia le emittenti aggiuntive selezionate nelle annotazioni per stabilire le connessioni.

1. Salva il seguente manifest di esempio come sample-l3-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-l3-pod
     annotations:
       networking.gke.io/default-interface: 'eth0'
       networking.gke.io/interfaces: |
         [
           {"interfaceName":"eth0","network":"default"},
           {"interfaceName":"eth1","network":"blue-network"}
         ]
   spec:
     containers:
     - name: sample-l3-pod
       image: busybox
       command: ["sleep", "10m"]
       ports:
       - containerPort: 80
     restartPolicy: Always
   

   Questo manifest crea un pod denominato sample-l3-pod con due interfacce di rete, eth0 e eth1, associate rispettivamente alle reti default e blue-network.

2. Applica il manifest al cluster:

   kubectl apply -f sample-l3-pod.yaml
   

Connettere il pod a più reti

1. Salva il seguente manifest di esempio come sample-l3-netdevice-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-l3-netdevice-pod
     annotations:
       networking.gke.io/default-interface: 'eth0'
       networking.gke.io/interfaces: |
         [
           {"interfaceName":"eth0","network":"default"},
           {"interfaceName":"eth1","network":"blue-network"},
           {"interfaceName":"eth2","network":"netdevice-network"}
         ]
   spec:
     containers:
     - name: sample-l3-netdevice-pod
       image: busybox
       command: ["sleep", "10m"]
       ports:
       - containerPort: 80
     restartPolicy: Always
   

   Questo manifest crea un pod denominato sample-l3-netdevice-pod con tre interfacce di rete, eth0, eth1 e eth2, associate rispettivamente alle reti default, blue-network e netdevice.

2. Applica il manifest al cluster:

   kubectl apply -f sample-l3-netdevice-pod.yaml
   

Puoi utilizzare la stessa annotazione in qualsiasi ReplicaSet (Deployment o DaemonSet) nella sezione delle annotazioni del modello.

Configurazione di esempio di un pod con più interfacce:

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: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default
    link/ether 2a:92:4a:e5:da:35 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.60.45.4/24 brd 10.60.45.255 scope global eth0
      valid_lft forever preferred_lft forever
10: eth1@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1460 qdisc noqueue state UP group default qlen 1000
    link/ether ba:f0:4d:eb:e8:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.1.2/32 scope global eth1
      valid_lft forever preferred_lft forever

Verifica

• Assicurati di creare cluster con --enable-multi-networking solo se --enable-dataplane-v2 è abilitato.
• Verifica che tutti i pool di nodi nel cluster eseguano immagini Container-Optimized OS al momento della creazione del cluster e del pool di nodi.
• Verifica che i pool di nodi vengano creati con --additional-node-network o --additional-pod-network solo se il networking multiplo è abilitato sul cluster.
• Assicurati che la stessa subnet non sia specificata due volte come argomento --additional-node-network di un pool di nodi.
• Verifica che lo stesso intervallo secondario non sia specificato come argomento --additional-pod-network di un pool di nodi.
• Rispetta i limiti di scalabilità specificati per gli oggetti di rete, tenendo conto del numero massimo di nodi, pod e indirizzi IP consentiti.
• Verifica che esista un solo oggetto GKENetworkParamSet che fa riferimento a una determinata subnet e a un intervallo secondario.
• Verifica che ogni oggetto di rete faccia riferimento a un oggetto GKENetworkParamSet diverso.
• Verifica che l'oggetto di rete, se creato con una subnet specifica con rete Device, non venga utilizzato sullo stesso nodo con un'altra rete con un intervallo secondario. Puoi convalidarlo solo in fase di runtime.
• Verifica che i vari intervalli secondari assegnati ai node pool non abbiano indirizzi IP sovrapposti.

Risolvi i problemi relativi ai parametri di multi-networking in GKE

Quando crei un cluster e un pool di nodi, Trusted Cloud by S3NS implementa determinati controlli per garantire che siano consentiti solo parametri di networking multiplo validi. In questo modo la rete è configurata correttamente per il cluster.

A partire dalla versione 1.32 di GKE e successive, high-perf-config-daemon è richiesto solo quando è presente una rete DPDK-VFIO sul nodo. Per controllare high-perf-config-daemon, verifica che sia presente l'etichetta del nodo cloud.google.com/run-high-perf-config-daemons: "true". L'assenza dei plug-in o delle etichette dei nodi richiesti per il tipo di rete specifico può indicare una configurazione incompleta o errata.

Se non riesci a creare workload multirete, puoi controllare lo stato e gli eventi del pod per ulteriori informazioni:

kubectl describe pods samplepod

L'output è simile al seguente:

Name:         samplepod
Namespace:    default
Status:       Running
IP:           192.168.6.130
IPs:
  IP:  192.168.6.130
...
Events:
  Type     Reason                  Age   From               Message
  ----     ------                  ----  ----               -------
  Normal   NotTriggerScaleUp  9s               cluster-autoscaler  pod didn't trigger scale-up:
  Warning  FailedScheduling   8s (x2 over 9s)  default-scheduler   0/1 nodes are available: 1 Insufficient networking.gke.io.networks/my-net.IP. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod

Di seguito sono riportati i motivi generali per cui la creazione di un pod non va a buon fine:

• Impossibile pianificare il pod perché i requisiti delle risorse di networking multiplo non sono soddisfatti
• Impossibile identificare le reti specificate

Risolvi i problemi relativi alla creazione di reti Kubernetes

Dopo aver creato correttamente una rete, i nodi che devono avere accesso alla rete configurata vengono annotati con un'annotazione di stato della rete.

Per osservare le annotazioni, esegui questo comando:

kubectl describe node NODE_NAME

Sostituisci NODE_NAME con il nome del nodo.

L'output è simile al seguente:

networking.gke.io/network-status: [{"name":"default"},{"name":"dp-network"}]

L'output elenca ogni rete disponibile sul nodo. Se lo stato di rete previsto non viene visualizzato sul nodo:

Controllare se il nodo può accedere alla rete

Se la rete non viene visualizzata nell'annotazione sullo stato della rete del nodo:

1. Verifica che il nodo faccia parte di un pool configurato per il multi-networking.
2. Controlla le interfacce del nodo per vedere se ne ha una per la rete che stai configurando.
3. Se a un nodo manca lo stato di rete e ha una sola interfaccia di rete, devi comunque creare un pool di nodi con il networking multiplo abilitato.
4. Se il nodo contiene l'interfaccia per la rete che stai configurando, ma non viene visualizzata nell'annotazione dello stato della rete, controlla le risorse Network e GKENetworkParamSet (GNP).

Consulta le risorse Network e GKENetworkParamSet

Lo stato delle risorse Network e GKENetworkParamSet (GNP) include un campo delle condizioni per segnalare gli errori di configurazione. Ti consigliamo di controllare prima GNP, in quanto non si basa su un'altra risorsa per essere valido.

Per controllare il campo delle condizioni, esegui questo comando:

kubectl get gkenetworkparamsets GNP_NAME -o yaml

Sostituisci GNP_NAME con il nome della risorsa GKENetworkParamSet.

Quando la condizione Ready è uguale a true, la configurazione è valida e l'output è simile al seguente:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-dp
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:38:04Z"
    message: ""
    reason: GNPReady
    status: "True"
    type: Ready
  networkName: dp-network
  podCIDRs:
    cidrBlocks:
    -   172.16.1.0/24

Quando la condizione Ready è uguale a false, l'output mostra il motivo ed è simile al seguente:

apiVersion: networking.gke.io/v1
kind: GKENetworkParamSet
...
spec:
  podIPv4Ranges:
    rangeNames:
    -   sec-range-blue
  vpc: dataplane
  vpcSubnet: subnet-nonexist
status:
  conditions:
  -   lastTransitionTime: "2023-06-26T17:37:57Z"
    message: 'subnet: subnet-nonexist not found in VPC: dataplane'
    reason: SubnetNotFound
    status: "False"
    type: Ready
  networkName: ""

Se visualizzi un messaggio simile, assicurati che il GNP sia configurato correttamente. Se è già così, assicurati che la configurazione di rete Trusted Cloud by S3NS sia corretta. Dopo aver aggiornato Trusted Cloud by S3NS la configurazione di rete, potrebbe essere necessario ricreare la risorsa GNP per attivare manualmente una risincronizzazione. In questo modo si evita il polling infinito dell'API Trusted Cloud by S3NS.

Una volta pronto il GNP, consulta la risorsa Network.

kubectl get networks NETWORK_NAME -o yaml

Sostituisci NETWORK_NAME con il nome della risorsa Network.

L'output di una configurazione valida è simile al seguente:

apiVersion: networking.gke.io/v1
kind: Network
...
spec:
  parametersRef:
    group: networking.gke.io
    kind: GKENetworkParamSet
    name: dp-gnp
  type: L3
status:
  conditions:
  -   lastTransitionTime: "2023-06-07T19:31:42Z"
    message: ""
    reason: GNPParamsReady
    status: "True"
    type: ParamsReady
  -   lastTransitionTime: "2023-06-07T19:31:51Z"
    message: ""
    reason: NetworkReady
    status: "True"
    type: Ready

• reason: NetworkReady indica che la risorsa di rete è configurata correttamente. reason: NetworkReady non implica che la risorsa di rete sia necessariamente disponibile su un nodo specifico o in uso attivo.
• In caso di configurazione errata o errore, il campo reason nella condizione specifica il motivo esatto del problema. In questi casi, modifica la configurazione di conseguenza.
• GKE compila il campo ParamsReady se il campo parametersRef è impostato su una risorsa GKENetworkParamSet esistente nel cluster. Se hai specificato un parametro type parametersRef di tipo GKENetworkParamSet e la condizione non viene visualizzata, assicurati che il nome, il tipo e il gruppo corrispondano alla risorsa GNP esistente nel cluster.

Passaggi successivi

• Scopri come creare cluster nativi di VPC
• Codelab
• Video dimostrativo