Crea e gestisci cluster IPv6 a stack singolo

Questo documento spiega come creare, configurare e gestire cluster IPv6 single-stack in Google Kubernetes Engine (GKE).

Puoi eseguire workload containerizzati in un ambiente di networking solo IPv6 per evitare di esaurire lo spazio di indirizzi IPv4 privati (RFC 1918). Quando esegui il deployment di un cluster IPv6 a stack singolo, assegni solo indirizzi IPv6 ai pod, ai nodi e ai servizi, mantenendo la connettività in entrata e in uscita alle risorse interne ed esterne.

Panoramica

Man mano che i workload scalano e la densità dei cluster aumenta, lo spazio degli indirizzi IPv4 privati può esaurirsi rapidamente. Nei cluster solo IPv4 e a doppio stack, ogni pod richiede un indirizzo IPv4, il che può rendere l'allocazione dei blocchi CIDR nella rete VPC un importante collo di bottiglia per la scalabilità.

Nei cluster IPv6 a stack singolo GKE, assegni gli indirizzi IPv6 esclusivamente nel piano dati del cluster, rimuovendo completamente i vincoli degli indirizzi IPv4. I nodi worker vengono eseguiti su istanze VM di Compute Engine IPv6 a stack singolo, mentre i pod e i servizi comunicano tramite connessioni IPv6.

Allocazione degli indirizzi IP (IPAM)

I cluster IPv6 a stack singolo allocano gli indirizzi IPv6 nella subnet, nei nodi, nei pod e nei servizi utilizzando le seguenti dimensioni dei prefissi:

Risorsa Prefisso del blocco CIDR Descrizione
Subnet /64 Specificato come blocco CIDR di una subnet solo IPv6.
Nodo /96 Assegnato automaticamente da GKE dal blocco CIDR della subnet, fornendo circa 4,29 miliardi di indirizzi IPv6 univoci per nodo.
Pod /112 Assegnato da un sottoinsieme dell'intervallo secondario /96 del nodo.
Servizio /64 Assegnato automaticamente da GKE per i servizi ClusterIP dall'intervallo di indirizzi IPv6 2600:2D00:0:4::0:0/64.

Tipi di accesso IPv6 esterni e interni

Quando configuri la subnet del cluster, puoi scegliere tra due tipi di accesso IPv6 per controllare la possibilità di routing su internet:

  • Interno (ULA): le subnet con il tipo di accesso INTERNAL utilizzano indirizzi unicast locali univoci (ULA) nell'intervallo fd20::/20. La comunicazione è limitata alla rete VPC, alle reti in peering e alle connessioni ibride. I nodi e i pod non possono raggiungere direttamente le risorse internet IPv6 pubbliche o ricevere traffico in entrata diretto da internet.
  • Esterno (GUA): le subnet con il tipo di accesso EXTERNAL utilizzano indirizzi Global Unicast Address (GUA). Ai nodi e ai pod vengono assegnati indirizzi IPv6 univoci a livello globale, che possono comunicare con le risorse internet IPv6 pubbliche sia in entrata che in uscita, in base alle regole firewall e alle tabelle di routing del VPC.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per 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

