Scopri l'architettura di networking di GKE

Il networking di Google Kubernetes Engine (GKE) utilizza ed estende l'infrastruttura di networking software-defined (SDN) fornita da Virtual Private Cloud (VPC). Il networking GKE consente ai componenti di comunicare all'interno di un cluster Kubernetes e con servizi e reti esterni. Il modello di networking di GKE si basa sul principio di networking di Kubernetes, in cui ogni pod riceve il proprio indirizzo IP, per fornire indirizzi IP, bilanciamento del carico, risoluzione DNS e applicazione dei criteri di rete. Questo documento spiega come i componenti principali come nodi, pod e servizi interagiscono con il control plane nel contesto del networking GKE, trattando i seguenti argomenti:

  • Come interagiscono questi componenti all'interno del VPC
  • Come vengono allocati e gestiti gli indirizzi IP
  • Come il traffico entra, si sposta all'interno e esce dal cluster

Architettura di una rete GKE

Una rete GKE si basa su Virtual Private Cloud (VPC) di Google Cloud. Questa base fornisce una connettività solida e scalabile per tutte le tue applicazioni containerizzate.

La base VPC e gli intervalli di indirizzi IP

All'interno del VPC, definisci le subnet, che sono intervalli di indirizzi IP regionali. GKE utilizza in modo strategico diversi intervalli di indirizzi IP all'interno di queste subnet per vari componenti del cluster, spesso utilizzando intervalli di indirizzi IP alias VPC:

  • Intervallo di indirizzi IP del nodo: questo è l'intervallo di indirizzi IP principale della subnet in cui vengono implementati i nodi del cluster. Tutti i nodi worker GKE, che sono VM di Compute Engine, ricevono i loro indirizzi IP principali da questo intervallo. Questi indirizzi IP vengono utilizzati per la comunicazione tra i nodi e per i controlli di integrità dei bilanciatori del carico. L'indirizzo IP del nodo è anche l'origine del traffico che ha origine sul nodo stesso. Nei cluster VPC nativi, il traffico dai pod utilizza l'indirizzo IP del pod come indirizzo di origine, a meno che l'indirizzo IP del pod non venga tradotto da una funzionalità come Cloud NAT.
  • Intervallo di indirizzi IP del pod: un intervallo di indirizzi IP secondari dedicato, spesso un blocco CIDR più grande, all'interno della subnet. Ogni nodo riceve un pool di indirizzi IP da questo intervallo. GKE assegna questi indirizzi IP ai pod eseguiti su quel nodo. Ogni pod del cluster riceve il proprio indirizzo IP univoco da questo intervallo. Questi indirizzi IP dei pod sono instradabili in modo nativo all'interno del tuo Virtual Private Cloud. Per impostazione predefinita, ogni nodo riceve un intervallo /24, che fornisce 256 indirizzi IP. Tuttavia, GKE limita il numero massimo di pod per nodo a 110. Questo buffer contribuisce a garantire la disponibilità degli indirizzi IP durante la creazione e l'eliminazione rapide dei pod, note anche come churn. Questi indirizzi IP consentono la comunicazione diretta tra pod su nodi diversi senza richiedere Network Address Translation (NAT).
  • Intervallo di indirizzi IP del servizio (ClusterIP): un intervallo di indirizzi IP secondario per gli indirizzi IP virtuali (ClusterIP) assegnati ai servizi Kubernetes. Questi indirizzi IP stabili vengono utilizzati solo per la comunicazione all'interno del cluster.
  • Indirizzo IP del control plane: ogni control plane ha un indirizzo IP pubblico o interno, a seconda del tipo, della versione e della data di creazione del cluster. Questo indirizzo IP viene utilizzato dai nodi di lavoro e dai client esterni, come kubectl, per comunicare in modo sicuro con il server API Kubernetes. GKE Frontend (GKFE) fornisce un endpoint basato su DNS per ogni cluster, offrendo un modo sicuro e affidabile per accedere al control plane senza gestire direttamente gli indirizzi IP.

I tre pilastri del networking di GKE

