Panoramica del networking di GKE (original) (raw)

Questa pagina fornisce una guida agli aspetti principali del networking di Google Kubernetes Engine (GKE). Queste informazioni sono utili per chi ha appena iniziato a utilizzare Kubernetes, nonché per operatori di cluster o sviluppatori di applicazioni esperti che hanno bisogno di maggiori conoscenze sulla rete Kubernetes per progettare meglio le applicazioni o configurare i carichi di lavoro Kubernetes.

Questa pagina e il resto di questo set di documentazione sono rivolti a architetti cloud e a esperti di networking che progettano e progettano la rete per la propria organizzazione. Se non hai dimestichezza con Kubernetes o GKE o se vuoi saperne di più su un argomento GKE più generale, consulta la documentazione di GKE di base, che copre le funzionalità di base disponibili per tutti gli utenti GKE. Per una panoramica di tutti i set di documentazione di GKE, consulta Esplorare la documentazione di GKE. Per approfondire i ruoli comuni e le attività di esempio a cui facciamo riferimento nei contenutiGoogle Cloud , consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Kubernetes ti consente di definire in modo dichiarativo il modo in cui le applicazioni vengono dipiattate, come comunicano tra loro e con il pannello di controllo Kubernetes e come i clienti possono raggiungerle. Questa pagina fornisce inoltre informazioni su come GKE configura i servizi Google Cloud, se pertinenti per il networking.

Perché il networking di Kubernetes è diverso

Quando utilizzi Kubernetes per orchestrare le tue applicazioni, è importante cambiare il modo in cui pensi alla progettazione di rete delle tue applicazioni e dei relativi host. Con Kubernetes, devi pensare a come comunicano i pod, i servizi e i client esterni, anziché a come sono connessi i tuoi host o le tue macchine virtuali (VM).

Networking software-defined (SDN) avanzata di Kubernetes consente il routing e l'inoltro dei pacchetti per pod, servizi e nodi in zone diverse dello stesso cluster regionale. Kubernetes e Google Cloud configurano anche dinamicamente regole di filtro IP, tabelle di routing e regole firewall su ogni nodo, a seconda del modello dichiarativo dei tuoi deployment Kubernetes e della configurazione del tuo cluster Google Cloud.

Prerequisiti

Prima di leggere questa pagina, ti consigliamo di avere familiarità con i concetti di gestione della rete Linux e con utilità come le regole e il routing di iptables.

Inoltre, assicurati di conoscere la terminologia di base per i seguenti argomenti:

Terminologia relativa alla rete di Kubernetes

Il modello di networking di Kubernetes fa grande affidamento sugli indirizzi IP. Servizi, pod, container e nodi comunicano tramite indirizzi IP e porte. Kubernetes fornisce diversi tipi di bilanciamento del carico per indirizzare il traffico ai pod corretti. Tutti questi meccanismi sono descritti in maggiore dettaglio di seguito. Tieni presente i seguenti termini relativi agli indirizzi IP mentre leggi:

Requisiti di connettività del cluster

Tutti i cluster richiedono la connettività a *.googleapis.com,*.gcr.io e all'indirizzo IP del control plane. Questo requisito è soddisfatto dalle regole di uscita consentite implicite e dalle regole firewall create automaticamente create da GKE.

Networking all'interno del cluster

Questa sezione illustra la rete all'interno di un cluster Kubernetes in relazione all'allocazione IP, ai pod, ai servizi, al DNS e al piano di controllo.

Allocazione degli indirizzi IP

Kubernetes utilizza vari intervalli IP per assegnare indirizzi IP a nodi, pod e servizi.

Il modello di networking di GKE non consente di riutilizzare gli indirizzi IP nella rete. Quando esegui la migrazione a GKE, devi pianificare l'allocazione degli indirizzi IP per ridurre l'utilizzo degli indirizzi IP interni in GKE.

Unità massima di trasmissione (MTU)

