Crea un cluster nativo di VPC

Questa pagina spiega come configurare i cluster nativi di VPC in Google Kubernetes Engine (GKE).

Per scoprire di più sui vantaggi e sui requisiti dei cluster nativi di VPC, consulta la panoramica dei cluster nativi di VPC.

Per i cluster GKE Autopilot, le reti VPC native sono abilitate per impostazione predefinita e non possono essere sostituite.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Limitazioni

• Non puoi convertire un cluster nativo di VPC in un cluster basato su route e viceversa.

• I cluster VPC nativi richiedono reti VPC. Le reti legacy non sono supportate.

• Come per qualsiasi cluster GKE, gli indirizzi Service (ClusterIP) sono disponibili solo dall'interno del cluster. Se devi accedere a un servizio Kubernetes da istanze VM al di fuori del cluster, ma all'interno della rete VPC e della regione del cluster, crea un bilanciatore del carico di rete passthrough interno.

• Se utilizzi tutti gli indirizzi IP dei pod in una subnet, non puoi sostituire l'intervallo di indirizzi IP secondari della subnet senza portare il cluster in uno stato instabile. Tuttavia, puoi creare intervalli di indirizzi IP dei pod aggiuntivi utilizzando il CIDR multi-pod non contiguo.

Crea un cluster

Questa sezione mostra come completare le seguenti attività al momento della creazione del cluster:

• Crea un cluster e una subnet contemporaneamente.
• Crea un cluster in una subnet esistente.
• Crea un cluster e seleziona l'intervallo di indirizzi IP del control plane.
• Crea un cluster con networking dual-stack in una nuova subnet (disponibile nei cluster Autopilot versione 1.25 o successive e nei cluster Standard versione 1.24 o successive).
• Crea contemporaneamente un cluster dual-stack e una subnet dual-stack (disponibile nei cluster Autopilot versione 1.25 o successive e nei cluster Standard versione 1.24 o successive).

Dopo aver creato il cluster, puoi modificare l'accesso al piano di controllo del cluster. Per saperne di più, consulta Personalizzare l'isolamento di rete in GKE.

Creare un cluster e una subnet contemporaneamente

Le indicazioni riportate di seguito mostrano come creare contemporaneamente un cluster GKE e una subnet nativi di VPC. Il metodo di assegnazione dell'intervallo secondario è gestito da GKE quando esegui questi due passaggi con un unico comando.

Se utilizzi il VPC condiviso, non puoi creare contemporaneamente il cluster e la subnet. Al contrario, un amministratore di rete nel progetto host VPC condiviso deve prima creare la subnet. Poi puoi creare il cluster in una subnet esistente con un metodo di assegnazione dell'intervallo secondario gestito dall'utente.

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": SUBNET_NAME
  },
  ...
}

Dopo aver creato il cluster, puoi modificare l'accesso al piano di controllo del cluster. Per saperne di più, consulta Personalizzare l'isolamento di rete in GKE.

Crea un cluster in una subnet esistente

Le seguenti istruzioni mostrano come creare un cluster GKE nativo VPC in una subnet esistente con il metodo di assegnazione dell'intervallo secondario che preferisci.

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

Dopo aver creato il cluster, puoi modificare l'accesso al piano di controllo del cluster. Per saperne di più, consulta Personalizzare l'isolamento di rete in GKE.

Crea un cluster e seleziona l'intervallo di indirizzi IP del control plane

Per impostazione predefinita, i cluster nella versione 1.29 o successive utilizzano l'intervallo di subnet principale per provisionare l'indirizzo IP interno assegnato all'endpoint del control plane. Puoi eseguire l'override di questa impostazione predefinita selezionando un intervallo di subnet diverso solo durante la creazione del cluster.

Le sezioni seguenti mostrano come creare un cluster e ignorare l'intervallo di subnet.

gcloud container clusters create CLUSTER_NAME \
    --enable-private-nodes \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Metadati del progetto per gli intervalli di indirizzi IP secondari

