Panoramica della rete

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

Kubernetes ti consente di definire in modo dichiarativo il modo in cui viene eseguito il deployment delle il modo in cui le applicazioni comunicano tra loro e con il e il modo in cui i client possono raggiungere le tue applicazioni. Questa pagina fornisce inoltre informazioni su come GKE configura Google Cloud e servizi correlati, ove siano pertinenti per il networking.

Quando utilizzi Kubernetes per orchestrare le tue applicazioni, è importante cambiare il tuo modo di pensare alla progettazione di rete delle tue applicazioni e ai relativi . Con Kubernetes, puoi pensare a come pod, servizi e client esterni anziché pensare a come i tuoi host o le tue macchine virtuali (VM) sono connessi.

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. Inoltre, Kubernetes e Google Cloud configurano regole di filtro IP, tabelle di routing e regole firewall su ciascun nodo, a seconda sul modello dichiarativo dei deployment Kubernetes e dei cluster configurazione su Google Cloud.

Prerequisiti

In questa pagina viene utilizzata la terminologia relativa Trasporti, Internet e Applicazione strati Protocollo internet suite, tra cui HTTP, e DNS, ma non è necessario essere esperti su questi argomenti.

Inoltre, questi contenuti potrebbero essere comprensibili se disponi di una comprensione dei concetti e delle utilità di gestione della rete Linux come iptables regole e routing.

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 chiamarsi "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 l'indirizzo IP del piano di controllo. 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 usa vari intervalli IP per assegnare indirizzi IP a nodi, pod Servizi.

  • A ogni nodo è assegnato un indirizzo IP una rete VPC (Virtual Private Cloud). Questo IP nodo fornisce connettività da componenti di controllo come kube-proxy e kubelet all'API Kubernetes o server web. 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 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. li connette ad altri pod in esecuzione nel cluster.
  • Ogni servizio ha un indirizzo IP, chiamato ClusterIP, che viene assegnato alla rete VPC del cluster. Facoltativamente, puoi personalizzare rete VPC quando crei il cluster.
  • Ogni piano di controllo ha un indirizzo IP pubblico o interno in base al tipo di il cluster, la versione e la data di creazione. Per maggiori informazioni delle informazioni, vedi la descrizione del piano di controllo.

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

La MTU selezionata per un'interfaccia di pod dipende dalla rete di container Interfaccia (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 1.26.1 e versioni 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 tramite uno dei seguenti elementi:
GKE Dataplane V2 Ereditato

Attivazione tramite --enable-dataplane-v2.

Per maggiori dettagli, consulta Utilizzo di GKE Dataplane V2.

Per ulteriori informazioni, vedi Cluster nativi VPC.

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 nel cluster fa parte 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 una spazio dei nomi di rete per il pod nel kernel Linux del nodo. Questo spazio dei nomi di rete connette all'interfaccia di rete fisica del nodo, come eth0, con il pod che utilizza di rete, in modo che i pacchetti possano passare da e verso il 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 presenti 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. Da dal punto di vista del container, il pod sembra essere una macchina fisica 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 comando seguente mostra di vari pod Indirizzi MAC collegati a diversi dispositivi Windows:

    arp -n

    L'esecuzione del seguente comando nel container 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 sono diverse 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 si modifica La configurazione dichiarativa del pod o la modifica dell'immagine di un container oppure quando 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 sono presenti pod che imposta hostNetwork: false.↩

Servizi

In Kubernetes, puoi assegnare coppie chiave-valore arbitrarie chiamate etichette su qualsiasi di una risorsa Kubernetes. Kubernetes usa le etichette per raggruppare più pod correlati in un'unità logica chiamata Service. 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, ognuno dei quali è composto da e più pod. Ciascuno dei pod nel diagramma ha l'etichetta app=demo, ma le altre etichette sono diverse. "frontend" del servizio corrisponde a tutti i pod app=demo e component=frontend, mentre il servizio "utenti" corrisponde a tutti i pod 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 due 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 IP di servizio disponibili per il cluster indirizzi IP. Kubernetes assegna anche un nome host a ClusterIP, aggiungendo un'etichetta Voce DNS. Il ClusterIP e il nome host sono univoci all'interno del cluster e non cambiano durante l'intero ciclo di vita del servizio. Kubernetes rilascia solo il cluster ClusterIP e nome host 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 basato su traffico in uscita di bilanciamento del carico, controlla il server API Kubernetes e continua mappa il ClusterIP a pod in stato integro aggiungendo e rimuovendo il NAT di destinazione (DNAT) le regole al sottosistema iptables del nodo. Quando un container in esecuzione in un pod invia il traffico al ClusterIP di un servizio, il nodo seleziona un pod in modo casuale instrada il traffico al pod.

