Panoramica del networking di GKE

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

Questa pagina e il resto di questo set di documentazione sono destinati ad architetti cloud e specialisti di networking che progettano e realizzano l'architettura di rete per la loro organizzazione. Se non hai familiarità con Kubernetes o GKE o se vuoi saperne di più su un argomento più generale di GKE, consulta la documentazione di base di GKE, che tratta 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 scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Kubernetes ti consente di definire in modo dichiarativo come vengono implementate le tue applicazioni, come comunicano tra loro e con il control plane Kubernetes e come i client possono raggiungerle. Questa pagina fornisce anche informazioni su come GKE configura i servizi Google Cloud, dove è pertinente al 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 loro host. Con Kubernetes, devi pensare a come comunicano pod, servizi e client esterni, anziché a come sono connessi host o macchine virtuali (VM).

Il networking software-defined (SDN) avanzato di Kubernetes consente il routing e l'inoltro dei pacchetti per pod, servizi e nodi in diverse zone dello stesso cluster regionale. Kubernetes e Google Cloud configura dinamicamente anche 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 cluster su Google Cloud.

Prerequisiti

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

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

• Trasporto
• Internet
• Livelli dell'applicazione
• Suite di protocolli internet, inclusi HTTP e DNS

Terminologia relativa al networking 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 modo più dettagliato in seguito. Tieni a mente i seguenti termini relativi agli indirizzi IP 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 del servizio, come descritto nella sezione Servizi.
• Indirizzo IP del pod:l'indirizzo IP assegnato a un determinato pod. È effimero, come descritto in Pod.
• Indirizzo IP del nodo:l'indirizzo IP assegnato a un determinato nodo.

Requisiti di connettività del cluster

Tutti i cluster richiedono la connettività a *.googleapis.com, *.gcr.io, *.pkg.dev e all'indirizzo IP del control plane. Questo requisito è soddisfatto dalle regole implicite per il traffico in uscita e dalle regole firewall create automaticamente che GKE crea.

Networking all'interno del cluster

Questa sezione descrive il networking all'interno di un cluster Kubernetes, in relazione a allocazione IP, pod, servizi, DNS e piano di controllo.

Allocazione degli indirizzi IP

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

• A ogni nodo viene assegnato un indirizzo IP dalla rete Virtual Private Cloud (VPC) del cluster. Questo IP del nodo fornisce connettività dai componenti di controllo come kube-proxy e kubelet al server API Kubernetes. Questo indirizzo IP è la connessione del nodo al resto del cluster.

• Ogni nodo ha un pool di indirizzi IP a cui GKE assegna i pod in esecuzione su quel nodo (un blocco CIDR/24 per impostazione predefinita). Puoi specificare facoltativamente l'intervallo di IP quando crei il cluster. La funzionalità dell'intervallo CIDR dei pod flessibile consente di ridurre le dimensioni dell'intervallo per gli indirizzi IP dei pod per i nodi in un pool di nodi

• A ogni pod viene assegnato un singolo indirizzo IP dall'intervallo CIDR del pod del relativo nodo. Questo indirizzo IP è condiviso da tutti i container in esecuzione all'interno del pod e li connette ad altri pod in esecuzione nel cluster.

• A ogni servizio viene assegnato un indirizzo IP, chiamato ClusterIP, dalla rete VPC del cluster. Se vuoi, puoi personalizzare la rete VPC quando crei il cluster.

• Ogni control plane ha un indirizzo IP pubblico o interno in base al tipo di cluster, alla versione e alla data di creazione. Per maggiori informazioni, vedi la descrizione del control plane.

Il modello di networking GKE non consente il riutilizzo degli 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 selezionata per un'interfaccia pod dipende dall'interfaccia di rete container (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU VPC sottostante. Per ulteriori informazioni, consulta la sezione Pod.

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

Per maggiori informazioni, consulta Cluster nativi di VPC.

Plug-in di rete supportati

• Per utilizzare un plug-in di rete, devi installarlo personalmente. 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 piano dati gestito per GKE Enterprise)

Pod

In Kubernetes, un pod è l'unità di deployment più semplice all'interno di un cluster Kubernetes. Un pod esegue uno o più container. Su un nodo vengono eseguiti zero o più pod. Ogni nodo del cluster fa parte di un node pool.

In GKE, questi nodi sono macchine virtuali, ognuna delle quali viene eseguita 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 che esegue due pod, ciascuno collegato a due volumi.

Quando Kubernetes pianifica l'esecuzione di un pod su un nodo, crea uno spazio dei nomi di rete per il pod nel kernel Linux del nodo. Questo spazio dei nomi di rete connette 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 nello spazio dei nomi 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 appare come una macchina fisica con un'interfaccia di rete. Tutti i container nel pod vedono la stessa interfaccia di rete. Il localhost di ogni container è connesso, tramite il pod, all'interfaccia di rete fisica del nodo, ad esempio eth0.

Tieni presente che questa connettività varia notevolmente a seconda che utilizzi l'interfaccia di rete dei container (CNI) di GKE o che scelga di utilizzare l'implementazione di Calico attivando Policy di rete quando crei il cluster.