Per utilizzare i cluster IPv6 a stack singolo, assicurati di soddisfare i seguenti requisiti e limitazioni:

  • Il cluster deve eseguire GKE versione 1.37.1-gke.3020000 o successiva.
  • Il cluster deve essere un cluster nativo di VPC che utilizza GKE Dataplane V2. I cluster IPv6 a stack singolo non supportano i cluster basati su route.
  • I cluster IPv6 a stack singolo supportano solo istanze VM IPv6 a stack singolo come nodi worker e non supportano pool di nodi misti o a doppio stack.
  • Devi utilizzare Cloud DNS come provider DNS del cluster (--cluster-dns=clouddns). I cluster IPv6 a stack singolo non supportano kube-dns.
  • L'accesso al control plane nei cluster IPv6 a stack singolo utilizza due percorsi distinti:
    • Client esterni: i client esterni al cluster (ad esempio, utilizzando kubectl) accedono al control plane tramite un endpoint basato su dominio su GKE Frontend (GKFE).
    • Workload interni: i nodi e i pod si connettono in modo sicuro al control plane tramite Private Service Connect. Per supportare questa comunicazione, devi fornire o creare una subnet con un tipo di accesso IPv6 INTERNAL (--private-endpoint-subnetwork).
  • Nelle subnet IPv6 interne (INTERNAL), i nodi e i pod possono raggiungere le API di Google e Artifact Registry tramite IPv6 senza un gateway Cloud NAT. Tuttavia, tieni presente quanto segue:
    • Per raggiungere endpoint esterni solo IPv4 (ad esempio registry dei container esterni solo IPv4), devi configurare DNS64 e Cloud NAT (NAT64).
    • I nodi e i pod nelle subnet INTERNAL non possono raggiungere endpoint IPv6 pubblici esterni al di fuori di Google perché gli indirizzi locali univoci (ULA) non sono instradabili sulla rete internet IPv6 pubblica e Cloud NAT non supporta la traduzione da IPv6 a IPv6 (NAT66).
  • I cluster IPv6 a stack singolo non supportano i flag del cluster --private-ipv6-google-access-type e --enable-private-nodes. Configura invece l'accesso privato Google e i tipi di accesso IPv6 (INTERNAL o EXTERNAL) direttamente sulla tua subnet VPC.
  • I cluster IPv6 a stack singolo non supportano le configurazioni con più subnet.
  • I cluster IPv6 a stack singolo non supportano GKE Ingress. Per configurare i bilanciatori del carico delle applicazioni di livello 7, utilizza l'API Gateway.
  • L'API di networking multiplo di GKE non supporta le reti di pod IPv6; le reti di pod secondarie devono essere solo IPv4. Per saperne di più, consulta Supporto di più reti per i pod.
  • I cluster solo IPv6 non supportano Cloud Service Mesh.
  • Puoi utilizzare Bring Your Own IPv6 (BYOIPv6) con i cluster IPv6 a stack singolo. Per scoprire i requisiti applicabili ai prefissi BYOIPv6, consulta Crea e utilizza sottoprefissi IPv6.

Configurazione del server di metadati del workload

Poiché i workload in esecuzione in pod solo IPv6 non possono raggiungere l'indirizzo del server dei metadati IPv4 standard (169.254.169.254), applica le seguenti modifiche:

  • Configura le applicazioni e le librerie client in modo che accedano al server dei metadati utilizzando il nome di dominio metadata.google.internal (consigliato) o l'indirizzo IPv6 ULA letterale [fd20:ce::254].

  • Se utilizzi librerie client o applicazioni con endpoint del server dei metadati IPv4 impostati come hardcoded (ad esempio, versioni precedenti delle librerie client delle API di Google), imposta la variabile di ambiente GCE_METADATA_HOST nelle immagini container o nelle specifiche dei pod:

    env:
- name: GCE_METADATA_HOST
  value: "metadata.google.internal"

Crea un cluster IPv6 a stack singolo

Puoi creare un cluster IPv6 a stack singolo utilizzando Google Cloud CLI.

Crea un cluster e una subnet contemporaneamente

Se non hai subnet personalizzate preesistenti, puoi creare un cluster IPv6 standard a stack singolo e fare in modo che GKE esegua automaticamente il provisioning della subnet del nodo richiesta e di --private-endpoint-subnetwork in un unico comando.

Esegui questo comando:

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster.
  • VERSION: GKE versione 1.37.1-gke.3020000 o successive.
  • NETWORK_NAME: il nome di una rete VPC in modalità personalizzata esistente.
  • SUBNET_NAME: il nome della nuova subnet dei nodi da creare.
  • ACCESS_TYPE: la possibilità di routing su internet della subnet. Specifica INTERNAL per l'indirizzamento ULA privato o EXTERNAL per l'indirizzamento GUA pubblico. Se omesso, il valore predefinito è EXTERNAL.
  • COMPUTE_LOCATION: la regione o la zona di computing del tuo cluster.

Crea un cluster Standard su subnet personalizzate

Per utilizzare subnet preesistenti o personalizzate, crea la rete VPC, la subnet del control plane PSC e la subnet dei nodi prima di creare il cluster.

  1. Crea una rete VPC in modalità personalizzata con indirizzi IPv6 interni ULA abilitati:

    gcloud compute networks create NETWORK_NAME \
    --subnet-mode=CUSTOM \
    --enable-ula-internal-ipv6

  2. Crea la subnet del control plane PSC interno dedicata:

    gcloud compute networks subnets create PSC_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Sostituisci COMPUTE_REGION con la regione in cui esegui il deployment del cluster (ad esempio us-central1). Puoi anche specificare --stack-type=ipv4_ipv6 per la subnet del control plane PSC.

  3. Crea la subnet del nodo. Scegli l'accesso interno (INTERNAL) o l'accesso esterno (EXTERNAL):

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  4. Crea il cluster Standard IPv6 a stack singolo che fa riferimento a entrambe le subnet:

    gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Crea un cluster Autopilot su subnet personalizzate

