In questa pagina viene spiegato come creare un cluster Google Kubernetes Engine privato (GKE), che è un tipo di cluster nativo di VPC. In un cluster privato, i nodi hanno solo indirizzi IP interni, il che significa che i nodi e i pod sono isolati da Internet per impostazione predefinita.
Gli indirizzi IP interni per i nodi provengono dall'intervallo di indirizzi IP principali della subnet che scegli per il cluster. Gli indirizzi IP dei pod e gli indirizzi IP di servizio provengono da due intervalli di indirizzi IP secondari della stessa subnet. Per ulteriori informazioni, consulta gli intervalli IP per i cluster nativi di VPC.
Le versioni di GKE 1.14.2 e versioni successive supportano intervalli di indirizzi IP interni, inclusi intervalli privati (RFC 1918 e altri intervalli privati) e intervalli di indirizzi IP pubblici utilizzati privatamente. Consulta la documentazione di VPC per un elenco di intervalli di indirizzi IP interni validi.
Per scoprire di più su come funzionano i cluster privati, vedi Cluster privati.
Prima di iniziare
Acquisisci familiarità con i requisiti, le restrizioni e le limitazioni prima di andare al passaggio successivo.
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e poi inizializza l'interfaccia a riga di comando gcloud.
- Assicurati di avere l'autorizzazione corretta per creare i cluster. Come minimo devi essere un amministratore del cluster Kubernetes Engine.
Creazione di un cluster privato senza accesso client all'endpoint pubblico
In questa sezione creerai le seguenti risorse:
- Un cluster privato denominato
private-cluster-0
con nodi privati e che non ha accesso client all'endpoint pubblico. - Una rete denominata
my-net-0
. - Una subnet denominata
my-subnet-0
.
gcloud
Per i cluster standard, esegui il comando seguente:
gcloud container clusters create private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --enable-private-endpoint \ --master-ipv4-cidr 172.16.0.32/28
Per i cluster Autopilot, esegui il comando seguente:
gcloud container clusters create-auto private-cluster-0 \ --create-subnetwork name=my-subnet-0 \ --enable-master-authorized-networks \ --enable-private-nodes \ --enable-private-endpoint
dove:
--create-subnetwork name=my-subnet-0
fa in modo che GKE crei automaticamente una subnet denominatamy-subnet-0
.--enable-master-authorized-networks
specifica che l'accesso all'endpoint pubblico è limitato agli intervalli di indirizzi IP da te autorizzati.--enable-ip-alias
rende il cluster VPC nativo (non richiesto per Autopilot).--enable-private-nodes
indica che i nodi del cluster non hanno indirizzi IP esterni.--enable-private-endpoint
indica che il cluster è gestito utilizzando l'indirizzo IP privato dell'endpoint dell'API del piano di controllo.--master-ipv4-cidr 172.16.0.32/28
specifica un intervallo di indirizzi IP interni per il piano di controllo (facoltativo per Autopilot). Questa impostazione è permanente per questo cluster e deve essere univoca all'interno del VPC. L'uso di indirizzi IP interni non conformi alla RFC 1918 è supportato.
console
Crea una rete e una subnet
Vai alla pagina Reti VPC nella console.
Fai clic su add_box Crea rete VPC.
In Nome, inserisci
my-net-0
.In Modalità di creazione subnet, seleziona Personalizzata.
Nella sezione Nuova subnet, per Nome, inserisci
my-subnet-0
.Nell'elenco Area geografica, seleziona l'area geografica che preferisci.
In Intervallo di indirizzi IP, inserisci
10.2.204.0/22
.Imposta Accesso privato Google su On.
Fai clic su Fine.
Fai clic su Crea.
Crea un cluster privato
Vai alla pagina Google Kubernetes Engine nella console.
Fai clic su add_box Crea.
Nella sezione Standard o Autopilot, fai clic su Configura.
In Nome, inserisci
private-cluster-0
.Per i cluster standard, nel riquadro di navigazione sotto Cluster, fai clic su Networking.
Nell'elenco Rete, seleziona my-net-0.
Nell'elenco Subnet nodo, seleziona my-subnet-0.
Seleziona il pulsante di opzione Cluster privato.
Deseleziona la casella di controllo Accedi al piano di controllo utilizzando l'indirizzo IP esterno.
(Facoltativo per Autopilot): imposta Intervallo IP piano di controllo su
172.16.0.32/28
.Fai clic su Crea.
Server
Per creare un cluster senza un piano di controllo raggiungibile pubblicamente, specifica il campo enablePrivateEndpoint: true
nella risorsa privateClusterConfig
.
A questo punto, sono i soli indirizzi IP che hanno accesso al piano di controllo:
- L'intervallo principale di
my-subnet-0
. - L'intervallo secondario utilizzato per i pod.
Supponi, ad esempio, di aver creato una VM nell'intervallo principale my-subnet-0
.
Quindi, nella VM potrai configurare kubectl
in modo che utilizzi l'indirizzo IP interno del piano di controllo.
Per accedere al piano di controllo dall'esterno di my-subnet-0
, devi
autorizzare almeno un intervallo di indirizzi per accedere all'endpoint privato.
Supponi di avere una VM nella rete predefinita, nella stessa regione del cluster, ma non in my-subnet-0
.
Ad esempio:
my-subnet-0
:10.0.0.0/22
- Intervallo secondario del pod:
10.52.0.0/14
- Indirizzo VM:
10.128.0.3
Puoi autorizzare la VM ad accedere al piano di controllo utilizzando questo comando:
gcloud container clusters update private-cluster-0 \
--enable-master-authorized-networks \
--master-authorized-networks 10.128.0.3/32
Creazione di un cluster privato con accesso limitato all'endpoint pubblico
Quando crei un cluster privato utilizzando questa configurazione, puoi scegliere di utilizzare una subnet generata automaticamente o una subnet personalizzata.
usando una subnet generata automaticamente.
In questa sezione creerai un cluster privato denominato private-cluster-1
, dove GKE genererà automaticamente una subnet per i tuoi nodi del cluster.
Nella subnet è abilitato l'accesso privato Google. Nella subnet, GKE crea automaticamente due intervalli secondari: uno per i pod e uno per i servizi.
Puoi usare l'interfaccia a riga di comando di Google Cloud o l'API GKE.
gcloud
Per i cluster standard, esegui il comando seguente:
gcloud container clusters create private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.0/28
Per i cluster Autopilot, esegui il comando seguente:
gcloud container clusters create-auto private-cluster-1 \ --create-subnetwork name=my-subnet-1 \ --enable-master-authorized-networks \ --enable-private-nodes
dove:
--create-subnetwork name=my-subnet-1
fa in modo che GKE crei automaticamente una subnet denominatamy-subnet-1
.--enable-master-authorized-networks
specifica che l'accesso all'endpoint pubblico è limitato agli intervalli di indirizzi IP da te autorizzati.--enable-ip-alias
rende il cluster VPC nativo (non richiesto per Autopilot).--enable-private-nodes
indica che i nodi del cluster non hanno indirizzi IP esterni.--master-ipv4-cidr 172.16.0.0/28
specifica un intervallo di indirizzi IP interni per il piano di controllo (facoltativo per Autopilot). Questa impostazione è permanente per questo cluster e deve essere univoca all'interno del VPC. L'uso di indirizzi IP interni non conformi alla RFC 1918 è supportato.
Server
Specifica il campo privateClusterConfig
nella risorsa API Cluster
:
{
"name": "private-cluster-1",
...
"ipAllocationPolicy": {
"createSubnetwork": true,
},
...
"privateClusterConfig" {
"enablePrivateNodes": boolean # Creates nodes with internal IP addresses only
"enablePrivateEndpoint": boolean # false creates a cluster control plane with a publicly-reachable endpoint
"masterIpv4CidrBlock": string # CIDR block for the cluster control plane
"privateEndpoint": string # Output only
"publicEndpoint": string # Output only
}
}
A questo punto, sono i soli indirizzi IP che hanno accesso al piano di controllo del cluster:
- L'intervallo principale di
my-subnet-1
. - L'intervallo secondario utilizzato per i pod.
Supponi di avere un gruppo di macchine, all'esterno della tua rete VPC, con indirizzi nell'intervallo 203.0.113.0/29
. Puoi autorizzare queste macchine ad accedere all'endpoint pubblico inserendo questo comando:
gcloud container clusters update private-cluster-1 \
--enable-master-authorized-networks \
--master-authorized-networks 203.0.113.0/29
Ora questi sono gli unici indirizzi IP che hanno accesso al piano di controllo:
- L'intervallo principale di
my-subnet-1
. - L'intervallo secondario utilizzato per i pod.
- Gli intervalli di indirizzi che hai autorizzato, ad esempio
203.0.113.0/29
.
usando una subnet personalizzata.
In questa sezione creerai le seguenti risorse:
- Un cluster privato denominato
private-cluster-2
. - Una rete denominata
my-net-2
. Una subnet denominata
my-subnet-2
, con intervallo primario192.168.0.0/20
, per i nodi del cluster. La subnet ha i seguenti intervalli di indirizzi secondari:
gcloud
Crea una rete
Per prima cosa, crea una rete per il tuo cluster. Il comando seguente crea una rete, my-net-2
:
gcloud compute networks create my-net-2 \
--subnet-mode custom
Creare una subnet e intervalli secondari
Successivamente, crea una subnet, my-subnet-2
, nella rete my-net-2
, con intervalli secondari my-pods
per pod e my-services
per servizi:
gcloud compute networks subnets create my-subnet-2 \
--network my-net-2 \
--range 192.168.0.0/20 \
--secondary-range my-pods=10.4.0.0/14,my-services=10.0.32.0/20 \
--enable-private-ip-google-access
Crea un cluster privato
Ora crea un cluster privato, private-cluster-2
, utilizzando la rete, la subnet e gli intervalli secondari che hai creato.
Per i cluster standard, esegui il comando seguente:
gcloud container clusters create private-cluster-2 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes \ --enable-ip-alias \ --master-ipv4-cidr 172.16.0.16/28 \ --no-enable-basic-auth \ --no-issue-client-certificate
Per i cluster Autopilot, esegui il comando seguente:
gcloud container clusters create-auto private-cluster-2 \ --region us-central1 \ --enable-master-authorized-networks \ --network my-net-2 \ --subnetwork my-subnet-2 \ --cluster-secondary-range-name my-pods \ --services-secondary-range-name my-services \ --enable-private-nodes
console
Crea una rete, una subnet e intervalli secondari
Vai alla pagina Reti VPC nella console.
Fai clic su add_box Crea rete VPC.
In Nome, inserisci
my-net-2
.In Modalità di creazione subnet, seleziona Personalizzata.
Nella sezione Nuova subnet, per Nome, inserisci
my-subnet-2
.Nell'elenco Area geografica, seleziona l'area geografica che preferisci.
In Intervallo di indirizzi IP, inserisci
192.168.0.0/20
.Fai clic su Crea intervallo IP secondario. In Nome intervallo di subnet, inserisci
my-services
. Per Intervallo IP secondario, inserisci10.0.32.0/20
.Fai clic su Aggiungi intervallo IP. In Nome intervallo di subnet, inserisci
my-pods
. Per Intervallo IP secondario, inserisci10.4.0.0/14
.Imposta Accesso privato Google su On.
Fai clic su Fine.
Fai clic su Crea.
Crea un cluster privato
Crea un cluster privato che utilizza la subnet:
Vai alla pagina Google Kubernetes Engine nella console.
Fai clic su add_box Crea.
Nella sezione Standard o Autopilot, fai clic su Configura.
In Nome, inserisci
private-cluster-2
.Per i cluster standard, nel riquadro di navigazione sotto Cluster, fai clic su Networking.
Seleziona il pulsante di opzione Cluster privato.
Per creare un piano di controllo accessibile dagli intervalli IP esterni autorizzati, mantieni selezionata la casella di controllo Accedi al piano di controllo utilizzando l'indirizzo IP esterno.
(Facoltativo per Autopilot) Imposta Intervallo IP piano di controllo su
172.16.0.16/28
.Nell'elenco Rete, seleziona my-net-2.
Nell'elenco Subnet nodo, seleziona my-subnet-2.
Deseleziona la casella di controllo Crea automaticamente intervalli secondari.
Nell'elenco Intervallo CIDR secondario del pod, seleziona my-pods.
Nell'elenco Intervallo CIDR secondario dei servizi, seleziona my-services.
Seleziona la casella di controllo Abilita reti autorizzate piano di controllo.
Fai clic su Crea.
A questo punto, sono i soli indirizzi IP che hanno accesso al piano di controllo:
- L'intervallo principale di
my-subnet-2
. - L'intervallo secondario
my-pods
.
Supponi di avere un gruppo di macchine, all'esterno di my-net-2
, con indirizzi nell'intervallo 203.0.113.0/29
. Puoi autorizzare queste macchine ad accedere all'endpoint pubblico inserendo questo comando:
gcloud container clusters update private-cluster-2 \
--enable-master-authorized-networks \
--master-authorized-networks 203.0.113.0/29
A questo punto, sono i soli indirizzi IP che hanno accesso al piano di controllo:
- L'intervallo principale di
my-subnet-2
. - L'intervallo secondario
my-pods
. - Gli intervalli di indirizzi che hai autorizzato, ad esempio
203.0.113.0/29
.
Utilizzo di Cloud Shell per accedere a un cluster privato
Il cluster privato che hai creato nella sezione
Utilizzo di una subnet generata automaticamente, private-cluster-1
,
ha un endpoint pubblico e ha reti autorizzate abilitate. Se vuoi utilizzare Cloud Shell per accedere al cluster, devi aggiungere l'indirizzo IP pubblico di Cloud Shell all'elenco delle reti autorizzate del cluster.
Per farlo:
Nella finestra della riga di comando di Cloud Shell, utilizza
dig
per trovare l'indirizzo IP esterno di Cloud Shell:dig +short myip.opendns.com @resolver1.opendns.com
Aggiungi l'indirizzo esterno di Cloud Shell all'elenco delle reti autorizzate del cluster:
gcloud container clusters update private-cluster-1 \ --enable-master-authorized-networks \ --master-authorized-networks EXISTING_AUTH_NETS,SHELL_IP/32
Sostituisci quanto segue:
EXISTING_AUTH_NETS
: gli indirizzi IP dell'elenco esistente di reti autorizzate. Puoi trovare le reti autorizzate nella console o eseguendo il comando seguente:gcloud container clusters describe private-cluster-1 --format "flattened(masterAuthorizedNetworksConfig.cidrBlocks[])"
SHELL_IP
: l'indirizzo IP esterno di Cloud Shell.
Recupera le credenziali, in modo da poter utilizzare
kubectl
per accedere al cluster:gcloud container clusters get-credentials private-cluster-1 \ --project PROJECT_ID
Sostituisci
PROJECT_ID
con l'ID progetto.Usa
kubectl
in Cloud Shell per accedere al cluster privato:kubectl get nodes
L'output è simile al seguente:
NAME STATUS ROLES AGE VERSION gke-private-cluster-1-default-pool-7d914212-18jv Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-3d9p Ready <none> 104m v1.21.5-gke.1302 gke-private-cluster-1-default-pool-7d914212-wgqf Ready <none> 104m v1.21.5-gke.1302
Creazione di un cluster privato con accesso illimitato all'endpoint pubblico
In questa sezione creerai un cluster privato in cui qualsiasi indirizzo IP potrà accedere al piano di controllo.
gcloud
Per i cluster standard, esegui il comando seguente:
gcloud container clusters create private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-ip-alias \ --enable-private-nodes \ --master-ipv4-cidr 172.16.0.32/28
Per i cluster Autopilot, esegui il comando seguente:
gcloud container clusters create-auto private-cluster-3 \ --create-subnetwork name=my-subnet-3 \ --no-enable-master-authorized-networks \ --enable-private-nodes
dove:
--create-subnetwork name=my-subnet-3
fa in modo che GKE crei automaticamente una subnet denominatamy-subnet-3
.--no-enable-master-authorized-networks
disabilita le reti autorizzate per il cluster.--enable-ip-alias
rende il cluster VPC nativo (non richiesto per Autopilot).--enable-private-nodes
indica che i nodi del cluster non hanno indirizzi IP esterni.--master-ipv4-cidr 172.16.0.32/28
specifica un intervallo di indirizzi IP interni per il piano di controllo (facoltativo per Autopilot). Questa impostazione è permanente per questo cluster e deve essere univoca all'interno del VPC. L'uso di indirizzi IP interni non conformi alla RFC 1918 è supportato.
console
Vai alla pagina Google Kubernetes Engine nella console.
Fai clic su add_box Crea.
Nella sezione Standard o Autopilot, fai clic su Configura.
In Nome, inserisci
private-cluster-3
.Per i cluster standard, nel riquadro di navigazione sotto Cluster, fai clic su Networking.
Seleziona l'opzione Cluster privato.
Mantieni selezionata la casella di controllo Accedi al piano di controllo utilizzando l'indirizzo IP esterno.
(Facoltativo per Autopilot) Imposta Intervallo IP piano di controllo su
172.16.0.32/28
.Lascia Rete e Subnet nodo impostate su
default
. GKE genera una subnet per il tuo cluster.Deseleziona la casella di controllo Abilita reti autorizzate piano di controllo.
Fai clic su Crea.
Altre configurazioni dei cluster privati
Oltre alle configurazioni precedenti, puoi eseguire i cluster privati con le seguenti configurazioni.
Concessione dell'accesso a Internet ai nodi privati
Per fornire l'accesso a Internet in uscita per i nodi privati, puoi utilizzare Cloud NAT.
Creazione di un cluster privato in una rete VPC condivisa
Per scoprire come creare un cluster privato in una rete VPC condivisa, vedi Creazione di un cluster privato in un VPC condiviso.
Deployment di un'applicazione container Windows Server in un cluster privato
Per scoprire come eseguire il deployment di un'applicazione container di Windows Server in un cluster privato, consulta la documentazione del pool di nodi Windows.
Accesso all'endpoint privato del piano di controllo a livello globale
L'endpoint privato del piano di controllo è implementato da un bilanciatore del carico TCP/UDP interno nella rete VPC del piano di controllo. I client interni o collegati tramite tunnel Cloud VPN e collegamenti Cloud Interconnect possono accedere ai bilanciatori del carico TCP/UDP interni.
Per impostazione predefinita, i client devono trovarsi nella stessa area geografica del bilanciatore del carico.
Quando abiliti l'accesso globale al piano di controllo, il bilanciatore del carico TCP/UDP interno è accessibile a livello globale: le VM client e i sistemi on-premise possono connettersi all'endpoint privato del piano di controllo, in base alla configurazione delle reti autorizzate, da qualsiasi regione.
Per ulteriori informazioni sui bilanciatori del carico TCP/UDP interni e sull'accesso globale, consulta Bilanciatori del carico interni e reti connesse.
Abilitazione dell'accesso globale agli endpoint privati del piano di controllo
Per impostazione predefinita, l'accesso globale non è abilitato per l'endpoint privato del piano di controllo quando crei un cluster privato. Per abilitare l'accesso globale al piano di controllo, utilizza i seguenti strumenti in base alla modalità cluster:
- Per i cluster standard, puoi utilizzare
Google Cloud CLI
o Google Cloud Console. Per i cluster Autopilot, puoi utilizzare la risorsa Terraform di
google_container_cluster
.
gcloud
Aggiungi il flag enable-master-global-access
per creare un cluster privato con
accesso globale all'endpoint privato del piano di controllo abilitato:
gcloud container clusters create CLUSTER_NAME \
--enable-private-nodes \
--enable-ip-alias \
--master-ipv4-cidr=172.16.16.0/28 \
--enable-master-global-access
Puoi anche abilitare l'accesso globale all'endpoint privato del piano di controllo per un cluster privato esistente:
gcloud container clusters update CLUSTER_NAME \
--enable-master-global-access
console
Per creare un nuovo cluster privato con accesso globale al piano di controllo abilitato, esegui i seguenti passaggi:
Vai alla pagina Google Kubernetes Engine nella console.
Fai clic su add_box Crea.
Inserisci un nome.
Nel riquadro di navigazione, in Cluster, fai clic su Networking.
Seleziona Cluster privato.
Seleziona la casella di controllo Abilita accesso globale piano di controllo.
Configura gli altri campi come preferisci.
Fai clic su Crea.
Per abilitare l'accesso globale al piano di controllo per un cluster privato esistente, esegui i seguenti passaggi:
Vai alla pagina Google Kubernetes Engine nella console.
Accanto al cluster che vuoi modificare, fai clic su more_vert Azioni, quindi fai clic su edit Modifica.
Nella sezione Networking, fai clic su edit Modifica accanto a Reti autorizzate piano di controllo.
Nella finestra di dialogo Modifica reti autorizzate piano di controllo, seleziona la casella di controllo Abilita reti autorizzate piano di controllo.
Fai clic su Salva modifiche.
Verifica dell'accesso globale agli endpoint privati del piano di controllo
Puoi verificare che l'accesso globale all'endpoint privato del piano di controllo sia abilitato eseguendo il comando seguente e esaminando il suo output.
gcloud container clusters describe CLUSTER_NAME
L'output include una sezione privateClusterConfig
in cui puoi visualizzare lo stato di masterGlobalAccessConfig
.
privateClusterConfig:
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.1.0/28
peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer
privateEndpoint: 172.16.1.2
publicEndpoint: 34.68.128.12
masterGlobalAccessConfig:
enabled: true
Connessione all'endpoint privato del piano di controllo dalle reti on-premise
Quando crei un cluster privato GKE e disattivi l'endpoint pubblico del piano di controllo, puoi comunque connetterti all'endpoint privato del piano di controllo da una rete on-premise utilizzando strumenti come kubectl
. Questa sezione descrive i requisiti di networking necessari per accedere all'endpoint privato del piano di controllo da una rete on-premise.
Il seguente diagramma mostra un percorso di routing tra una rete on-premise e i nodi del piano di controllo GKE:
Per connetterti all'endpoint privato di un piano di controllo dalla rete on-premise, completa le seguenti attività:
Identifica il peering tra la rete VPC del tuo cluster e la rete VPC del piano di controllo:
gcloud container clusters describe CLUSTER_NAME
L'output di questo comando include il campo
privateClusterConfig.peeringName
del cluster. Questo è il nome del peering tra il cluster e la rete VPC del piano di controllo. Ad esempio:privateClusterConfig: enablePrivateNodes: true masterIpv4CidrBlock: 172.16.1.0/28 peeringName: gke-1921aee31283146cdde5-9bae-9cf1-peer privateEndpoint: 172.16.1.2 publicEndpoint: 34.68.128.12
Configura la tua rete VPC per esportare le relative route personalizzate nella relazione di peering con la rete VPC del piano di controllo. La rete VPC del piano di controllo è già configurata per importare route personalizzate. Questo fornisce un percorso che consente al piano di controllo di inviare pacchetti alle risorse on-premise.
Aggiorna la connessione in peering, consentendo l'esportazione di route personalizzate, per la connessione in peering identificata nel passaggio precedente.
Per fornire un percorso per il traffico dalla rete on-premise alla rete VPC del piano di controllo, procedi in uno dei seguenti modi:
Per Cloud Interconnect e Cloud VPN: pubblicizza l'intervallo CIDR del piano di controllo utilizzando un annuncio di route personalizzata del router Cloud. Se l'accesso globale al piano di controllo è disabilitato, questo annuncio di percorso personalizzato deve essere in una sessione BGP di un router Cloud nella stessa regione del cluster. Se l'accesso globale al piano di controllo è abilitato, puoi inserire questo annuncio di route personalizzata su un router Cloud in qualsiasi regione. Per ulteriori informazioni, consulta la sezione Intervalli IP personalizzati per la pubblicità.
Per un tunnel VPN classico che non utilizza il routing dinamico: devi configurare una route statica per l'intervallo CIDR del piano di controllo nei tuoi router on-premise.
Considerazioni sulla pubblicità di route on-premise
I CIDR che la rete on-premise pubblicizza sui router Cloud della rete VPC del cluster devono rispettare le seguenti condizioni:
Sebbene il VPC del tuo cluster accetterà una route predefinita, la rete VPC del piano di controllo rifiuta sempre le route con una destinazione
0.0.0.0/0
(una route predefinita) perché la rete VPC del piano di controllo ha già una route locale locale e questa route locale è sempre considerata per prima. Se il router on-premise pubblicizza una route predefinita nella tua rete VPC, deve anche pubblicizzare destinazioni specifiche on-premise, in modo che il piano di controllo abbia un percorso di ritorno alla rete on-premise. Queste destinazioni più specifiche generano route dinamiche personalizzate più specifiche nella tua rete VPC e tali route più specifiche vengono accettate dalla rete VPC del piano di controllo tramite il peering di rete VPC.Quando la rete VPC del piano di controllo accetta altre route ampie, interrompe la connettività agli indirizzi IP pubblici per le API e i servizi Google. A titolo di esempio, non dovresti pubblicizzare percorsi con destinazioni
0.0.0.0/1
e128.0.0.0/1
. Fai riferimento al punto precedente per un'alternativa.Presta particolare attenzione ai limiti del router Cloud, in particolare al numero massimo di destinazioni univoche per route apprese.
Disattivazione dell'esportazione di route personalizzata
Per disattivare l'esportazione delle route personalizzate dal tuo VPC:
gcloud compute networks peerings update PEERING_NAME \
--network VPC_NAME \
--no-export-custom-routes
Sostituisci quanto segue:
PEERING_NAME
: il valore diprivateClusterConfig.peeringName
.VPC_NAME
: il nome del tuo VPC.
Per trovare l'peeringName
, vedi il primo passaggio delle istruzioni precedenti per abilitare l'esportazione di route personalizzata.
Verifica che i nodi non abbiano indirizzi IP esterni
Dopo aver creato un cluster privato, verifica che i nodi del cluster non abbiano indirizzi IP esterni.
gcloud
Esegui questo comando:
kubectl get nodes --output wide
La colonna EXTERNAL-IP
dell'output è vuota:
STATUS ... VERSION EXTERNAL-IP OS-IMAGE ...
Ready v.8.7-gke.1 Container-Optimized OS from Google
Ready v1.8.7-gke.1 Container-Optimized OS from Google
Ready v1.8.7-gke.1 Container-Optimized OS from Google
console
Vai alla pagina Google Kubernetes Engine nella console.
Nell'elenco dei cluster, fai clic sul nome del cluster.
Nella pagina Cluster, fai clic sulla scheda Nodi.
In Pool di nodi, fai clic sul nome del pool di nodi.
Nella pagina Dettagli pool di nodi, in Gruppi di istanze, fai clic sul nome del gruppo di istanze. Ad esempio:
gke-private-cluster-0-default- pool-5c5add1f-grp
.Nell'elenco delle istanze, verifica che non abbiano indirizzi IP esterni.
Visualizzazione della subnet e degli intervalli di indirizzi secondari del cluster
Dopo aver creato un cluster privato, puoi visualizzare gli intervalli di subnet e indirizzi secondari di cui tu o GKE hai eseguito il provisioning per il cluster.
gcloud
Elenca tutte le subnet
Per elencare le subnet nella rete del tuo cluster, esegui il comando seguente:
gcloud compute networks subnets list \
--network NETWORK_NAME
Sostituisci NETWORK_NAME
con la rete del cluster privato. Se hai creato il cluster con una subnet creata automaticamente, utilizza default
.
Nell'output comando, individua il nome della subnet del cluster.
Visualizza subnet del cluster
Ottieni informazioni sulla subnet creata automaticamente:
gcloud compute networks subnets describe SUBNET_NAME
Sostituisci SUBNET_NAME
con il nome della subnet.
L'output mostra l'intervallo di indirizzi principale per i nodi (il primo campo ipCidrRange
) e gli intervalli secondari per pod e servizi (in secondaryIpRanges
):
...
ipCidrRange: 10.0.0.0/22
kind: compute#subnetwork
name: gke-private-cluster-1-subnet-163e3c97
...
privateIpGoogleAccess: true
...
secondaryIpRanges:
- ipCidrRange: 10.40.0.0/14
rangeName: gke-private-cluster-1-pods-163e3c97
- ipCidrRange: 10.0.16.0/20
rangeName: gke-private-cluster-1-services-163e3c97
...
console
Vai alla pagina Reti VPC nella console.
Fai clic sul nome della subnet. Ad esempio,
gke-private-cluster-0-subnet-163e3c97
.In Intervallo di indirizzi IP puoi vedere l'intervallo di indirizzi principale della subnet. Questo è l'intervallo utilizzato per i nodi.
In Intervalli IP secondari, puoi visualizzare l'intervallo di indirizzi IP per i pod e l'intervallo per i servizi.
Visualizzazione degli endpoint di un cluster privato
Puoi visualizzare gli endpoint di un cluster privato utilizzando l'interfaccia a riga di comando gcloud o la console.
gcloud
Esegui questo comando:
gcloud container clusters describe CLUSTER_NAME
L'output mostra gli endpoint privati e pubblici:
...
privateClusterConfig:
enablePrivateEndpoint: true
enablePrivateNodes: true
masterIpv4CidrBlock: 172.16.0.32/28
privateEndpoint: 172.16.0.34
publicEndpoint: 35.239.154.67
console
Vai alla pagina Google Kubernetes Engine nella console.
Nell'elenco dei cluster, fai clic sul relativo nome.
Nella scheda Dettagli, in Nozioni di base sul cluster, cerca il campo Endpoint.
Estrazione delle immagini container da un registro di immagini
In un cluster privato, il runtime del container può estrarre immagini container da Artifact Registry, non può estrarre immagini da qualsiasi altro registro di immagini container su Internet. Questo perché i nodi in un cluster privato non hanno indirizzi IP esterni, quindi per impostazione predefinita non possono comunicare con i servizi esterni alla rete Google.
I nodi in un cluster privato possono comunicare con i servizi Google, come Artifact Registry, se si trovano su una subnet per cui è abilitato l'accesso privato Google.
I seguenti comandi creano un deployment che estrae un'immagine di esempio da un repository Artifact Registry di proprietà di Google:
kubectl run hello-deployment --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
Aggiungere regole firewall per casi d'uso specifici
Questa sezione spiega come aggiungere una regola firewall a un cluster privato. Per impostazione predefinita,
le regole firewall applicano limitazioni al tuo piano di controllo del cluster per avviare solo le connessioni TCP ai tuoi nodi e pod sulle porte 443
(HTTPS) e 10250
(kubelet). Per alcune funzionalità di Kubernetes, potrebbe essere necessario aggiungere regole firewall per consentire l'accesso su porte aggiuntive.
Le funzionalità di Kubernetes che richiedono regole firewall aggiuntive includono:
- webhook di ammissione
- Server API aggregati
- Conversione webhook
- Configurazione dei controlli dinamici
- In genere, qualsiasi API con un campo Servicereference richiede regole firewall aggiuntive.
L'aggiunta di una regola firewall consente il traffico dal piano di controllo del cluster a tutti i seguenti elementi:
- La porta specificata di ciascun nodo (hostPort).
- La porta specificata di ogni pod in esecuzione su questi nodi.
- La porta specificata di ogni servizio in esecuzione su questi nodi.
Per saperne di più sulle regole firewall, consulta le regole firewall nella documentazione di Cloud Load Balancing.
Per aggiungere una regola firewall in un cluster privato, devi registrare il blocco CIDR del piano di controllo del cluster e la destinazione utilizzata. Dopo aver registrato questo valore, puoi creare la regola.
Passaggio 1: Visualizza il blocco CIDR del piano di controllo
Per aggiungere una regola firewall è necessario il blocco CIDR del piano di controllo del cluster.
gcloud
Esegui questo comando:
gcloud container clusters describe CLUSTER_NAME
Sostituisci CLUSTER_NAME
con il nome del tuo cluster privato.
Nell'output comando, prendi nota del valore nel campo masterIpv4CidrBlock.
console
Vai alla pagina Google Kubernetes Engine nella console.
Nell'elenco dei cluster, fai clic sul relativo nome.
Nella scheda Dettagli, in Networking, prendi nota del valore nel campo Intervallo di indirizzi del piano di controllo.
Passaggio 2: Visualizza le regole firewall esistenti
Devi specificare il target (in questo caso, i nodi di destinazione) utilizzato dalle regole firewall esistenti del cluster.
gcloud
Esegui questo comando:
gcloud compute firewall-rules list \
--filter 'name~^gke-CLUSTER_NAME' \
--format 'table(
name,
network,
direction,
sourceRanges.list():label=SRC_RANGES,
allowed[].map().firewall_rule().list():label=ALLOW,
targetTags.list():label=TARGET_TAGS
)'
Nell'output comando, prendi nota del valore nel campo Destinazioni.
console
Vai alla pagina Firewall nella console.
In Filtra tabella, inserisci
gke-CLUSTER_NAME
.
Nei risultati, prendi nota del valore del campo Target.
Passaggio 3: Aggiungi una regola firewall
gcloud
Esegui questo comando:
gcloud compute firewall-rules create FIREWALL_RULE_NAME \
--action ALLOW \
--direction INGRESS \
--source-ranges CONTROL_PLANE_RANGE \
--rules PROTOCOL:PORT \
--target-tags TARGET
Sostituisci quanto segue:
FIREWALL_RULE_NAME
: il nome che scegli per la regola firewall.CONTROL_PLANE_RANGE
: l'intervallo di indirizzi IP del piano di controllo del cluster (masterIpv4CidrBlock
) che hai raccolto in precedenza.PROTOCOL:PORT
: la porta e il relativo protocollo,tcp
oudp
.TARGET
: il valore target (Targets
) che hai raccolto in precedenza.
console
Vai alla pagina Firewall nella console.
Fai clic su add_box Crea regola firewall.
In Name (Nome), inserisci il nome della regola firewall.
Nell'elenco Rete, seleziona la rete pertinente.
In Direzione del traffico, fai clic su In entrata.
In Azione in caso di corrispondenza, fai clic su Consenti.
Nell'elenco Target, seleziona Tag target specificati.
In Tag target, inserisci il valore target che hai annotato in precedenza.
Nell'elenco Filtro di origine, seleziona Intervalli IP.
In Intervalli IP di origine, inserisci il blocco CIDR del piano di controllo del cluster.
In Protocolli e porte, fai clic su Protocolli e porte specificati, seleziona la casella di controllo del protocollo pertinente (tcp o udp) e inserisci il numero di porta nel campo protocollo.
Fai clic su Crea.
Protezione di un cluster privato con i Controlli di servizio VPC
Per proteggere ulteriormente i tuoi cluster privati GKE, puoi proteggerli utilizzando i Controlli di servizio VPC.
Controlli di servizio VPC fornisce ulteriore sicurezza ai tuoi cluster privati GKE per contribuire a ridurre il rischio di esfiltrazione dei dati. Utilizzando i Controlli di servizio VPC, puoi aggiungere progetti ai perimetri di servizio che proteggono risorse e servizi dalle richieste che hanno origine al di fuori del perimetro.
Per scoprire di più sui perimetri di servizio, vedi Dettagli e configurazione dei perimetri di servizio.
Se utilizzi Container Registry o Artifact Registry con il tuo cluster privato GKE, sono necessari passaggi aggiuntivi per utilizzare quel cluster privato con i Controlli di servizio VPC. Per ulteriori informazioni, consulta la pagina Configurazione di cluster privati di Container Registry o Artifact Registry per i cluster GKE.
Riutilizzo peering VPC
Tutti i cluster privati che crei dopo il 15 gennaio 2020 riutilizzano le connessioni di peering di rete VPC.
I cluster privati creati prima del 15 gennaio 2020 utilizzano una connessione di rete VPC univoca. Ogni rete VPC può peer con un massimo di 25 altre reti VPC, il che significa che per questi cluster esiste un limite di massimo 25 cluster privati per rete (supponendo che i peering non vengano utilizzati per altri scopi).
Questa funzionalità non è supportata nelle release precedenti. Per abilitare il riutilizzo del peering di rete VPC sui cluster privati meno recenti, puoi eliminare un cluster e ricrearlo. L'upgrade di un cluster non comporta il riutilizzo di una connessione di peering di rete VPC esistente.
Ogni località può supportare un massimo di 75 cluster privati, se nei cluster è abilitato il riutilizzo del peering di rete VPC. Le zone e le aree geografiche vengono trattate come località separate.
Ad esempio, puoi creare fino a 75 cluster di zona privati in us-east1-a
e altri 75 cluster a livello di regione privata in us-east1
. Questo vale anche se utilizzi
cluster privati in una rete VPC condivisa. Il numero massimo di connessioni a una singola rete VPC è 25, il che significa che puoi creare cluster privati solo utilizzando 25 località univoche.
Il riutilizzo del peering di rete VPC si applica solo ai cluster nella stessa località, ad esempio i cluster a livello di regione nella stessa regione o i cluster di zona nella stessa zona. Al massimo puoi avere quattro peering di rete VPC per area geografica se crei sia cluster regionali sia cluster di zona in tutte le zone di quell'area geografica.
Puoi verificare se il tuo cluster privato riutilizza le connessioni di peering di rete VPC utilizzando l'interfaccia a riga di comando gcloud o Google Cloud Console.
gcloud
gcloud container clusters describe CLUSTER_NAME \
--format="value(privateClusterConfig.peeringName)"
Se il tuo cluster riutilizza le connessioni in peering VPC, l'output inizia con gke-n
. Ad esempio, gke-n34a117b968dee3b2221-93c6-40af-peer
.
console
Controlla la riga Peering VPC nella pagina Dettagli cluster. Se il cluster riutilizza le connessioni in peering VPC, l'output inizia con gke-n
.
Ad esempio: gke-n34a117b968dee3b2221-93c6-40af-peer
.
Pulizia
Dopo aver completato le attività in questa pagina, segui questi passaggi per rimuovere le risorse al fine di evitare addebiti indesiderati sul tuo account:
Elimina i cluster
gcloud
gcloud container clusters delete -q private-cluster-0 private-cluster-1 private-cluster-2 private-cluster-3
console
Vai alla pagina Google Kubernetes Engine nella console.
Seleziona ciascun cluster.
Fai clic su delete Elimina.
Elimina la rete
gcloud
gcloud compute networks delete my-net-0
console
Vai alla pagina Reti VPC nella console.
Nell'elenco delle reti, fai clic su
my-net-0
.Nella pagina Dettagli rete VPC, fai clic su delete Elimina rete VPC.
Nella finestra di dialogo Elimina una rete, fai clic su Elimina.
Requisiti, restrizioni e limitazioni
I cluster privati hanno i seguenti requisiti:
- Un cluster privato deve essere un cluster nativo VPC, in cui sono attivi gli intervalli IP alias. La configurazione nativa di VPC è abilitata per i nuovi cluster per impostazione predefinita. I cluster nativi di VPC non sono compatibili con le reti legacy.
I cluster privati hanno le seguenti limitazioni:
- Non puoi convertire un cluster esistente e non privato in un cluster privato.
- Per i cluster che eseguono versioni precedenti alla 1.16.9 o versioni tra la 1.17.0 e la 1.17.4, il piano di controllo del cluster non è raggiungibile dai CIDR di
172.17.0.0/16
. - Per i cluster che eseguono versioni precedenti alla 1.14.4, un piano di controllo del cluster, un nodo, un pod o un intervallo IP di servizio non possono sovrapporsi a
172.17.0.0/16
. - Se utilizzi
172.17.0.0/16
per l'intervallo IP del piano di controllo, non puoi utilizzare questo intervallo per i nodi, i pod o gli indirizzi IP dei servizi. Questa restrizione si applica ai cluster di zona che eseguono le versioni 1.14.4 o successive e ai cluster a livello di regione che eseguono le versioni 1.16.9 - 1.17.0 o 1.17.4 e successive. - L'eliminazione del peering VPC tra il piano di controllo del cluster e i nodi del cluster, l'eliminazione delle regole firewall che consentono il traffico in entrata dal piano di controllo del cluster ai nodi sulla porta 10250 o l'eliminazione della route predefinita al gateway Internet predefinito, fa sì che un cluster privato smetta di funzionare. Se elimini il percorso predefinito, devi assicurarti che venga indirizzato il traffico ai servizi Google necessari. Per ulteriori informazioni, consulta la pagina relativa al routing personalizzato.
- Quando l'esportazione di route personalizzate è abilitata per il VPC, la creazione di route che si sovrappongono con gli intervalli di indirizzi IP di Google potrebbe interrompere il cluster.
- Puoi aggiungere fino a 50 reti autorizzate (blocchi CIDR consentiti) in un progetto. Per saperne di più, consulta l'articolo Aggiungere una rete autorizzata a un cluster esistente.
I cluster privati hanno le seguenti limitazioni:
- Le dimensioni del blocco RFC 1918 per il piano di controllo del cluster devono essere
/28
. - Sebbene GKE possa rilevare la sovrapposizione con il blocco degli indirizzi del piano di controllo, non può rilevare la sovrapposizione all'interno di una rete VPC condivisa.
- Tutti i nodi in un cluster privato vengono creati senza un IP pubblico; hanno accesso limitato alle API e ai servizi Google. Per fornire l'accesso a Internet in uscita per i nodi privati, puoi utilizzare Cloud NAT.
- L'accesso privato Google viene abilitato automaticamente quando crei un cluster privato, a meno che non utilizzi il VPC condiviso. Non devi disabilitare l'accesso privato Google a meno che non utilizzi NAT per accedere a Internet.
- I cluster privati creati prima del 15 gennaio 2020 hanno un limite di massimo 25 cluster privati per rete (supponendo che i peering non vengano utilizzati per altri scopi). Consulta il riutilizzo del peering VPC per saperne di più.
- Ogni cluster privato richiede una route di peering tra il tuo e i VPC di Google, ma può verificarsi una sola operazione di peering alla volta. Se provi a creare più cluster privati contemporaneamente, la creazione del cluster potrebbe scadere. Per evitare che ciò accada, crea nuovi cluster privati in serie in modo che le route di peering VPC esistano già per ogni cluster privato successivo. Anche il tentativo di creare un singolo cluster privato potrebbe scadere se esistono operazioni in esecuzione sul tuo VPC.
- Se espandi l'intervallo IP principale di una subnet per includere nodi aggiuntivi, devi aggiungere l'intervallo di indirizzi IP principali della subnet espansa all'elenco delle reti autorizzate per il tuo cluster. Se non lo fai, le regole firewall in entrata non pertinenti per il piano di controllo non vengono aggiornate e i nuovi nodi creati nello spazio di indirizzi IP espansi non potranno registrarsi con il piano di controllo. Questo può comportare un'interruzione in cui i nuovi nodi vengono eliminati e sostituiti continuamente. Tale interruzione può verificarsi durante l'esecuzione di upgrade di pool di nodi o la sostituzione automatica dei nodi a causa di errori del probe di attività.
- Non creare regole firewall o regole di criteri firewall gerarchici che hanno una priorità più elevata rispetto alle regole firewall create automaticamente.
Risolvere i problemi
Le seguenti sezioni spiegano come risolvere i problemi comuni relativi ai cluster privati.
Sovrapposizione del cluster con peer attivo
- Sintomi
Il tentativo di creare un cluster privato restituisce un errore simile al seguente:
Google Compute Engine: An IP range in the peer network overlaps with an IP range in an active peer of the local network.
- Potenziali cause
Hai scelto un CIDR del piano di controllo sovrapposto.
- Risoluzione
Elimina e ricrea il cluster utilizzando un CIDR del piano di controllo diverso.
Impossibile raggiungere il piano di controllo di un cluster privato
Aumenta la probabilità di raggiungere il piano di controllo del cluster implementando una qualsiasi configurazione dell'accesso all'endpoint del cluster. Per ulteriori informazioni, consulta la pagina relativa all'accesso agli endpoint del cluster.
- Sintomi
Dopo aver creato un cluster privato, il tentativo di eseguire comandi
kubectl
sul cluster restituisce un errore simile a uno dei seguenti:Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection timed out.
Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
- Potenziali cause
kubectl
non è in grado di comunicare con il piano di controllo del cluster.- Risoluzione
Verifica che le credenziali per il cluster siano state generate per kubeconfig o che il contesto corretto sia attivato. Per ulteriori informazioni sull'impostazione delle credenziali del cluster, consulta la pagina Generare una voce kubeconfig.
Verifica che sia consentito l'accesso al piano di controllo utilizzando il suo indirizzo IP esterno. La disabilitazione dell'accesso esterno al piano di controllo del cluster isola il cluster da Internet.Questa configurazione è immutabile dopo la creazione del cluster. Con questa configurazione, solo gli intervalli CIDR di rete interni autorizzati o la rete riservata hanno accesso al piano di controllo.
Verifica che l'indirizzo IP di origine sia autorizzato a raggiungere il piano di controllo:
gcloud container clusters describe CLUSTER_NAME \ --format="value(masterAuthorizedNetworksConfig)"\ --region=COMPUTE_REGION
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del tuo cluster.COMPUTE_REGION
: l'area geografica di Compute Engine per il cluster. Per i cluster a livello di zona, utilizza--zone=COMPUTE_ZONE
.
Se il tuo indirizzo IP di origine non è autorizzato, l'output può restituire un risultato vuoto (solo parentesi graffe) o intervalli CIDR che non includono il tuo indirizzo IP di origine
cidrBlocks: cidrBlock: 10.XXX.X.XX/32 displayName: jumphost cidrBlock: 35.XXX.XXX.XX/32 displayName: cloud shell enabled: true
Aggiungi reti autorizzate per accedere al piano di controllo.
Se esegui il comando
kubectl
da un ambiente on-premise o da un'area geografica diversa dalla località del cluster, assicurati che l'accesso globale agli endpoint privati del piano di controllo sia abilitato. Per ulteriori informazioni, consulta l'articolo su come accedere all'endpoint privato del piano di controllo a livello globale.Descrivi il cluster per visualizzare la risposta di configurazione dell'accesso master:
gcloud container clusters describe CLUSTER_NAME \ --region=COMPUTE_REGION \ --flatten "privateClusterConfig.masterGlobalAccessConfig"
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del tuo cluster.COMPUTE_REGION
: l'area geografica di Compute Engine per il cluster. Per i cluster a livello di zona, utilizza--zone=COMPUTE_ZONE
.
Un risultato riuscito è simile al seguente:
enabled: true
Se viene restituito
null
, abilita l'accesso globale master.
Impossibile creare il cluster a causa di un blocco CIDR IPv4 che si sovrappone
- Sintomi
gcloud container clusters create
restituisce un errore simile al seguente:The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network 10.128.0.0/20.
- Potenziali cause
Hai specificato un blocco CIDR del piano di controllo che si sovrappone a una subnet esistente nel tuo VPC.
- Risoluzione
Specifica un blocco CIDR per
--master-ipv4-cidr
che non si sovrapponga a una subnet esistente.
Impossibile creare il cluster a causa dell'intervallo di servizi già in uso in un altro cluster
- Sintomi
Il tentativo di creare un cluster privato restituisce un errore simile al seguente:
Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork [SUBNET_NAME] is already used by another cluster.
- Potenziali cause
Può:
- Hai scelto un intervallo di servizi che è ancora in uso da un altro cluster, oppure il cluster non è stato eliminato.
- Un cluster che utilizzava questo intervallo di servizi è stato eliminato, ma i metadati degli intervalli secondari non sono stati eliminati correttamente. Gli intervalli secondari per un cluster GKE vengono salvati nei metadati di Compute Engine e devono essere rimossi dopo l'eliminazione del cluster. Anche se un cluster viene eliminato correttamente, i metadati potrebbero non essere rimossi.
- Risoluzione
Segui questi passaggi:
- Verifica se l'intervallo di servizi è utilizzato da un cluster esistente. Per cercare il cluster, puoi utilizzare il comando
gcloud container clusters list
con il flagfilter
. Se esiste già un cluster che utilizza gli intervalli di servizi, devi eliminare il cluster o crearne uno nuovo. - Se l'intervallo di servizi non è utilizzato da un cluster esistente, rimuovi manualmente la voce di metadati che corrisponde all'intervallo di servizi che vuoi utilizzare.
- Verifica se l'intervallo di servizi è utilizzato da un cluster esistente. Per cercare il cluster, puoi utilizzare il comando
Impossibile creare la subnet
- Sintomi
Quando provi a creare un cluster privato con una subnet automatica o a creare una subnet personalizzata, potresti riscontrare il seguente errore:
An IP range in the peer network overlaps with an IP range in one of the active peers of the local network.
- Potenziali cause
L'intervallo CIDR del piano di controllo specificato si sovrappone a un altro intervallo IP nel cluster. Questo può verificarsi anche se di recente hai eliminato un cluster privato e stai tentando di creare un nuovo cluster privato utilizzando lo stesso CIDR del piano di controllo.
- Risoluzione
Prova a utilizzare un intervallo CIDR diverso.
Impossibile eseguire il pull dell'immagine da Docker Hub pubblico
- Sintomi
Un pod in esecuzione nel tuo cluster visualizza un avviso in
kubectl describe
:Failed to pull image: rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
- Potenziali cause
I nodi in un cluster privato non hanno indirizzi IP esterni, quindi non soddisfano i requisiti di accesso a Internet. Tuttavia, i nodi possono accedere alle API e ai servizi Google, tra cui Artifact Registry e Container Registry, se hai attivato l'accesso privato Google e soddisfatto i requisiti di rete.
- Risoluzione
Utilizza una delle seguenti soluzioni:
Copia le immagini nel cluster privato da Docker Hub ad Artifact Registry. Per ulteriori informazioni, consulta la sezione Migrazione dei container da un registro di terze parti.
GKE controlla automaticamente
mirror.gcr.io
per le copie memorizzate nella cache delle immagini Docker Hub a cui si accede di frequente.Se devi estrarre immagini da Docker Hub o da un altro repository pubblico, utilizza Cloud NAT o un proxy basato su istanza che funge da destinazione per una route
0.0.0.0/0
statica.
Richiesta API che attiva il timeout del webhook di ammissione
- Sintomi
Una richiesta API che attiva un webhook di ammissione configurato per utilizzare un servizio con una destinazione Porta diversa da 443 timeout, causando un errore della richiesta:
Error from server (Timeout): request did not complete within requested timeout 30s
- Potenziali cause
Per impostazione predefinita, il firewall non consente connessioni TCP ai nodi tranne che sulle porte 443 (HTTPS) e 10250 (kubelet). Un webhook di ammissione che tenta di comunicare con un pod su una porta diversa da 443 avrà esito negativo se non è presente una regola firewall personalizzata che consenta il traffico.
- Risoluzione
Aggiungi una regola firewall per il tuo caso d'uso specifico.
Impossibile creare il cluster a causa di un controllo di integrità non riuscito
- Sintomi
Dopo aver creato un cluster privato, questo si blocca durante il passaggio del controllo di integrità e segnala un errore simile a uno dei seguenti:
All cluster resources were brought up, but only 0 of 2 have registered.
All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
- Potenziali cause
Uno qualsiasi dei seguenti elementi:
- I nodi cluster non possono scaricare i programmi binari richiesti dall'API Cloud Storage
(
storage.googleapis.com
). - Regole firewall che limitano il traffico in uscita.
- Le autorizzazioni IAM del VPC condiviso non sono corrette.
- L'accesso privato Google richiede la configurazione del DNS per
*.gcr.io
.
- I nodi cluster non possono scaricare i programmi binari richiesti dall'API Cloud Storage
(
- Risoluzione
Utilizza una delle seguenti soluzioni:
Abilita l'accesso privato Google nella subnet per l'accesso della rete dei nodi a
storage.googleapis.com
oppure abilita Cloud NAT per consentire ai nodi di comunicare con gli endpointstorage.googleapis.com
.Per l'accesso in lettura al nodo per
storage.googleapis.com
, verifica che l'account di servizio assegnato al nodo del cluster disponga dell'accesso in lettura allo spazio di archiviazione.Assicurati di avere una regola firewall di Google Cloud per consentire tutto il traffico in uscita o di configurare una regola firewall per consentire il traffico in uscita per i nodi al piano di controllo del cluster e a
*.googleapis.com
.Crea la configurazione DNS per
*.gcr.io
.Se hai un firewall o una route non predefiniti, configura l'accesso privato Google.
Se utilizzi i Controlli di servizio VPC, configura i cluster privati Container Registry o Artifact Registry per GKE.
Assicurati di non aver eliminato o modificato le regole firewall create automaticamente per Ingress.
Se utilizzi un VPC condiviso, assicurati di aver configurato le autorizzazioni IAM richieste.
Creazione di Sandbox del pod in kubelet non riuscita
- Sintomi
Dopo aver creato un cluster privato, viene segnalato un errore simile a uno dei seguenti:
Warning FailedCreatePodSandBox 12s (x9 over 4m) kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://k8s.gcr.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
- Potenziali cause
Il pod
calico-node
onetd
non può raggiungere*.gcr.io
.- Risoluzione
Utilizza una delle seguenti soluzioni:
- Assicurati di aver completato la configurazione richiesta per Container Registry o Artifact Registry.
Nodi del cluster privato creati ma non aggiunti al cluster
Spesso quando si utilizzano il routing personalizzato e le appliance di rete di terze parti sul VPC utilizzato dal cluster privato, la route predefinita (0.0.0.0/0
) viene reindirizzata all'appliance anziché al gateway Internet predefinito. Oltre alla connettività del piano di controllo, devi assicurarti che siano raggiungibili le seguenti destinazioni:
- *.googleapis.com
- *.gcr.io
- gcr.io
Configura l'accesso privato Google per tutti e tre i domini. Questa best practice consente ai nuovi nodi di avviarsi e unirsi al cluster, mantenendo limitato il traffico Internet.
Passaggi successivi
- Leggi la panoramica della rete GKE.
- Scopri come creare cluster nativi di VPC.
- Scopri di più sul peering di rete VPC.
- Segui il tutorial sull'accesso ai cluster GKE privati con i pool privati di Cloud Build.