Panoramica della rete

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

Kubernetes ti consente di definire in modo dichiarativo il modo in cui viene eseguito il deployment delle applicazioni, in che modo le applicazioni comunicano tra loro e con il pannello di controllo, e come i client possono raggiungerle. In questa pagina vengono fornite anche le informazioni su come GKE configura i servizi Google Cloud, in quanto rilevanti per il networking.

Quando utilizzi Kubernetes per orchestrare le tue applicazioni, è importante cambiare il tuo modo di pensare alla progettazione delle reti delle applicazioni e dei relativi host. Con Kubernetes, penserai al modo in cui comunicano i pod, i servizi e i client esterni, piuttosto che a come sono collegati i tuoi host o macchine virtuali (VM).

L'avanzato networking software-defined (SDN) di Kubernetes consente il routing e l'inoltro dei pacchetti per pod, servizi e nodi in zone diverse dello stesso cluster di regione. Kubernetes e Google Cloud configurano inoltre in modo dinamico regole di filtro IP, tabelle di routing e regole firewall per ciascun nodo, a seconda del modello dichiarativo dei tuoi deployment Kubernetes e della configurazione del cluster su Google Cloud.

Prerequisiti

Questa pagina utilizza la terminologia relativa ai livelli di Transport, Internet e Application della suite di protocolli Internet, inclusi HTTP e DNS, ma non è necessario essere un esperto di questi argomenti.

Inoltre, potrebbe essere più facile capire questi contenuti se hai una conoscenza di base dei concetti e delle utilità della gestione della rete Linux, ad esempio le regole iptables e il routing.

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 più in dettaglio più avanti in questo argomento. 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 descritto nella sezione Servizi in questo argomento.
  • IP pod: l'indirizzo IP assegnato a un determinato pod. Questo è temporaneo, come discusso nella sezione Pod in questo argomento.
  • IP del nodo: l'indirizzo IP assegnato a un determinato nodo.

Requisiti di networking del cluster

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

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

Per saperne di più sui requisiti cluster privato, consulta Requisiti, limitazioni e limitazioni

Networking all'interno del cluster

Questa sezione riguarda il networking all'interno di un cluster Kubernetes, in relazione ad allocazione IP, pod, servizi, 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 è 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 di Kubernetes. Questo IP è la connessione del nodo al resto del cluster.

  • Ogni nodo dispone di un pool di indirizzi IP assegnati a GKE in esecuzione su quel nodo (un blocco CIDR/24 per impostazione predefinita). Facoltativamente, puoi specificare l'intervallo di IP al momento della creazione del cluster. La funzionalità flessibile dell'intervallo CIDR pod consente di ridurre le dimensioni dell'intervallo per gli IP dei pod dei nodi in un pool di nodi.

  • 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 durante la creazione del cluster.

  • Ogni piano di controllo ha un indirizzo IP pubblico o privato in base al tipo di cluster, alla versione e alla data di creazione. Per saperne di più, consulta la descrizione del piano di controllo.

MTU

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

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

CNI MTU GKE Standard
Kubenet 1460 Predefinito
kubenet
(GKE 1.26.1 e versioni successive) 		Ereditato Predefinito
Calico 1460

Abilitata utilizzando --enable-network-policy.

Per maggiori dettagli, consulta la pagina Controllare la comunicazione tra pod e servizi utilizzando i criteri di rete.
netto Ereditato Abilitato utilizzando uno dei seguenti metodi:
GKE Dataplane V2 Ereditato

Abilitata utilizzando --enable-dataplane-v2.

Per maggiori dettagli, consulta la sezione Utilizzo di GKE Dataplane V2.

Per saperne di più, consulta Cluster nativi VPC.

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. Zero o più pod vengono eseguiti su un nodo. Ogni nodo nel cluster fa parte di un pool di nodi. In GKE, questi nodi sono macchine virtuali, ciascuna delle quali è eseguita come istanza in Compute Engine.

I pod possono essere collegati anche 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 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, come eth0, con il pod utilizzando un'interfaccia di rete virtuale, in modo che i pacchetti possano passare 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'IP 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'interfaccia di rete. Tutti i container nel pod vedono la stessa interfaccia di rete. Il localhost di ogni container è collegato, tramite il pod, all'interfaccia di rete fisica del nodo, come eth0.