I cluster Autopilot ereditano automaticamente il tipo di stack dalla subnet dei nodi specificata. Quando selezioni una subnet solo IPv6, GKE crea un cluster Autopilot IPv6 a stack singolo.

  1. Assicurati di aver creato una rete VPC personalizzata, una subnet PSC interna e una subnet di nodi solo IPv6, come descritto nella sezione precedente.

  2. Crea il cluster Autopilot:

    gcloud container clusters create-auto CLUSTER_NAME \
    --cluster-version=VERSION \
    --network=NETWORK_NAME \
    --subnetwork=NODE_SUBNET_NAME \
    --private-endpoint-subnetwork=PSC_SUBNET_NAME \
    --location=COMPUTE_LOCATION

Crea un cluster Standard con nodi gestiti

Puoi anche creare un cluster Standard IPv6 a stack singolo che utilizza nodi gestiti configurati a livello di workload. Per scoprire di più sulla configurazione delle classi di computing gestite nei cluster Standard, consulta Classi Autopilot nei cluster Standard.

Utilizza i tuoi indirizzi IPv6 per nodi e pod

Puoi creare un cluster IPv6 a stack singolo i cui nodi e pod utilizzano indirizzi IPv6 personalizzati (BYOIPv6) anziché indirizzi forniti da Google. Per farlo, crea la subnet del nodo con un intervallo di indirizzi IPv6 esterni provenienti da un sottoprefisso IPv6 regionale del prefisso delegato pubblico (PDP). I nodi e i pod ricevono quindi gli indirizzi IPv6 da quel prefisso e comunicano con internet e tra loro utilizzando questi indirizzi.

  1. Crea un sottoprefisso IPv6 regionale del prefisso delegato pubblico in modalità EXTERNAL_IPV6_SUBNETWORK_CREATION. Per saperne di più, consulta Crea sottoprefissi IPv6.

  2. Crea la subnet del nodo con un tipo di accesso IPv6 EXTERNAL e fai riferimento al prefisso secondario utilizzando il flag --ip-collection. Compute Engine alloca l'intervallo di indirizzi IPv6 /64 della subnet dal prefisso secondario:

    gcloud compute networks subnets create NODE_SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=EXTERNAL \
    --ip-collection=SUB_PREFIX_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

    Sostituisci SUB_PREFIX_NAME con il nome del prefisso secondario che hai creato nel passaggio precedente. Il sottoprefisso deve trovarsi nella stessa regione della subnet. Per scegliere un intervallo /64 specifico dal prefisso secondario anziché consentire a Compute Engine di allocarne uno, aggiungi il flag --external-ipv6-prefix.

  3. Crea il cluster su questa subnet dei nodi seguendo i passaggi descritti in Crea un cluster Standard su subnet personalizzate o Crea un cluster Autopilot su subnet personalizzate. La subnet del control plane PSC non ha bisogno di un intervallo di indirizzi BYOIPv6.

  4. Dopo che GKE ha creato il cluster, verifica che i nodi e i pod abbiano indirizzi IPv6 del tuo prefisso:

    kubectl get nodes -o wide
kubectl get pods --all-namespaces -o wide

Tieni presente che:

  • Questa procedura utilizza una subnet di nodi con il tipo di accesso IPv6 EXTERNAL, in modo che i nodi e i pod ricevano indirizzi instradabili a livello globale dal tuo prefisso. Puoi anche utilizzare una subnet del nodo con il tipo di accesso IPv6 INTERNAL facendo riferimento a un prefisso secondario in modalità INTERNAL_IPV6_SUBNETWORK_CREATION. In questo caso, i nodi e i pod ricevono indirizzi BYOIPv6 interni e si applicano le limitazioni di connettività del tipo di accesso IPv6 interno. Per saperne di più, consulta Connettiti a risorse esterne e private.
  • Per esporre i workload su indirizzi BYOIPv6 con i servizi LoadBalancer, consulta Bring Your Own IPv6 (BYOIPv6), che non richiede una subnet di nodi BYOIPv6.
  • Per i requisiti applicabili ai prefissi BYOIPv6, consulta Crea e utilizza sottoprefissi IPv6.

Verifica il tipo di stack del cluster

Al termine della creazione del cluster, elenca i cluster per verificare che venga eseguito in modalità IPv6 a stack singolo:

gcloud beta container clusters list

L'output conferma che la colonna STACK_TYPE è impostata su IPV6:

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

Bilanciamento del carico nei cluster IPv6 a stack singolo

