Panoramica della rete

Autopilot Standard

---

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 gli operatori di cluster o gli sviluppatori di applicazioni esperti che hanno bisogno di una maggiore conoscenza del networking di Kubernetes per progettare meglio applicazioni o configurare carichi di lavoro Kubernetes.

Kubernetes ti permette di definire in modo dichiarativo il modo in cui viene eseguito il deployment delle tue applicazioni, il modo in cui le applicazioni comunicano tra loro e con il piano di controllo Kubernetes e in che modo i client possono raggiungere le tue applicazioni. Questa pagina fornisce anche informazioni su come GKE configura i servizi Google Cloud, ove pertinente per il networking.

Quando utilizzi Kubernetes per orchestrare le tue applicazioni, è importante cambiare il modo in cui pensi al design della rete delle tue applicazioni e dei loro host. Con Kubernetes, pensi a come comunicano i pod, i servizi e i client esterni, invece di pensare a come sono connessi i tuoi host o le tue macchine virtuali (VM).

Il networking software-defined avanzato (SDN) di Kubernetes consente il routing e l'inoltro dei pacchetti per pod, servizi e nodi in zone diverse dello stesso cluster a livello di regione. Kubernetes e Google Cloud configurano inoltre dinamicamente le regole di filtro IP, le tabelle di routing e le regole del firewall su ciascun nodo, in base al modello dichiarativo dei deployment Kubernetes e alla configurazione del cluster su Google Cloud.

Avviso: non apportare manualmente modifiche ai nodi perché vengono sostituiti da GKE e il cluster potrebbe non funzionare correttamente. L'unico motivo per accedere direttamente a un nodo è eseguire il debug dei problemi relativi alla configurazione.

Prerequisiti

Questa pagina utilizza una terminologia correlata ai livelli Transport, Internet e Applicazione della suite Internet Protocol, inclusi HTTP e DNS, ma non è necessario essere esperti di questi argomenti.

Inoltre, questi contenuti potrebbero essere più facilmente comprensibili se hai una conoscenza di base dei concetti e delle utilità di gestione della rete di Linux, come le regole e il routing iptables.

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 e porte. Kubernetes offre diversi tipi di bilanciamento del carico per indirizzare il traffico ai pod corretti. Tutti questi meccanismi sono descritti più dettagliatamente in seguito. Durante la lettura, tieni presente i seguenti termini:

• 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 spiegato nella sezione Servizi.
• Indirizzo IP del pod:l'indirizzo IP assegnato a un determinato pod. Questa operazione è temporanea, come spiegato nella sezione Pod.
• Indirizzo IP del nodo: l'indirizzo IP assegnato a un determinato nodo.

Requisiti di networking dei cluster

Sia i cluster pubblici che privati richiedono la connettività a *.googleapis.com, *.gcr.io e all'indirizzo IP del piano di controllo. Questo requisito è soddisfatto dalle regole di autorizzazione in uscita implicite e dalle regole firewall create automaticamente da GKE.

Per i cluster pubblici, se aggiungi regole firewall che negano il traffico in uscita con una priorità più elevata, devi creare regole firewall per consentire *.googleapis.com, *.gcr.io e l'indirizzo IP del piano di controllo.

Per maggiori informazioni sui requisiti cluster privato, consulta Requisiti, restrizioni e limitazioni

Networking all'interno del cluster

Questa sezione illustra il networking all'interno di un cluster Kubernetes per quanto riguarda l'allocazione degli IP, i pod, i servizi, il DNS e il piano di controllo.

Allocazione di IP

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

• A ogni nodo è assegnato un indirizzo IP dalla rete VPC (Virtual Private Cloud) 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 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 crei il cluster. La funzionalità Intervallo CIDR flessibile dei pod consente di ridurre le dimensioni dell'intervallo per gli indirizzi IP dei pod per i nodi in un pool di nodi.

Nota: per i cluster standard, puoi eseguire un massimo di 256 pod su un nodo con un intervallo /23, non 512 come previsto. In questo modo viene fornito un buffer che impedisce ai pod di diventare non pianificabili a causa di una mancanza temporanea di indirizzi IP nell'intervallo di indirizzi IP dei pod per un determinato nodo. Per tutti gli intervalli, è possibile pianificare al massimo metà dei pod come indirizzi IP nell'intervallo. I cluster Autopilot possono eseguire un massimo di 32 pod per nodo.

• Ogni pod ha un singolo indirizzo IP assegnato dall'intervallo CIDR del pod del suo 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.
• Ogni servizio ha un indirizzo IP, chiamato ClusterIP, assegnato dalla rete VPC del cluster. Facoltativamente, 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 ulteriori informazioni, consulta la descrizione del piano di controllo.

Il modello di networking di 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.

MTU