Tieni presente che questa connettività varia drasticamente a seconda che utilizzi la container di rete di rete (CNI) nativa di GKE o se scegli di utilizzare l'implementazione di Calico attivando il criterio di rete quando crei il cluster.

  • Se utilizzi la CNI di GKE, un'estremità della coppia di dispositivi Ethernet (veth) virtuali è collegata al pod nello spazio dei nomi e l'altra è collegata al dispositivo bridge Linux cbr0.1 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 della casella degli strumenti mostra l'estremità dello spazio dei nomi radice di ogni coppia vet collegata a cbr0:

    brctl show cbr0

  • Se il criterio di rete è abilitato, un'estremità della coppia di nodi è 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:

    arp -n

    L'esecuzione del seguente comando nel container della casella degli strumenti mostra che non esiste un dispositivo bridge Linux denominato cbr0:

    brctl show

Le regole iptables che facilitano l'inoltro all'interno del cluster 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 rimuove regolarmente i pod e li ricrea. Questo accade quando viene eseguito l'upgrade di un pool di nodi, quando cambia la configurazione dichiarativa del pod o quando cambia l'immagine di un container o quando un nodo non è più disponibile. Pertanto, l'indirizzo IP di un pod è un dettaglio dell'implementazione e non bisogna affidarsi a loro. Kubernetes fornisce indirizzi IP stabili utilizzando i Servizi.

  1. Il bridge di rete virtuale cbr0 viene creato solo se sono presenti pod che hanno impostato 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 delle porte stabili e fornisce il bilanciamento del carico tra l'insieme di pod le cui etichette corrispondono a tutte le etichette definite nel selettore di etichette al momento della creazione del servizio.

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

immagine

Kubernetes assegna un indirizzo IP stabile e affidabile a ogni nuovo servizio creato (il ClusterIP) dal pool di indirizzi IP del servizio disponibili del cluster. Kubernetes assegna inoltre un nome host al 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 il ClusterIP e il nome host solo se il servizio viene eliminato dalla configurazione del cluster. Puoi raggiungere un pod integro in esecuzione dell'applicazione utilizzando il 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 sull'intero set 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).

Proxy kube

Kubernetes gestisce la connettività tra pod e servizi utilizzando il componente kube-proxy, che è un DaemonSet che esegue il deployment di un pod su ogni nodo per impostazione predefinita.

kube-proxy, che non è un proxy in linea, ma un controller di bilanciamento del carico basato su traffico in uscita, controlla il server API di Kubernetes e mappa continuamente il 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 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 iptables regole 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 presso 172.16.12.100:80. Il server API di Kubernetes gestisce un elenco di pod che eseguono l'applicazione. Il processo kube-proxy su ciascun nodo utilizza questo elenco per creare una regola iptables per indirizzare il traffico a un pod appropriato (come 10.255.255.202:8080). Il pod client non deve essere a conoscenza della topologia del cluster o di qualsiasi dettaglio sui singoli pod o container al suo interno.

immagine

Il modo in cui viene eseguito il deployment di kube-proxy dipende dalla versione di GKE del cluster:

  • Per GKE 1.16.0 e 1.16.8-gke.13, viene eseguito il deployment di kube-proxy 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 offre le seguenti opzioni DNS per i cluster gestiti per risolvere i nomi di 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.
  • Cloud DNS: un'infrastruttura DNS del cluster gestita da cloud che sostituisce kube-dns nel cluster.

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 DNS, consulta Rilevamento servizi e DNS.

Piano di controllo

In Kubernetes, il piano di controllo gestisce i processi del piano di controllo, incluso il server API di Kubernetes.

Le modalità di accesso al piano di controllo dipendono dalla versione del cluster GKE e dal tipo di cluster.

Per tutti i cluster privati, il piano di controllo ha un indirizzo IP privato e un indirizzo IP pubblico.

Cluster pubblici con Private Service Connect

GKE utilizza Private Service Connect per connettere privatamente nodi e piano di controllo nei cluster pubblici con le seguenti condizioni:

  • Versioni 1.22 e successive, create tra il 28 ottobre e il 17 febbraio 2022.
  • Versioni 1.23 e successive, create a partire dal 15 marzo 2022.

È in corso la migrazione a Private Service Connect di tutti i cluster pubblici nella versione 1.24 e successive 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 il tuo cluster pubblico utilizza Private Service Connect, la risorsa privateClusterConfig ha i seguenti valori:

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

Questo non si applica ai cluster pubblici in esecuzione su reti legacy.

Networking esterno al cluster

Questa sezione spiega in che modo il traffico dall'esterno del cluster raggiunge le applicazioni in esecuzione all'interno di un cluster Kubernetes. Queste informazioni sono importanti durante la progettazione di applicazioni e carichi di lavoro del cluster.