Puoi esporre le applicazioni in esecuzione all'interno di cluster IPv6 a stack singolo utilizzando bilanciatori del carico di livello 7 e di livello 4:

  • Bilanciamento del carico delle applicazioni di livello 7 (API Gateway): utilizza l'API Gateway di Kubernetes per eseguire il deployment dei bilanciatori del carico delle applicazioni di livello 7 (gke-l7-rilb, gke-l7-regional-external-managed o gke-l7-global-external-managed). Questi gateway possono servire client IPv4 e IPv6 sia interni che esterni, instradando al contempo il traffico in modo trasparente agli endpoint dei pod solo IPv6 interni. Tieni presente che GKE Ingress non è supportato sui cluster IPv6 a stack singolo. Quando esegui il deployment dei gateway regionali (gke-l7-rilb e gke-l7-regional-external-managed) su cluster IPv6 a stack singolo, tieni presente i seguenti requisiti delle subnet:

    • Subnet solo proxy: nei cluster IPv6 a stack singolo, la subnet solo proxy regionale (--purpose=REGIONAL_MANAGED_PROXY) deve essere a doppio stack (--stack-type=IPV4_IPV6). Nei cluster solo IPv4 e a doppio stack, la subnet può essere solo IPv4 o a doppio stack.
    • Subnet VIP del gateway: a differenza dei gateway esterni regionali IPv4 (che non allocano VIP da una subnet), i gateway esterni regionali IPv6 (gke-l7-regional-external-managed) richiedono una subnet con accesso IPv6 EXTERNAL e i gateway interni regionali (gke-l7-rilb) richiedono una subnet con accesso IPv6 INTERNAL (o un intervallo IPv4 per un VIP IPv4 interno). Per allocare un VIP del gateway regionale temporaneo da una subnet personalizzata anziché dalla subnet del nodo del cluster, specifica il nome della subnet nel campo spec.default.subnetwork di un GCPGatewayPolicy collegato al gateway.

    Per istruzioni sulla configurazione, consulta Esegui il deployment dei gateway.

  • Bilanciamento del carico passthrough di livello 4 (API Service): puoi esporre i workload ai client IPv6 utilizzando i servizi Kubernetes configurati con type: LoadBalancer. A seconda che i nodi del cluster vengano eseguiti su una subnet INTERNAL (ULA) o EXTERNAL (GUA), potrebbe essere necessario eseguire il provisioning di una subnet del bilanciatore del carico dedicata e farvi riferimento utilizzando l'annotazione networking.gke.io/load-balancer-subnet:

Connettiti a risorse esterne e private

I workload nel cluster IPv6 a stack singolo spesso devono comunicare con servizi esterni su internet o servizi privati in Google Cloud.

Connettiti alle risorse internet IPv6 pubbliche

Se i nodi del cluster vengono eseguiti su una subnet configurata con il tipo di accesso IPv6 EXTERNAL (--ipv6-access-type=EXTERNAL), la connettività in uscita e in entrata verso gli endpoint IPv6 di internet pubblico è abilitata per impostazione predefinita. Verifica che le regole firewall VPC consentano il traffico IPv6 richiesto. Per saperne di più, consulta Utilizza le regole firewall VPC.

Connettiti alle risorse internet IPv4 pubbliche (DNS64 e NAT64)

Poiché i pod in un cluster IPv6 a stack singolo hanno solo indirizzi IPv6, la connessione a endpoint internet pubblici solo IPv4 richiede la traduzione di rete. Puoi configurare Cloud DNS e Cloud NAT nella tua rete VPC per fornire la traduzione automatica di DNS64 e NAT64:

  1. Crea una policy dei server DNS64:

    gcloud dns policies create POLICY_NAME \
    --description="DNS64 policy for single-stack IPv6 cluster" \
    --networks=NETWORK_NAME \
    --enable-dns64-all-queries

  2. Crea un router Cloud nella regione in cui è stato eseguito il deployment del cluster:

    gcloud compute routers create ROUTER_NAME \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

  3. Crea un gateway Cloud NAT configurato per la traduzione NAT64:

    gcloud compute routers nats create NAT_NAME \
    --router=ROUTER_NAME \
    --region=COMPUTE_REGION \
    --auto-allocate-nat-external-ips \
    --nat64-all-v6-subnet-ip-ranges

    Per configurare NAT64 con subnet specifiche o indirizzi IP esterni manuali, utilizza --nat64-custom-v6-subnet-ip-ranges e --nat-external-ip-pool.

Per scoprire di più sulla traduzione degli indirizzi, consulta Configura DNS64 e NAT64 e DNS64 e NAT64 per la connettività 6to4.

Connettiti ai servizi privati utilizzando Private Service Connect

