Informazioni sui cluster privati

Questa pagina spiega come funzionano i cluster privati in Google Kubernetes Engine (GKE). Puoi anche scoprire come creare cluster privati.

I cluster privati utilizzano nodi che non hanno indirizzi IP esterni. Ciò significa che i client su internet non possono connettersi agli indirizzi IP dei nodi. I cluster privati sono ideali per i carichi di lavoro che, ad esempio, richiedono un accesso controllato a causa delle normative sulla privacy e sulla sicurezza dei dati.

I cluster privati sono disponibili in modalità Standard o Autopilot.

Architettura dei cluster privati

A differenza di un cluster pubblico, un cluster privato ha sia un endpoint interno del control plane sia un endpoint esterno del control plane.

Il seguente diagramma fornisce una panoramica dell'architettura di un cluster privato:

Architettura di cluster privato

Di seguito sono riportati i componenti principali di un cluster privato:

  • Control plane: il control plane ha un endpoint interno per la comunicazione interna del cluster e un endpoint esterno. Puoi scegliere di disattivare l'endpoint esterno.

  • Nodi: i nodi utilizzano solo indirizzi IP interni, isolandoli da internet pubblico.

  • Rete VPC: si tratta di una rete virtuale in cui crei subnet con intervalli di indirizzi IP interni specifici per i nodi e i pod del cluster.

  • Accesso privato Google: è abilitato nella subnet del cluster e consente ai nodi con indirizzi IP interni di raggiungere API e servizi Google Cloud essenziali senza bisogno di indirizzi IP pubblici. Ad esempio, l'accesso privato Google è necessario per i cluster privati per accedere alle immagini container da Artifact Registry e per inviare log a Cloud Logging. L'accesso privato Google è abilitato per impostazione predefinita nei cluster privati, ad eccezione dei cluster VPC condiviso, che richiedono l'attivazione manuale.

Il control plane nei cluster privati

Ogni cluster GKE ha un server API Kubernetes gestito dal control plane.

Il control plane viene eseguito su una macchina virtuale (VM) che si trova in una rete VPC in un progetto gestito da Google. Un cluster regionale ha più repliche del control plane, ognuna delle quali viene eseguita sulla propria VM.

Nei cluster privati, la rete VPC del control plane è connessa alla rete VPC del cluster tramite peering di rete VPC. La rete VPC contiene i nodi del cluster e la rete VPC Google Cloudgestita da Google contiene il control plane del cluster.

Il traffico tra i nodi e il control plane viene instradato interamente utilizzando indirizzi IP interni. Se utilizzi il peering di rete VPC per connettere la rete VPC del cluster a una terza rete, quest'ultima non può raggiungere le risorse nella rete VPC del control plane. Questo perché il peering di rete VPC supporta solo la comunicazione tra reti in peering diretto e la terza rete non può essere in peering con la rete del piano di controllo. Per ulteriori informazioni, vedi Limitazioni del peering di rete VPC.

Endpoint nei cluster privati

Il control plane per un cluster privato ha un endpoint interno oltre a un endpoint esterno.

L'endpoint interno è un indirizzo IP interno nella rete VPC del control plane. In un cluster privato, i nodi comunicano sempre con l'endpoint interno del control plane. A seconda della configurazione, puoi gestire il cluster con strumenti come kubectl che si connettono anche all'endpoint privato. Qualsiasi VM che utilizza la stessa subnet del cluster privato può accedere anche all'endpoint interno.

L'endpoint esterno è l'indirizzo IP esterno del control plane. Per impostazione predefinita, strumenti come kubectl comunicano con il control plane sul relativo endpoint esterno.

Opzioni per l'accesso agli endpoint del cluster

