Panoramica della rete

Questa pagina fornisce una guida agli aspetti principali del networking di Google Kubernetes Engine (GKE). 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 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 sulle attività di esempio 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).

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, assicurati di acquisire familiarità con Concetti di gestione della rete Linux e utilità come le regole iptables e il routing.

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 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. Questo è temporaneo, 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 all'indirizzo IP del control plane. 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 del cluster privato, vedi Requisiti, limitazioni e limitazioni

Networking all'interno del cluster

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

Assegnazione IP

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

  • A ogni nodo è 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). 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 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 GKE non consente il riutilizzo degli indirizzi IP in tutta la rete. Quando esegui la migrazione a GKE, devi pianificare 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 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 versione 1.26.1 e successive) 		Ereditato Predefinito
Calico 1460

Attivazione tramite --enable-network-policy.

Per maggiori dettagli, vedi Controllare la comunicazione tra pod e servizi tramite criteri di rete.
netd Ereditato Attivata utilizzando una delle seguenti opzioni:
GKE Dataplane V2 Ereditato

Attivazione tramite --enable-dataplane-v2.

Per maggiori dettagli, consulta Utilizzo di GKE Dataplane V2.

Per ulteriori informazioni, consulta Cluster nativi di 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 del cluster fa parte di un pool di nodi.

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

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'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) alla rete virtuale interfaccia nello spazio dei nomi di rete del pod da un intervallo di indirizzi riservati ai pod nel 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. 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. 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 a cbr0:

    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 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 avere 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 viene modificata la configurazione dichiarativa del pod o l'immagine di un container o quando un nodo 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.

  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 su 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 con etichette le etichette che definisci selettore 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 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 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 raggiungere un pod integro che esegue la tua applicazione utilizzando il nome host del servizio.

A prima vista, un servizio può 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 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 facoltativamente rimapparne la porta di ascolto che definiscono i valori di port e targetPort.

  • port è il punto 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 di 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.

immagine

Il modo in cui viene eseguito il deployment di kube-proxy dipende dalla versione GKE della 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 il cui deployment viene eseguito per impostazione predefinita in cluster GKE. Per ulteriori informazioni, vedi 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 offre inoltre NodeLocal DNSCache come componente aggiuntivo facoltativo con kube-dns o Cloud DNS per migliorare il DNS del cluster le prestazioni dei dispositivi.

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. Come per accedere al piano di controllo dipende dalla versione Pilota automatico o Standard in un cluster Kubernetes.

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 tuo 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, la migrazione dei cluster privati esistenti che non soddisfano le condizioni precedenti non è stata ancora eseguita.

Puoi creare cluster che utilizzano Private Service Connect e modificare l'isolamento dei 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 durante la creazione delle 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 al di fuori 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 per la progettazione delle applicazioni e dei carichi di lavoro del 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 comunicare liberamente, ma le connessioni esterne al cluster non possono accedere al servizio. 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 per 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 le regole di forwarding associate 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, utilizza le regole di forwarding associate alla rete Google Cloud 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). 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 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 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 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 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, vedi Configurazione dei nomi di dominio con indirizzi IP statici.

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 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 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 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 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 di servizi web RESTful, comunicano utilizzando HTTP(S). Puoi consentire ai client esterni alla tua rete VPC di accedere di un'applicazione con un cluster Kubernetes In entrata.

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 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. 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 al bilanciatore del carico delle applicazioni. Il bilanciatore del carico è un proxy effettivo; sceglie un nodo e inoltra la richiesta alla combinazione NodeIP:NodePort del nodo. Il nodo utilizza la sua 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 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.

Limitazione dell'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 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 abilitarlo esplicitamente per il cluster. Per ulteriori informazioni, vedi 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 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 servizio LoadBalancer, GKE crea una regola firewall VPC corrispondente per applicare queste limitazioni a livello di rete.

Limitazione dell'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 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 node con containerd abilitato non può connettersi a un host con un indirizzo IP all'interno di 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 e hai eliminato il progetto contenente il cluster prima di quello stesso, potresti aver alle risorse Private Service Connect associate. Queste risorse rimangono e non ti consentono di eliminare le subnet associate. Se riscontri Per questo problema, contatta l'assistenza Google Cloud.

Passaggi successivi