Private Service Connect (PSC) supporta la traduzione degli indirizzi da IPv6 a IPv4 tra endpoint e regole di forwarding. Puoi connettere i workload nel tuo cluster IPv6 a stack singolo ai servizi gestiti Google Cloud (come le istanze Cloud SQL) o ai servizi di producer di terze parti:

  1. Prenota un indirizzo IPv6 interno statico dalla subnet PSC del cluster:

    gcloud compute addresses create ADDRESS_NAME \
    --ip-version=IPV6 \
    --subnet=PSC_SUBNET_NAME \
    --region=COMPUTE_REGION

  2. Crea una regola di forwarding dell'endpoint PSC che ha come target il collegamento al servizio:

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
    --address=ADDRESS_NAME \
    --region=COMPUTE_REGION \
    --network=NETWORK_NAME \
    --target-service-attachment=SERVICE_ATTACHMENT_URL \
    --allow-psc-global-access

  3. Recupera l'indirizzo IPv6 assegnato:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
    --region=COMPUTE_REGION \
    --format='value(IPAddress)'

  4. Utilizza l'indirizzo IPv6 recuperato all'interno delle stringhe di connessione dell'applicazione. PSC traduce il traffico in modo che i pod IPv6 possano raggiungere in sicurezza i servizi producer IPv4 o dual-stack.

Per scoprire di più sull'utilizzo dei servizi pubblicati, consulta Crea un endpoint Private Service Connect e Connettiti a Cloud SQL con Private Service Connect. Per pubblicare un servizio LoadBalancer interno in esecuzione nel tuo cluster per i consumer in altre reti VPC utilizzando una risorsa ServiceAttachment, consulta Crea un bilanciatore del carico interno con Private Service Connect.

Networking e acceleratori avanzati

Puoi configurare cluster IPv6 a stack singolo con interfacce di rete secondarie per i pool di nodi acceleratore e i pod multirete.

Networking con acceleratore multi-NIC

Nei cluster IPv6 a stack singolo standard, puoi collegare reti dati secondarie (RDMA o DIORITE) ai node pool di acceleratori (GPU e TPU) utilizzando il networking automatico (--accelerator-network-profile=auto) o la configurazione manuale di più reti (--additional-node-network). Le interfacce secondarie possono essere eseguite su subnet IPv4, subnet a doppio stack o subnet solo IPv6.

Per istruzioni passo passo, consulta Configura reti di nodi multi-NIC su cluster IPv6 a stack singolo.

Supporto di più reti per i pod

I cluster IPv6 a stack singolo supportano il networking multiplo per i pod con le seguenti caratteristiche:

  • L'interfaccia di rete del pod principale (eth0) utilizza il networking IPv6 a stack singolo.
  • Le interfacce di rete dei pod aggiuntivi devono essere solo IPv4 (reti VPC di livello 3). I cluster IPv6 a stack singolo non supportano le reti di pod IPv6 su interfacce di rete aggiuntive.
  • L'annotazione del pod networking.gke.io/default-interface configura l'interfaccia predefinita solo per il traffico IPv4; non è configurata alcuna interfaccia predefinita per il traffico IPv6.

Per scoprire come configurare reti di pod IPv4 secondarie supportate da subnet VPC, consulta Configura il supporto di più reti per i pod su cluster IPv6 a stack singolo.

Esegui la migrazione ai cluster IPv6 a stack singolo

Non puoi convertire direttamente o aggiornare in loco i cluster IPv4 o dual-stack esistenti in cluster IPv6 a stack singolo. Per eseguire la transizione dei workload, utilizza una migrazione blu/verde:

  1. Controlla le dipendenze: verifica che le configurazioni delle applicazioni, le librerie client e gli agenti utilizzino nomi DNS (come metadata.google.internal) anziché indirizzi IPv4 impostati come hardcoded. Configura GCE_METADATA_HOST, se necessario.
  2. Esegui il provisioning del cluster verde: esegui il deployment di un nuovo cluster IPv6 a stack singolo affiancato al cluster esistente all'interno della stessa rete VPC o di una rete VPC in peering. Verifica che Cloud DNS, DNS64, Cloud NAT (NAT64) e le regole di forwarding PSC siano configurati.
  3. Esegui il deployment dei workload: applica i manifest Kubernetes al cluster verde e verifica che i pod vengano avviati e comunichino correttamente.
  4. Sposta il traffico: utilizzando i bilanciatori del carico (API Gateway o policy di routing di Cloud DNS), sposta gradualmente il traffico dal cluster precedente al nuovo cluster IPv6 monitorando le metriche e i tassi di errore.
  5. Dismettere il cluster precedente: dopo che tutto il traffico è stato spostato e la stabilità del cluster verde è stata verificata, svuota ed elimina il cluster precedente.

Passaggi successivi