Il networking GKE è costituito da tre pilastri interconnessi, ognuno che rappresenta un livello di comunicazione distinto. Questo framework ti aiuta a capire come comunicano le tue applicazioni all'interno del cluster e con reti esterne:

  • Networking dei pod: il livello fondamentale, che definisce il modo in cui i singoli container (pod) comunicano tra loro all'interno del cluster.
  • Service Networking: basato sul networking dei pod, questo livello descrive in che modo i servizi Kubernetes forniscono endpoint stabili per esporre le applicazioni per i client interni o esterni, inclusi il bilanciamento del carico e l'individuazione dei servizi.
  • Networking del cluster: il livello più esterno, che copre il modo in cui l'intero cluster GKE si connette all'ecosistema di rete più ampio, inclusa la gestione dell'ingresso da internet, dell'uscita verso servizi esterni e della connettività ai servizi Google Cloud e ai sistemi on-premise.

Questi livelli collaborano per creare un modello di comunicazione completo che supporti connettività interna ed esterna, sicurezza e scalabilità. Le sezioni seguenti analizzano in dettaglio ogni pilastro.

Networking di pod

Il networking dei pod è la base di tutta la comunicazione all'interno di un cluster GKE. Definisce il modo in cui le applicazioni in esecuzione all'interno dei pod possono trovarsi e interagire tra loro. In Kubernetes, un pod è l'unità di cui è possibile eseguire il deployment più piccola e basilare. Un pod funge da host logico per le tue applicazioni. Esegue uno o più container che condividono le risorse di rete. Quando un pod viene pianificato su un nodo, Kubernetes crea uno spazio dei nomi di rete dedicato nel kernel Linux del nodo, che isola la sua rete dagli altri pod sullo stesso nodo.

Come funziona il networking dei pod

Il networking dei pod viene stabilito tramite una combinazione di indirizzi IP univoci, dispositivi di rete virtuali e plug-in specializzati che gestiscono la connettività.

Container Network Interface (CNI): GKE utilizza i plug-in CNI per implementare e gestire il networking dei pod. Per i cluster VPC nativi, il valore predefinito è Google CNI. Altre opzioni includono kubenet (per cluster non VPC nativi), Calico e GKE Dataplane V2 (basato su Cilium). Questi plug-in sono responsabili della connessione dei pod alla rete e dell'applicazione dei criteri di rete.

  • Allocazione degli indirizzi IP: ogni nodo riceve un pool di indirizzi IP dall'intervallo di indirizzi IP dei pod da assegnare ai pod. GKE riserva una parte di questi indirizzi per creare un buffer che garantisca la disponibilità dell'indirizzo IP durante la rapida rotazione (creazione ed eliminazione) dei pod. Questa prenotazione è il motivo per cui il numero di indirizzi IP dei pod allocabili per nodo è sempre inferiore alla dimensione dell'intervallo.

  • Spazi dei nomi di rete e coppie Ethernet virtuali (veth): per facilitare la comunicazione, Kubernetes collega lo spazio dei nomi di rete isolato del pod allo spazio dei nomi di rete principale o radice del nodo. Kubernetes stabilisce questa connessione utilizzando una coppia Ethernet virtuale, o coppia veth, che funge da cavo di rete virtuale. Un'estremità della coppia viene inserita nello spazio dei nomi del pod e viene visualizzata come eth0. L'altra estremità si connette a un bridge di rete o direttamente allo stack di rete del nodo nello spazio dei nomi principale del nodo, il che consente il flusso di pacchetti da e verso il pod.

    Il metodo di connessione specifico dipende dal plug-in CNI utilizzato dal cluster:

    • Google CNI: questo è il CNI predefinito per i cluster nativi di VPC. La coppia veth del pod si connette allo spazio dei nomi di rete principale del nodo. Poiché gli indirizzi IP dei pod sono indirizzi IP alias noti alla rete VPC, il routing Linux standard sul nodo indirizza il traffico da e verso il pod.
    • GKE Dataplane V2: utilizza programmi eBPF per gestire il networking dei pod e spesso bypassa i ponti Linux convenzionali e le coppie veth per gestire direttamente i flussi di pacchetti all'interno del kernel per prestazioni più elevate.
    • Kubenet: viene utilizzato nei cluster non nativi di VPC. L'altra estremità della coppia veth si connette a un dispositivo bridge Linux chiamato cbr0 nello spazio dei nomi principale del nodo. Questo bridge gestisce il traffico tra i pod sullo stesso nodo e utilizza NAT per il traffico che esce dal nodo.
    • Calico: quando la policy di rete è abilitata con Calico, l'altra estremità della coppia veth si connette allo spazio dei nomi root del nodo e Calico programma quindi le route host per indirizzare il traffico ai pod corretti.

