Informazioni sulle scelte di configurazione del cluster

Questa pagina spiega le principali scelte di configurazione del cluster che puoi fare quando crei un cluster in Google Kubernetes Engine (GKE), sia che utilizzi la consoleGoogle Cloud , Google Cloud CLI o Terraform. Queste opzioni ti consentono di personalizzare un'ampia gamma di attributi e comportamenti del cluster per soddisfare le tue esigenze, dall'accessibilità del cluster da reti pubbliche alla modalità di ricezione degli upgrade di versione.

Molte delle opzioni descritte in questa guida non possono essere modificate dopo la creazione di un cluster. Queste includono scelte che influiscono sulla disponibilità e sulla rete di un cluster. Se devi modificare queste opzioni, devi creare un nuovo cluster e poi eseguire la migrazione del traffico, il che potrebbe causare interruzioni.

Best practice:

Poiché molte opzioni di configurazione del cluster non possono essere modificate dopo la creazione del cluster, pianifica e progetta la configurazione del cluster con gli amministratori e gli architetti della tua organizzazione, i Cloud Architect, gli amministratori di rete o qualsiasi altro team responsabile della definizione, dell'implementazione e della manutenzione di GKE e dell'architetturaGoogle Cloud .

Questa pagina è rivolta ad amministratori e architetti che definiscono le soluzioni IT e l'architettura di sistema in conformità con la strategia aziendale. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Prima di leggere questa pagina, devi avere familiarità con i seguenti concetti, oltre ai concetti di base di Kubernetes:

Livello di gestione dei cluster

Prima di discutere delle opzioni del cluster, è importante comprendere il livello di flessibilità, responsabilità e controllo di cui hai bisogno per il tuo cluster. Il livello di controllo richiesto determina la modalità operativa da utilizzare in GKE e le scelte di configurazione del cluster che devi effettuare.

Quando crei un cluster in GKE, utilizzi una delle seguenti modalità operative:

  • Autopilot (consigliata): fornisce una configurazione del cluster completamente sottoposta a provisioning e gestita. I cluster Autopilot sono preconfigurati con una configurazione del cluster ottimizzata e pronta per i workload di produzione.

  • Standard: offre una flessibilità di configurazione avanzata sull'infrastruttura sottostante del cluster. Per i cluster creati utilizzando la modalità Standard, sei tu a determinare la configurazione necessaria per i tuoi workload di produzione.

Per saperne di più su queste modalità e su Autopilot, consulta Modalità operative di GKE e la panoramica di Autopilot.

Puoi trovare un confronto fianco a fianco dettagliato delle due modalità in Confronta GKE Standard e Autopilot.

Scelte di configurazione del cluster

Dopo aver scelto una modalità di funzionamento, seleziona la configurazione richiesta per il cluster. Poiché i cluster Autopilot sono gestiti e configurati in modo più completo da Google Cloud rispetto ai cluster Standard, hanno meno opzioni di configurazione disponibili.

Le opzioni di configurazione per tutti i cluster rientrano nelle seguenti categorie:

  • Nome e altri metadati: ogni cluster deve avere un nome identificativo univoco all'interno del progetto. Se vuoi, puoi anche aggiungere una descrizione e delle etichette del cluster.
  • Disponibilità e scalabilità: specifica dove vuoi che vengano eseguiti il control plane e i nodi del cluster e se vuoi più repliche del control plane. Tutti i cluster Autopilot sono regionali, il che significa che hanno più control plane in più zone di computing in una regione Google Cloud.
  • Appartenenza al parco risorse: scegli se vuoi che il tuo cluster sia un membro di un parco risorse.
  • Networking: opzioni di networking, tra cui la rete VPC (Virtual Private Cloud) e la subnet in cui si trova il cluster, nonché se vuoi che il cluster sia accessibile dalle reti pubbliche.
  • Gestione delle versioni e degli upgrade: utilizza i canali di rilascio per scegliere il tuo equilibrio preferito tra nuove funzionalità e stabilità durante l'upgrade del software di questo cluster e imposta periodi di manutenzione ed esclusioni per scegliere quando eseguire o meno gli upgrade.
  • Sicurezza: include se il cluster utilizza Workload Identity Federation for GKE e il account di servizio utilizzato dai nodi del cluster per l'autenticazione inGoogle Cloud.
  • Funzionalità del cluster: abilita e configura funzionalità aggiuntive di GKE eGoogle Cloud per questo cluster, inclusi backup e osservabilità. La modalità standard consente inoltre di creare cluster alpha di breve durata per provare le funzionalità alpha di Kubernetes.

