Informazioni sui cluster privati


Questa pagina spiega come funzionano i cluster privati in Google Kubernetes Engine (GKE). Tu possono anche imparare a per creare cluster privati.

Utilizzo dei cluster privati nodi che non che hanno un indirizzo IP esterno. Ciò significa che i client su internet non possono connettersi agli indirizzi IP dei nodi. I cluster privati sono ideali carichi di lavoro che, ad esempio, richiedono un accesso controllato per via della privacy dei dati normative in materia di sicurezza.

I cluster privati sono disponibili sia nella versione standard Autopilot.

Architettura dei cluster privati

A differenza di un cluster pubblico, un cluster privato ha un piano di controllo interno e un endpoint esterno del piano di controllo.

Il seguente diagramma fornisce una panoramica dell'architettura per un ambiente cluster:

Architettura del cluster privato

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

  • Piano di controllo: il piano di controllo ha sia un endpoint interno per la comunicazione tra il cluster e un endpoint esterno. Puoi scegliere di disattivare endpoint esterno.

  • Nodi: i nodi utilizzano solo gli indirizzi IP interni, isolandoli dalla tramite la rete internet pubblica.

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

  • Accesso privato Google: si tratta di abilitata sulla subnet del cluster e consente ai nodi con indirizzi IP interni di raggiungere API e servizi Google Cloud essenziali senza la necessità e gli indirizzi IP esterni. Ad esempio, l'accesso privato Google è obbligatorio per dai cluster per accedere alle immagini container Artifact Registry e di inviare log a Cloud Logging. L'accesso privato Google è attivato da l'impostazione predefinita nei cluster privati, ad eccezione di Cluster VPC condivisi, che richiedono la gestione manuale e abilitare l'abilitazione.

Il piano di controllo nei cluster privati

Ogni cluster GKE ha un server API Kubernetes gestito il controllo aereo.

Il piano di controllo viene eseguito su una macchina virtuale (VM) che si trova in un VPC in un progetto gestito da Google. Un cluster a livello di regione ha più repliche sul piano di controllo, ognuno dei quali viene eseguito sulla propria VM.

Nei cluster privati, la rete VPC del piano di controllo è connessa alla rete VPC del cluster Peering di rete VPC. Il tuo VPC che contiene i nodi del cluster e la rete Google La rete VPC contiene il piano di controllo del cluster.

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

Endpoint nei cluster privati

Il piano di controllo per un cluster privato ha un endpoint interno oltre endpoint esterno.

L'endpoint interno è un indirizzo IP interno nel campo rete VPC. In un cluster privato, i nodi comunicano sempre dall'endpoint interno del piano di controllo. A seconda della configurazione, puoi: gestisci il cluster con strumenti come kubectl che si connettono all'ambiente privato endpoint. Qualsiasi VM che utilizza la stessa subnet del cluster privato accedono anche all'endpoint interno.

L'endpoint esterno è l'indirizzo IP esterno del piano di controllo. Per impostazione predefinita, strumenti come kubectl comunicano con il piano di controllo sul suo endpoint esterno.

Opzioni per l'accesso agli endpoint del cluster

Puoi controllare l'accesso agli endpoint utilizzando uno dei seguenti modi configurazioni:

  • Accesso esterno agli endpoint disattivato: è l'opzione più sicura in quanto impedisce l'accesso a internet al piano di controllo. Questo è un buon se hai configurato la rete on-premise per la connessione a Google Cloud Cloud Interconnect o Cloud VPN.

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

  • Accesso esterno agli endpoint abilitato, reti autorizzate abilitate: In questa configurazione, le reti autorizzate si applicano endpoint esterno. Questa è una buona scelta se devi amministrare il cluster dalle reti di origine non connesse una rete VPC tramite Cloud Interconnect o Cloud VPN.

  • Accesso esterno agli endpoint abilitato, reti autorizzate disattivate: Questa è l'opzione predefinita ed è anche l'opzione meno restrittiva. Dall'autorizzazione non sono abilitate, puoi amministrare il cluster da qualsiasi all'indirizzo IP di origine, purché tu esegua l'autenticazione.

Riutilizzo del peering di rete VPC

I cluster privati creati dopo il 15 gennaio 2020 utilizzano un'istanza Connessione in peering di rete VPC se i cluster si trovano negli stessi zona o regione Google Cloud e utilizza la stessa rete VPC.

  • Per i cluster di zona: il primo cluster privato che crei in una zona genera una nuova connessione in peering di rete VPC al VPC del cluster in ogni rete. Cluster privati a livello di zona aggiuntivi che crei nella stessa zona e la rete VPC usano la stessa connessione in peering.

  • Per i cluster a livello di regione: il primo cluster privato che crei in una regione una nuova connessione in peering di rete VPC rete VPC. Ulteriori cluster privati a livello di regione nella stessa regione e nella stessa rete VPC usano lo stesso connessione.

I cluster a livello di zona e di regione utilizzano le proprie connessioni in peering, anche se si trovano nella stessa regione. Ad esempio:

  • Creerai due o più cluster privati a livello di zona nella zona us-east1-b e configurarli affinché utilizzino lo stesso rete VPC. Entrambi i cluster utilizzano la stessa connessione in peering.

  • Crea due o più cluster privati a livello di regione nella regione us-east1 e configurarle in modo che utilizzino la stessa rete VPC cluster. Questi cluster a livello di regione utilizzano lo stesso peering di rete VPC ma necessitano di una connessione in peering diversa comunicare con i cluster di zona.

Tutti i cluster privati creati prima del 15 gennaio 2020 utilizzano un'istanza Connessione in peering di rete VPC. In altre parole, questi cluster non utilizzano la stessa connessione in peering con altri cluster a livello di zona o di regione. Per attivare Riutilizzo del peering di rete VPC su questi cluster, puoi eliminare un cluster ricrearlo. L'upgrade di un cluster non comporta il riutilizzo di un cluster esistente Connessione in peering di rete VPC.

Per verificare se il 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 in cui è abilitato il riutilizzo del peering di rete VPC.

    Ad esempio, puoi creare fino a 75 cluster di zona privati in us-east1-b e e altri 75 cluster a livello di regione privati in us-east1. Lo stesso vale anche se utilizzando cluster privati in una rete VPC condiviso.

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

  • Il riutilizzo del peering di rete VPC si applica solo ai cluster nella stessa località, ad esempio cluster a livello di regione di esempio nella stessa regione o cluster di zona nella stessa zona. Al massimo, puoi avere quattro peering di rete VPC per regione se crei sia a livello di regione sia di zona 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 esiste un limite di massimo 25 cluster privati per rete (supponendo che i peering non vengono usati per altri scopi).

Passaggi successivi