L'MTU selezionato per un'interfaccia del pod dipende dall'interfaccia di rete del contenitore (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU della VPC sottostante. Per ulteriori informazioni, consultaPod.

Il valore MTU dell'interfaccia del pod è 1460 o ereditato dall'interfaccia principale del nodo.

CNI MTU GKE Standard
kubenet 1460 Predefinito
kubenet (GKE versione 1.26.1 e successive) Ereditato Predefinito
Calico 1460 Abilitata utilizzando --enable-network-policy. Per maggiori dettagli, vedi Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.
netd Ereditato Attivata utilizzando una delle seguenti opzioni: Visibilità tra nodi Workload Identity Federation per GKE Configurazione di rete IPv4/IPv6 dual-stack
GKE Dataplane V2 Ereditato Abilitata utilizzando --enable-dataplane-v2. Per maggiori dettagli, consulta Utilizzare GKE Dataplane V2.

Per ulteriori informazioni, consultaCluster nativi di VPC.

Componenti aggiuntivi di rete supportati

Pod

In Kubernetes, unpod è l'unità di deployment più di base all'interno di un cluster Kubernetes. Un pod esegue uno o più container. Zero o più pod vengono eseguiti su un nodo. Ogni nodo del cluster fa parte di unpool di nodi.

In GKE, questi nodi sono macchine virtuali, ciascuna in esecuzione come istanza in Compute Engine.

I pod possono anche essere collegati a volumi di archiviazione esterni e ad altre risorse personalizzate. Questo diagramma mostra un singolo nodo su cui sono in esecuzione due pod, ciascuno collegato a due volumi.

immagine

Quando Kubernetes pianifica l'esecuzione di un pod su un nodo, crea unspazio dei nomi di reteper il pod nel kernel Linux del nodo. Questo spazio dei nomi di rete collega l'interfaccia di rete fisica del nodo, ad esempio eth0, al pod utilizzando un'interfaccia di rete virtuale, in modo che i pacchetti possano fluire verso e dal pod. L'interfaccia di rete virtuale associata nello spazio dei nomi di rete principale del nodo si connette a un bridge Linux che consente la comunicazione tra i pod sullo stesso nodo. Un pod può anche inviare pacchetti all'esterno del nodo utilizzando la stessa interfaccia virtuale.