Puoi controllare l'accesso agli endpoint utilizzando una delle seguenti configurazioni:

  • Accesso all'endpoint esterno disabilitato: questa è l'opzione più sicura, in quanto impedisce qualsiasi accesso a internet al control plane. Questa è una buona scelta se hai configurato la tua rete on-premise per connettersi a Google Cloud utilizzando Cloud Interconnect o Cloud VPN.

    Se disattivi l'accesso all'endpoint esterno, devi configurare le reti autorizzate per l'endpoint interno. In caso contrario, puoi connetterti all'endpoint interno solo dai nodi del cluster o dalle VM nella stessa subnet del cluster. Con questa impostazione, le reti autorizzate devono essere indirizzi IP interni.

  • Accesso all'endpoint esterno abilitato, reti autorizzate abilitate: In questa configurazione, le reti autorizzate si applicano all'endpoint esterno del control plane. Questa è una buona scelta se devi amministrare il cluster da reti di origine non connesse alla rete VPC del cluster utilizzando Cloud Interconnect o Cloud VPN.

  • Accesso all'endpoint esterno abilitato, reti autorizzate disabilitate: Questa è l'opzione predefinita ed è anche la meno restrittiva. Poiché le reti autorizzate non sono abilitate, puoi amministrare il cluster da qualsiasi indirizzo IP di origine, a condizione che tu esegua l'autenticazione.

Riutilizzo del peering di rete VPC

I cluster privati creati dopo il 15 gennaio 2020 utilizzano una connessione di peering di rete VPC comune se i cluster si trovano nella stessa zona o regione e utilizzano la stessa rete VPC.Google Cloud

  • Per i cluster zonali: il primo cluster privato che crei in una zona genera una nuova connessione di peering di rete VPC alla rete VPC del control plane. I cluster privati zonali aggiuntivi che crei nella stessa zona e nella stessa rete VPC utilizzano la stessa connessione di peering.

  • Per i cluster regionali: il primo cluster privato che crei in una regione genera una nuova connessione di peering di rete VPC alla rete VPC del control plane. I cluster privati regionali aggiuntivi che crei nella stessa regione e rete VPC utilizzano la stessa connessione di peering.

I cluster zonali e regionali utilizzano le proprie connessioni di peering, anche se si trovano nella stessa regione. Ad esempio:

  • Crea due o più cluster privati zonali nella zona us-east1-b e configurali in modo che utilizzino la stessa rete VPC. Entrambi i cluster utilizzano la stessa connessione di peering.

  • Crea due o più cluster privati regionali nella regione us-east1 e configurali in modo che utilizzino la stessa rete VPC dei cluster zonali. Questi cluster regionali utilizzano la stessa connessione di peering di rete VPC tra loro, ma avranno bisogno di una connessione di peering diversa per comunicare con i cluster di zona.

Tutti i cluster privati creati prima del 15 gennaio 2020 utilizzano una connessione di peering di rete VPC unica. In altre parole, questi cluster non utilizzano la stessa connessione di peering con altri cluster zonali o regionali. Per abilitare il riutilizzo del peering di rete VPC su questi cluster, puoi eliminare un cluster e ricrearlo. L'upgrade di un cluster non comporta il riutilizzo di una connessione di peering di rete VPC esistente.

Per verificare se il tuo cluster privato utilizza una connessione di peering di rete VPC comune, consulta Verifica il riutilizzo del peering VPC.

Limitazioni

  • Ogni zona o regione può supportare un massimo di 75 cluster privati se il riutilizzo del peering di rete VPC è abilitato.

    Ad esempio, puoi creare fino a 75 cluster di zona privati in us-east1-b e altri 75 cluster regionali privati in us-east1. Ciò vale anche se utilizzi cluster privati in una rete VPC condiviso.

  • Il numero massimo di connessioni a una singola rete VPC è 25, il che significa che puoi creare cluster privati utilizzando solo 25 località uniche.

  • Il riutilizzo del peering di rete VPC si applica solo ai cluster nella stessa località, ad esempio i cluster regionali nella stessa regione o i cluster zonali nella stessa zona. Al massimo, puoi avere quattro peering di rete VPC per regione se crei cluster regionali e cluster zonali in tutte le zone di quella regione.

  • Per i cluster creati prima del 15 gennaio 2020, ogni rete VPC può eseguire il peering con un massimo di 25 altre reti VPC, il che significa che per questi cluster esiste un limite di al massimo 25 cluster privati per rete (supponendo che i peering non vengano utilizzati per altri scopi).

Passaggi successivi