Oltre a queste, i cluster Standard hanno anche opzioni nella seguente categoria:

  • Pool di nodi: specifica i dettagli dei nodi del cluster, inclusi i pool di nodi, il sistema operativo dei nodi e le dimensioni dei nodi.

Le sezioni seguenti esaminano alcune di queste categorie in maggiore dettaglio, in particolare quelle con opzioni in cui non è possibile modificare l'impostazione dopo la creazione del cluster. Per un elenco completo delle opzioni di configurazione, consulta il Riferimento per la configurazione.

La tabella seguente mette a confronto le opzioni disponibili in alcune aree chiave per i cluster Autopilot e Standard:

Scelte dei cluster Modalità
Autopilot Standard
Tipo di disponibilità Regionale A livello di regione o Zonal
Canale di rilascio Rapido, Regolare o Stabile Qualsiasi canale
Versioni cluster Predefinita o un'altra versione disponibile Predefinita o un'altra versione disponibile
Routing di rete Rete VPC nativa Nativo di VPC o Basato su route
Isolamento della rete Personalizzabile Personalizzabile
Funzionalità di Kubernetes Produzione Produzione o Alpha

Disponibilità dei cluster

Con GKE, puoi creare un cluster personalizzato in base ai requisiti di disponibilità del tuo workload e al tuo budget. Puoi scegliere tra cluster regionali con più repliche del control plane in più zone di computing in una regione Google Cloud o cluster di zona con un singolo control plane in una singola zona. I cluster Autopilot sono sempre regionali.

Per scegliere il tipo di cluster da creare in modalità Standard, consulta Scelta di un control plane regionale o zonale.

Queste impostazioni non possono essere aggiornate dopo la creazione del cluster: un cluster a livello di zona non può diventare un cluster a livello di regione e un cluster a livello di regione non può diventare un cluster a livello di zona.

Best practice:

Per i workload di produzione, utilizza i cluster a livello di regione, perché in genere offrono una disponibilità maggiore rispetto ai cluster a livello di zona. Per gli ambienti di sviluppo, utilizza cluster a livello di regione con pool di nodi a livello di zona. Un cluster con un control plane regionale e pool di nodi di zona ha gli stessi costi di un cluster di zona. Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.

Cluster a livello di regione

Un cluster regionale include più repliche del control plane, in esecuzione in più zone all'interno della Google Cloud regione specificata. Devi sempre specificare una regione quando crei un cluster Autopilot o un altro cluster a livello di regione.

Solo per i cluster Standard regionali, puoi anche scegliere le zone in cui vengono eseguiti i nodi del cluster. I nodi di un cluster regionale possono essere eseguiti in più zone o in una singola zona, a seconda delle località dei nodi configurate. Per impostazione predefinita, GKE replica ogni pool di nodi in tre zone della regione del control plane. Quando crei un cluster Standard a livello di regione o quando aggiungi un nuovo pool di nodi, puoi modificare la configurazione predefinita specificando le zone in cui vengono eseguiti i nodi del cluster. Tutte le zone devono trovarsi nella stessa regione del control plane.

Utilizza i cluster a livello di regione per eseguire i workload di produzione, in quanto offrono una disponibilità maggiore rispetto ai cluster a livello di zona.

Non puoi modificare la regione di un cluster regionale dopo averlo creato.

Cluster di zona

I cluster di zona hanno un unico control plane in un'unica zona. I workload continuano a essere eseguiti durante un upgrade del cluster o un'interruzione della zona in cui viene eseguito il control plane. Tuttavia, il cluster, i suoi nodi e i suoi workload non possono essere configurati finché il control plane non è disponibile. A seconda dei requisiti di disponibilità del workload, puoi scegliere di distribuire i nodi per il cluster di zona in una o più zone.

Per creare un cluster di zona, consulta Creazione di un cluster di zona.