Unità massima di trasmissione (MTU): determina la dimensione massima del pacchetto che può essere inviato su una rete senza essere frammentato. In GKE, l'MTU per l'interfaccia di un pod è un'impostazione fondamentale che dipende dal plug-in CNI di GKE utilizzato dal cluster e dalle impostazioni MTU della rete VPC sottostante. Una mancata corrispondenza nei valori MTU può causare perdita di pacchetti o peggioramento delle prestazioni. Il valore MTU dell'interfaccia del pod è 1460 byte fisso o viene ereditato dall'interfaccia di rete principale del nodo, come mostrato nella tabella seguente.

CNI MTU Utilizzo
Google CNI 1460 Valore predefinito per i cluster VPC nativi che utilizzano versioni di GKE precedenti alla 1.26.1.
Google CNI Ereditato Valore predefinito per i cluster VPC nativi che utilizzano GKE versione 1.26.1 e successive.
Calico 1460 Utilizzato quando il criterio di rete è abilitato (--enable-network-policy).
GKE Dataplane V2 Ereditato Utilizzato quando GKE Dataplane V2 è abilitato (--enable-dataplane-v2).
netd Ereditato Utilizzato quando sono abilitate funzionalità come la visibilità "Intranode", Workload Identity Federation for GKE per GKE o il networking dual-stack IPv4/IPv6.

Flusso di comunicazione tra pod

Kubernetes utilizza un modello di networking flat, in cui ogni pod ha un indirizzo IP univoco e instradabile. Questo modello contribuisce a garantire una connettività perfetta tra i pod.

Comunicazione all'interno dello stesso nodo

Quando un pod invia traffico a un altro pod sullo stesso nodo, la richiesta passa dallo spazio dei nomi di rete del primo pod, attraverso la sua coppia veth, e nello spazio dei nomi di rete principale del nodo. Questo traffico rimane all'interno del nodo. A seconda del plug-in CNI utilizzato, il plug-in CNI inoltra il traffico alla coppia veth del secondo pod. Ad esempio, con kubenet, un dispositivo bridge inoltra il traffico. Con GKE Dataplane V2, i programmi eBPF gestiscono direttamente il flusso di pacchetti.

Comunicazione tra nodi diversi

Quando un pod su un nodo invia traffico a un pod su un altro nodo, il traffico viene inviato allo spazio dei nomi di rete principale del primo nodo. Il traffico esce quindi dall'interfaccia di rete principale del primo nodo ed entra nella rete VPC. Poiché gli indirizzi IP dei pod sono instradabili in modo nativo in un cluster GKE nativo VPC, la rete VPC instrada il traffico direttamente al secondo nodo. Il secondo nodo inoltra quindi il traffico al pod di destinazione.

Pod di rete host