• Se utilizzi CNI di GKE, un'estremità della coppia di dispositivi Ethernet virtuali (veth) è collegata al pod nel relativo spazio dei nomi, mentre l'altra è connessa al dispositivo bridge Linux cbr0.¹ In questo caso, il seguente comando mostra i vari indirizzi MAC dei pod collegati a cbr0:

  arp -n
  

  L'esecuzione del seguente comando nel container toolbox mostra la fine dello spazio dei nomi root di ogni coppia veth collegata a cbr0:

  brctl show cbr0
  

• Se il criterio di rete è attivato, un'estremità della coppia veth è collegata al pod e l'altra a eth0. In questo caso, il seguente comando mostra i vari indirizzi MAC dei pod collegati a diversi dispositivi veth:

  arp -n
  

  L'esecuzione del seguente comando nel container toolbox mostra che non esiste un dispositivo bridge Linux denominato cbr0:

  brctl show
  

Le regole iptables che facilitano l'inoltro all'interno del cluster variano 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 tutti i nodi del cluster, ma puoi limitare l'accesso tra i pod. Kubernetes smantella e ricrea regolarmente i pod. Ciò si verifica quando viene eseguito l'upgrade di un pool di nodi, quando viene modificata la configurazione dichiarativa del pod o l'immagine di un container oppure quando un nodo non è più disponibile. Pertanto, l'indirizzo IP di un pod è un dettaglio di implementazione e non dovresti farvi affidamento. Kubernetes fornisce indirizzi IP stabili utilizzando i servizi.

Servizi

In Kubernetes, puoi assegnare coppie chiave-valore arbitrarie chiamate etichette 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 definite nel selettore etichetta quando crei il servizio.

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

Kubernetes assegna un indirizzo IP stabile e affidabile a ogni servizio appena creato (ClusterIP) dal pool di indirizzi IP di servizio disponibili del cluster. Kubernetes assegna anche un nome host a ClusterIP, aggiungendo una voce DNS. ClusterIP e nome host sono univoci all'interno del cluster e non cambiano durante il ciclo di vita del servizio. Kubernetes rilascia solo ClusterIP e nome host se il servizio viene eliminato dalla configurazione del cluster. Puoi raggiungere un pod integro che esegue la tua applicazione utilizzando ClusterIP o 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 insieme di pod, in esecuzione su molti nodi, in modo che un cluster possa resistere a un'interruzione che interessa uno o più nodi (ma non tutti).

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 inline, ma un controller di bilanciamento del carico basato sull'uscita, monitora il server API Kubernetes e mappa continuamente ClusterIP ai pod integri aggiungendo e rimuovendo regole NAT di destinazione (DNAT) al sottosistema iptables del nodo. Quando un container in esecuzione in un pod invia traffico al ClusterIP di un servizio, il nodo seleziona un pod in modo casuale e instrada il traffico a quel pod.

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

• port è il punto in cui i client raggiungono l'applicazione.
• targetPort è la porta in cui l'applicazione è effettivamente in ascolto del traffico all'interno del pod.

kube-proxy gestisce questa rimappatura delle porte aggiungendo e rimuovendo regole iptables sul nodo.

Questo diagramma mostra 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 su singoli pod o contenitori al loro interno.

La modalità di deployment di kube-proxy dipende dalla versione GKE del cluster:

• Per le versioni GKE 1.16.0 e 1.16.8-gke.13, kube-proxy viene implementato come DaemonSet.
• Per le versioni di GKE successive alla 1.16.8-gke.13, kube-proxy viene implementato come pod statico per i nodi.

DNS

GKE fornisce le seguenti opzioni DNS del cluster gestito per risolvere i nomi dei servizi e i 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, consulta la sezione Utilizzo di kube-dns.

• Cloud DNS: un'infrastruttura DNS del cluster gestita dal cloud che sostituisce kube-dns nel cluster. Per maggiori informazioni, consulta Utilizzare Cloud DNS per GKE.

GKE fornisce anche 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, consulta Service Discovery e DNS.

Piano di controllo

In Kubernetes, il control plane gestisce i processi del control plane, incluso il server API Kubernetes. Il modo in cui accedi al control plane dipende da come hai configurato l'isolamento di rete del control plane.

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 quando progetti le applicazioni e i 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 container 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 Service in modo che utilizzi più tipi di bilanciatori del carico contemporaneamente.