Posizione e distribuzione dei nodi

Indipendentemente dal fatto che utilizzi cluster a livello di regione o di zona, puoi determinare con precisione la posizione e la distribuzione dei nodi tra le zone. Puoi configurare le zone predefinite per tutti i pool di nodi futuri, nonché assegnare o modificare le zone specifiche per i nodi all'interno dei pool di nodi esistenti.

Cluster a zona singola

Un cluster a zona singola, che può essere un cluster a livello di zona o di regione, esegue i workload su nodi situati in una sola zona. Se si verifica un'interruzione in quella zona, tutti i workload diventano non disponibili.

I cluster di zona vengono creati per impostazione predefinita come cluster a zona singola, ma puoi aggiornare questa configurazione in cluster multizona.

Cluster multizona

Un cluster multizona, che può essere un cluster a livello di regione o di zona, migliora la disponibilità del workload distribuendo i nodi in più zone all'interno di una singola regione. In questo modo puoi eseguire i workload in più zone di una regione. Se esegui un workload in più zone e si verifica un'interruzione del servizio a livello di zona, il workload viene interrotto in quella zona, ma rimane disponibile nelle altre zone.

La distribuzione dei nodi GKE in più zone può comportare addebiti per il traffico di rete in uscita tra zone quando i nodi devono comunicare con i peer situati in una zona diversa all'interno della regione.

I cluster a livello di regione vengono creati per impostazione predefinita come cluster multizona, ma puoi aggiornare questa configurazione in cluster a zona singola.

Zone AI

Le zone AI sono zone specializzate utilizzate per i workload di addestramento e inferenza AI/ML. Queste zone offrono una capacità significativa di acceleratori ML. Per saperne di più, consulta la documentazione relativa alle zone AI.

In questo documento e nella documentazione di GKE, "zone standard" o "zone" si riferiscono alle zone non AI all'interno di una regione Google Cloud .

Prima di utilizzare una zona AI in GKE, considera le seguenti caratteristiche:

  • Per utilizzare una zona AI con i cluster GKE esistenti, il control plane deve eseguire la versione 1.36.4-gke.1495002 o successiva oppure 1.37.1-gke.1552000 o successiva. Queste versioni consentono al control plane di riconoscere la zona e registrare i nodi. Se il control plane esegue la versione 1.35 o precedente o una versione precedente a questi minimi, esegui l'upgrade del control plane prima di creare i node pool nella AI Zone. Se l'upgrade non è possibile, contatta l'assistenza clienti Google Cloud.
  • Le zone AI sono separate fisicamente dalle zone standard per fornire spazio di archiviazione e potenza aggiuntivi. Questa separazione potrebbe comportare una latenza più elevata, che è generalmente tollerabile per i workload AI/ML.
  • Le zone AI hanno un suffisso con la notazione ai. Ad esempio, una zona AI nella regione us-central1 è denominata us-central1-ai1a.
  • Al momento sono supportate solo le VM TPU.
  • Il control plane del cluster viene eseguito in una o più zone standard all'interno della stessa regione della zona AI.

  • Puoi eseguire VM senza TPU collegate in una zona AI solo se soddisfi i seguenti requisiti:

    • Stai già eseguendo altri workload che utilizzano VM TPU nella stessa zona.
    • Le VM non TPU sono VM spot, associate a una prenotazione o parte di un pool di nodi con un rapporto specifico tra VM con acceleratore e VM per uso generico.

  • Le zone AI condividono componenti, come connessioni di rete e implementazioni software, con le zone standard che hanno lo stesso suffisso nella stessa regione. Per i workload ad alta affidabilità, ti consigliamo di utilizzare zone diverse. Ad esempio, evita di utilizzare sia us-central1-ai1a che us-central1-a per l'alta affidabilità.