Kubernetes assegna un indirizzo IP (l'indirizzo IP del pod) all'interfaccia di rete virtuale nel nome dello spazio di rete del pod da un intervallo di indirizzi riservati ai pod sul nodo. Questo intervallo di indirizzi è un sottoinsieme dell'intervallo di indirizzi IP assegnato al cluster per i pod, che puoi configurare quando crei un cluster.

Un container in esecuzione in un pod utilizza lo spazio dei nomi di rete del pod. Dal punto di vista del container, il pod sembra essere una macchina fisica con un'interfaccia di rete. Tutti i container nel pod vedono la stessa interfaccia di rete.localhost di ogni contenitore è connesso, tramite il pod, all'interfaccia di rete fisica del nodo, ad esempio eth0.

Tieni presente che questa connettività è molto diversa a seconda che tu utilizzi CNI (Container Network Interface) di GKE o scelga di utilizzare l'implementazione di Calico attivando il criterio di rete quando crei il cluster.

arp -n

L'esecuzione del seguente comando nel contenitore della cassetta degli attrezzi mostra la parte dello spazio dei nomi principale di ogni coppia veth collegata a cbr0: 

brctl show cbr0  
arp -n

L'esecuzione del seguente comando nel contenitore della cassetta degli attrezzi mostra che non esiste un dispositivo bridge Linux denominato cbr0: 

brctl show

Le regole iptables che facilitano il forwarding all'interno del cluster differiscono da uno scenario all'altro. È importante tenere presente questa distinzione durante la risoluzione dettagliata dei problemi di connettività.

Per impostazione predefinita, ogni pod ha accesso non filtrato a tutti gli altri pod in esecuzione su tutti i nodi del cluster, ma puoi limitare l'accesso tra i pod. Kubernetes elimina regolarmente e ricrea i pod. Ciò accade quando viene eseguito l'upgrade di un pool di nodi, quando viene modificata la configurazione dichiarativa del pod o l'immagine di un container o quando un nodo diventa non disponibile. Pertanto, l'indirizzo IP di un pod è un dettaglio di implementazione e non devi basarti su di esso. Kubernetes fornisce indirizzi IP stabili utilizzandoServices.

Servizi

In Kubernetes, puoi assegnare coppie chiave-valore arbitrarie chiamateetichette a qualsiasi risorsa Kubernetes. Kubernetes utilizza le etichette per raggruppare più pod correlati in un'unità logica chiamata servizio. Un servizio ha un indirizzo IP e porte stabili e fornisce il bilanciamento del carico tra l'insieme di pod le cui etichette corrispondono a tutte le etichette che definisci nel selettore di etichette quando crei il servizio.

Il seguente diagramma mostra due servizi distinti, ciascuno composto da più pod. Ognuno dei pod nel diagramma ha l'etichetta app=demo, ma le altre etichette sono diverse. "Frontend" del servizio corrisponde a tutti i pod con app=demo e component=frontend, mentre "Utenti" del servizio corrisponde a tutti i pod con app=demo e component=users. Il pod client non corrisponde esattamente a nessuno dei valori di Service selector, pertanto non fa parte di nessuno dei servizi. Tuttavia, il pod client può comunicare con uno dei servizi perché viene eseguito nello stesso cluster.

immagine

Kubernetes assegna un indirizzo IP stabile e affidabile a ogni servizio appena creato (ClusterIP) dal pool di indirizzi IP dei servizi disponibili del cluster. Kubernetes assegna anche un nome host a ClusterIP, aggiungendo unavoce DNS. ClusterIP e il nome host sono univoci all'interno del cluster e non cambiano durante il ciclo di vita del servizio. Kubernetes rilascia ClusterIP e il nome host solo se il servizio viene eliminato dalla configurazione del cluster. Puoi accedere a un pod funzionante che esegue la tua applicazione utilizzando ClusterIP o l'hostname del servizio.

A prima vista, un servizio potrebbe sembrare un single point of failure per le tue applicazioni. Tuttavia, Kubernetes distribuisce il traffico nel modo più uniforme possibile tra l'intero insieme di pod in esecuzione su molti nodi, in modo che un cluster possa resistere a un'interruzione che interessa uno o più (ma non tutti) nodi.

Kube-Proxy

Kubernetes gestisce la connettività tra pod e servizi utilizzando il componente kube-proxy, che tradizionalmente viene eseguito come pod statico su ogni nodo.

kube-proxy, che non è un proxy in linea, ma un controller di bilanciamento del carico in base all'uscita, monitora il server API Kubernetes e mappa continuamente ClusterIP ai pod sani aggiungendo e rimuovendo le regole NAT (DNAT) di destinazione al sottosistema iptables del nodo. Quando un contenitore in esecuzione in un pod invia traffico all'indirizzo ClusterIP di un servizio, il nodo seleziona un pod in modo casuale e instrada il traffico a quel pod.

Quando configuri un servizio, puoi eventualmente rimappare la relativa porta di ascolto definendo i valori per port e targetPort.

kube-proxy gestisce questo rimappamento delle porte aggiungendo e rimuovendo regole iptables sul nodo.

Questo diagramma illustra il flusso di traffico da un pod client a un pod server su un nodo diverso. Il client si connette al Servizio all'indirizzo 172.16.12.100:80. Il server API Kubernetes gestisce un elenco di pod che eseguono l'applicazione. Il processo kube-proxy su ogni nodo utilizza questo elenco per creare una regola iptables per indirizzare il traffico a un pod appropriato (ad esempio 10.255.255.202:8080). Il pod client non deve essere a conoscenza della topologia del cluster o di dettagli sui singoli pod o contenitori al suo interno.

immagine

Il modo in cui kube-proxy viene disegnato dipende dalla versione GKE del cluster:

DNS

GKE fornisce le seguenti opzioni DNS del cluster gestito per risolvere i nomi di servizio e i nomi esterni:

GKE fornisce inoltre NodeLocal DNSCache come componente aggiuntivo facoltativo con kube-dns o Cloud DNS per migliorare le prestazioni del DNS del cluster.

Per scoprire di più su come GKE fornisce il DNS, consultaService Discovery e DNS.

Piano di controllo

In Kubernetes, il piano di controllogestisce i processi del piano di controllo, incluso il server API Kubernetes. Il modo in cui accedi al piano di controllo dipende da come hai configurato l'isolamento della rete del piano di controllo.

Networking al di fuori del cluster

Questa sezione spiega come il traffico proveniente dall'esterno del cluster raggiunge le applicazioni in esecuzione all'interno di un cluster Kubernetes. Queste informazioni sono importanti per la progettazione delle applicazioni e dei workload del cluster.

Hai già letto di come Kubernetes utilizza i servizi per fornire indirizzi IP stabili per le applicazioni in esecuzione all'interno dei pod. Per impostazione predefinita, i pod non espongono un indirizzo IP esterno, perché kube-proxy gestisce tutto il traffico su ogni nodo. I pod e i relativi contenitori possono comunicare liberamente, ma le connessioni esterne al cluster non possono accedere al servizio. Ad esempio, nell'illustrazione precedente, i client esterni al cluster non possono accedere al servizio frontend utilizzando il relativo ClusterIP.

GKE fornisce tre diversi tipi di bilanciatori del carico per controllare l'accesso e distribuire il traffico in entrata nel cluster nel modo più uniforme possibile. Puoi configurare un servizio in modo che utilizzi più tipi di bilanciatori del carico contemporaneamente.

Quando il traffico raggiunge un nodo Kubernetes, viene gestito allo stesso modo, indipendentemente dal tipo di bilanciatore del carico. Il bilanciatore del carico non è a conoscenza di quali nodi nel cluster eseguono pod per il servizio. ma bilancia il traffico su tutti i nodi del cluster, anche su quelli su cui non è in esecuzione un pod pertinente. In un cluster regionale, il carico viene distribuito su tutti i nodi di tutte le zone della regione del cluster. Quando il traffico viene indirizzato a un nodo, il nodo lo inoltra a un pod, che può essere in esecuzione sullo stesso nodo o su un altro. Il nodo inoltra il traffico a un pod scelto in modo casuale utilizzando le regole iptables gestite da kube-proxy sul nodo.

Nel diagramma seguente, il bilanciatore del carico di rete passthrough esterno indirizza il traffico al nodo intermedio, che viene reindirizzato a un pod sul primo nodo.

immagine

Quando un bilanciatore del carico invia traffico a un nodo, il traffico potrebbe essere inoltrato a un pod su un altro nodo. Ciò richiede hop di rete aggiuntivi. Se vuoi evitare gli hop aggiuntivi, puoi specificare che il traffico deve essere indirizzato a un pod che si trova sullo stesso nodo che lo riceve inizialmente.

Per specificare che il traffico deve essere indirizzato a un pod sullo stesso nodo, impostaexternalTrafficPolicy su Local nel manifest del servizio:

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: demo
    component: users
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Quando imposti externalTrafficPolicy su Local, il bilanciatore del carico invia il traffico solo ai nodi con un pod integro che appartiene al servizio. Il bilanciatore del carico utilizza un controllo di integrità per determinare quali nodi contengono i pod appropriati.

Bilanciatore del carico esterno

Se il servizio deve essere raggiungibile dall'esterno del cluster e della rete VPC, puoi configurarlo come LoadBalancer impostando il campo type del servizio su Loadbalancer quando lo definisci. GKE esegue quindi il provisioning di unbilanciatore del carico di rete passthrough esterno davanti al servizio. Il bilanciatore del carico di rete passthrough esterno è a conoscenza di tutti i nodi del cluster e configura le regole del firewall della rete VPC per consentire le connessioni al servizio dall'esterno della rete VPC utilizzando l'indirizzo IP esterno del servizio. Puoi assegnare un indirizzo IP esterno statico al servizio.

Per ulteriori informazioni, consulta la pagina sulla configurazione dei nomi di dominio con indirizzi IP statici.

Per scoprire di più sulle regole firewall, consultaRegole firewall create automaticamente.

Dettagli tecnici

Quando utilizzi il bilanciatore del carico esterno, il traffico in arrivo viene inizialmente indirizzato a un nodo utilizzando una regola di forwarding associata alla rete. Google Cloud Una volta che il traffico raggiunge il nodo, quest'ultimo utilizza la propria tabella NAT iptables per scegliere un pod. kube-proxy gestisce le regole iptables sul nodo.

Bilanciatore del carico interno

Per il traffico che deve raggiungere il cluster dalla stessa rete VPC, puoi configurare il servizio per eseguire il provisioning di unNetwork Load Balancer passthrough interno. Il bilanciatore del carico di rete passthrough interno sceglie un indirizzo IP dalla subnet VPC del cluster anziché un indirizzo IP esterno. Le applicazioni o i servizi all'interno della rete VPC possono utilizzare questo indirizzo IP per comunicare con i servizi all'interno del cluster.

Dettagli tecnici

Il bilanciamento del carico interno è fornito da Google Cloud. Quando il traffico raggiunge un determinato nodo, questo utilizza la propria tabella NAT iptables per scegliere un pod, anche se si trova su un altro nodo.kube-proxy gestisce le regole iptables sul nodo.

Per ulteriori informazioni sui bilanciatori del carico interni, consulta Utilizzo di un bilanciatore del carico di rete passthrough interno.

Bilanciatore del carico delle applicazioni

Molte applicazioni, come le API di servizi web RESTful, comunicano utilizzando HTTP(S). Puoi consentire ai client esterni alla tua rete VPC di accedere a questo tipo di applicazione utilizzando un Ingress Kubernetes.

Un Ingress consente di mappare i nomi host e i percorsi URL ai servizi all'interno del cluster. Quando utilizzi un bilanciatore del carico delle applicazioni, devi configurare il servizio in modo che utilizzi un NodePort e un ClusterIP. Quando il traffico accede al servizio sull'IP di un nodo in NodePort, GKE instrada il traffico a un pod integro per il servizio. Puoi specificare una porta NodePort o consentire a GKE di assegnarne una non utilizzata in modo casuale.

Quando crei la risorsa Ingress, GKE esegue il provisioning di unbilanciatore del carico delle applicazioni esternonel Google Cloud progetto. Il bilanciatore del carico invia una richiesta all'indirizzo IP di un nodo in NodePort. Una volta che la richiesta raggiunge il nodo, quest'ultimo utilizza la tabella NATiptables per scegliere un pod. kube-proxy gestisce le regole iptables sul nodo.

Questa definizione di Ingress instrada il traffico per demo.example.com a un servizio denominatofrontend sulla porta 80 e demo-backend.example.com a un servizio denominatousers sulla porta 8080.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
spec:
  rules:
  - host: demo.example.com
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 80
  - host: demo-backend.example.com
    http:
      paths:
      - backend:
          service:
            name: users
            port:
              number: 8080

Per ulteriori informazioni, consulta GKE Ingress per il bilanciatore del carico delle applicazioni.

Dettagli tecnici

Quando crei un oggetto Ingress, il controller Ingress di GKE configura un bilanciatore del carico delle applicazioni in base alle regole nel manifest Ingress e nei manifest del servizio associati. Il client invia una richiesta all'Application Load Balancer. Il bilanciatore del carico è un proxy effettivo; sceglie un nodo e inoltra la richiesta alla combinazione NodeIP:NodePort del nodo. Il nodo utilizza la propria tabella NAT iptables per scegliere un pod.kube-proxy gestisce le regole iptables sul nodo.

Sicurezza Networking

Per migliorare la sicurezza del cluster, puoi limitare la connettività tra i nodi, tra i pod e ai bilanciatori del carico.

Limita la connettività tra i nodi

La creazione di regole firewall in entrata o in uscita che hanno come target i nodi del cluster potrebbe avere effetti negativi. Ad esempio, l'applicazione di regole di rifiuto in uscita ai nodi del tuo cluster potrebbe causare il malfunzionamento di funzionalità come NodePort e kubectl exec.

Limitare la connettività a pod e servizi

Per impostazione predefinita, tutti i pod in esecuzione nello stesso cluster possono comunicare liberamente. Tuttavia, puoi limitare la connettività all'interno di un cluster in diversi modi, a seconda delle tue esigenze.

Limita l'accesso tra i pod

Puoi limitare l'accesso tra i pod utilizzando uncriterio di rete. Le definizioni dei criteri di rete consentono di limitare il traffico in entrata e in uscita dei pod in base a una combinazione arbitraria di etichette, intervalli IP e numeri di porta.

Per impostazione predefinita, non esiste alcun criterio di rete, pertanto tutto il traffico tra i pod nel cluster è consentito. Non appena crei il primo criterio di rete in uno spazio dei nomi, tutto l'altro traffico viene negato.

Dopo aver creato un criterio di rete, devi attivarlo esplicitamente per il cluster. Per ulteriori informazioni, consulta la pagina sullaconfigurazione dei criteri di rete per le applicazioni.

Limitare l'accesso a un bilanciatore del carico esterno

Se il servizio utilizza un bilanciatore del carico esterno, per impostazione predefinita il traffico da qualsiasi indirizzo IP esterno può accedere al servizio. Puoi limitare gli intervalli di indirizzi IP che possono accedere agli endpoint all'interno del cluster configurando l'opzione loadBalancerSourceRanges durante la configurazione del servizio. Puoi specificare più intervalli e aggiornare la configurazione di un servizio in esecuzione in qualsiasi momento. L'istanza kube-proxy in esecuzione su ogni nodo configura le regole iptables del nodo in modo da negare tutto il traffico che non corrisponde al loadBalancerSourceRanges specificato. Inoltre, quando crei un servizio LoadBalancer, GKE crea una regola firewall VPC corrispondente per applicare queste limitazioni a livello di rete.

Limitare l'accesso a un bilanciatore del carico delle applicazioni

Se il tuo servizio utilizza un Application Load Balancer, puoi utilizzare un criterio di sicurezza di Google Cloud Armor per limitare gli indirizzi IP esterni che possono accedere al servizio e le risposte da restituire quando l'accesso viene negato a causa del criterio di sicurezza. Puoi configurareCloud Logging per registrare informazioni su queste interazioni.

Se un criterio di sicurezza di Google Cloud Armor non è sufficientemente granulare, puoi attivare Identity-Aware Proxy sui tuoi endpoint per implementare l'autenticazione e l'autorizzazione basate sugli utenti per la tua applicazione. Per ulteriori informazioni, consulta il tutorial dettagliato sulla configurazione degli acquisti in-app.

Problemi noti

Questa sezione illustra i problemi noti.

Nodo con contenitore abilitato non in grado di connettersi all'intervallo 172.17/16

Una VM node con containerd abilitato non può connettersi a un host con un indirizzo IP all'interno di 172.17/16. Per ulteriori informazioni, consultaConflitto con l'intervallo di indirizzi IP 172.17/16.

Risorse rimanenti dei cluster GKE eliminati con Private Service Connect

Se hai creato ed eliminato cluster GKE con Private Service Connect prima del 7 maggio 2024 ed hai eliminato il progetto contenente il cluster prima del cluster stesso, potresti aver divulgato le risorse Private Service Connect associate. Queste risorse rimangono nascoste e non ti consentono di eliminare le subnet associate. Se riscontri questo problema, contatta l'Google Cloud assistenza.

Passaggi successivi