• I bilanciatori del carico esterni gestiscono il traffico proveniente dall'esterno del cluster e della tua rete VPC Google Cloud. Utilizzano regole di forwarding associate alla reteGoogle Cloud per instradare il traffico a un nodo Kubernetes.
• I bilanciatori del carico interni gestiscono il traffico proveniente dalla stessa rete VPC. Come i bilanciatori del carico esterni, utilizzano regole di forwarding associate alla rete Google Cloud per instradare il traffico a un nodo Kubernetes.
• I bilanciatori del carico delle applicazioni sono bilanciatori del carico esterni specializzati utilizzati per il traffico HTTP(S). Utilizzano una risorsa Ingress anziché 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 dal tipo di bilanciatore del carico. Il bilanciatore del carico non sa quali nodi nel cluster eseguono i pod per il suo servizio. ma bilancia il traffico su tutti i nodi del cluster, anche quelli che non eseguono un pod pertinente. In un cluster regionale, il carico viene distribuito su tutti i nodi in tutte le zone della regione del cluster. Quando il traffico viene indirizzato a un nodo, il nodo lo indirizza 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 seguente diagramma, il bilanciatore del carico di rete passthrough esterno indirizza il traffico al nodo centrale e il traffico viene reindirizzato a un pod sul primo nodo.

Quando un bilanciatore del carico invia traffico a un nodo, il traffico potrebbe essere inoltrato a un pod su un nodo diverso. 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 riceve inizialmente il traffico.

Per specificare che il traffico deve essere indirizzato a un pod sullo stesso nodo, imposta externalTrafficPolicy 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 che hanno un pod integro appartenente 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 tuo servizio deve essere raggiungibile dall'esterno del cluster e della tua rete VPC, puoi configurarlo come LoadBalancer impostando il campo type del servizio su Loadbalancer quando lo definisci. GKE esegue quindi il provisioning di un bilanciatore del carico di rete passthrough esterno davanti al servizio. Il bilanciatore del carico di rete pass-through esterno è a conoscenza di tutti i nodi del cluster e configura le regole 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 Configurazione dei nomi di dominio con indirizzi IP statici.

Per scoprire di più sulle regole firewall, consulta Regole 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 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 dall'interno della stessa rete VPC, puoi configurare il servizio in modo da eseguire il provisioning di un bilanciatore del carico di rete pass-through 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 sua tabella NAT iptables per scegliere un pod, anche se si trova su un nodo diverso. kube-proxy gestisce le regole iptables sul nodo.

Per ulteriori informazioni sui bilanciatori del carico interni, vedi 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 a questo tipo di applicazione utilizzando una risorsa Ingress di Kubernetes.

Una risorsa 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, nonché un ClusterIP. Quando il traffico accede al servizio sull'IP di un nodo alla porta NodePort, GKE instrada il traffico a un pod integro per il servizio. Puoi specificare un NodePort o consentire a GKE di assegnare una porta inutilizzata casuale.

Quando crei la risorsa Ingress, GKE esegue il provisioning di un bilanciatore del carico delle applicazioni esterno nel progetto Google Cloud . Il bilanciatore del carico invia una richiesta all'indirizzo IP di un nodo sulla porta NodePort. Dopo che la richiesta raggiunge il nodo, quest'ultimo utilizza la sua tabella NAT iptables 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 la pagina GKE Ingress per il bilanciatore del carico delle applicazioni per saperne di più.

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 dei servizi associati. Il client invia una richiesta al bilanciatore del carico delle applicazioni. Il bilanciatore del carico è un proxy effettivo; sceglie un nodo e inoltra la richiesta alla combinazione NodeIP:NodePort di quel nodo. Il nodo utilizza la 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.

Limitare la connettività tra i nodi

La creazione di regole firewall in entrata o in uscita destinate ai nodi del cluster potrebbe avere effetti negativi. Ad esempio, l'applicazione di regole di negazione dell'uscita ai nodi del cluster potrebbe interrompere 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.

Limitare l'accesso tra i pod

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

Per impostazione predefinita, non esistono criteri 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 il resto del traffico viene negato.

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

Limitare l'accesso a un bilanciatore del carico esterno

Se il tuo servizio utilizza un bilanciatore del carico esterno, il traffico proveniente da qualsiasi indirizzo IP esterno può accedere al tuo servizio per impostazione predefinita. 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 puoi 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 per negare tutto il traffico che non corrisponde a 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 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 tuo servizio e le risposte da restituire quando l'accesso viene negato a causa del criterio di sicurezza. Puoi configurare Cloud Logging per registrare informazioni su queste interazioni.

Se un criterio di sicurezza di Google Cloud Armor non è sufficientemente granulare, puoi attivare Identity-Aware Proxy sugli endpoint per implementare l'autenticazione e l'autorizzazione basate sull'utente per la tua applicazione. Per ulteriori informazioni, consulta il tutorial dettagliato per la configurazione di IAP.

Problemi noti

Questa sezione tratta i problemi noti.

Il nodo abilitato per i container non riesce a connettersi all'intervallo 172.17/16

Una VM nodo con containerd abilitato non può connettersi a un host con un IP all'interno di 172.17/16. Per saperne di più, consulta 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 e hai eliminato il progetto contenente il cluster prima del cluster stesso, potresti aver divulgato risorse Private Service Connect associate. Queste risorse rimangono nascoste e non ti consentono di eliminare le subnet associate. Se riscontri questo problema, contatta l'assistenzaGoogle Cloud .

Passaggi successivi

• Scopri di più sui servizi.
• Scopri di più sui pod.
• Configura un cluster con VPC condiviso.