Questa pagina fornisce una guida agli aspetti principali di Google Kubernetes Engine (GKE) networking. Queste informazioni sono utili a chi ha appena iniziato con Kubernetes, nonché con operatori cluster o applicazioni con esperienza agli sviluppatori che hanno bisogno di maggiori conoscenze sul networking Kubernetes progettare meglio le applicazioni o configurare carichi di lavoro Kubernetes.
Questa pagina è rivolta agli specialisti di Cloud Architect e Networking che progettare e progettare la rete per la propria organizzazione. 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.
Kubernetes consente di definire in modo dichiarativo il modo in cui viene eseguito il deployment delle il modo in cui le applicazioni comunicano tra loro e con il e il modo in cui i client possono raggiungere le tue applicazioni. Questa pagina fornisce inoltre informazioni su come GKE configura Google Cloud e servizi correlati, ove siano pertinenti per il networking.
Quando utilizzi Kubernetes per orchestrare le tue applicazioni, è importante cambiare il tuo modo di pensare alla progettazione di rete delle tue applicazioni e ai relativi . Con Kubernetes, puoi pensare a come pod, servizi e client esterni anziché pensare a come i tuoi host o le tue macchine virtuali (VM) sono connessi.
Kubernetes il routing dei pacchetti tramite networking software-defined (SDN) avanzato e l'inoltro di pod, servizi e nodi in zone diverse nello stesso a livello di regione. Kubernetes e Google Cloud configurano anche dinamicamente le regole di filtro IP, le tabelle di routing e le regole del firewall su ogni nodo, a seconda del modello dichiarativo dei deployment di Kubernetes e della configurazione del cluster su 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, è bene acquisire familiarità con la terminologia di base per i seguenti argomenti:
Terminologia relativa agli indirizzi IP in Kubernetes
Il modello di networking di Kubernetes fa grande affidamento sugli indirizzi IP. Servizi, Pod, container e nodi comunicano tramite indirizzi IP porte. Kubernetes offre diversi tipi di carichi di lavoro per indirizzare il traffico ai pod corretti. Tutti questi questi meccanismi sono descritti più dettagliatamente in seguito. Conserva i seguenti termini a mente mentre leggi:
- ClusterIP:l'indirizzo IP assegnato a un servizio. In altri documenti, potrebbe essere chiamato "IP cluster". Questo indirizzo è stabile per tutta la durata di dal Servizio, come descritto nella sezione Servizi.
- Indirizzo IP del pod: l'indirizzo IP assegnato a un determinato pod. Si tratta di un'operazione temporanea, come descritto nei Pod.
- Indirizzo IP del nodo: l'indirizzo IP assegnato a un determinato nodo.
Requisiti di networking del cluster
Sia i cluster pubblici che quelli privati richiedono la connettività a *.googleapis.com
,
*.gcr.io
e l'indirizzo IP del piano di controllo. Questo requisito è soddisfatto
dal
regole di autorizzazione in uscita implicite e
il
regole firewall create automaticamente
creati da GKE.
Per i cluster pubblici, se aggiungi regole firewall che negano il traffico in uscita con una
devi creare regole firewall per consentire *.googleapis.com
,
*.gcr.io
e l'indirizzo IP del piano di controllo.
Per ulteriori informazioni sui requisiti dei cluster privati, consulta Requisiti, restrizioni e limitazioni.
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.
Assegnazione IP
Kubernetes usa vari intervalli IP per assegnare indirizzi IP a nodi, pod Servizi.
- A ogni nodo è assegnato un indirizzo IP
una rete VPC (Virtual Private Cloud). Questo indirizzo IP del nodo fornisce connettività dai componenti di controllo come
kube-proxy
ekubelet
al server API Kubernetes. Questo indirizzo IP è la connessione del nodo al resto del cluster. - Ogni nodo ha un pool di indirizzi IP che GKE assegna i pod in esecuzione su quel nodo (un Blocco CIDR/24 per impostazione predefinita). Facoltativamente, puoi specificare l'intervallo di IP quando devi creare il cluster. L'operazione Funzionalità per l'intervallo CIDR dei pod flessibile consente di ridurre la dimensione dell'intervallo per gli indirizzi IP dei pod per i nodi in un pool di nodi.
- Ogni pod ha un singolo indirizzo IP assegnato dall'intervallo CIDR pod del relativo nodo. Questo indirizzo IP è condiviso da tutti i container in esecuzione nel pod. li connette ad altri pod in esecuzione nel cluster.
- Ogni servizio ha un indirizzo IP, chiamato ClusterIP, che viene assegnato alla rete VPC del cluster. Facoltativamente, puoi personalizzare rete VPC quando crei il cluster.
- Ogni piano di controllo ha un indirizzo IP pubblico o interno in base al tipo di il cluster, la versione e la data di creazione. Per maggiori informazioni delle informazioni, vedi la descrizione del piano di controllo.
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.
MTU
La MTU selezionata per l'interfaccia di un pod dipende dalla rete di container Interfaccia (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU VPC sottostante. Per ulteriori informazioni, vedi Pod.
Il valore MTU dell'interfaccia del pod è 1460
o ereditato dall'istanza principale
all'interfaccia del Nodo.
CNI | MTU | GKE Standard |
---|---|---|
Kubernetes | 1460 | Predefinito |
kubenet (GKE 1.26.1 e versioni successive) |
Ereditato | Predefinito |
Calico | 1460 |
Attivazione tramite Per maggiori dettagli, vedi Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete. |
netd | Ereditato | Attivata utilizzando una delle seguenti opzioni: |
GKE Dataplane V2 | Ereditato |
Attivazione tramite Per maggiori dettagli, consulta Utilizzare GKE Dataplane V2. |
Per ulteriori informazioni, vedi Cluster nativi VPC.
Plug-in di rete supportati
- Per utilizzare un plug-in di rete, è necessario installarlo autonomamente. GKE offre i seguenti plug-in di rete supportati in modo nativo:
- Calico (in Dataplane V1)
- Cilium (in Dataplane V2)
- Istio-CNI (nel controller del dataplane gestito per GKE Enterprise)
Pod
In Kubernetes, Il pod è il più semplice di cui è possibile eseguire il deployment all'interno di un cluster Kubernetes. Un pod esegue uno o più container. Su un nodo vengono eseguiti zero o più pod. Ogni nodo nel cluster fa parte pool di nodi.
Nel GKE, questi nodi sono macchine virtuali, ciascuna in esecuzione come in Compute Engine.
I pod possono anche collegarsi a volumi di archiviazione esterni e altre risorse personalizzate. Questo diagramma mostra un singolo nodo che esegue due pod, ciascuno collegato a due volumi.
Quando Kubernetes pianifica l'esecuzione di un pod su un nodo, crea una
spazio dei nomi di rete
per il pod nel kernel Linux del nodo. Questo spazio dei nomi di rete connette
all'interfaccia di rete fisica del nodo, come eth0
, con il pod che utilizza
di rete, in modo che i pacchetti possano passare da e verso il pod. L'attributo associato
l'interfaccia della rete virtuale nello spazio dei nomi della rete principale del nodo
Bridge Linux che consente la comunicazione tra i pod sullo stesso nodo. Un pod può
e 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 per i pod, che puoi configurare durante la creazione di un cluster.
Un container in esecuzione in un pod utilizza lo spazio dei nomi di rete del pod. Da
dal punto di vista del container, il pod sembra essere una macchina fisica
a riga di comando gcloud. Tutti i container nel pod vedono la stessa interfaccia di rete.
L'elemento localhost
di ogni container è connesso, tramite il pod, alla rete
di rete fisica, ad esempio eth0
.
Tieni presente che questa connettività varia drasticamente a seconda che utilizzi o meno Container Network Interface (CNI) di GKE o scegliere usare l'implementazione di Calico abilitando Criterio di rete quando crei il cluster.
Se utilizzi la CNI di GKE, un'estremità del modulo La coppia di dispositivi (veth) è collegata al pod nello spazio dei nomi, mentre l'altra è connesso al dispositivo bridge Linux
cbr0
.1 In questo caso, viene eseguita la seguente che mostra i vari pod Indirizzi MAC collegati acbr0
:arp -n
L'esecuzione del seguente comando nel container degli strumenti mostra la fine dello spazio dei nomi principale di ogni coppia di vettore associata a
cbr0
:brctl show cbr0
Se il criterio di rete è abilitato, un'estremità della coppia di partner è collegata alla e l'altro a
eth0
. In questo caso, il comando seguente mostra di vari pod Indirizzi MAC collegati a diversi dispositivi Windows:arp -n
L'esecuzione del seguente comando nel container degli strumenti mostra che non esiste un dispositivo bridge Linux denominato
cbr0
:brctl show
Le regole iptables che facilitano l'inoltro all'interno del cluster sono diverse 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 senza filtri a tutti gli altri pod in esecuzione su nodi del cluster, ma puoi limitare l'accesso tra i pod. Kubernetes elimina regolarmente e ricrea i pod. Questo accade quando viene eseguito l'upgrade di un pool di nodi, quando si modifica La configurazione dichiarativa del pod o la modifica dell'immagine di un container oppure quando diventa non disponibile. Di conseguenza, l'indirizzo IP di un pod è un dettaglio di implementazione, e non dovresti farvi affidamento. Kubernetes fornisce indirizzi IP stabili Servizi.
-
Il bridge di rete virtuale
cbr0
viene creato solo se sono presenti pod che impostahostNetwork: false
.↩
Servizi
In Kubernetes, puoi assegnare coppie chiave-valore arbitrarie chiamate etichette su qualsiasi di una risorsa Kubernetes. Kubernetes usa le etichette per raggruppare più pod correlati in un'unità logica chiamata Service. Un servizio ha un indirizzo IP e porte stabili e fornisce il bilanciamento del carico tra l'insieme di pod con etichette le etichette che definisci selettore etichette quando crei il Servizio.
Il seguente diagramma mostra due Servizi distinti, ognuno dei quali è composto
e più pod. Ciascuno 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 del client non corrisponde a nessun servizio
selettore, quindi non fa parte di nessuno dei due servizi. Tuttavia, il pod client
può comunicare con uno dei due servizi perché viene eseguito nello stesso cluster.
Kubernetes assegna un indirizzo IP stabile e affidabile a ogni servizio appena creato (ClusterIP) dal pool di IP di servizio disponibili per il cluster indirizzi IP. Kubernetes assegna anche un nome host a ClusterIP, aggiungendo un'etichetta Voce DNS. Il ClusterIP e il nome host sono univoci all'interno del cluster e non cambiano durante l'intero ciclo di vita del servizio. Kubernetes rilascia solo il cluster ClusterIP e nome host se il servizio viene eliminato dalla configurazione del cluster. Puoi raggiungere un pod integro che esegue la tua applicazione utilizzando il nome host 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 nell'intero set di pod, in esecuzione su molti nodi, in modo che un cluster possa un'interruzione che interessa uno o più nodi (ma non tutti).
Kube-Proxy
Kubernetes gestisce la connettività tra pod e servizi utilizzando kube-proxy
, che tradizionalmente viene eseguito come pod statico su ciascun nodo.
kube-proxy
, che non è un proxy in linea, ma basato su traffico in uscita
di bilanciamento del carico, controlla il server API Kubernetes e continua
mappa il ClusterIP a pod in stato integro aggiungendo e rimuovendo il NAT di destinazione (DNAT)
le regole 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
.
port
è la posizione in cui i client raggiungono l'applicazione.targetPort
è la porta su cui l'applicazione sta effettivamente ascoltando del traffico all'interno del pod.
kube-proxy
gestisce la rimappatura di questa porta aggiungendo e rimuovendo iptables
regole
sul nodo.
Questo diagramma illustra il flusso di traffico da un pod del client a un pod del 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 dei pod che eseguono l'applicazione. La
Il processo kube-proxy
su ciascun 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 cliente
Non è necessario che il pod sia a conoscenza della topologia del cluster o di eventuali dettagli
su singoli pod o container al loro interno.
Il modo in cui viene eseguito il deployment di kube-proxy
dipende dalla versione GKE del
cluster:
- Per GKE versioni 1.16.0 e 1.16.8-gke.13,
kube-proxy
viene eseguito il deployment come DaemonSet. - Per le versioni GKE successive alla 1.16.8-gke.13,
kube-proxy
è il deployment come pod statico per i nodi.
DNS
GKE fornisce le seguenti opzioni DNS del cluster gestito per risolvere di servizi e nomi esterni:
kube-dns: un componente aggiuntivo del cluster di cui viene eseguito il deployment per impostazione predefinita in tutti i cluster GKE. Per ulteriori informazioni, vedi Utilizzo di kube-dns.
Cloud DNS: un'infrastruttura DNS del cluster gestita su cloud che sostituisce a kube-dns nel cluster. Per ulteriori informazioni, vedi Utilizza Cloud DNS per GKE.
GKE fornisce inoltre NodeLocal DNSCache come componente aggiuntivo facoltativo con kube-dns o Cloud DNS per migliorare le prestazioni del DNS del cluster.
Per saperne di più su come GKE fornisce il DNS, consulta Service Discovery e DNS.
Piano di controllo
In Kubernetes, il piano di controllo gestisce i processi del piano di controllo, incluso il server API Kubernetes. Il modo in cui accedi al piano di controllo dipende dalla versione del cluster GKE Autopilot o Standard.
Cluster con Private Service Connect
I cluster privati o pubblici che soddisfano una qualsiasi delle seguenti condizioni utilizzano Private Service Connect per connettere privatamente i nodi e il piano di controllo:
- Nuovi cluster pubblici nella versione 1.23 a partire dal 15 marzo 2022.
- Nuovi cluster privati nella versione 1.29 dopo il 28 gennaio 2024.
È in corso la migrazione a Private Service Connect dei cluster pubblici esistenti che non soddisfano le condizioni precedenti. Pertanto, questi cluster potrebbero già utilizzare Private Service Connect. Per verificare se il cluster utilizza Private Service Connect, esegui il
Comando gcloud container clusters describe. Se le tue
cluster pubblico utilizza Private Service Connect, privateClusterConfig
risorsa ha i seguenti valori:
- Il campo
peeringName
è vuoto o non esiste. - Al campo
privateEndpoint
è stato assegnato un valore.
Tuttavia, i cluster privati esistenti che non soddisfano le condizioni precedenti sono non ancora eseguita.
Puoi creare cluster che utilizzano Private Service Connect e modificare l'isolamento del cluster. Usa le reti autorizzate per limitare l'accesso al piano di controllo del cluster definendo le origini che possono per raggiungere il piano di controllo.
Risorse Private Service Connect utilizzate per GKE sono nascosti.
Per i cluster privati che utilizzano Private Service Connect,
Il flag --master-ipv4-cidr
è facoltativo quando si creano subnet. Se utilizzi
questo flag, GKE crea una nuova subnet che utilizza
i valori definiti in --master-ipv4-cidr
e utilizza la nuova subnet per
eseguire il provisioning dell'indirizzo IP interno per il piano di controllo.
Networking all'esterno del cluster
Questa sezione spiega come il traffico proveniente dall'esterno del cluster raggiunge le applicazioni in esecuzione in un cluster Kubernetes. Queste informazioni sono importanti quando progettando le applicazioni e i carichi di lavoro del tuo cluster.
Hai già letto come Kubernetes utilizza i servizi per fornire
e 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 tutti
traffico su ciascun nodo. I pod e i relativi container possono
comunicano liberamente, ma le connessioni esterne al cluster non possono accedere
assistenza. Ad esempio, nell'illustrazione precedente, i clienti esterni al cluster
non può accedere al servizio frontend utilizzando il relativo ClusterIP.
GKE offre tre diversi tipi di bilanciatori del carico controllare gli accessi e distribuire il traffico in entrata nel cluster in modo possibile. Puoi configurare un servizio in modo da utilizzare più tipi di bilanciatori del carico contemporaneamente.
- I bilanciatori del carico esterni gestiscono il traffico in arrivo sia dall'esterno del cluster che dall'esterno rete VPC. Utilizzano le regole di forwarding associate Rete Google Cloud per instradare il traffico a un nodo Kubernetes.
- I bilanciatori del carico interni gestiscono il traffico in entrata della stessa rete VPC. Come i bilanciatori del carico esterni, utilizza le regole di forwarding associate alla rete Google Cloud indirizzare il traffico a un nodo Kubernetes.
- I bilanciatori del carico delle applicazioni sono esterni specializzati bilanciatori del carico utilizzati per il traffico HTTP(S). Usano una risorsa Ingress anziché rispetto a una regola di forwarding per instradare il traffico a un nodo Kubernetes.
Quando il traffico raggiunge un nodo Kubernetes, viene gestito allo stesso modo, indipendentemente
del tipo di bilanciatore del carico. Il bilanciatore del carico non è a conoscenza di quali nodi
nel cluster eseguono pod per il suo servizio. Bilancia invece il traffico
in tutti i nodi nel cluster, anche quelli che non eseguono un pod pertinente. Su un
a livello di regione, il carico viene distribuito tra tutti i nodi in tutte le zone
della regione del cluster. Quando il traffico viene instradato a un nodo, quest'ultimo lo instrada.
a un pod, che potrebbe essere in esecuzione sullo stesso nodo o su un nodo diverso. Il nodo
inoltra il traffico a un pod scelto in modo casuale utilizzando le regole iptables
che kube-proxy
gestisce sul nodo.
Nel diagramma seguente, il bilanciatore del carico di rete passthrough esterno indirizza il traffico alla centrale, il traffico viene reindirizzato a un pod sul primo nodo.
Quando un bilanciatore del carico invia il traffico a un nodo, il traffico potrebbe essere inoltrato a un pod su un nodo diverso. Richiede hop di rete aggiuntivi. Se vuoi per evitare hop aggiuntivi, puoi specificare che il traffico deve essere indirizzato a un pod si trova sullo stesso nodo che riceve inizialmente il traffico.
Per specificare che il traffico deve essere indirizzato a un pod sullo stesso nodo, imposta
Da externalTrafficPolicy
a Local
nel manifest del tuo 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 verso i nodi con un pod integro che appartiene al servizio.
Il bilanciatore del carico utilizza un controllo di integrità per determinare quali nodi hanno
i pod appropriati.
Bilanciatore del carico esterno
Se il servizio deve essere raggiungibile dall'esterno del cluster e dell'esterno
rete VPC, puoi configurare il servizio come
LoadBalancer,
impostando il campo type
del servizio su Loadbalancer
quando definisci
assistenza. GKE esegue quindi il provisioning
bilanciatore del carico di rete passthrough esterno davanti al servizio.
Il bilanciatore del carico di rete passthrough esterno è a conoscenza di tutti i nodi nel cluster e configura
le regole firewall della tua rete VPC per consentire
dall'esterno della rete VPC, utilizzando
all'indirizzo IP esterno. Puoi assegnare un indirizzo IP esterno statico al servizio.
Per scoprire di più sulle regole firewall, consulta Regole firewall create automaticamente.
Dettagli tecnici
Quando si utilizza il bilanciatore del carico esterno, il traffico in arrivo viene inizialmente instradato a
su un nodo utilizzando una regola di forwarding associata alla rete Google Cloud.
Quando il traffico raggiunge il nodo, quest'ultimo utilizza la tabella NAT iptables
per
scegli 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 tuo Servizio per eseguire il provisioning bilanciatore del carico di rete passthrough interno. Il bilanciatore del carico di rete passthrough interno sceglie un indirizzo IP dal bilanciatore del carico una subnet VPC invece di un indirizzo IP esterno. Applicazioni o all'interno della rete VPC possono utilizzare questo indirizzo IP comunicare con i servizi all'interno del cluster.
Dettagli tecnici
Il bilanciamento del carico interno è fornito da Google Cloud. Quando
quando il traffico raggiunge un determinato nodo, quest'ultimo utilizza la tabella NAT iptables
per
anche se si pod su un nodo diverso.
kube-proxy
gestisce le regole iptables
sul nodo.
Per saperne di più 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 dei servizi web RESTful, comunicano tramite HTTP(S). Puoi consentire ai client esterni alla tua rete VPC di accedere di un'applicazione con un cluster Kubernetes In entrata.
Una risorsa Ingress consente di mappare nomi host e percorsi URL ai servizi all'interno del cluster. Quando utilizzi un bilanciatore del carico delle applicazioni, devi configurare il servizio in modo che utilizzi una NodePort e 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 un nodo NodePort o consentire a GKE di assegnare porta inutilizzata.
Quando crei la risorsa Ingress, GKE esegue il provisioning di un
Application Load Balancer esterno
nel progetto Google Cloud. Il bilanciatore del carico invia una richiesta
all'indirizzo IP di NodePort. Dopo che la richiesta raggiunge il nodo, quest'ultimo utilizza i suoi
iptables
tabella NAT per scegliere un pod. kube-proxy
gestisce le regole iptables
sul nodo.
Questa definizione Ingress instrada il traffico per demo.example.com
a un servizio denominato
frontend
sulla porta 80 e demo-backend.example.com
a un servizio denominato
users
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
Visita GKE Ingress per il bilanciatore del carico delle applicazioni per ulteriori informazioni.
Dettagli tecnici
Quando crei un oggetto Ingress, il controller GKE Ingress
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
una richiesta al bilanciatore del carico delle applicazioni. Il bilanciatore del carico è un proxy reale; questo elemento
sceglie un nodo e inoltra la richiesta all'oggetto NodeIP
di quel nodo:NodePort
combinazione. Il nodo utilizza la sua tabella NAT iptables
per scegliere un pod.
kube-proxy
gestisce le regole iptables
sul nodo.
Limitazione della connettività tra nodi
La creazione di regole firewall in entrata o in uscita che ha come target i nodi nel tuo cluster potrebbe avere
effetti negativi. Ad esempio, l'applicazione di regole di negazione in uscita ai nodi in
potrebbe interrompere funzionalità come NodePort
e kubectl exec
.
Limitazione della connettività a pod e servizi
Per impostazione predefinita, tutti i pod in esecuzione all'interno dello stesso cluster possono comunicare liberamente. Tuttavia, puoi limitare la connettività all'interno di un cluster in diversi modi, a seconda delle tue esigenze.
Limitare l'accesso tra i pod
Puoi limitare l'accesso tra i pod utilizzando una criterio di rete. Criterio di rete le definizioni ti 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 un criterio di rete, quindi 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, vedi Configurazione dei criteri di rete per le applicazioni.
Limitazione dell'accesso a un bilanciatore del carico esterno
Se il tuo servizio utilizza un bilanciatore del carico esterno, il traffico proveniente da qualsiasi
può accedere al tuo servizio per impostazione predefinita. Puoi limitare
Gli intervalli di indirizzi IP possono accedere agli endpoint all'interno del tuo cluster, configurando il
loadBalancerSourceRanges
durante la configurazione del servizio. Puoi specificare
e puoi aggiornare la configurazione di un servizio in esecuzione
in qualsiasi momento. L'istanza kube-proxy
in esecuzione su ciascun nodo configura
iptables
regole per negare tutto il traffico che non corrisponde a quanto specificato
loadBalancerSourceRanges
. Inoltre, quando crei un bilanciatore del carico
GKE crea un firewall VPC corrispondente
per applicare queste restrizioni a livello di rete.
Limitazione dell'accesso a un bilanciatore del carico delle applicazioni
Se il tuo servizio utilizza un bilanciatore del carico delle applicazioni, puoi: utilizzare un criterio di sicurezza di Google Cloud Armor per limitare gli indirizzi IP esterni che possono accedere al Servizio e le risposte alle torna indietro quando l'accesso viene negato a causa del criterio di sicurezza. Puoi configurare Cloud Logging per registrare le relative informazioni e interazioni.
Se un criterio di sicurezza di Google Cloud Armor non è abbastanza granulare, puoi abilitare Identity-Aware Proxy sui tuoi endpoint per implementare le di autenticazione e autorizzazione per la tua applicazione. Visita il tutorial dettagliato per la configurazione di IAP per ulteriori informazioni.
Problemi noti
Questa sezione illustra i problemi noti.
Il nodo abilitato per il container non è in grado di connettersi all'intervallo 172.17/16
Una VM nodo con containerd abilitato non può connettersi a un host con un IP
in 172.17/16
. Per ulteriori informazioni, vedi
Conflitto con l'intervallo di indirizzi IP 172.17/16.
Risorse rimanenti dai 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 e non ti consentono di eliminare le subnet associate. Se riscontri questo problema, contatta l'assistenza Google Cloud.