La MTU selezionata per l'interfaccia di un pod dipende dall'interfaccia di rete del container (CNI) utilizzata dai nodi del cluster e dall'impostazione MTU VPC sottostante. Per ulteriori informazioni, consulta la sezione Pod.

Autopilot è configurato per ereditare sempre la MTU VPC.

Il valore MTU dell'interfaccia del pod è 1460 o ereditato dall'interfaccia principale 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, consulta Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.
netd	Ereditato	L'attivazione avviene tramite: Visibilità tra nodi Federazione delle identità per i carichi di lavoro per GKE Networking a doppio stack IPv4/IPv6
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.

i pod

In Kubernetes, un pod è l'unità di base di cui è possibile eseguire il deployment all'interno di un cluster Kubernetes. Un pod esegue uno o più container. Su un nodo non vengono eseguiti o più pod. Ogni nodo del cluster fa parte di un pool di nodi.

In GKE, questi nodi sono macchine virtuali, ognuna in esecuzione come un'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, con il pod utilizzando un'interfaccia di rete virtuale, in modo che i pacchetti possano fluire da e verso il 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 sembra essere una macchina fisica con un'unica interfaccia di rete. Tutti i container nel pod vedono questa stessa interfaccia di rete. L'oggetto localhost di ogni container è connesso, tramite il pod, all'interfaccia di rete fisica del nodo, ad esempio eth0.

Tieni presente che questa connettività varia drasticamente a seconda che utilizzi il Container Network Interface (CNI) di GKE o se scegli di utilizzare l'implementazione di Calico abilitando 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 nello spazio dei nomi, mentre l'altra è connessa al dispositivo bridge Linux cbr0.¹ In questo caso, il comando seguente mostra gli indirizzi MAC dei vari pod collegati a cbr0:

  arp -n
  

  L'esecuzione del seguente comando nel container toolbox mostra l'estremità dello spazio dei nomi radice di ogni coppia veth associata a cbr0:

  brctl show cbr0
  

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

  arp -n
  

  Se esegui questo comando nel container della casella degli strumenti, risulta che non esiste un dispositivo bridge Linux denominato cbr0:

  brctl show
  

Le regole di iptables che facilitano l'inoltro all'interno del cluster differiscono da uno scenario all'altro. È importante tenere a mente 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 e ricrea i pod regolarmente. Questo accade quando viene eseguito l'upgrade di un pool di nodi, quando si modifica la configurazione dichiarativa del pod o l'immagine di un container, oppure quando un nodo diventa non disponibile. Di conseguenza, l'indirizzo IP di un pod è un dettaglio di implementazione e non dovresti usarlo. Kubernetes fornisce indirizzi IP stabili utilizzando i servizi.

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

Servizi

In Kubernetes, puoi assegnare coppie chiave-valore arbitrarie chiamate etichette a qualsiasi risorsa Kubernetes. Kubernetes usa le etichette per raggruppare vari pod correlati in un'unità logica denominata Service. Un servizio ha un indirizzo IP e porte stabili e fornisce il bilanciamento del carico tra il set di pod le cui etichette corrispondono a tutte le etichette che definisci nel selettore di etichette quando crei il servizio.

Nota: i servizi in Kubernetes non sono completamente correlati ai servizi in Docker. Un servizio Docker è più vicino a un pod Kubernetes.

Il seguente diagramma mostra due servizi separati, ciascuno dei quali è 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 entrambi i valori app=demo e component=frontend, mentre il servizio "users" corrisponde a tutti i pod con app=demo e component=users. Il pod del client non corrisponde esattamente a nessuno dei selettori dei servizi, 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 Service appena creato (ClusterIP) dal pool di indirizzi IP di servizio disponibili del cluster. Kubernetes assegna inoltre 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 ClusterIP e nome host solo 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 può sembrare un single point of failure per le tue applicazioni. Tuttavia, Kubernetes distribuisce il traffico nel modo più uniforme possibile nell'insieme completo di pod, in esecuzione su molti nodi, in modo che un cluster possa tollerare un'interruzione che interessa uno o più nodi, ma non tutti.

Proxy kube

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

kube-proxy, che non è un proxy in linea, ma un controller di bilanciamento del carico basato sul traffico in uscita, controlla il server API Kubernetes e mappa continuamente ClusterIP a pod integri aggiungendo e rimuovendo le regole NAT (DNAT) di destinazione 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 facoltativamente rimappare la sua porta di ascolto definendo valori per port e targetPort.

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

kube-proxy gestisce la rimappatura di questa porta 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 dei 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 eventuali dettagli sui singoli pod o container al suo interno.

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

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

DNS

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

• kube-dns: un componente aggiuntivo del cluster il cui deployment viene eseguito per impostazione predefinita in tutti i cluster GKE. Per ulteriori informazioni, consulta Utilizzo di kube-dns.

