Panoramica della rete

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 è rivolta agli architetti cloud e agli esperti di networking che progettano e progettano la rete per la propria organizzazione. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google 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 alla rete.

Quando utilizzi Kubernetes per orchestrare le tue applicazioni, è importante cambiare il modo in cui pensi alla progettazione di rete delle 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 le regole di filtro IP, le tabelle di routing e le regole di 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, assicurati di conoscere la terminologia di base per i seguenti argomenti:

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 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. Si tratta di un elemento temporaneo, come discusso in Pod.
  • Indirizzo IP del nodo: l'indirizzo IP assegnato a un determinato nodo.

Requisiti di networking 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 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 indirizzo 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 che GKE assegna ai pod in esecuzione su quel nodo (un blocco CIDR/24 per impostazione predefinita). Se vuoi, puoi specificare l'intervallo di IP quando crei il cluster. La funzionalità di intervallo CIDR del pod flessibile ti consente di ridurre le dimensioni dell'intervallo per gli indirizzi IP dei pod per i nodi in un node pool.
  • 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 nel pod e li collega 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 piano di controllo ha un indirizzo IP pubblico o interno in base al tipo di cluster, alla versione e alla data di creazione. Per maggiori informazioni, consulta la descrizione del control plane.

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

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, consulta Pod.

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

Abilitato 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:
GKE Dataplane V2 Ereditato

Abilitato utilizzando --enable-dataplane-v2.

Per maggiori dettagli, consulta Utilizzare GKE Dataplane V2.

Per ulteriori informazioni, consulta Cluster nativi di VPC.

Componenti aggiuntivi di rete supportati

  • Per utilizzare un plug-in di rete, devi 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, un pod è 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 un pool 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 un spazio dei nomi di rete per 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.

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

    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

  • 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 gli indirizzi MAC dei vari pod collegati a diversi dispositivi veth:

    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. Questo 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 utilizzando Services.

  1. Il bridge di rete virtuale cbr0 viene creato solo se esistono pod che impostano hostNetwork: false.↩

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 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 una voce 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 l'indirizzo 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 DNAT (NAT 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.

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

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:

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

DNS

GKE fornisce le seguenti opzioni DNS del cluster gestito per risolvere i nomi di servizio 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 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 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, 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. La modalità di accesso 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 carichi di lavoro 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 servizio in modo da utilizzare più tipi di bilanciatori del carico contemporaneamente.

  • I bilanciatori del carico esterni gestiscono il traffico proveniente dall'esterno del cluster e dalla rete VPC (Virtual Private Cloud) di Google Cloud. Utilizzano regole di inoltro associate alla rete Google 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 le regole di inoltro associate alla rete Google Cloud per indirizzare 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 è 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 a sua volta lo reindirizza 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 sullo stesso nodo che lo riceve inizialmente.

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 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 della 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 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, 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 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 un bilanciatore del carico di rete 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 gli host name 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 un Application Load Balancer esterno nel progetto Google Cloud. 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 NAT iptables 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 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

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.

Limitare 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.

Limitazione dell'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 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 sulla configurazione 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 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 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, consulta Conflitto 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'assistenza Google Cloud.

Passaggi successivi