Quando crei o esegui l'upgrade di un cluster GKE, GKE aggiunge automaticamente voci di metadati a livello di progetto come google_compute_project_metadata per monitorare l'utilizzo dell'intervallo di indirizzi IP secondari, anche negli ambienti VPC condiviso. Questi metadati verificano che GKE allochi correttamente gli indirizzi IP per pod e servizi, il che aiuta a evitare conflitti.

GKE gestisce automaticamente questi metadati.

I metadati hanno il seguente formato:

key:   gke-REGION-CLUSTER_NAME-GKE_UID-secondary-ranges
value: pods:SHARED_VPC_NETWORK:SHARED_VPC_SUBNETWORK:CLUSTER_PODS_SECONDARY_RANGE_NAME

dove:

• REGION: la Google Cloud regione in cui si trova il cluster.

• CLUSTER_NAME: il nome del cluster GKE.

• GKE_UID: un identificatore univoco per il cluster GKE.

• VPC_NETWORK: il nome della rete VPC utilizzata dal cluster.

• VPC_SUBNETWORK: il nome della subnet all'interno della rete VPC utilizzata dal cluster.

• CLUSTER_PODS_SECONDARY_RANGE_NAME: il nome dell'intervallo di indirizzi IP secondari utilizzato per i pod del cluster.

Crea un cluster con networking dual-stack

Puoi creare un cluster con rete a doppio stack IPv4/IPv6 su una subnet a doppio stack nuova o esistente. La subnet dual-stack è disponibile nei cluster Autopilot versione 1.25 o successive e nei cluster Standard versione 1.24 o successive. La subnet dual stack non è supportata con i node pool Windows Server.

Prima di configurare cluster dual-stack, ti consigliamo di completare le seguenti azioni:

• Scopri di più sui vantaggi e sui requisiti dei cluster GKE con networking dual-stack.
• Consulta le limitazioni e le restrizioni del networking dual-stack.

In questa sezione, prima crei una subnet a doppio stack e poi la utilizzi per creare un cluster.

1. Per creare una subnet dual-stack, esegui questo comando:

   gcloud compute networks subnets create SUBNET_NAME \
       --stack-type=ipv4-ipv6 \
       --ipv6-access-type=ACCESS_TYPE \
       --network=NETWORK_NAME \
       --range=PRIMARY_RANGE \
       --region=COMPUTE_REGION
   

   Sostituisci quanto segue:

   • SUBNET_NAME: il nome della subnet che scegli.
   • ACCESS_TYPE: la raggiungibilità a internet pubblico. Utilizza INTERNAL per gli indirizzi IPv6 interni o EXTERNAL per gli indirizzi IPv6 esterni. Se --ipv6-access-type non è specificato, il tipo di accesso predefinito è EXTERNAL.
   • NETWORK_NAME: il nome della rete che conterrà la nuova subnet. Questa rete deve soddisfare le seguenti condizioni:
     • Deve essere una rete VPC in modalità personalizzata. Per maggiori informazioni, scopri come passare dalla modalità automatica alla modalità personalizzata per una rete VPC.
     • Se sostituisci ACCESS_TYPE con INTERNAL, la rete deve utilizzare indirizzi unicast IPv6 locali unici (ULA).
   • PRIMARY_RANGE: l'intervallo di indirizzi IP IPv4 principali per la nuova subnet, nella notazione CIDR. Per ulteriori informazioni, consulta Intervalli di subnet.
   • COMPUTE_REGION: la regione di computing del cluster.

2. Per creare un cluster con una subnet dual-stack, utilizza gcloud CLI o la console Google Cloud :

Crea contemporaneamente un cluster a doppio stack e una subnet

Puoi creare una subnet e un cluster dual-stack contemporaneamente. GKE crea una subnet IPv6 e assegna un intervallo IPv6 esterno principale alla subnet.

Se utilizzi il VPC condiviso, non puoi creare contemporaneamente il cluster e la subnet. Al contrario, un amministratore di rete nel progetto host VPC condiviso deve prima creare la subnet dual-stack.