Per casi d'uso specifici, puoi configurare un pod con l'impostazione hostNetwork: true. Questa impostazione ignora la rete di pod isolata e consente al pod di condividere direttamente lo spazio dei nomi di rete del nodo. Con questo accesso diretto, il pod utilizza l'indirizzo IP del nodo e può comunicare con tutti gli altri pod senza bisogno di NAT. Nei cluster che utilizzano il plug-in CNI kubenet, questo comportamento è diverso dai pod normali. I pod regolari richiedono NAT per il traffico in uscita perché i loro indirizzi IP non sono direttamente instradabili sulla rete VPC. Al contrario, il networking nativo VPC di GKE rende questa traduzione non necessaria per tutti i pod. Tuttavia, quando configuri i pod con l'impostazione hostNetwork: true, fai attenzione a evitare conflitti di porta con altri processi o pod eseguiti sullo stesso nodo. Nei cluster che utilizzano la CNI kubenet, il bridge di rete virtuale cbr0 viene creato solo se il nodo ha pod con l'impostazione hostNetwork: false.

Networking di servizi

Sebbene il networking dei pod fornisca la connettività di base tra i singoli pod, non è sufficiente per creare applicazioni robuste e scalabili. I pod sono temporanei: possono essere creati, eliminati e riprogrammati in qualsiasi momento. Questa situazione causa la modifica dei loro indirizzi IP. Il networking dei servizi risolve questo problema fornendo un modo stabile e affidabile per esporre le applicazioni e gestire il modo in cui comunicano, sia all'interno del cluster sia con il mondo esterno.

Un servizio Kubernetes è un'astrazione che definisce un insieme logico di pod e un criterio per accedervi. I servizi utilizzano le etichette per raggruppare più pod correlati in un'unica unità logica. Quando crei un servizio, Kubernetes gli assegna un indirizzo IP virtuale stabile, noto come ClusterIP, da un pool di indirizzi riservati ai servizi. Questo ClusterIP, insieme a un nome DNS associato, rimane costante per l'intero ciclo di vita del servizio, fornendo un endpoint coerente che altre applicazioni possono utilizzare per connettersi ai pod.

Come funziona il networking dei servizi

Il networking dei servizi si basa su due meccanismi chiave per instradare il traffico da un endpoint stabile di un servizio ai suoi pod di backend dinamici: Service Discovery e bilanciamento del carico.

Service Discovery: per consentire alle applicazioni di trovarsi e comunicare tra loro, GKE fornisce un servizio DNS interno (kube-dns o Cloud DNS). Quando crei un servizio, il servizio DNS crea automaticamente un record DNS corrispondente. Questo record consente alle applicazioni di connettersi al servizio utilizzando il nome DNS (ad esempio, my-app-service) anziché dover conoscere il ClusterIP. Sebbene kube-dns sia l'impostazione predefinita per i cluster Standard, Cloud DNS per GKE è la soluzione consigliata per la maggior parte degli ambienti di produzione. È anche l'unica soluzione supportata per i cluster GKE Autopilot. Questo servizio è completamente gestito, scalabile e a disponibilità elevata. Si integra con il networking VPC e Cloud Logging, offrendo prestazioni e osservabilità migliori senza richiedere la gestione dei pod kube-dns.

Meccanismi di bilanciamento del carico: l'implementazione del bilanciamento del carico del servizio dipende dalla modalità di networking del cluster GKE.

  • GKE Dataplane V2: i cluster che utilizzano GKE Dataplane V2 (basato su Cilium) non utilizzano kube-proxy per il bilanciamento del carico del servizio. GKE Dataplane V2 utilizza invece programmi eBPF eseguiti nel kernel Linux. Questi programmi eBPF sono molto efficienti nell'intercettare il traffico verso i ClusterIP del servizio e bilanciare direttamente il carico del traffico verso i pod di backend appropriati. Questo approccio si traduce in un rendimento migliore ed è strettamente integrato con le funzionalità di applicazione dei criteri di rete di GKE Dataplane V2.

  • kube-proxy (per i cluster senza GKE Dataplane V2): su ogni nodo di un cluster GKE che non utilizza GKE Dataplane V2, un componente chiamato kube-proxy implementa il meccanismo dell'indirizzo IP virtuale per i servizi. kube-proxy monitora il server API Kubernetes per rilevare modifiche a servizi ed endpoint, quindi programma le regole di rete sul nodo per intercettare il traffico destinato al ClusterIP di un servizio.

    kube-proxy può funzionare in diverse modalità, tra cui:

    • Modalità iptables: questa è la modalità predefinita. kube-proxy aggiunge e rimuove regole NAT di destinazione (DNAT) nel sottosistema iptables del nodo. Quando il traffico arriva per il ClusterIP di un servizio, queste regole eseguono una traduzione NAT e modificano l'indirizzo IP di destinazione in uno dei pod di backend integri. Il bilanciamento del carico tra i pod di backend è in genere casuale o round robin.
    • Modalità ipvs: questa modalità utilizza Linux IP Virtual Server (IPVS) per il bilanciamento del carico ad alte prestazioni. kube-proxy configura le regole IPVS, che possono gestire un numero elevato di servizi e fornire algoritmi di bilanciamento del carico più sofisticati.