• Cloud DNS: un'infrastruttura DNS del cluster gestito su 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 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 relativi processi, incluso il server API Kubernetes. Il modo per accedere al piano di controllo dipende dalla versione del tuo cluster GKE Autopilot o Standard.

Cluster con Private Service Connect

Cluster privati o pubblici che soddisfano una qualsiasi delle seguenti condizioni, utilizza 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. Di conseguenza, 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 il cluster pubblico utilizza Private Service Connect, la risorsa privateClusterConfig avrà i seguenti valori:

• Il campo peeringName è vuoto o non esiste.
• Al campo privateEndpoint è assegnato un valore.

Tuttavia, non viene ancora eseguita la migrazione dei cluster privati esistenti che non soddisfano le condizioni precedenti.

Puoi creare cluster che utilizzano Private Service Connect e modificare l'isolamento del cluster.

Utilizza le reti autorizzate per restrict l'accesso al piano di controllo del tuo cluster definendo le origini che possono raggiungere il piano di controllo.

Avviso: i cluster pubblici con Private Service Connect creati prima del 30 gennaio 2022 utilizzano un endpoint e una regola di forwarding Private Service Connect. Entrambe le risorse sono denominate gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe e consentono al piano di controllo e ai nodi di connettersi privatamente. GKE crea queste risorse automaticamente senza costi. Se rimuovi queste risorse, si verificheranno problemi di rete del cluster, inclusi i tempi di inattività.

Networking all'esterno del cluster

Questa sezione spiega in che modo il traffico esterno al cluster raggiunge le applicazioni in esecuzione in un cluster Kubernetes. Queste informazioni sono importanti quando si progettano le applicazioni e i carichi di lavoro del cluster.

Hai già letto 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 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 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 solo servizio per utilizzare contemporaneamente più tipi di bilanciatori del carico.

• I bilanciatori del carico esterni gestiscono il traffico proveniente dall'esterno del cluster e dall'esterno della rete VPC di Google Cloud. Usano regole di forwarding 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 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). Usano una risorsa Ingress piuttosto che 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 del cluster eseguono i pod per il suo servizio. ma bilancia il traffico fra tutti i nodi del cluster, anche quelli che non eseguono un pod pertinente. In un cluster a livello di regione, il carico è distribuito tra tutti i nodi in tutte le zone per la 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. 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 al nodo centrale, che viene reindirizzato a un pod sul primo nodo.

Quando un bilanciatore del carico invia traffico a un nodo, questo 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 andare 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 dispongono dei pod appropriati.

Bilanciatore del carico esterno

Se il servizio deve essere raggiungibile dall'esterno del cluster e dall'esterno della rete VPC, puoi configurarlo come LoadBalancer, impostando il campo type del servizio su Loadbalancer durante la definizione del servizio. 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 nel tuo cluster e configura le regole firewall della tua 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 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 instradato a un nodo utilizzando una regola di forwarding associata alla rete Google Cloud. Dopo che il traffico raggiunge il nodo, quest'ultimo utilizza la sua 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 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, quest'ultimo utilizza la sua tabella NAT iptables per scegliere un pod, anche se il pod si trova su un nodo diverso. kube-proxy gestisce le regole iptables sul nodo.

Per maggiori 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 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 un cluster Kubernetes in entrata.

Una risorsa Ingress consente di mappare i nomi host e i percorsi degli URL ai servizi all'interno del cluster. Quando utilizzi un bilanciatore del carico delle applicazioni, devi configurare il servizio in modo che utilizzi un nodo 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 una NodePort o consentire a GKE di assegnare una porta inutilizzata 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. 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

Per ulteriori informazioni, visita la pagina relativa a GKE Ingress per il bilanciatore del carico delle applicazioni.

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 all'Application Load Balancer. 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 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 hanno come target i nodi nel cluster potrebbe avere effetti negativi. Ad esempio, l'applicazione di regole di negazione in uscita ai nodi nel 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 modi diversi, 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 il ingresso e l'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 il resto del traffico viene negato.

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

Limitazione dell'accesso a un bilanciatore del carico esterno

Se il servizio utilizza un bilanciatore del carico esterno, il traffico proveniente da qualsiasi indirizzo IP esterno può accedere al servizio per impostazione predefinita. Puoi limitare gli intervalli di indirizzi IP che possono accedere agli endpoint all'interno del tuo 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 ciascun nodo configura le regole iptables del nodo stesso in modo da negare tutto il traffico che non corrisponde al valore loadBalancerSourceRanges specificato. Non viene creata alcuna regola firewall VPC.

Limitare l'accesso a un bilanciatore del carico delle applicazioni

Se il 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 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 abilitare 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 illustra i problemi noti.

Il nodo abilitato per Containerd 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 maggiori informazioni, consulta la sezione Conflitto con l'intervallo di indirizzi IP 172.17/16.

Passaggi successivi

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