Aggiungi subnet ai cluster

Questa pagina mostra come assegnare subnet aggiuntive a un cluster nativo di VPCC. Le subnet aggiuntive assegnate a un cluster ti consentono di creare nuovi pool di nodi in cui gli indirizzi IPv4 per i nodi e i pod provengono dagli intervalli di subnet aggiuntivi.

Questa pagina è rivolta agli specialisti di networking che progettano e realizzano l'architettura di rete per la loro organizzazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Panoramica

Quando crei un nuovo cluster GKE nativo di VPC, selezioni una subnet predefinita per il cluster. La subnet predefinita del cluster fornisce indirizzi IPv4 per nodi, pod e servizi come descritto in Intervalli di indirizzi IP per i cluster VPC nativi.

Puoi assegnare fino a otto subnet aggiuntive a un cluster VPC nativo, consentendo una crescita significativa del cluster. Ogni subnet aggiuntiva appena assegnata viene chiamata subnet non predefinita.

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 inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti e limitazioni

Questa sezione descrive i requisiti e le limitazioni che si applicano quando assegni e utilizzi subnet aggiuntive a un cluster. Devi soddisfare tutti i requisiti prima di assegnare subnet aggiuntive.

  • Assicurati che il cluster GKE sia un cluster VPC nativo che esegue GKE versione 1.30.3-gke.1211000 o successive. I cluster basati su route e i cluster sulle reti legacy non supportano subnet aggiuntive.
  • Puoi assegnare fino a otto subnet aggiuntive per cluster.
  • Le subnet aggiuntive forniscono solo indirizzi IPv4 per nodi e pod. Le subnet aggiuntive non possono essere utilizzate per fornire indirizzi IPv6 per nodi o pod.
  • Solo i nuovi node pool possono utilizzare le subnet aggiuntive, non quelli esistenti. Quando crei un nuovo pool di nodi e sono disponibili più subnet non predefinite, GKE seleziona la subnet migliore per il pool di nodi in base ai requisiti per gli indirizzi IP e alla disponibilità di indirizzi IP in tutte le subnet del cluster.
  • Non puoi controllare quale subnet non predefinita utilizza un nuovo pool di nodi. Ad esempio, se il cluster ha una subnet predefinita (quella utilizzata durante la creazione del cluster) e due subnet non predefinite, non puoi specificare quale delle subnet non predefinite deve utilizzare un nuovo pool di nodi.
  • Gli intervalli di indirizzi IPv4 secondari della subnet in una subnet non predefinita possono essere utilizzati solo da un singolo cluster.
  • Non è possibile utilizzare subnet aggiuntive con i gateway multi-cluster.
  • Se utilizzi il supporto multi-rete per i pod, gli intervalli di indirizzi IPv4 principali e dei pod di una subnet aggiuntiva non devono sovrapporsi a nessun intervallo CIDR configurato nella configurazione multi-rete. Le subnet aggiuntive che configuri si applicano solo alla rete predefinita. Questa limitazione significa che le interfacce di rete aggiuntive sui nodi e sui pod non possono utilizzare gli indirizzi IP forniti da queste subnet aggiuntive.
  • Quando aggiungi una subnet ai cluster in cui è abilitato Cloud Service Mesh, la mesh non può instradare il traffico ai pod nella subnet non predefinita.

Requisiti del bilanciatore del carico per i cluster con subnet aggiuntive