• Per i cluster Autopilot, esegui questo comando:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME
  

  Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster Autopilot.
  • COMPUTE_LOCATION: la posizione di Compute Engine per il cluster.
  • NETWORK_NAME: il nome di una rete VPC che contiene la subnet. Questa rete VPC deve essere una rete VPC in modalità personalizzata che utilizza indirizzi unicast IPv6 locali unici (ULA). Per maggiori informazioni, scopri come passare dalla modalità automatica alla modalità personalizzata per una rete VPC.
  • SUBNET_NAME: il nome della nuova subnet. GKE può creare la subnet in base ai tuoi criteri dell'organizzazione:
    • Se i criteri della tua organizzazione consentono il doppio stack e la rete è in modalità personalizzata, GKE crea una subnet a doppio stack e assegna un intervallo IPv6 esterno principale alla subnet .
    • Se i criteri dell'organizzazione non consentono lo stack doppio o se la rete è in modalità automatica, GKE crea una subnet a stack singolo (IPv4).

• Per i cluster Standard, esegui questo comando:

  gcloud container clusters create CLUSTER_NAME \
      --enable-ip-alias \
      --stack-type=ipv4-ipv6 \
      --ipv6-access-type=ACCESS_TYPE \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
      --location=COMPUTE_LOCATION
  

  Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster che scegli.
  • ACCESS_TYPE: la raggiungibilità a internet pubblico. Utilizza INTERNAL per gli indirizzi IPv6 interni o EXTERNAL per gli indirizzi IPv6 esterni. Se --ipv6-access-type non è specificato, il tipo di accesso predefinito è EXTERNAL.
  • NETWORK_NAME: il nome della rete che conterrà la nuova subnet. Questa rete deve soddisfare le seguenti condizioni:
    • Deve essere una rete VPC in modalità personalizzata. Per maggiori informazioni, scopri come passare dalla modalità automatica alla modalità personalizzata per una rete VPC.
    • Se sostituisci ACCESS_TYPE con INTERNAL, la rete deve utilizzare indirizzi unicast IPv6 locali unici (ULA).
  • SUBNET_NAME: il nome della nuova subnet che scegli.
  • PRIMARY_RANGE: l'intervallo di indirizzi IPv4 principale per la nuova subnet, nella notazione CIDR. Per ulteriori informazioni, consulta Intervalli di subnet.
  • COMPUTE_LOCATION: la posizione di Compute Engine per il cluster.

Aggiornare il tipo di stack

Puoi modificare il tipo di stack di un cluster esistente o aggiornare una subnet esistente a una subnet dual-stack.

Aggiorna il tipo di stack su un cluster esistente

Prima di modificare il tipo di stack in un cluster esistente, tieni presente le seguenti limitazioni:

• La modifica del tipo di stack è supportata nei nuovi cluster GKE che eseguono la versione 1.25 o successive. I cluster GKE di cui è stato eseguito l'upgrade dalle versioni 1.24 alle versioni 1.25 o 1.26 potrebbero generare errori di convalida quando viene abilitata la rete dual-stack. In caso di errori, contatta il Google Cloud team di assistenza.

• La modifica del tipo di stack è un'operazione distruttiva perché GKE riavvia i componenti sia nel control plane che nei nodi.

• GKE rispetta i periodi di manutenzione configurati durante la ricreazione dei nodi. Ciò significa che il tipo di stack del cluster non sarà operativo sul cluster fino alla successivaperiodo di manutenzionee. Se preferisci non attendere, puoi eseguire l'upgrade manuale del pool di nodi impostando il flag --cluster-version sulla stessa versione GKE in esecuzione sul control plane. Se utilizzi questa soluzione alternativa, devi utilizzare gcloud CLI. Per saperne di più, consulta avvertenze per i periodi di manutenzione.