Per impostazione predefinita, GKE non esegue il deployment dei workload nelle zone AI. Per utilizzare una zona AI, devi configurare una delle seguenti opzioni:

  • (Consigliato) ComputeClasses: imposta la priorità più alta per richiedere TPU on demand in una AI Zone. Le classi di computing ti aiutano a definire un elenco con priorità delle configurazioni hardware per i tuoi workload. Per un esempio, consulta Informazioni su ComputeClasses.
  • Provisioning automatico dei nodi: utilizza un nodeSelector o un nodeAffinity nella specifica del pod per indicare al provisioning automatico dei nodi di creare un pool di nodi nella zona AI. Se il tuo workload non ha come target esplicito una zona AI, il provisioning automatico dei nodi prende in considerazione solo le zone standard o le zone di --autoprovisioning-locations durante la creazione di nuovi node pool. Questa configurazione contribuisce a garantire che i workload che non eseguono modelli AI/ML rimangano nelle zone standard, a meno che tu non li configuri esplicitamente in modo diverso. Per un esempio di manifest che utilizza un nodeSelector, consulta Imposta le zone predefinite per i nodi creati automaticamente.
  • GKE Standard: se gestisci direttamente i tuoi pool di nodi, utilizza una zona AI nel flag --node-locations quando crei un pool di nodi. Per un esempio, consulta Esegui il deployment dei workload TPU in GKE Standard.

Abbonamento al parco risorse

Se la tua organizzazione utilizza più cluster, puoi semplificare la gestione multi-cluster aggiungendo i cluster a un parco risorse: un raggruppamento logico di cluster Kubernetes. La creazione di un parco risorse aiuta la tua organizzazione a migliorare il livello di gestione da singoli cluster a interi gruppi di cluster e ti consente di utilizzare funzionalità abilitate per il parco risorse come Ingress multi-cluster, Config Sync e Policy Controller.

Sebbene sia possibile aggiungere cluster a un parco risorse in qualsiasi momento, consigliamo vivamente di registrare i nuovi cluster in un parco risorse durante la creazione dei cluster. Questo perché i cluster "nati nel parco risorse" vengono creati con le impostazioni predefinite a livello di parco risorse che hai scelto per una serie di funzionalità aziendali e con i log e le metriche consigliati già abilitati. Puoi scoprire di più su questi aspetti nelle seguenti guide:

Questa impostazione può essere aggiornata dopo la creazione del cluster per registrare o annullare la registrazione del cluster, anche se sconsigliamo di spostare i cluster con workload attivi da un parco risorse all'altro.

Puoi scoprire di più sull'aggiunta di cluster ai parchi risorse in Crea parchi risorse per semplificare la gestione multi-cluster.

Impostazioni Networking

Quando crei un cluster GKE, puoi specificare una serie di impostazioni di rete, tra cui la rete in cui si trova il cluster, la modalità di routing della rete e se vuoi che i nodi del cluster siano accessibili dalle reti pubbliche.

Se non sei un amministratore di rete, consulta gli specialisti di networking della tua organizzazione prima di creare un cluster pronto per la produzione, poiché molte di queste opzioni non possono essere modificate dopo la creazione del cluster. Se sei un amministratore di rete, puoi scoprire di più sul networking GKE in Informazioni sul networking GKE, con le best practice per le opzioni di networking in Best practice per il networking GKE. Questa sezione descrive solo un sottoinsieme delle nostre possibili opzioni di networking.

Rete e subnet

La rete Virtual Private Cloud (VPC) in cui si trova un cluster determina le altre risorse di Compute Engine con cui può comunicare. Per impostazione predefinita, i cluster GKE vengono creati nella rete predefinita del progetto, anche se puoi scegliere un'altra rete se tu o l'amministratore ne avete creata una. Se disponibile, puoi specificare che vuoi che il tuo cluster appartenga a una subnet VPC specifica; in caso contrario, viene utilizzata la subnet predefinita. Se vuoi, puoi anche specificare che vuoi utilizzare un intervallo di indirizzi IP specifico all'interno della subnet per i tuoi pod e servizi.

Queste impostazioni non possono essere aggiornate dopo la creazione del cluster.

Scelte relative all'isolamento di rete