Questa sezione descrive i requisiti del bilanciatore del carico che si applicano quando utilizzi subnet aggiuntive nel cluster. Questi requisiti si applicano ogni volta che crei un servizio Ingress esterno, un gateway esterno o un bilanciatore del carico esterno.

  • Per utilizzare un servizio Ingress, Gateway o LoadBalancer esterno in un cluster con subnet aggiuntive, il cluster deve eseguire GKE versione 1.33.2-gke.4780000 o successive.
  • Gli oggetti Ingress esterni che utilizzano il controller Ingress di GKE devono utilizzare il bilanciamento del carico nativo del container.
  • Abilita l'impostazione secondaria di GKE per i servizi LoadBalancer interni. L'impostazione secondaria di GKE influisce solo sui servizi LoadBalancer interni nuovi. Pertanto, devi eliminare e ricreare tutti i servizi esistenti nel cluster dopo aver abilitato il sottoinsieme GKE.

  • Per creare un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend, i nuovi servizi LoadBalancer esterni devono includere l'annotazione cloud.google.com/l4-rbs: "enabled". Questa annotazione influisce solo sui servizi LoadBalancer esterni nuovi e non si applica ai servizi LoadBalancer esterni esistenti. Elimina e ricrea tutti i servizi LoadBalancer esterni creati senza l'annotazione cloud.google.com/l4-rbs: "enabled".

    Il tipo di backend utilizzato (backend NEG GCE_VM_IP o backend del gruppo di istanze) dipende dalla versione di GKE quando crei il servizio LoadBalancer esterno. Per ulteriori informazioni, vedi Raggruppamento dei nodi.

Aggiungi una nuova subnet con un intervallo di indirizzi IPv4 del pod

  1. Crea una nuova subnet e aggiungi un nuovo intervallo di indirizzi IPv4 secondari della subnet. La subnet deve trovarsi nella stessa regione e nella stessa rete VPC del cluster:

       gcloud compute networks subnets create SUBNET_NAME \
     --network=NETWORK \
     --region=REGION \
     --range=PRIMARY_RANGE \
     --secondary-range=POD_RANGE_NAME=SECONDARY_RANGE \
     --enable-private-ip-google-access

    Sostituisci quanto segue:

    • SUBNET_NAME: il nome della nuova subnet.
    • NETWORK: il nome della rete VPC che contiene la nuova subnet.
    • REGION: la regione in cui si trova la subnet.
    • PRIMARY_RANGE: l'intervallo IPv4 principale per la nuova subnet, in notazione CIDR. Per saperne di più, vedi Intervalli di subnet IPv4.
    • POD_RANGE_NAME: un nome per l'intervallo secondario.
    • SECONDARY_RANGE: l'intervallo IPv4 secondario in notazione CIDR. Per gli intervalli validi, vedi Intervalli di subnet IPv4.

    Per saperne di più, consulta Utilizzare le subnet.

  2. Aggiorna il cluster in modo che utilizzi la subnet aggiuntiva utilizzando gcloud CLI:

       gcloud container clusters update CLUSTER_NAME \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster esistente.
    • SUBNET_NAME: il nome della nuova subnet che hai creato.
    • POD_RANGE_NAME: il nome dell'intervallo di indirizzi IPv4 secondari della subnet che vuoi utilizzare per l'intervallo di indirizzi IPv4 del pod.

Aggiungi una nuova subnet con più intervalli di indirizzi IPv4 del pod

  1. Crea una nuova subnet nella stessa regione e rete VPC del cluster. Imposta l'intervallo di indirizzi IPv4 principale della subnet su un intervallo di indirizzi IPv4 aggiuntivo per i nodi.

  2. Per ogni intervallo di indirizzi IPv4 di pod aggiuntivo di cui hai bisogno, aggiungi un nuovo intervallo di indirizzi IPv4 secondario della subnet alla subnet che hai creato nel passaggio precedente.

  3. Aggiorna il cluster in modo che utilizzi la subnet aggiuntiva utilizzando gcloud CLI. L'esempio seguente aggiunge una subnet con due intervalli di indirizzi IPv4 secondari per i pod.

       gcloud container clusters update CLUSTER_NAME \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_1 \
     --additional-ip-ranges=subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME_2

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster esistente.
    • SUBNET_NAME: il nome della nuova subnet che hai creato.
    • POD_RANGE_NAME_1 e POD_RANGE_NAME_2: i nomi degli intervalli di indirizzi IPv4 secondari della subnet che vuoi utilizzare per gli intervalli di indirizzi IPv4 dei pod.

Verifica le subnet

Per cluster: per visualizzare i dettagli di tutte le subnet associate a un cluster, esegui questo comando:

   gcloud container clusters describe CLUSTER_NAME

Sostituisci CLUSTER_NAME con il nome del cluster.