Quando configuri un servizio, puoi facoltativamente rimapparne la porta di ascolto che definiscono i valori di port e targetPort.

  • port è la posizione 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 dei 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 del cluster:

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

DNS

GKE fornisce le seguenti opzioni DNS del cluster gestito per risolvere di servizi e 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 su cloud che sostituisce a kube-dns nel cluster. Per ulteriori informazioni, vedi Utilizza 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 delle prestazioni.

Per saperne di più su come GKE fornisce il DNS, consulta Service Discovery e DNS.

Piano di controllo

In Kubernetes, il controllo aereo 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 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, i cluster privati esistenti che non soddisfano le condizioni precedenti sono non 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.

Networking all'esterno 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 quando progettando le applicazioni e i carichi di lavoro del tuo 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 comunicano liberamente, ma le connessioni esterne al cluster non possono accedere assistenza. Ad esempio, nell'illustrazione precedente, i clienti esterni al cluster non può accedere al servizio frontend utilizzando il suo 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 in arrivo sia dall'esterno del cluster che dall'esterno rete VPC. 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 in entrata della 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 esterni specializzati bilanciatori del carico 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 suo servizio. Bilancia invece il traffico in tutti i nodi nel cluster, anche quelli che non eseguono un pod pertinente. Su un a livello di regione, il carico viene distribuito tra tutti i nodi in tutte le zone della 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 o su un nodo diverso. 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 alla centrale, 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. Richiede hop di rete aggiuntivi. Se vuoi per evitare hop aggiuntivi, puoi specificare che il traffico deve essere indirizzato a un pod 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 Da externalTrafficPolicy a 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 verso i 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 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 cluster e configura le regole firewall della tua rete VPC per consentire dall'esterno della rete VPC, utilizzando all'indirizzo IP esterno. 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 tuo Servizio per eseguire il provisioning 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 quando il traffico raggiunge un determinato nodo, quest'ultimo utilizza la tabella NAT iptables per anche se si pod su un nodo diverso. 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 dei servizi web RESTful, comunicano tramite HTTP(S). Puoi consentire ai client esterni alla tua rete VPC di accedere di un'applicazione con un cluster Kubernetes In entrata.

Una risorsa Ingress consente di mappare nomi host e 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 Bilanciatore del carico delle applicazioni esterno nel progetto Google Cloud. Il bilanciatore del carico invia una richiesta all'indirizzo IP di NodePort. Dopo che la richiesta raggiunge il nodo, quest'ultimo utilizza i suoi iptables tabella NAT 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

Visita GKE Ingress per il bilanciatore del carico delle applicazioni per ulteriori informazioni.

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 al bilanciatore del carico delle applicazioni. Il bilanciatore del carico è un proxy reale; questo elemento sceglie un nodo e inoltra la richiesta all'oggetto NodeIP di quel nodo:NodePort combinazione. 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 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 nello stesso cluster possono comunicare liberamente. Tuttavia, puoi limitare la connettività all'interno di un cluster in diversi modi, a seconda delle tue esigenze.

Limitare l'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 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, e altro traffico.

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.

Limitazione dell'accesso a un bilanciatore del carico esterno

Se il tuo servizio utilizza un bilanciatore del carico esterno, il traffico proveniente da qualsiasi indirizzo IP esterno può accedere al Servizio per impostazione predefinita. Puoi limita gli intervalli di indirizzi IP che possono accedere agli endpoint all'interno del cluster, la configurazione dell'opzione loadBalancerSourceRanges durante la configurazione del servizio. Puoi specificare più intervalli e aggiornare la configurazione in esecuzione in qualsiasi momento. L'istanza kube-proxy in esecuzione su ciascun nodo configura le regole iptables del nodo in modo da negare tutto il traffico che non corrisponde il loadBalancerSourceRanges specificato. Nessuna regola firewall VPC è è stato creato.

Limitazione dell'accesso a un bilanciatore del carico delle applicazioni

Se il tuo 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 alle torna indietro 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 con containerd non è in grado di connettersi all'intervallo 172.17/16

Una VM nodo con containerd abilitato non può connettersi a un host con un IP in 172.17/16. Per ulteriori informazioni, vedi Conflitto con l'intervallo di indirizzi IP 172.17/16.

Passaggi successivi