• La modifica del tipo di stack non comporta la modifica automatica della famiglia IP dei servizi esistenti. Si applicano le seguenti condizioni:

  • Se modifichi uno stack singolo in dual-stack, i servizi esistenti rimangono single stack.
  • Se modifichi uno stack doppio in stack singolo, i servizi esistenti con indirizzi IPv6 entrano in uno stato di errore. Elimina il servizio e creane uno con il ipFamilies corretto. Per saperne di più, consulta un esempio di come configurare un deployment.

Per aggiornare un cluster nativo di VPC esistente, puoi utilizzare gcloud CLI o la console Google Cloud :

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Aggiorna una subnet esistente a una subnet dual-stack (disponibile nei cluster Autopilot versione 1.25 o successive e nei cluster Standard versione 1.24 o successive).

Aggiornare una subnet esistente a una subnet a doppio stack

Per aggiornare una subnet esistente a una subnet dual-stack, esegui questo comando. L'aggiornamento di una subnet non influisce sui cluster IPv4 esistenti nella subnet.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Sostituisci quanto segue:

• SUBNET_NAME: il nome della subnet.
• ACCESS_TYPE: la raggiungibilità a internet pubblico. Utilizza INTERNAL per gli indirizzi IPv6 interni o EXTERNAL per gli indirizzi IPv6 esterni. Se --ipv6-access-type non è specificato, il tipo di accesso predefinito è EXTERNAL.
• COMPUTE_REGION: la regione di computing del cluster.

Verifica gli intervalli di indirizzi IP di tipo stack, pod e servizio

Dopo aver creato un cluster nativo di VPC, puoi verificare gli intervalli di pod e servizi.

gcloud container clusters describe CLUSTER_NAME

Elimina il cluster

Per eliminare il cluster, segui i passaggi descritti in Eliminazione di un cluster.

GKE tenta di pulire la subnet creata quando il cluster viene eliminato. Se la subnet viene utilizzata da altre risorse, GKE non la elimina e devi gestirne il ciclo di vita in autonomia.

Configurazione avanzata per gli indirizzi IP interni

Le sezioni seguenti mostrano come utilizzare intervalli di indirizzi IP privati non RFC 1918 e come abilitare intervalli di indirizzi IP pubblici utilizzati privatamente.

Utilizzare intervalli di indirizzi IP non RFC 1918

I cluster GKE possono utilizzare intervalli di indirizzi IP al di fuori degli intervalli RFC 1918 per nodi, pod e servizi. Consulta gli intervalli validi nella documentazione della rete VPC per un elenco di intervalli privati non RFC 1918 che possono essere utilizzati come indirizzi IP interni per gli intervalli di subnet.

Questa funzionalità non è supportata con i node pool Windows Server.

Gli intervalli privati non RFC 1918 sono intervalli di subnet. Puoi utilizzarli esclusivamente o in combinazione con gli intervalli di subnet RFC 1918. Nodi, pod e servizi continuano a utilizzare gli intervalli di subnet come descritto in Intervalli IP per i cluster nativi VPC. Se utilizzi intervalli non conformi a RFC 1918, tieni presente quanto segue:

• Gli intervalli di subnet, anche quelli che utilizzano intervalli non RFC 1918, devono essere assegnati manualmente o da GKE prima della creazione dei nodi del cluster. Non puoi passare a intervalli di subnet non RFC 1918 o smettere di utilizzarli per gli indirizzi IP di nodi o servizi in un cluster esistente, a meno che tu non sostituisca il cluster. Tuttavia, puoi aggiungere intervalli CIDR pod aggiuntivi, inclusi intervalli non RFC 1918, a un cluster nativo di VPC esistente. Per saperne di più sull'aggiunta di intervalli CIDR pod aggiuntivi, consulta Espandere gli intervalli di indirizzi IP di un cluster GKE.

• I bilanciatori del carico di rete passthrough interni utilizzano solo indirizzi IP dell'intervallo di indirizzi IP principale della subnet. Per creare un bilanciatore del carico di rete pass-through interno con un indirizzo non RFC 1918, l'intervallo di indirizzi IP principale della subnet deve essere non RFC 1918.