L'output è simile al seguente:

ipAllocationPolicy:
  additionalIPRangesConfig:
  - podIpv4RangeNames:
    - pod-range-1
    subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets

Per pool di nodi: per visualizzare i dettagli di tutte le subnet associate a un pool di nodi, esegui questo comando:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \

Sostituisci quanto segue:

  • POOL_NAME: il nome del pool di nodi.
  • CLUSTER_NAME: il nome del cluster.

L'output è simile al seguente:

name: pool-1
networkConfig:
  podRange: pod-range-1
  subnetwork: projects/user-gke-dev-2/regions/us-central1/subnetworks/shared-msc-subnets

Rimuovere una subnet non predefinita

La rimozione di una subnet non predefinita da un cluster indica al cluster di non utilizzare più gli intervalli della subnet in nessuno dei node pool del cluster. La rimozione ha i seguenti effetti:

  • L'intervallo di indirizzi IPv4 principale della subnet non predefinita non può essere utilizzato per gli intervalli di indirizzi IPv4 dei nodi.
  • Gli intervalli IPv4 secondari della subnet nella subnet non predefinita non possono essere utilizzati per gli intervalli IPv4 dei pod.

Prima di rimuovere una subnet non predefinita, devi eliminare tutti i pool di nodi che utilizzano questa subnet. L'impostazione della subnet sullo stato di svuotamento è il primo passaggio consigliato. Le subnet con stato di svuotamento non verranno prese in considerazione per l'utilizzo da parte dei pool di nodi appena creati. In questo modo, le operazioni di scalabilità automatica del cluster (come lo scale up del pool di nodi) non selezionano la subnet che intendi rimuovere, senza dover disattivare la scalabilità automatica per l'intero cluster.

Passaggi per rimuovere una subnet:

  1. Imposta la subnet non predefinita sullo stato di svuotamento. In questo modo, i nuovi node pool non possono selezionare questa subnet, il che è utile quando abiliti la scalabilità automatica sul cluster.
  2. Elimina tutti i pool di nodi che utilizzano questa subnet.
  3. Rimuovi la subnet dal cluster.

Per rimuovere una subnet non predefinita dal cluster, esegui questo comando:

   gcloud container clusters update CLUSTER_NAME \
     --remove-additional-ip-ranges=subnetwork=SUBNET_NAME

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • SUBNET_NAME: il nome della subnet che vuoi rimuovere dal cluster.

Per impostare lo stato di una subnet non predefinita su draining, esegui questo comando:

   gcloud container clusters update CLUSTER_NAME \
     --drain-additional-ip-ranges=subnetwork=SUBNET_NAME

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • SUBNET_NAME: il nome della subnet che vuoi impostare sullo stato di svuotamento.

Per annullare il drenaggio di una subnet non predefinita, esegui questo comando:

   gcloud container clusters update CLUSTER_NAME \
     --undrain-additional-ip-ranges=subnetwork=SUBNET_NAME

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • SUBNET_NAME: il nome della subnet di cui vuoi annullare il svuotamento.

Dopo aver rimosso una subnet non predefinita dal cluster, puoi eliminarla.

Rimuovere un intervallo IPv4 secondario di subnet non predefinito

Quando rimuovi un intervallo IPv4 secondario della subnet non predefinito da un cluster, GKE indica al cluster di non utilizzare questo intervallo per gli intervalli IPv4 dei pod in nessun pool di nodi. Se l'intervallo IPv4 secondario della subnet non predefinita che rimuovi è l'unico intervallo della subnet non predefinita utilizzato da questo cluster, GKE indica anche al cluster di interrompere l'utilizzo dell'indirizzo IPv4 principale di questa subnet per gli indirizzi IPv4 dei nodi.

Prima di rimuovere un intervallo IPv4 secondario della subnet non predefinito, devi eliminare tutti i pool di nodi che utilizzano l'intervallo per gli indirizzi IPv4 dei pod.