Puoi personalizzare l'isolamento della rete nel tuo cluster considerando i seguenti due aspetti:

  • Accesso al control plane: per impostazione predefinita, sia l'endpoint interno che l'endpoint esterno del control plane sono abilitati, mentre l'endpoint basato su DNS è disabilitato. Puoi scegliere di:

    • Disattiva sia l'endpoint esterno che quello interno e utilizza solo l'endpoint DNS.
    • Disattiva l'endpoint esterno solo per impedire l'accesso ai client esterni.
    • Abilita le reti autorizzate per controllare quali indirizzi IP raggiungono gli endpoint del control plane.

  • Configurazione di networking del cluster: puoi scegliere di attivare i nodi privati nel cluster per isolare completamente i workload dalle reti pubbliche. Puoi abilitare i nodi privati per interi cluster o a livello di pool di nodi (per Standard) o di workload (per Autopilot). L'abilitazione dei nodi privati a livello di pool di nodi o di workload esegue l'override di qualsiasi configurazione dei nodi a livello di cluster.

Queste impostazioni possono essere modificate dopo la creazione del cluster.

Per saperne di più sull'isolamento di rete, consulta Informazioni sulla personalizzazione dell'isolamento di rete e Personalizza l'isolamento di rete.

Best practice:

Utilizza Cloud NAT per fornire ai pod GKE l'accesso alle risorse con indirizzi IP pubblici. Cloud NAT migliora la security posture complessiva del cluster perché i pod non sono esposti direttamente a internet, ma possono comunque accedere alle risorse connesse a internet.

Cluster nativi di VPC e basati su route

In GKE, i cluster possono essere distinti in base al modo in cui instradano il traffico da un pod all'altro. Un cluster in cui gli indirizzi IP dei pod sono instradabili in modo nativo all'interno della rete VPC senza utilizzare route statiche personalizzate è chiamato cluster nativo di VPC. Nei cluster IPv4 e dual-stack, GKE utilizza indirizzi IP alias; nei cluster IPv6 a stack singolo, GKE alloca gli indirizzi direttamente dalla subnet senza intervalli di indirizzi IP alias. Al contrario, un cluster che utilizza le routeGoogle Cloud è chiamato cluster basato su route.

Per impostazione predefinita, tutti i nuovi cluster GKE utilizzano il routing nativo di VPC, che è l'opzione consigliata. Puoi modificare questa impostazione durante la creazione del cluster per creare un cluster basato su route solo in modalità Standard. Questa impostazione non può essere aggiornata dopo la creazione del cluster.

Puoi scoprire di più sui cluster nativi di VPC e sui loro vantaggi, inclusi eventuali requisiti speciali, in Cluster nativi di VPC.

Best practice:

Utilizza la modalità di rete VPC nativa per i tuoi cluster. Questa è l'impostazione predefinita per i cluster Autopilot.

Versioni e upgrade

Con i canali di rilascio, GKE sceglie le versioni software per un cluster per bilanciare la disponibilità e la stabilità delle funzionalità. Quando crei un cluster, puoi scegliere il canale di rilascio che preferisci. I nuovi cluster (sia Autopilot che Standard) vengono registrati nel canale di rilascio regolare per impostazione predefinita, anche se, se necessario, puoi scegliere una versione specifica durante la creazione del cluster.

I cluster Autopilot utilizzano sempre i canali di rilascio. I cluster Standard utilizzano i canali di rilascio per impostazione predefinita, ma puoi scegliere di non registrare il cluster in un canale di rilascio (anche se non lo consigliamo, perché questa impostazione offre un accesso più limitato alle funzionalità del cluster).

GKE esegue automaticamente l'upgrade di tutti i cluster nel tempo, indipendentemente dalla registrazione al canale di rilascio. GKE esegue automaticamente l'upgrade del control plane del cluster e dei relativi nodi man mano che diventano disponibili nuove versioni in quel canale di rilascio. Puoi controllare la tempistica e l'ambito degli upgrade con periodi di manutenzione ed esclusioni.

Puoi modificare il canale di rilascio di un cluster in qualsiasi momento.

Per informazioni sui prossimi upgrade automatici, consulta le note di rilascio di GKE.

Best practice:

Scegli un canale di rilascio per GKE per selezionare le versioni del tuo cluster per bilanciare la disponibilità e la stabilità delle funzionalità. Utilizza i periodi di manutenzione e le esclusioni per controllare la tempistica e l'ambito degli upgrade automatici.

Funzionalità alfa (solo cluster Standard)

Le nuove funzionalità di Kubernetes sono elencate come Alpha, Beta o Stable, a seconda del loro stato di sviluppo. Nella maggior parte dei casi, le funzionalità di Kubernetes elencate come beta o stabili sono incluse nei cluster GKE.

