Creazione di un cluster privato

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.
  Nota: per le installazioni dell'interfaccia a riga di comando gcloud esistenti, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nell'interfaccia a riga di comando gcloud come segue: One of [--zone, --region] must be supplied: Please specify location.

• 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.

Importante: anche se disabiliti l'accesso all'endpoint pubblico, Google può utilizzare l'endpoint pubblico del piano di controllo per scopi di gestione dei cluster, ad esempio la manutenzione pianificata e gli upgrade automatici.

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 denominata my-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

1. Vai alla pagina Reti VPC nella console.
   

   Vai a Reti VPC

2. Fai clic su Crea rete VPC.

3. In Nome, inserisci my-net-0.

4. In Modalità di creazione subnet, seleziona Personalizzata.

5. Nella sezione Nuova subnet, per Nome, inserisci my-subnet-0.

6. Nell'elenco Area geografica, seleziona l'area geografica che preferisci.

7. In Intervallo di indirizzi IP, inserisci 10.2.204.0/22.

8. Imposta Accesso privato Google su On.

9. Fai clic su Fine.

10. Fai clic su Crea.

Crea un cluster privato

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Nella sezione Standard o Autopilot, fai clic su Configura.

4. In Nome, inserisci private-cluster-0.

5. Per i cluster standard, nel riquadro di navigazione sotto Cluster, fai clic su Networking.

6. Nell'elenco Rete, seleziona my-net-0.

7. Nell'elenco Subnet nodo, seleziona my-subnet-0.

8. Seleziona il pulsante di opzione Cluster privato.

9. Deseleziona la casella di controllo Accedi al piano di controllo utilizzando l'indirizzo IP esterno.

10. (Facoltativo per Autopilot): imposta Intervallo IP piano di controllo su 172.16.0.32/28.

11. 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 denominata my-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 primario 192.168.0.0/20, per i nodi del cluster. La subnet ha i seguenti intervalli di indirizzi secondari:

  • my-pods per gli indirizzi IP del pod.
  • my-services per gli indirizzi IP del servizio.

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

1. Vai alla pagina Reti VPC nella console.
   

   Vai a Reti VPC

2. Fai clic su Crea rete VPC.

3. In Nome, inserisci my-net-2.

4. In Modalità di creazione subnet, seleziona Personalizzata.

5. Nella sezione Nuova subnet, per Nome, inserisci my-subnet-2.

6. Nell'elenco Area geografica, seleziona l'area geografica che preferisci.

7. In Intervallo di indirizzi IP, inserisci 192.168.0.0/20.

8. Fai clic su Crea intervallo IP secondario. In Nome intervallo di subnet, inserisci my-services. Per Intervallo IP secondario, inserisci 10.0.32.0/20.

9. Fai clic su Aggiungi intervallo IP. In Nome intervallo di subnet, inserisci my-pods. Per Intervallo IP secondario, inserisci 10.4.0.0/14.

10. Imposta Accesso privato Google su On.

11. Fai clic su Fine.

12. Fai clic su Crea.

Crea un cluster privato

Crea un cluster privato che utilizza la subnet:

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Nella sezione Standard o Autopilot, fai clic su Configura.

4. In Nome, inserisci private-cluster-2.

5. Per i cluster standard, nel riquadro di navigazione sotto Cluster, fai clic su Networking.

6. Seleziona il pulsante di opzione Cluster privato.

7. 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.

8. (Facoltativo per Autopilot) Imposta Intervallo IP piano di controllo su 172.16.0.16/28.

9. Nell'elenco Rete, seleziona my-net-2.

10. Nell'elenco Subnet nodo, seleziona my-subnet-2.

11. Deseleziona la casella di controllo Crea automaticamente intervalli secondari.

12. Nell'elenco Intervallo CIDR secondario del pod, seleziona my-pods.

13. Nell'elenco Intervallo CIDR secondario dei servizi, seleziona my-services.

14. Seleziona la casella di controllo Abilita reti autorizzate piano di controllo.

15. 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

Importante: se hai abilitato un endpoint privato, non puoi accedere al tuo piano di controllo GKE con Cloud Shell.

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:

1. 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
   

2. 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.

3. 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.

4. 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 denominata my-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

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Nella sezione Standard o Autopilot, fai clic su Configura.

4. In Nome, inserisci private-cluster-3.

5. Per i cluster standard, nel riquadro di navigazione sotto Cluster, fai clic su Networking.

6. Seleziona l'opzione Cluster privato.

7. Mantieni selezionata la casella di controllo Accedi al piano di controllo utilizzando l'indirizzo IP esterno.

8. (Facoltativo per Autopilot) Imposta Intervallo IP piano di controllo su 172.16.0.32/28.

9. Lascia Rete e Subnet nodo impostate su default. GKE genera una subnet per il tuo cluster.

10. Deseleziona la casella di controllo Abilita reti autorizzate piano di controllo.

11. 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.