Per rimuovere un intervallo IPv4 secondario della subnet non predefinita dal cluster, esegui questo comando:

   gcloud container clusters update CLUSTER_NAME \
     --remove-additional-ip-ranges=\
       subnetwork=SUBNET_NAME,pod-ipv4-range=POD_RANGE_NAME

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • SUBNET_NAME: il nome della subnet non predefinita.
  • POD_RANGE_NAME: il nome dell'intervallo IPv4 secondario della subnet non predefinita che vuoi rimuovere dal cluster.

Dopo aver rimosso un intervallo IPv4 secondario di subnet non predefinito dal cluster, puoi eliminare l'intervallo IPv4 secondario di subnet non predefinito.

Utilizzare subnet aggiuntive nel VPC condiviso

Prima di procedere, assicurati di avere quanto segue:

  • Un ambiente VPC condiviso funzionale in cui sono collegati i progetti host e di servizio. Per istruzioni, vedi Configurare un cluster con VPC condiviso.
  • Un cluster GKE in esecuzione che si trova nel progetto di servizio.
  • Tutte le API necessarie sono abilitate sia nel progetto host sia in quello di servizio.

  1. Crea una subnet aggiuntiva nel progetto host nella stessa rete del cluster GKE:

    gcloud compute networks subnets create ADDITIONAL_SUBNET_NAME \
  --project HOST_PROJECT_ID \
  --network shared-net \
  --range 172.16.4.0/22 \
  --region COMPUTE_REGION \
  --secondary-range ADDITIONAL_SUBNET_NAME-services=172.16.16.0/20,ADDITIONAL_SUBNET_NAME-pods=172.20.0.0/14

  2. Recupera il criterio IAM. Per consentire al cluster GKE nel progetto di servizio di accedere a subnet aggiuntive all'interno del VPC condiviso del progetto host, devi configurare le autorizzazioni IAM necessarie. Se le autorizzazioni non sono già configurate, procedi con i seguenti passaggi. Non è necessaria alcuna azione se le autorizzazioni esistono già.

    gcloud compute networks subnets get-iam-policy ADDITIONAL_SUBNET_NAME \
    --project HOST_PROJECT_ID \
    --region COMPUTE_REGION

    L'output contiene un campo etag. Prendi nota del valore di etag.

  3. Crea un file denominato ADDITIONAL_SUBNET_NAME-policy.yaml con i seguenti contenuti:

      bindings:
  - members:
    - serviceAccount:SERVICE_PROJECT_NUM@cloudservices.gserviceaccount.com
    - serviceAccount:service-SERVICE_PROJECT_NUM@container-engine-robot.iam.gserviceaccount.com
    role: roles/compute.networkUser
  etag: ETAG_STRING

    Sostituisci ETAG_STRING con il valore etag che hai annotato in precedenza.

  4. Imposta il criterio IAM per la subnet ADDITIONAL_SUBNET_NAME:

      gcloud compute networks subnets set-iam-policy ADDITIONAL_SUBNET_NAME \
      ADDITIONAL_SUBNET_NAME-policy.yaml \
      --project HOST_PROJECT_ID \
      --region COMPUTE_REGION

  5. Verifica le subnet utilizzabili e gli intervalli di indirizzi IP secondari, come descritto in shared vpc verify usable subnets.

  6. Aggiorna il cluster VPC condiviso delle subnet aggiuntive:

    gcloud container clusters update CLUSTER_NAME \
        --project=SERVICE_PROJECT_ID \
        --location=CONTROL_PLANE_LOCATION \
        --additional-ip-ranges=subnetwork=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/ADDITIONAL_SUBNET_NAME,pod-ipv4-range=ADDITIONAL_SUBNET_NAME-pods

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster GKE nel progetto di servizio.
  • ADDITIONAL_SUBNET_NAME: il nome della subnet aggiuntiva che hai creato nel progetto host (ad es. tier-2).
  • HOST_PROJECT_ID: l'ID progetto host.
  • SERVICE_PROJECT_NUM: il nome del progetto di servizio.
  • COMPUTE_REGION: la regione in cui si trova la subnet.

In questo modo puoi utilizzare le subnet aggiuntive in un ambiente VPC condiviso.

Passaggi successivi