Esempio di flusso di comunicazione interna

Il seguente elenco descrive il flusso di una richiesta da un pod client a un pod server utilizzando un servizio in un cluster che non utilizza GKE Dataplane V2:

  1. L'applicazione client esegue una query DNS per my-server-service.
  2. Il servizio DNS interno del cluster risolve questo nome nel ClusterIP stabile del servizio (ad esempio, 10.0.32.8).
  3. Il pod client invia una richiesta al ClusterIP del servizio.
  4. Le regole iptables sul nodo del client, gestite da kube-proxy, intercettano questa richiesta.
  5. Queste regole iptables eseguono DNAT e selezionano uno dei pod di backend integri per my-server-service (ad esempio, il pod 2 con indirizzo IP 10.4.0.3). Le regole riscrivono anche l'indirizzo IP di destinazione del pacchetto con l'indirizzo IP del pod.
  6. Il pacchetto viene instradato tramite la rete flat dei pod al pod 2, che elabora la richiesta.

Nei cluster che utilizzano GKE Dataplane V2, i programmi eBPF gestiscono l'intercettazione e il bilanciamento del carico del traffico verso il Service ClusterIP, bypassando kube-proxy e iptables.

Manifest di Servizio di esempio

L'esempio seguente mostra un manifest del servizio. Il campo selector specifica quali pod ricevono traffico in base alle relative etichette.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

Funzionalità del networking di servizi

Il networking dei servizi GKE offre diverse funzionalità per gestire il flusso di traffico ed esporre le applicazioni, sia internamente che esternamente.

  • Bilanciamento del carico interno ed esterno: per i servizi a cui è necessario accedere solo dall'interno del cluster, kube-proxy (o GKE Dataplane V2) gestisce il bilanciamento del carico internamente. Per i servizi che devono essere esposti a internet, GKE esegue automaticamente il provisioning di un bilanciatore del carico cloud per distribuire il traffico esterno ai nodi del cluster.
  • Bilanciatori del carico delle applicazioni per il routing HTTP(S).Per il traffico HTTP(S), GKE utilizza un bilanciatore del carico di livello 7 specializzato, il bilanciatore del carico delle applicazioni. Configura questo bilanciatore del carico utilizzando l'API Kubernetes Gateway, che è l'approccio consigliato per tutte le nuove applicazioni. Il controller GKE Gateway è l'implementazione di Google dell'API Gateway ed è progettato per essere un successore più espressivo, flessibile ed estensibile della risorsa Ingress. L'API Gateway utilizza le seguenti risorse per configurare il bilanciatore del carico:
    • Gateway:definisce le configurazioni del listener, come porte, protocolli e nomi host. Funziona come punto di ingresso per il traffico.
    • HTTPRoute:specifica come il traffico ricevuto da un gateway viene indirizzato ai servizi. Supporta funzionalità avanzate come il routing basato sul percorso, la corrispondenza delle intestazioni e la suddivisione del traffico.
    • Policy:definisce il funzionamento dell'infrastruttura Google Cloud sottostante se collegata a un gateway, una route o un servizio.
  • Integrazione della mesh di servizi per architetture di microservizi complesse, GKE supporta le tecnologie di mesh di servizi. Un mesh di servizi è un livello di infrastruttura facoltativo che fornisce funzionalità avanzate per la gestione del traffico, l'osservabilità e la sicurezza. Per un'esperienza completamente gestita e supportata, GKE offre Cloud Service Mesh, basato su Istio.