Nota: i costi per il traffico in uscita vengono applicati al traffico tra aree geografiche nella rete Google Cloud, quindi l'accesso all'endpoint privato del piano di controllo da un'altra area geografica prevede costi per il traffico in uscita tra aree geografiche standard.

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:

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Fai clic su Crea.

3. Inserisci un nome.

4. Nel riquadro di navigazione, in Cluster, fai clic su Networking.

5. Seleziona Cluster privato.

6. Seleziona la casella di controllo Abilita accesso globale piano di controllo.

7. Configura gli altri campi come preferisci.

8. Fai clic su Crea.

Per abilitare l'accesso globale al piano di controllo per un cluster privato esistente, esegui i seguenti passaggi:

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Accanto al cluster che vuoi modificare, fai clic su Azioni, quindi fai clic su Modifica.

3. Nella sezione Networking, fai clic su Modifica accanto a Reti autorizzate piano di controllo.

4. Nella finestra di dialogo Modifica reti autorizzate piano di controllo, seleziona la casella di controllo Abilita reti autorizzate piano di controllo.

5. 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à:

1. 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
   

2. 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.

3. 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 e 128.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 di privateClusterConfig.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

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster.

3. Nella pagina Cluster, fai clic sulla scheda Nodi.

4. In Pool di nodi, fai clic sul nome del pool di nodi.

5. 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.

6. 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

1. Vai alla pagina Reti VPC nella console.

   Vai a Reti VPC

2. Fai clic sul nome della subnet. Ad esempio, gke-private-cluster-0-subnet-163e3c97.

3. In Intervallo di indirizzi IP puoi vedere l'intervallo di indirizzi principale della subnet. Questo è l'intervallo utilizzato per i nodi.

4. 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

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul relativo nome.

3. Nella scheda Dettagli, in Nozioni di base sul cluster, cerca il campo Endpoint.

Estrazione delle immagini container da un registro di immagini

Nota: Artifact Registry estende le capacità di Container Registry ed è il servizio consigliato per la gestione di immagini container e altri artefatti in Google Cloud. Scopri la transizione ad Artifact Registry. Per scoprire di più sull'archiviazione delle immagini in Artifact Registry, consulta la pagina Push ed pull delle 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

Nota: mentre il mirroring Docker Hub è accessibile da un cluster privato, non è consigliabile affidarsi esclusivamente a questo cluster. Il mirroring è solo una cache, quindi le immagini vengono rimosse periodicamente e un cluster privato non può utilizzare Docker Hub.

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.

Nota: le porte consentite (443 e 10250) si riferiscono alle porte esposte dai nodi e dai pod, non dalle porte esposte da qualsiasi servizio Kubernetes. Ad esempio, se il piano di controllo del cluster tenta di accedere a un servizio sulla porta 443, ma il servizio viene implementato da un pod utilizzando la porta 9443, questo verrà bloccato dal firewall, a meno che non aggiungi una regola firewall per consentire esplicitamente il traffico in entrata alla porta 9443.

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

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. 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.

Nota: per visualizzare le regole firewall per un VPC condiviso, aggiungi il flag --project HOST_PROJECT_ID al comando.

Per maggiori informazioni sul VPC condiviso, consulta la pagina Configurare i cluster con VPC condiviso.

console

1. Vai alla pagina Firewall nella console.

   Vai a Firewall

2. 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 o udp.
• TARGET: il valore target (Targets) che hai raccolto in precedenza.

Nota: per aggiungere una regola firewall per un VPC condiviso, aggiungi i seguenti flag al comando:

--project HOST_PROJECT_ID
--network NETWORK_ID

Per maggiori informazioni sul VPC condiviso, consulta la pagina Configurare i cluster con VPC condiviso.

console

1. Vai alla pagina Firewall nella console.

   Vai a Firewall

2. Fai clic su Crea regola firewall.

3. In Name (Nome), inserisci il nome della regola firewall.

4. Nell'elenco Rete, seleziona la rete pertinente.

5. In Direzione del traffico, fai clic su In entrata.

6. In Azione in caso di corrispondenza, fai clic su Consenti.

7. Nell'elenco Target, seleziona Tag target specificati.

8. In Tag target, inserisci il valore target che hai annotato in precedenza.

9. Nell'elenco Filtro di origine, seleziona Intervalli IP.

10. In Intervalli IP di origine, inserisci il blocco CIDR del piano di controllo del cluster.

11. 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.

12. 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

1. Vai alla pagina Google Kubernetes Engine nella console.

   Vai a Google Kubernetes Engine

2. Seleziona ciascun cluster.

3. Fai clic su Elimina.

Elimina la rete

gcloud

gcloud compute networks delete my-net-0

console

1. Vai alla pagina Reti VPC nella console.

   Vai a Reti VPC

2. Nell'elenco delle reti, fai clic su my-net-0.

3. Nella pagina Dettagli rete VPC, fai clic su Elimina rete VPC.

4. 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.

1. 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
   

2. 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.

1. 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
   

2. 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 flag filter. 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.

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.

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 endpoint storage.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 o netd 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.