Le destinazioni al di fuori del cluster potrebbero avere difficoltà a ricevere traffico da intervalli privati non conformi a RFC 1918. Ad esempio, gli intervalli privati RFC 1112 (classe E) vengono in genere utilizzati come indirizzi multicast. Se una destinazione al di fuori del cluster non può elaborare i pacchetti le cui origini sono indirizzi IP privati al di fuori dell'intervallo RFC 1918, puoi procedere nel seguente modo:

• Utilizza un intervallo RFC 1918 per l'intervallo di indirizzi IP principale della subnet. In questo modo, i nodi del cluster utilizzano indirizzi RFC 1918.

• Assicurati che nel cluster sia in esecuzione l'agente IP masquerade e che le destinazioni non siano nell'elenco nonMasqueradeCIDRs. In questo modo, l'origine dei pacchetti inviati dai pod viene modificata (SNAT) in indirizzi dei nodi, che sono RFC 1918.

Abilita gli intervalli di indirizzi IP esterni utilizzati privatamente

I cluster GKE possono utilizzare privatamente determinati intervalli di indirizzi IP esterni come intervalli di indirizzi IP interni della subnet. Puoi utilizzare privatamente qualsiasi indirizzo IP esterno, ad eccezione di determinati intervalli con limitazioni, come descritto nella documentazione della rete VPC. Questa funzionalità non è supportata con i node pool Windows Server.

Il cluster deve essere un cluster nativo di VPC per poter utilizzare intervalli di indirizzi IP esterni utilizzati privatamente. I cluster basati su route non sono supportati.

Gli intervalli esterni utilizzati privatamente sono intervalli di subnet. Puoi utilizzarli esclusivamente o in combinazione con altri intervalli di subnet che utilizzano indirizzi privati. Nodi, pod e servizi continuano a utilizzare gli intervalli di subnet come descritto in Intervalli IP per i cluster nativi VPC. Tieni presente quanto segue quando riutilizzi privatamente gli indirizzi IP esterni:

• Quando utilizzi un intervallo di indirizzi IP esterni come intervallo di subnet, il cluster non può più comunicare con i sistemi su internet che utilizzano quell'intervallo esterno. L'intervallo diventa un intervallo di indirizzi IP interni nella rete VPC del cluster.

• Gli intervalli di subnet, anche quelli che utilizzano privatamente intervalli di indirizzi IP esterni, devono essere assegnati manualmente o da GKE prima della creazione dei nodi del cluster. Non puoi passare a intervalli di subnet non RFC 1918 o smettere di utilizzarli per gli indirizzi IP dei nodi o dei servizi in un cluster esistente, a meno che tu non sostituisca il cluster. Tuttavia, puoi aggiungere intervalli CIDR pod aggiuntivi, inclusi intervalli non RFC 1918, a un cluster nativo di VPC esistente. Per saperne di più sull'aggiunta di intervalli CIDR pod aggiuntivi, consulta Espandere gli intervalli di indirizzi IP di un cluster GKE.

Per impostazione predefinita, GKE implementa la SNAT sui nodi per le destinazioni IP esterni. Se hai configurato il CIDR del pod in modo che utilizzi indirizzi IP esterni, le regole SNAT si applicano al traffico da pod a pod. Per evitare questo problema, hai due opzioni:

• Crea il cluster con il flag --disable-default-snat. Per ulteriori dettagli su questo flag, consulta Mascheramento IP in GKE.
• Configura configMap ip-masq-agent inclusi nell'elenco nonMasqueradeCIDRs almeno il CIDR pod, il CIDR servizio e la subnet dei nodi.

Per i cluster Standard, se la versione del cluster è 1.14 o successive, entrambe le opzioni funzioneranno. Se la versione del cluster è precedente alla 1.14, puoi utilizzare solo la seconda opzione (configurazione di ip-masq-agent).

Passaggi successivi

• Leggi la panoramica della rete GKE.
• Scopri di più sul bilanciamento del carico interno.
• Scopri di più sulla configurazione delle reti autorizzate.
• Scopri di più sulla creazione di criteri di rete del cluster.