Networking per il cluster

Il networking del cluster è il livello più esterno del networking GKE. Si concentra sul modo in cui l'intero cluster Kubernetes interagisce con risorse e reti esterne, incluso il modo in cui i client internet raggiungono le tue applicazioni, il modo in cui i tuoi pod accedono alle API esterne e il modo in cui il tuo cluster si connette ai data center on-premise. Il networking del cluster si basa sull'infrastruttura VPC di Google Cloud.

Gestire il traffico in entrata

Ingress è il traffico che entra nel cluster dal mondo esterno. GKE utilizza diverse funzionalità Google Cloud integrate per gestire e proteggere questo traffico.

Flusso di dati di accesso esterno: quando un client da internet invia una richiesta alla tua applicazione (in genere esposta tramite un servizio di tipo LoadBalancer o una risorsa Ingress o Gateway), raggiunge prima un bilanciatore del carico Google Cloud . Il bilanciatore del carico instrada la richiesta a un nodo integro nel cluster. Il nodo inoltra il traffico al pod appropriato. kube-proxy gestisce questo inoltro sui cluster che non utilizzano GKE Dataplane V2 oppure i programmi eBPF lo gestiscono nei cluster che utilizzano GKE Dataplane V2. Il pod di destinazione potrebbe trovarsi sullo stesso nodo o su un nodo diverso.

Regole firewall: i cluster GKE utilizzano le regole firewall VPC per controllare il traffico in entrata. Sebbene GKE crei automaticamente alcune regole firewall predefinite per le operazioni essenziali del cluster, ad esempio consentendo al control plane di raggiungere i nodi, puoi definire regole personalizzate per soddisfare i tuoi requisiti di sicurezza specifici. Queste regole firewall VPC funzionano con i criteri di rete Kubernetes per fornire una difesa approfondita controllando il traffico a livello di nodo e di pod.

Ottimizzazione del flusso di traffico esterno: quando un bilanciatore del carico invia traffico a un nodo, quest'ultimo potrebbe dover inoltrare il traffico a un pod su un nodo diverso, il che richiede hop di rete aggiuntivi. Per evitare questa situazione, imposta il campo externalTrafficPolicy su Local nel manifest del servizio. Quando questo criterio è attivo, il bilanciatore del carico utilizza un controllo di integrità per identificare i nodi con pod integri per il servizio di destinazione. Il bilanciatore del carico invia il traffico solo ai pod integri, il che impedisce l'hop di rete aggiuntivo. Il compromesso è che queste norme possono portare a una distribuzione del traffico non uniforme se i pod di backend non sono distribuiti uniformemente tra i nodi del cluster.

Gestire il traffico in uscita

Il traffico in uscita è il traffico che esce dal cluster. Affinché un cluster GKE funzioni e le tue applicazioni possano raggiungere servizi esterni, devi gestire diversi percorsi di connettività.

Requisiti di connettività fondamentali: tutti i cluster GKE richiedono la connettività in uscita ai domini *.googleapis.com, *.gcr.io e *.pkg.dev. Anche la connettività in uscita all'indirizzo IP del control plane deve funzionare correttamente. Accesso a internet per i pod tramite Cloud NAT: nei cluster privati in cui i pod non hanno indirizzi IP pubblici, utilizza Cloud NAT per abilitare l'accesso a internet in uscita. Cloud NAT è un servizio gestito che consente ai pod di connettersi a internet per attività come il download di aggiornamenti o l'accesso ad API esterne senza esporli a connessioni in entrata.

Connettività ai Google Cloud servizi: se devi consentire al tuo cluster di comunicare in modo sicuro con altri servizi Google Cloud , come Cloud Storage o Cloud SQL, senza attraversare la rete internet pubblica, utilizza l'accesso privato Google. Si tratta di un importante meccanismo di uscita per i cluster privati che interagiscono con le API di Google.