Hai già letto in che modo 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 all'esterno del 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 offre tre diversi tipi di bilanciatori del carico per controllare l'accesso e distribuire il traffico in entrata nel cluster in modo uniforme possibile. Puoi configurare un servizio 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 dalla tua rete VPC Google Cloud. Utilizzano le 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 HTTP(S) sono bilanciatori del carico esterni specifici utilizzati per il traffico HTTP(S). Utilizzano una risorsa Ingress invece di 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 stanno eseguendo pod per il suo servizio. Bilancia invece il traffico su tutti i nodi del cluster, anche quelli che non eseguono un pod pertinente. Su un cluster a livello di area geografica, il carico viene distribuito tra tutti i nodi in tutte le zone per l'area geografica del cluster. Quando il traffico viene instradato a un nodo, il nodo lo indirizza a un pod, che potrebbe 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 centrale e il traffico viene reindirizzato a un pod sul primo nodo.

immagine

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

Per specificare che il traffico deve andare a un pod sullo stesso nodo, imposta externalTrafficPolicy su Local nel manifest del tuo servizio:

apiVersion: v1
kind: Service
metadata:
  name: my-lb-service
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  selector:
    app: demo
    component: users
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Quando imposti externalTrafficPolicy su Local, il bilanciatore del carico invia il traffico solo ai nodi che hanno 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 dall'esterno della rete VPC, puoi configurare il servizio 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 esterno passthrough davanti al servizio. Il bilanciatore del carico di rete passthrough esterno è a conoscenza di tutti i nodi nel cluster e configura le regole firewall della 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 la pagina Regole firewall create automaticamente.

Dettagli tecnici

Quando utilizzi il bilanciatore del carico esterno, il traffico in entrata viene inizialmente instradato a un nodo utilizzando una regola di forwarding associata alla rete Google Cloud. Quando il traffico raggiunge il nodo, il nodo 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 tuo 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é da 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

La funzionalità di bilanciamento del carico interno è fornita da Google Cloud. Quando il traffico raggiunge un determinato nodo, quel nodo 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, consulta Utilizzo di un bilanciatore del carico di rete passthrough interno.

Bilanciatore del carico HTTPS

Molte applicazioni, come le API del servizio 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 in entrata Kubernetes. Una risorsa Ingress consente di mappare nomi host e percorsi degli URL ai servizi all'interno del cluster. Quando utilizzi un bilanciatore del carico HTTP(S), devi configurare il servizio per l'utilizzo di un NodePort e di un ClusterIP. Quando il traffico accede al servizio sull'IP di un nodo su NodePort, GKE lo indirizza a un pod integro per il servizio. Puoi specificare una NodePort o consentire a GKE di assegnare una porta non utilizzata casuale.

Quando crei la risorsa Ingress, GKE esegue il provisioning di un bilanciatore del carico dell'applicazione esterno nel progetto Google Cloud. Il bilanciatore del carico invia una richiesta all'indirizzo IP di un nodo su NodePort. Quando la richiesta raggiunge il nodo, il nodo utilizza la propria tabella NAT iptables per scegliere un pod. kube-proxy gestisce le regole iptables sul nodo.

Questa definizione di Ingress indirizza 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 bilanciamento del carico HTTP(S).

Dettagli tecnici

Quando crei un oggetto Ingress, il controller Ingress di GKE configura un bilanciatore del carico HTTP(S) Google Cloud in base alle regole nel manifest Ingress e nei manifest dei servizi associati. Il client invia una richiesta al bilanciatore del carico HTTP(S). Il bilanciatore del carico è un proxy effettivo; sceglie un nodo e inoltra la richiesta alla combinazione NodeIP:NodePort del nodo. Il nodo utilizza la tabella NAT iptables per scegliere un pod. kube-proxy gestisce le regole iptables sul nodo.

Limitazione della connettività tra i 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 tuo cluster 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 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 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.

Consulta i criteri di rete per maggiori dettagli su come specificare il criterio stesso.

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.

Limitazione dell'accesso a un bilanciatore del carico esterno

Se il Servizio utilizza un bilanciatore del carico esterno, il traffico 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 di quel nodo per negare tutto il traffico che non corrisponde al valore loadBalancerSourceRanges specificato. Non viene creata alcuna regola firewall VPC.

Limitazione dell'accesso a un bilanciatore del carico HTTP(S)

Se il servizio utilizza il bilanciatore del carico HTTP(S), 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 dei criteri di sicurezza. Puoi configurare Cloud Logging per registrare le informazioni su queste interazioni.

Se un criterio di sicurezza di Google Cloud Armor non è abbastanza granulare, puoi abilitare Identity-Aware Proxy sui tuoi endpoint per implementare l'autenticazione e l'autorizzazione basate sull'utente per l'applicazione. Per saperne di più, consulta il tutorial dettagliato per la configurazione di IAP.

Problemi noti

Impossibile connettersi al nodo abilitato per il container nell'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 pagina Conflitto con l'intervallo di indirizzi IP 172.17/16.

Passaggi successivi