Se vuoi sperimentare funzionalità molto nuove che non sono pronte per la produzione, le funzionalità alfa sono disponibili in cluster GKE alfa speciali. Un cluster alpha ha tutte le API alpha di Kubernetes (a volte chiamate feature gate) abilitate. Puoi utilizzare i cluster alpha per i test e la convalida iniziali delle funzionalità di Kubernetes. I cluster alpha non sono supportati per i workload di produzione, non possono essere sottoposti ad upgrade o aggiunti ai canali di rilascio e scadono entro 30 giorni.

Le funzionalità alpha non sono disponibili per i cluster Autopilot.

Per creare un cluster alpha, consulta Creazione di un cluster alpha.

Impostazioni di sicurezza

GKE dispone di una serie di impostazioni di sicurezza che puoi specificare al momento della creazione del cluster. Queste includono le impostazioni di crittografia, le funzionalità di sicurezza come Autorizzazione binaria, il account di servizio che vuoi utilizzare per i nodi del cluster (illustrato in maggiore dettaglio nella sezione successiva) e se il cluster utilizza Workload Identity Federation for GKE.

Come per le altre impostazioni, prima di creare un cluster pronto per la produzione, devi consultare colleghi esperti, in questo caso gli specialisti della sicurezza della tua organizzazione. Puoi scoprire di più sulla sicurezza di GKE nella nostra Panoramica sulla sicurezza e in Rafforza la sicurezza del cluster.

Service account per i nodi

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi service account dei nodi devono avere il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) nel tuo progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, che viene creato automaticamente nel tuo progetto, come service account del nodo.

Se la tua organizzazione applica il vincolo della policy dell'organizzazione iam.automaticIamGrantsForDefaultServiceAccounts, il account di servizio Compute Engine predefinito nel tuo progetto potrebbe non ottenere automaticamente le autorizzazioni richieste per GKE.

Se utilizzi il account di servizio predefinito di Compute Engine per altre funzioni nel tuo progetto o nella tua organizzazione, il account di servizio potrebbe avere più autorizzazioni di quelle necessarie a GKE, il che potrebbe esporti a rischi per la sicurezza.

Non puoi modificare il account di servizio per i cluster in modalità Autopilot o per i pool di nodi in modalità Standard dopo la creazione.

Impostazioni dei node pool (solo cluster Standard)

Come sai dalla Panoramica dell'amministrazione dei cluster e dalle modalità operative di GKE, se utilizzi Autopilot per i tuoi cluster non devi preoccuparti della configurazione dei nodi, perché GKE li configura per te. I nodi del cluster Autopilot sono tutti completamente gestiti da GKE e utilizzano tutti lo stesso sistema operativo (OS) dei nodi.

Se scegli di creare un cluster Standard, puoi specificare una serie di opzioni per i nodi durante la creazione di un cluster, tra cui:

  • Il nome, il numero, le dimensioni e la località dei node pool che vuoi utilizzare; i node pool sono gruppi di nodi all'interno del cluster che condividono una configurazione comune.
  • Il sistema operativo dei nodi che vuoi utilizzare per i nuovi nodi.
  • Se vuoi utilizzare VM spot temporanee per i nodi.
  • Il tipo di macchina Compute Engine che vuoi utilizzare per i nodi.
  • Il account di servizio che vuoi utilizzare per i nodi, come descritto in Impostazioni di sicurezza.

Alcune impostazioni del pool di nodi di un cluster possono essere modificate dopo la creazione del cluster, anche se tutti i cluster Standard richiedono almeno un pool di nodi. Se non specifichi un numero di nodi e un tipo di macchina durante la creazione di un cluster Standard, il suo pool di nodi predefinito è composto da tre nodi in ciascuna delle zone del cluster, con l'immagine del nodo predefinita cos_containerd e un tipo di macchina per uso generico.

Puoi scoprire di più sulla configurazione pool di nodi in Informazioni sui node pool e Aggiungi e gestisci i node pool.

Riferimento per la configurazione

Trova un elenco completo delle possibili opzioni di configurazione nelle seguenti guide di riferimento:

Passaggi successivi