Connettività ibrida e multi-cluster

Per connettere i cluster GKE all'infrastruttura on-premise, utilizza Cloud VPN per i tunnel criptati o Cloud Interconnect per connessioni dedicate a larghezza di banda elevata. Per attivare la comunicazione tra più cluster GKE, utilizza i servizi multi-cluster, che facilitano l'Service Discovery e il flusso di traffico tra diversi cluster, regioni o progetti.

Controlli di sicurezza della rete

Per proteggere il cluster e le applicazioni in esecuzione al suo interno, GKE fornisce più livelli di controlli di sicurezza per il traffico interno (est-ovest) ed esterno (nord-sud).

Protezione del traffico interno (est-ovest) con criteri di rete

Per impostazione predefinita, tutti i pod in un cluster GKE possono comunicare liberamente tra loro. Per proteggere il traffico interno e applicare il principio del privilegio minimo, puoi utilizzare NetworkPolicy. Un NetworkPolicy è una risorsa Kubernetes che funge da firewall per i tuoi pod controllando il traffico di rete tra loro. Le risorse NetworkPolicy consentono di definire regole per limitare il traffico in entrata e in uscita per un gruppo selezionato di pod in base a una combinazione di etichette, intervalli di indirizzi IP e numeri di porta. Quando crei il primo NetworkPolicy in uno spazio dei nomi, tutto il traffico non esplicitamente consentito da questo criterio viene negato. L'applicazione di questi criteri è integrata direttamente in GKE Dataplane V2 o viene gestita dal plug-in CNI del cluster, ad esempio Calico.

Esempio di manifest NetworkPolicy

L'esempio seguente mostra un manifest NetworkPolicy. Queste norme si applicano ai pod con l'etichetta app: backend e consentono il traffico in entrata solo dai pod che hanno l'etichetta app: frontend sulla porta TCP 6379.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

Proteggere l'accesso esterno al cluster

Controllare il traffico in entrata e in uscita dal cluster è fondamentale per proteggere le applicazioni da minacce esterne.

Regole firewall VPC

I cluster GKE si trovano all'interno di una rete VPC e sono protetti dalle regole firewall VPC che controllano il traffico da e verso i nodi del cluster. Google Cloud Le regole firewall VPC e i criteri di rete funzionano insieme per fornire una difesa approfondita. I firewall VPC operano a livello di nodo (livello 3 o livello 4) e controllano il traffico verso le VM stesse. I criteri di rete operano a livello di pod (livello 3 o livello 4) e forniscono un controllo più granulare sul traffico tra le applicazioni all'interno del cluster.

La creazione di regole firewall in entrata o in uscita che hanno come target i nodi del tuo cluster potrebbe avere effetti negativi. Ad esempio, l'applicazione di regole di negazione dell'uscita ai nodi del cluster potrebbe interrompere funzionalità come NodePort e kubectl exec.

Limitare l'accesso ai bilanciatori del carico

Quando esponi le applicazioni utilizzando un servizio o un ingresso Kubernetes, puoi applicare controlli di sicurezza aggiuntivi a livello di bilanciatore del carico. Per i bilanciatori del carico esterni, valuta queste opzioni:

  • Se esponi un servizio utilizzando il campo type: LoadBalancer, puoi specificare il campo loadBalancerSourceRanges nel manifest del servizio. Questo campo limita l'accesso al servizio solo agli intervalli di indirizzi IP che definisci.

  • Per i bilanciatori del carico delle applicazioni (Ingress), puoi utilizzare servizi di sicurezza più avanzati quando esponi applicazioni HTTP(S):

    • Google Cloud Armor: questo servizio è un firewall per applicazioni web (WAF) che contribuisce a proteggere le tue applicazioni da attacchi DDoS e altre minacce basate sul web.
    • Identity-Aware Proxy (IAP): per controllo dell'accesso granulare, puoi attivare IAP sui tuoi endpoint. IAP verifica l'identità di un utente e la utilizza per determinare se l'utente deve essere autorizzato ad accedere all'applicazione.

Passaggi successivi