Distribuzione dei cluster di gestione con l'interfaccia del programma di installazione

In questo argomento viene descritto come utilizzare l'interfaccia del programma di installazione di Tanzu Kubernetes Grid per distribuire un cluster di gestione in vSphere quando il supervisore vSphere with Tanzu non è abilitato, in Amazon Web Services (AWS) e in Microsoft Azure. L'interfaccia del programma di installazione di Tanzu Kubernetes Grid consente di eseguire la distribuzione del cluster di gestione e fornisce configurazioni diverse da selezionare o riconfigurare. Se questa è la prima volta che si distribuisce un cluster di gestione in una determinata piattaforma di destinazione, è consigliabile utilizzare l'interfaccia del programma di installazione, ad eccezione dei casi in cui è necessario eseguire la distribuzione da un file di configurazione.

Prerequisiti

Prima di poter distribuire un cluster di gestione, è necessario assicurarsi che l'ambiente soddisfi i requisiti per la piattaforma di destinazione.

Prerequisiti generali

• Verificare di aver soddisfatto tutti i requisiti e di aver eseguito tutte le procedure indicate in Installazione della CLI di Tanzu e altri strumenti per l'utilizzo con i cluster di gestione autonomi.

• Per le distribuzioni di produzione, è consigliabile abilitare la gestione delle identità per i cluster. Per informazioni sui passaggi preparatori da eseguire prima di distribuire un cluster di gestione, vedere Recupero dei dettagli del provider di identità in Configurazione della gestione delle identità.

• Se si distribuiscono cluster in un ambiente con limitazioni Internet in vSphere o AWS, è necessario eseguire anche i passaggi descritti in Preparazione di un ambiente con limitazioni Internet. Questi passaggi includono l'impostazione di TKG_CUSTOM_IMAGE_REPOSITORY come variabile di ambiente.

Prerequisiti dell'infrastruttura

Ogni piattaforma di destinazione ha prerequisiti aggiuntivi per la distribuzione del cluster di gestione.

vSphere

Verificare di aver soddisfatto tutti i requisiti indicati in Preparazione della distribuzione dei cluster di gestione in vSphere.

Nota

In vSphere with Tanzu in vSphere 8, non è necessario distribuire un cluster di gestione. Vedere Il supervisore vSphere with Tanzu è un cluster di gestione.

AWS

• Assicurarsi di aver soddisfatto tutti i requisiti indicati in Preparazione della distribuzione dei cluster di gestione in AWS.
• Per informazioni sulle configurazioni delle diverse dimensioni delle istanze dei nodi, ad esempio t3.large o t3.xlarge, vedere Tipi di istanze di Amazon EC2.
• Per informazioni sulle risorse VPC e NAT utilizzate da Tanzu Kubernetes Grid, vedere Utilizzo delle risorse nell'account Amazon Web Services.

Azure

• Verificare di aver soddisfatto i requisiti indicati in Preparazione della distribuzione dei cluster di gestione in Microsoft Azure.
• Per informazioni sulle configurazioni di istanze dei nodi di Azure di dimensioni diverse, ad esempio Standard_D2s_v3 o Standard_D4s_v3, vedere Dimensioni delle macchine virtuali in Azure.

Avvio dell'interfaccia del programma di installazione

Per impostazione predefinita, Tanzu Kubernetes Grid salva kubeconfig per tutti i cluster di gestione nel file ~/.kube-tkg/config. Se si desidera salvare il file kubeconfig per il cluster di gestione in una posizione diversa, impostare la variabile di ambiente KUBECONFIG prima di eseguire tanzu mc create.

1. Nella macchina in cui è stata scaricata e installata la CLI di Tanzu, eseguire il comando tanzu mc create con l'opzione --ui:

   tanzu management-cluster create --ui
   

   Se i prerequisiti sono soddisfatti, l'interfaccia del programma di installazione viene avviata in un browser e consente di eseguire i passaggi necessari per configurare il cluster di gestione.

   Attenzione

   il completamento del comando tanzu mc create richiede tempo. Mentre tanzu mc create è in esecuzione, non eseguire ulteriori chiamate di tanzu mc create nella stessa macchina di bootstrap per distribuire più cluster di gestione, modificare il contesto o modificare ~/.kube-tkg/config.

   La sezione seguente Opzioni dell'interfaccia del programma di installazione spiega come modificare la posizione di esecuzione dell'interfaccia del programma di installazione, inclusa l'esecuzione in una macchina diversa dalla CLI di Tanzu.

2. Fare clic sul pulsante Distribuisci (Deploy) per VMware vSphere, Amazon EC2 o Microsoft Azure.

   

Opzioni dell'interfaccia del programma di installazione

Per impostazione predefinita, tanzu mc create --ui apre l'interfaccia del programma di installazione in locale, all'indirizzo http://127.0.0.1:8080 nel browser predefinito. È possibile utilizzare le opzioni --browser e --bind per controllare dove viene eseguita l'interfaccia del programma di installazione:

• --browser consente di specificare il browser locale in cui aprire l'interfaccia.
  • I valori supportati sono chrome, firefox, safari, ie, edge o none.
  • Utilizzare none con --bind per eseguire l'interfaccia in una macchina diversa, come descritto di seguito.

• --bind consente di specificare l'indirizzo IP e la porta da cui eseguire l'interfaccia.

  Attenzione

  L'esecuzione dell'interfaccia del programma di installazione da un indirizzo IP e una porta non predefiniti potrebbe esporre la CLI di Tanzu a un potenziale rischio per la sicurezza mentre l'interfaccia è in esecuzione. VMware consiglia di passare all'opzione –bind un IP e una porta in una rete sicura.

I casi d'uso per --browser e --bind includono:

• Se un altro processo sta già utilizzando http://127.0.0.1:8080, utilizzare --bind per eseguire l'interfaccia da un'altra porta locale.
• Per fare in modo che l'interfaccia del programma di installazione venga visualizzata in locale se si sta eseguendo il tunneling SSH nella macchina di bootstrap o l'inoltro X11 della relativa visualizzazione, potrebbe essere necessario utilizzare --browser none.

• Per eseguire la CLI di Tanzu, creare cluster di gestione in una macchina remota ed eseguire l'interfaccia del programma di installazione in locale o altrove:

  1. Nella macchina di bootstrap remota, eseguire tanzu mc create --ui con le opzioni e i valori seguenti:

     • --bind: un indirizzo IP e una porta per la macchina remota
     • --browser: none

     tanzu mc create --ui --bind 192.168.1.87:5555 --browser none
     

  2. Nella macchina dell'interfaccia utente locale, passare all'indirizzo IP della macchina remota per accedere all'interfaccia del programma di installazione.

Configurazione della piattaforma di destinazione

Le opzioni per configurare la piattaforma di destinazione dipendono dal provider utilizzato.

vSphere

Configurare la connessione all'istanza di vSphere.

1. Nella sezione Provider IaaS (IaaS Provider) immettere l'indirizzo IP o il nome di dominio completo (FQDN) dell'istanza di vCenter Server in cui distribuire il cluster di gestione.

   Il supporto per gli indirizzi IPv6 in Tanzu Kubernetes Grid è limitato; vedere Distribuzione dei cluster in IPv6 (solo vSphere). Se non si distribuisce in un ambiente di rete solo IPv6, è necessario specificare gli indirizzi IPv4 nei passaggi seguenti.

2. Immettere il nome utente e la password di vCenter Single Sign-On per un account utente che disponga dei privilegi necessari per le operazioni di Tanzu Kubernetes Grid.

   Il nome dell'account deve includere il dominio, ad esempio [email protected].

   

3. (Facoltativo) In Verifica identificazione personale SSL (SSL Thumbprint Verification) selezionare Disabilita verifica (Disable Verification). Se si seleziona questa casella di controllo, il programma di installazione ignora la verifica dell'identificazione personale del certificato durante la connessione a vCenter Server.

4. Fare clic su Connetti (Connect).

5. Verificare l'identificazione personale SSL del certificato di vCenter Server e fare clic su Continua (Continue) se è valido. Questa schermata viene visualizzata solo se la casella di controllo Disabilita verifica (Disable Verification) precedente è deselezionata.

   

   Per informazioni su come ottenere l'identificazione personale del certificato di vCenter Server, vedere Recupero delle identificazioni personali del certificato di vSphere.

6. Se si distribuisce un cluster di gestione in un'istanza di vSphere 7 o vSphere 8, confermare se si desidera procedere o meno con la distribuzione.

   In vSphere 7 e vSphere 8, vSphere with Tanzu fornisce un supervisore integrato che funziona come cluster di gestione e offre un'esperienza migliore rispetto a un cluster di gestione autonomo. La distribuzione di un cluster di gestione di Tanzu Kubernetes Grid in vSphere 7 o vSphere 8 quando il supervisore non è presente è supportata, ma l'opzione preferita consiste nell'abilitare vSphere with Tanzu e utilizzare il supervisore se possibile. Poiché Azure VMware Solution non supporta un cluster supervisore, è necessario distribuire un cluster di gestione.

   Per informazioni, vedere Il supervisore vSphere with Tanzu è un cluster di gestione in Creazione e gestione di cluster del carico di lavoro TKG 2.1 con la CLI di Tanzu .

   Per seguire il consiglio di utilizzare vSphere with Tanzu quando si esegue la distribuzione in vSphere 7 e vSphere 8, il programma di installazione di Tanzu Kubernetes Grid si comporta nel modo seguente:

   • Se vSphere with Tanzu è abilitato, il programma di installazione informa che la distribuzione di un cluster di gestione non è possibile e viene chiuso.
   • Se vSphere with Tanzu non è abilitato, il programma di installazione informa che la distribuzione di un cluster di gestione di Tanzu Kubernetes Grid è possibile ma non consigliata e visualizza una scelta:
   • Configura vSphere with Tanzu (Configure vSphere with Tanzu) apre vSphere Client per consentire di configurare il supervisore come descritto in Configurazione e gestione di un supervisore nella documentazione di vSphere 8.
   • Distribuisci cluster di gestione TKG (Deploy TKG Management Cluster) consente di continuare a distribuire un cluster di gestione per vSphere 7 o vSphere 8 e come richiesto per Azure VMware Solution. Quando si utilizza vSphere 8, l'opzione preferita consiste nell'abilitare vSphere with Tanzu e utilizzare il supervisore integrato anziché distribuire un cluster di gestione di Tanzu Kubernetes Grid.

   

7. Nel menu a discesa Data center (Datacenter), selezionare il data center in cui distribuire il cluster di gestione.

8. Aggiungere la chiave pubblica SSH. Per aggiungere la chiave pubblica SSH, utilizzare l'opzione Sfoglia file (Browse File) o incollare manualmente i contenuti della chiave nella casella di testo. Fare clic su Avanti (Next).

   

AWS

Configurare la connessione all'account AWS.

1. Nella sezione Provider IaaS (IaaS Provider) selezionare il modo in cui si desidera fornire le credenziali per l'account AWS. Sono disponibili due opzioni:

   • Profilo credenziali (consigliato) (Credential Profile (recommended)): selezionare un profilo di credenziali AWS già esistente. Se si seleziona un profilo, le informazioni della chiave di accesso e del token di sessione configurate per il profilo vengono passate al programma di installazione senza visualizzare i valori effettivi nell'interfaccia utente. Per informazioni sulla configurazione dei profili di credenziali, vedere File e profili di credenziali.

     

   • Credenziali monouso: immettere le credenziali dell'account AWS direttamente nei campi ID chiave di accesso (Access Key ID) e Chiave di accesso segreta (Secret Access Key) per l'account AWS. Facoltativamente, specificare un token della sessione AWS in Token sessione (Session Token) se l'account AWS è configurato in modo da richiedere credenziali temporanee. Per ulteriori informazioni sull'acquisizione dei token di sessione, vedere Utilizzo di credenziali temporanee con le risorse AWS.

     

2. In Regione (Region), selezionare la regione AWS in cui si desidera distribuire il cluster di gestione.

   Se si intende distribuire un cluster di gestione della produzione, questa regione deve disporre di almeno tre zone di disponibilità.

3. Fare clic su Connetti (Connect). Se la connessione riesce, fare clic su Avanti (Next).

4. Nella sezione VPC per AWS (VPC for AWS), selezionare l'ID VPC (VPC ID) dal menu a discesa. Il blocco CIDR VPC (VPC CIDR) viene compilato automaticamente quando si seleziona il VPC. Se si distribuisce il cluster di gestione in un ambiente con limitazioni Internet, ad esempio un ambiente con proxy o air gap, selezionare la casella di controllo Questo non è un VPC connesso a Internet (This is not an internet facing VPC).

   

Azure

Configurare la connessione all'account Microsoft Azure.

Importante

se è la prima volta che si distribuisce un cluster di gestione in Azure con una nuova versione di Tanzu Kubernetes Grid, ad esempio v2.1.1, assicurarsi di aver accettato la licenza dell'immagine di base per tale versione. Per informazioni, vedere Accettazione della licenza dell'immagine di base in Preparazione della distribuzione dei cluster di gestione in Microsoft Azure.

1. Nella sezione Provider IaaS (IaaS Provider) immettere i valori di ID tenant (Tenant ID), ID client (Client ID), Segreto client (Client Secret) e ID sottoscrizione (Subscription ID) per l'account Azure. Questi valori vengono registrati quando si registra un'app di Azure e si crea un segreto per tale app utilizzando il portale di Azure.

   

2. Selezionare Ambiente Azure (Azure Environment), Cloud pubblico (Public Cloud) o Cloud US Government (US Government Cloud). È possibile specificare altri ambienti eseguendo la distribuzione da un file di configurazione e impostando AZURE_ENVIRONMENT.
3. Fare clic su Connetti (Connect). Il programma di installazione verifica la connessione e modifica l'etichetta del pulsante impostandola su Connesso (Connected).
4. Selezionare la regione di Azure in cui si desidera distribuire il cluster di gestione.

5. Incollare nella casella di testo i contenuti della chiave pubblica SSH, ad esempio .ssh/id_rsa.pub.

6. In Gruppo di risorse (Resource Group) selezionare il pulsante di opzione Seleziona gruppo di risorse esistente (Select an existing resource group) o Crea nuovo gruppo di risorse (Create a new resource group).

   • Se si seleziona Seleziona gruppo di risorse esistente (Select an existing resource group), utilizzare il menu a discesa per selezionare il gruppo, quindi fare clic su Avanti (Next).

     

   • Se si seleziona Crea nuovo gruppo di risorse (Create a new resource group), immettere un nome per il nuovo gruppo di risorse e quindi fare clic su Avanti (Next).

     

7. Nella sezione VNet per Azure (VNet for Azure) selezionare il pulsante di opzione Crea nuova VNet in Azure (Create a new VNet on Azure) o Seleziona VNet esistente (Select an existing VNet).

   • Se si seleziona Crea nuova VNet in Azure (Create a new VNet on Azure), utilizzare il menu a discesa per selezionare il gruppo di risorse in cui creare la VNet e specificare quanto segue:

     • Un nome e un blocco CIDR per la VNet. Il valore predefinito è 10.0.0.0/16.
     • Un nome e un blocco CIDR per la subnet del piano di controllo. Il valore predefinito è 10.0.0.0/24.
     • Un nome e un blocco CIDR per la subnet del nodo worker. Il valore predefinito è 10.0.1.0/24.

     

     Dopo aver configurato questi campi, fare clic su Avanti (Next).

   • Se si seleziona Seleziona VNet esistente (Select an existing VNet), utilizzare i menu a discesa per selezionare il gruppo di risorse in cui si trova la VNet, il nome della VNet, le subnet del piano di controllo e del nodo worker, quindi fare clic su Avanti (Next).

     

   • Per rendere il cluster di gestione privato, come descritto in Cluster privati di Azure, abilitare la casella di controllo Cluster privato Azure (Private Azure Cluster).

Configurazione delle impostazioni del cluster di gestione

Alcune delle opzioni per configurare il cluster di gestione dipendono dal provider in uso.

1. Nella sezione Impostazioni cluster di gestione (Management Cluster Settings) selezionare il riquadro Sviluppo (Development) o Produzione (Production).

   • Se si seleziona Sviluppo (Development), il programma di installazione distribuisce un cluster di gestione con un singolo nodo del piano di controllo e un singolo nodo worker.
   • Se si seleziona Produzione (Production), il programma di installazione distribuisce un cluster di gestione ad alta disponibilità con tre nodi del piano di controllo e tre nodi worker.

2. Nel riquadro Sviluppo (Development) o Produzione (Production) utilizzare il menu a discesa Tipo di istanza (Instance Type) per selezionare tra le diverse combinazioni di CPU, RAM e storage per la macchina virtuale o le macchine virtuali del nodo del piano di controllo.

   Scegliere la configurazione per le macchine virtuali del nodo del piano di controllo in base ai carichi di lavoro che si prevede eseguirà. Ad esempio, alcuni carichi di lavoro potrebbero richiedere una notevole capacità di elaborazione ma relativamente poco storage, mentre altri potrebbero richiedere una notevole quantità di storage e meno capacità di elaborazione. Se si seleziona un tipo di istanza nel riquadro Produzione (Production), il tipo di istanza viene selezionato automaticamente per Tipo di istanza nodo worker (Worker Node Instance Type). Se necessario, è possibile modificare questa opzione.

   Se si intende registrare il cluster di gestione in Tanzu Mission Control, assicurarsi che i cluster del carico di lavoro soddisfino i requisiti indicati in Requisiti per la registrazione di un cluster di Tanzu Kubernetes in Tanzu Mission Control nella documentazione di Tanzu Mission Control.

   vSphere

   Selezionare le dimensioni dalle configurazioni predefinite di CPU, memoria e storage. La configurazione minima è 2 CPU e 4 GB di memoria.

   AWS

   Selezionare le dimensioni di un'istanza. Il menu a discesa include le scelte in ordine alfabetico, non in base alle dimensioni. La configurazione minima è 2 CPU e 8 GB di memoria. L'elenco dei tipi di istanze compatibili varia in base alle diverse regioni. Per informazioni sulla configurazione delle diverse dimensioni delle istanze, vedere Tipi di istanze di Amazon EC2.

   Azure

   Selezionare le dimensioni di un'istanza. La configurazione minima è 2 CPU e 8 GB di memoria. L'elenco dei tipi di istanze compatibili varia in base alle diverse regioni. Per informazioni sulle configurazioni delle diverse dimensioni delle istanze dei nodi per Azure, vedere Dimensioni per le macchine virtuali in Azure.

   

3. Facoltativamente, immettere un nome per il cluster di gestione.

   Se non si specifica un nome, Tanzu Kubernetes Grid genera automaticamente un nome univoco. Se si specifica un nome, tale nome deve terminare con una lettera, non con un carattere numerico, e deve essere conforme ai requisiti del nome host DNS in base alla RFC 952 e alla modifica indicata nella RFC 1123.

4. (Facoltativo) Selezionare la casella di controllo Controlli integrità macchine (Machine Health Checks) se si desidera attivare MachineHealthCheck. È possibile attivare o disattivare MachineHealthCheck nei cluster dopo la distribuzione utilizzando la CLI. Per istruzioni, vedere Configurazione dei controlli di integrità delle macchine per i cluster del carico di lavoro.

5. (Facoltativo) Selezionare la casella di controllo Abilita registrazione di controllo (Enable Audit Logging) per registrare le richieste inviate al server dell'API di Kubernetes. Per ulteriori informazioni, vedere Registrazione di controllo.

6. Configura impostazioni aggiuntive specifiche per la piattaforma di destinazione.

   vSphere

   Configurare le impostazioni specifiche per vSphere.

   1. In Tipo di istanza nodo worker (Worker Node Instance Type), selezionare la configurazione per la macchina virtuale del nodo worker.

   2. In Provider endpoint piano di controllo (Control Plane Endpoint Provider) selezionare Kube-Vip o NSX Advanced Load Balancer per scegliere il componente da utilizzare per il server dell'API del piano di controllo.

      Per utilizzare NSX Advanced Load Balancer, è innanzitutto necessario distribuirlo nell'ambiente vSphere. Per informazioni, vedere Installazione di NSX Advanced Load Balancer. Per ulteriori informazioni sui vantaggi dell'utilizzo di NSX Advanced Load Balancer come provider dell'endpoint del piano di controllo, vedere Configurazione di NSX Advanced Load Balancer.

   3. In Endpoint piano di controllo (Control Plane Endpoint), immettere un indirizzo IP virtuale statico o un nome di dominio completo per le richieste API al cluster di gestione. Questa impostazione è obbligatoria se si utilizza Kube-Vip.
      

      Assicurarsi che questo indirizzo IP non sia incluso nell'intervallo DHCP, ma si trovi nella stessa subnet dell'intervallo DHCP. Se un nome di dominio completo è stato mappato all'indirizzo VIP, è possibile specificare il nome di dominio completo anziché l'indirizzo VIP. Per ulteriori informazioni, vedere VIP statici e bilanciamenti del carico per vSphere.

      Se si utilizza NSX Advanced Load Balancer come provider dell'endpoint del piano di controllo, il VIP viene assegnato automaticamente dal pool di IP statici di NSX Advanced Load Balancer.

      

   AWS

   Configurare le impostazioni specifiche per AWS.

   1. In Coppia di chiavi EC2 (EC2 Key Pair), specificare il nome di una coppia di chiavi AWS già registrata nell'account AWS e nella regione in cui si sta distribuendo il cluster di gestione. È possibile che questa configurazione sia stata eseguita in Configurazione delle credenziali dell'account AWS e della chiave SSH.

   2. (Facoltativo) Disattivare la casella di controllo Host Bastion (Bastion Host) se un host Bastion esiste già nelle zone di disponibilità in cui si sta distribuendo il cluster di gestione.

      Se si lascia abilitata questa opzione, Tanzu Kubernetes Grid crea automaticamente un host Bastion.

   3. Se è la prima volta che si distribuisce un cluster di gestione in questo account AWS, selezionare la casella di controllo Crea automaticamente stack AWS CloudFormation (Automate creation of AWS CloudFormation Stack).

      Questo stack CloudFormation crea le risorse di gestione di identità e accessi (IAM) di cui Tanzu Kubernetes Grid necessita per distribuire ed eseguire cluster in AWS. Per ulteriori informazioni, vedere Autorizzazioni impostate da Tanzu Kubernetes Grid in Preparazione della distribuzione dei cluster di gestione in AWS.

   4. Configurare le zone di disponibilità:

      1. Nel menu a discesa Zona di disponibilità 1 (Availability Zone 1) selezionare una zona di disponibilità per il cluster di gestione. Se è stato selezionato il riquadro Sviluppo (Development), è possibile selezionare una sola zona di disponibilità. Vedere l'immagine seguente.

         

      2. Nel menu a discesa Tipo di istanza nodo worker ZD1 (AZ1 Worker Node Instance Type) selezionare la configurazione per la macchina virtuale del nodo worker nell'elenco delle istanze disponibili in questa zona di disponibilità.

      3. Se in precedenza è stato selezionato il riquadro Produzione (Production), utilizzare i menu a discesa Zona di disponibilità 2 (Availability Zone 2), Zona di disponibilità 3 (Availability Zone 3) e Tipo di istanza nodo worker ZD (AZ Worker Node Instance Type) per selezionare tre zone di disponibilità univoche per il cluster di gestione.

         Quando Tanzu Kubernetes Grid distribuisce il cluster di gestione, che include tre nodi del piano di controllo e tre nodi worker, distribuisce i nodi del piano di controllo e i nodi worker in queste zone di disponibilità.

      4. Utilizzare i menu a discesa Subnet pubblica VPC (VPC public subnet) e Subnet privata VPC (VPC private subnet) per selezionare le subnet nel VPC.

         Se si distribuisce un cluster di gestione di produzione, selezionare le subnet per tutte e tre le zone di disponibilità. Se nella sezione precedente è stata selezionata l'opzione Questo non è un VPC connesso a Internet (This is not an internet facing VPC), le subnet pubbliche non sono disponibili. L'immagine seguente mostra il riquadro Sviluppo (Development).

      

   Azure

   In Tipo di istanza nodo worker (Worker Node Instance Type), selezionare la configurazione per la macchina virtuale del nodo worker.

7. Fare clic su Avanti (Next).

Configurazione di VMware NSX Advanced Load Balancer

La configurazione di NSX Advanced Load Balancer si applica solo alle distribuzioni di vSphere.

vSphere

VMware NSX Advanced Load Balancer (ALB) offre una soluzione di bilanciamento del carico L4+L7 per vSphere. NSX ALB include un operatore Kubernetes che si integra con l'API di Kubernetes per gestire il ciclo di vita del bilanciamento del carico e delle risorse in ingresso per i carichi di lavoro. Per utilizzare NSX ALB, è innanzitutto necessario distribuirlo nell'ambiente vSphere. Per informazioni, vedere Installazione di NSX Advanced Load Balancer.

Importante

In vSphere 8, per utilizzare NSX Advanced Load Balancer con un cluster di gestione autonomo TKG e i relativi cluster del carico di lavoro è necessario NSX ALB v22.1.2 o versione successiva e TKG v2.1.1 o versione successiva.

Nella sezione VMware NSX Advanced Load Balancer facoltativa è possibile configurare Tanzu Kubernetes Grid per l'utilizzo di NSX Advanced Load Balancer. Per impostazione predefinita, tutti i cluster del carico di lavoro utilizzeranno il bilanciamento del carico.

1. In Host controller (Controller Host) immettere l'indirizzo IP o il nome di dominio completo della macchina virtuale del controller.
2. Immettere il nome utente e la password impostati per l'host controller quando lo si è distribuito.

3. Incollare i contenuti dell'autorità di certificazione utilizzata per generare il certificato del controller nella casella di testo Autorità di certificazione controller (Controller Certificate Authority) e fare clic su Verifica credenziali (Verify Credentials).

   I contenuti del certificato iniziano con -----BEGIN CERTIFICATE-----.

   Se si dispone di un certificato del controller autofirmato, deve utilizzare un certificato SSL/TLS configurato nell'interfaccia utente del controller Avi > scheda Amministrazione (Administration) > Impostazioni (Settings) > Impostazioni di accesso (Access Settings) in Impostazioni di accesso sistema (System Access Settings) > Certificato SSL (SSL Certificate). È possibile recuperare i contenuti del certificato come indicato in Configurazione del controller Avi: certificato personalizzato.

   

4. Utilizzare il menu a discesa Nome cloud (Cloud Name) per selezionare il cloud creato nella distribuzione di NSX Advanced Load Balancer.

   Ad esempio, Default-Cloud.

5. Nella sezione Cluster del carico di lavoro (Workload Cluster) e Cluster di gestione (Management Cluster), utilizzare il menu a discesa Nome gruppo motori di servizio (Service Engine Group Name) per selezionare un gruppo di motori di servizio.

   Ad esempio, Default-Group.

6. Nel menu a discesa Cluster del carico di lavoro - Nome rete VIP piano dati (Workload Cluster - Data Plane VIP Network Name) selezionare il nome della rete in cui si trova il pool di IP mobili del bilanciamento del carico.

   La stessa rete viene selezionata automaticamente per l'utilizzo da parte del piano dati e del piano di controllo dei cluster del carico di lavoro e dei cluster di gestione. Se necessario, è possibile modificarli.

   La rete VIP per NSX ALB deve essere presente nella stessa istanza di vCenter Server della rete di Kubernetes utilizzata da Tanzu Kubernetes Grid. In questo modo, NSX Advanced Load Balancer può individuare la rete di Kubernetes in vCenter Server, nonché distribuire e configurare i motori di servizio.

   È possibile visualizzare la rete nella vista Infrastruttura > Reti dell'interfaccia di NSX Advanced Load Balancer.

7. Nei menu a discesa Cluster del carico di lavoro - CIDR rete VIP piano dati (Workload Cluster - Data Plane VIP Network CIDR) e Cluster del carico di lavoro - CIDR rete VIP piano di controllo (Workload Cluster - Control Plane VIP Network CIDR), selezionare o immettere il CIDR della subnet da usare per il VIP del bilanciamento del carico, per l'utilizzo da parte del piano dati e del piano di controllo dei cluster del carico di lavoro e dei cluster di gestione.

   Tale CIDR proviene da una delle subnet configurate della rete VIP. È possibile visualizzare il CIDR della subnet per una determinata rete nella vista Infrastruttura > Reti dell'interfaccia di NSX Advanced Load Balancer. Gli stessi CIDR vengono applicati automaticamente nelle impostazioni del cluster di gestione corrispondente. Se necessario, è possibile modificarli.

   

8. (Facoltativo) Immettere una o più etichette di cluster per identificare i cluster in cui abilitare selettivamente NSX ALB o per personalizzare le impostazioni di NSX ALB per gruppi di cluster diversi.

   Per impostazione predefinita, NSX Advanced Load Balancer è abilitato in tutti i cluster del carico di lavoro distribuiti con questo cluster di gestione e i cluster condividono gli stessi controller, cloud, gruppo di motori di servizio e rete VIP di VMware NSX Advanced Load Balancer. Questa impostazione non può essere modificata in un secondo momento.

   Facoltativamente, è possibile abilitare NSX ALB solo in un sottoinsieme di cluster o conservare la possibilità di personalizzare le impostazioni di NSX ALB in un secondo momento per gruppi di cluster diversi. Questo è utile negli scenari seguenti:

   • Si desidera configurare set di cluster del carico di lavoro diversi in gruppi di motori di servizio diversi per implementare l'isolamento o supportare più tipi di servizio bilanciamento del carico rispetto alla capacità di un gruppo di motori di servizio.
   • Si desidera configurare set di cluster del carico di lavoro diversi in cloud diversi perché sono distribuiti in siti separati.

   Per abilitare NSX ALB in modo selettivo anziché globale, aggiungere etichette nel formato key: value. Le etichette definite qui verranno utilizzate per creare un selettore di etichette. Il bilanciamento del carico di lavoro sarà abilitato solo per gli oggetti Cluster del cluster del carico di lavoro con etichette corrispondenti. Di conseguenza, è necessario assicurarsi che l'oggetto Cluster del cluster del carico di lavoro abbia le etichette corrispondenti.

   Ad esempio, se si utilizza team: tkg, per abilitare il bilanciamento del carico in un cluster del carico di lavoro:

   1. Impostare kubectl sul contesto del cluster di gestione.

      kubectl config use-context management-cluster@admin
      

   2. Applicare all'oggetto Cluster del cluster del carico di lavoro corrispondente le etichette definite. Se si definiscono più coppie chiave-valore, è necessario applicarle tutte.

      kubectl label cluster <cluster-name> team=tkg
      

   

9. Fare clic su Avanti (Next) per configurare i metadati.

AWS

Tanzu Kubernetes Grid on AWS crea automaticamente un bilanciamento del carico quando si distribuisce un cluster di gestione.

Azure

Tanzu Kubernetes Grid on Azure crea automaticamente un bilanciamento del carico quando si distribuisce un cluster di gestione.

Configurazione dei metadati

Questa sezione è la stessa per tutte le piattaforme di destinazione.

Nella sezione Metadati (Metadata) facoltativa, è possibile specificare informazioni descrittive su questo cluster di gestione.

Tutti i metadati specificati qui si applicano al cluster di gestione e ai cluster del carico di lavoro che gestisce e possono essere utilizzati mediante lo strumento di gestione del cluster desiderato.

• Posizione: Posizione geografica in cui vengono eseguiti i cluster.
• Descrizione: Descrizione di questo cluster di gestione. La descrizione può includere al massimo 63 caratteri e deve iniziare e terminare con una lettera. Può contenere solo lettere minuscole, numeri e trattini, senza spazi.
• Etichette: coppie chiave/valore per consentire agli utenti di identificare i cluster, ad esempio release : beta, environment : staging o environment : production. Per ulteriori informazioni, vedere Etichette e selettori nella documentazione di Kubernetes.
  È possibile fare clic su Aggiungi (Add) per applicare più etichette ai cluster.

Se si esegue la distribuzione in vSphere, fare clic su Avanti (Next) per passare a Configurazione delle risorse. Se si esegue la distribuzione in AWS o Azure, fare clic su Avanti (Next) per passare a Configurazione della rete e dei proxy di Kubernetes.

Configurazione delle risorse di vSphere

Questa sezione si applica solo alle distribuzioni di vSphere.

vSphere

Nella sezione Risorse (Resources) selezionare le risorse di vSphere che verranno utilizzate dal cluster di gestione.

1. Selezionare la cartella della macchina virtuale in cui posizionare le macchine virtuali del cluster di gestione.
2. Selezionare i datastore di vSphere che verranno utilizzati dal cluster di gestione. Il criterio di storage per le macchine virtuali può essere specificato solo quando si distribuisce il cluster di gestione da un file di configurazione.

3. Selezionare il cluster, l'host o il pool di risorse in cui posizionare il cluster di gestione.

   "Nota" Se le risorse appropriate non esistono già in vSphere, senza chiudere il programma di installazione di Tanzu Kubernetes Grid, passare a vSphere per crearle. Fare quindi clic sul pulsante di aggiornamento in modo che sia possibile selezionare le nuove risorse.

   

4. Fare clic su Avanti (Next) per configurare la rete e i proxy di Kubernetes.

AWS

Questa sezione non si applica alle distribuzioni di AWS.

Azure

Questa sezione non si applica alle distribuzioni di Azure.

Configurazione della rete e dei proxy di Kubernetes

Questa sezione è la stessa per tutte le piattaforme di destinazione, anche se alcune delle informazioni da specificare dipendono dal provider che si sta utilizzando.

1. Nella sezione Rete Kubernetes (Kubernetes Network) configurare la rete per i servizi di Kubernetes e fare clic su Avanti (Next).

   • (Solo vSphere) In Nome rete (Network Name) selezionare una rete di vSphere da utilizzare come rete del servizio Kubernetes.
   • Controllare gli intervalli CIDR servizio cluster (Cluster Service CIDR) e CIDR pod cluster (Cluster Pod CIDR). Se gli intervalli CIDR consigliati 100.64.0.0/13 e 100.96.0.0/11 non sono disponibili, aggiornare i valori in CIDR servizio cluster (Cluster Service CIDR) e CIDR pod cluster (Cluster Pod CIDR).

   

2. (Facoltativo) Per inviare il traffico HTTP(S) in uscita dal cluster di gestione a un proxy, ad esempio in un ambiente con limitazioni Internet, attivare Abilita impostazioni proxy (Enable Proxy Settings) e seguire le istruzioni seguenti per immettere le informazioni del proxy. Tanzu Kubernetes Grid applica queste impostazioni a kubelet, container e piano di controllo.

   È possibile scegliere di utilizzare un proxy per il traffico HTTP e un altro proxy per il traffico HTTPS oppure utilizzare lo stesso proxy per il traffico HTTP e HTTPS.

   Importante Non è possibile modificare il proxy dopo aver distribuito il cluster.

   1. Per aggiungere le informazioni del proxy HTTP:

      1. In URL proxy HTTP (HTTP Proxy URL) immettere l'URL del proxy che gestisce le richieste HTTP. L'URL deve iniziare con http://. Ad esempio, http://myproxy.com:1234.

      2. Se il proxy richiede l'autenticazione, in Nome utente proxy HTTP (HTTP Proxy Username) e Password proxy HTTP (HTTP Proxy Password) immettere il nome utente e la password da utilizzare per connettersi al proxy HTTP.

         Nota

         Nelle password non è possibile utilizzare caratteri non alfanumerici quando si distribuiscono cluster di gestione con l'interfaccia del programma di installazione.

   2. Per aggiungere le informazioni del proxy HTTPS:

      • Se si desidera utilizzare lo stesso URL per il traffico HTTP e HTTPS, selezionare Usa la stessa configurazione per il proxy https (Use the same configuration for https proxy).

      • Se si desidera utilizzare un URL diverso per il traffico HTTPS, eseguire i passaggi seguenti:

        1. In URL proxy HTTPS (HTTPS Proxy URL) immettere l'URL del proxy che gestisce le richieste HTTPS. L'URL deve iniziare con http://. Ad esempio, http://myproxy.com:1234.

        2. Se il proxy richiede l'autenticazione, in Nome utente proxy HTTPS (HTTPS Proxy Username) e Password proxy HTTPS (HTTPS Proxy Password) immettere il nome utente e la password da utilizzare per connettersi al proxy HTTPS.

           Nota

           Nelle password non è possibile utilizzare caratteri non alfanumerici quando si distribuiscono cluster di gestione con l'interfaccia del programma di installazione.

   3. In Nessun proxy (No proxy) immettere un elenco di CIDR o nomi host di rete separati da virgola che devono ignorare il proxy HTTP(S). Se il cluster di gestione viene eseguito nella stessa rete dell'infrastruttura, dietro lo stesso proxy, impostare questa opzione sui CIDR o sui nomi di dominio completi dell'infrastruttura in modo che il cluster di gestione comunichi direttamente con l'infrastruttura.

      Ad esempio, noproxy.yourdomain.com,192.168.0.0/24.

      vSphere

      L'elenco Nessun proxy (No proxy) deve includere quanto segue:

      • Indirizzo IP o nome host per vCenter. Non è possibile utilizzare un proxy per il traffico verso vCenter.
      • CIDR della rete di vSphere selezionata in Nome rete (Network Name). Il CIDR della rete di vSphere include l'indirizzo IP di Endpoint piano di controllo (Control Plane Endpoint). Se in Endpoint piano di controllo (Control Plane Endpoint) è stato immesso un nome di dominio completo, aggiungere sia il nome di dominio completo sia il CIDR della rete di vSphere in Nessun proxy (No proxy). Internamente, Tanzu Kubernetes Grid aggiunge localhost, 127.0.0.1, i valori di CIDR pod cluster (Cluster Pod CIDR) e CIDR servizio cluster (Cluster Service CIDR), nonché .svc e .svc.cluster.local all'elenco immesso in questo campo.

      AWS

      Internamente, Tanzu Kubernetes Grid aggiunge localhost, 127.0.0.1, il CIDR di VPC, CIDR pod cluster (Cluster Pod CIDR) e CIDR servizio cluster (Cluster Service CIDR), nonché .svc, .svc.cluster.local e 169.254.0.0/16 all'elenco immesso in questo campo.

      Azure

      Internamente, Tanzu Kubernetes Grid aggiunge localhost, 127.0.0.1, il CIDR di VNet, CIDR pod cluster (Cluster Pod CIDR) e CIDR servizio cluster (Cluster Service CIDR), nonché .svc, .svc.cluster.local, 169.254.0.0/16 e 168.63.129.16 all'elenco immesso in questo campo.

      Importante

      Se le macchine virtuali del cluster di gestione devono comunicare con i servizi esterni e gli endpoint dell'infrastruttura nell'ambiente di Tanzu Kubernetes Grid, assicurarsi che tali endpoint siano raggiungibili dai proxy configurati in precedenza o aggiungerli in Nessun proxy (No proxy). In base alla configurazione dell'ambiente, possono essere inclusi ad esempio il server OIDC o LDAP, Harbor e nel caso di vSphere, VMware NSX e NSX Advanced Load Balancer.

Configurazione della gestione delle identità

Questa sezione è la stessa per tutte le piattaforme di destinazione. Per informazioni su come Tanzu Kubernetes Grid implementa la gestione delle identità, vedere Informazioni sulla gestione di identità e accessi.

1. Nella sezione Gestione identità (Identity Management) selezionare facoltativamente Attiva impostazioni gestione identità (Activate Identity Management Settings).

   

   È possibile disattivare la gestione delle identità per le distribuzioni di prova, ma è consigliabile implementarla nelle distribuzioni di produzione. Se si disattiva la gestione delle identità, è possibile attivarla di nuovo in un secondo momento. Per istruzioni su come riabilitare la gestione delle identità, vedere Abilitazione e configurazione della gestione delle identità in una distribuzione esistente in Configurazione della gestione delle identità.

2. Se si abilita la gestione delle identità, selezionare OIDC o LDAPS.

   Selezionare la scheda OIDC o LDAPS di seguito per visualizzare le informazioni di configurazione.

   OIDC

   Specificare i dettagli dell'account del provider OIDC, ad esempio Okta.

   • URL emittente (Issuer URL): Indirizzo IP o DNS del server OIDC.
   • ID client (Client ID): valore di client_id ottenuto dal provider OIDC. Ad esempio, se il provider è Okta, accedere a Okta, creare un'applicazione Web e selezionare le opzioni di Credenziali client (Client Credentials) per ottenere client_id e secret.
   • Segreto client (Client Secret): valore di secret ottenuto dal provider OIDC.
   • Ambiti (Scopes): Elenco delimitato da virgole degli ambiti aggiuntivi da richiedere nella risposta del token. Ad esempio, openid,groups,email.
   • Richiesta nome utente (Username Claim): Nome della richiesta del nome utente. Questa opzione viene utilizzata per impostare il nome utente di un utente nella richiesta JSON Web Token (JWT). In base al provider in uso, immettere richieste come user_name, email o code.
   • Richiesta gruppi (Groups Claim): nome della richiesta di gruppi. Questa opzione viene utilizzata per impostare il gruppo di un utente nella richiesta JWT. Ad esempio, groups.

   

   LDAPS

   Specificare i dettagli del server LDAPS della propria azienda. Tutte le impostazioni ad eccezione di Endpoint LDAPS (LDAPS Endpoint) sono facoltative.

   • Endpoint LDAPS (LDAPS Endpoint): indirizzo IP o DNS del server LDAPS. Specificare l'indirizzo e la porta del server LDAP, nel formato host:port.
   • Nome distinto di binding (Bind DN): DN per l'account di servizio di un'applicazione. Il connettore utilizza queste credenziali per cercare utenti e gruppi. Questa variabile non è obbligatoria se il server LDAP fornisce l'accesso per l'autenticazione anonima.
   • Password di binding (Bind Password): password di un account di servizio dell'applicazione, se è impostata l'opzione Nome distinto di binding (Bind DN).

   Specificare gli attributi di ricerca utente.

   • Nome distinto di base (Base DN): Punto da cui avviare la ricerca LDAP. Ad esempio, OU=Users,OU=domain,DC=io.
   • Filtro (Filter): filtro facoltativo che deve essere utilizzato dalla ricerca LDAP.
   • Nome utente (Username): Attributo LDAP che contiene l'ID utente. Ad esempio, uid, sAMAccountName.

   Specificare gli attributi di ricerca gruppo.

   • Nome distinto di base (Base DN): Punto da cui avviare la ricerca LDAP. Ad esempio, OU=Groups,OU=domain,DC=io.
   • Filtro (Filter): filtro facoltativo che deve essere utilizzato dalla ricerca LDAP.
   • Attributo nome (Name Attribute): Attributo LDAP che contiene il nome del gruppo. Ad esempio, cn.
   • Attributo utente (User Attribute): Attributo del record utente utilizzato come valore dell'attributo di appartenenza del record gruppo. Ad esempio, distinguishedName, dn.
   • Attributo gruppo (Group Attribute): Attributo del record gruppo che contiene le informazioni dell'utente o del membro. Ad esempio, member.

   Incollare i contenuti del certificato CA del server LDAPS nella casella di testo CA root (Root CA).

   

   (Facoltativo) Verificare le impostazioni LDAP.

   1. Fare clic sull'opzione Verifica configurazione LDAP (Verify LDAP Configuration).

   2. Immettere un nome utente e un nome per il gruppo.

      Nota

      In Tanzu Kubernetes Grid v1.4.x e versioni successive, questi campi vengono ignorati e vengono ripristinati cn per il nome utente e ou per il nome del gruppo. Per gli aggiornamenti relativi a questo problema noto, vedere le Note di rilascio di VMware Tanzu Kubernetes Grid 1.5.

   3. Fare clic su Avvia (Start).

      Dopo aver completato la verifica, se vengono visualizzati altri errori, è necessario esaminarli attentamente nei passaggi successivi.

      Nota

      Questo controllo viene eseguito dall'host LDAP, non dai nodi del cluster di gestione. La configurazione LDAP potrebbe quindi funzionare anche se la verifica non riesce.

3. Fare clic su Avanti (Next) per passare a Selezione dell'immagine del sistema operativo di base.

Selezione dell'immagine del sistema operativo di base

Nella sezione Immagine sistema operativo (OS Image) utilizzare il menu a discesa per selezionare il modello di immagine del sistema operativo e della versione di Kubernetes da utilizzare per la distribuzione delle macchine virtuali di Tanzu Kubernetes Grid, quindi fare clic su Avanti (Next).

Come vengono generate le scelte dell'immagine del sistema operativo di base

Il menu a discesa Immagine sistema operativo (OS Image) include immagini del sistema operativo che soddisfano tutti i criteri seguenti:

• L'immagine è disponibile in IaaS.
  • In vSphere, è necessario importare le immagini come descritto in Importazione del modello dell'immagine di base in vSphere. È possibile importare un'immagine ora, senza chiudere l'interfaccia del programma di installazione. Dopo averla importata, utilizzare il pulsante Aggiorna (Refresh) per fare in modo che venga visualizzata nel menu a discesa.
  • In Azure è necessario accettare la licenza come descritto in Accettazione della licenza dell'immagine di base in Preparazione della distribuzione dei cluster di gestione in Microsoft Azure.
• L'immagine del sistema operativo è elencata nel file BoM (Bill of Materials) della versione di Tanzu Kubernetes (TKr) per la versione di Kubernetes in cui viene eseguito il cluster di gestione.
  • I cluster di gestione di Tanzu Kubernetes Grid v2.1.1 vengono eseguiti in Kubernetes v1.24.10.
  • Per utilizzare un'immagine personalizzata, modificare il file BoM di TKr in modo da elencare l'immagine, come indicato in Creazione di immagini di macchine.
  • Le immagini di vSphere, AWS e Azure sono elencate rispettivamente nei blocchi ova, ami e azure di BoM.
• Il nome dell'immagine in IaaS corrisponde al relativo identificatore nel file BoM di TKr:
  • Le immagini di vSphere, AWS e Azure sono identificate rispettivamente dai valori dei loro campi version, id e sku.

Finalizzazione della distribuzione

Questa sezione è la stessa per tutte le piattaforme di destinazione.

1. Nella sezione Partecipazione al programma CEIP deselezionare facoltativamente la casella di controllo per rifiutare la partecipazione al programma Customer Experience Improvement Program di VMware e fare clic su Avanti.

   È possibile scegliere o rifiutare esplicitamente il programma anche dopo la distribuzione del cluster di gestione. Per informazioni sul programma CEIP, vedere Gestione della partecipazione al programma CEIP e https://www.vmware.com/solutions/trustvmware/ceip.html.

2. Fare clic su Rivedi configurazione (Review Configuration) per visualizzare i dettagli del cluster di gestione configurato. Se si desidera tornare all'installazione guidata per modificare la configurazione, fare clic su Modifica configurazione (Edit Configuration).

   Quando si fa clic su Rivedi configurazione (Review Configuration), il programma di installazione popola il file di configurazione del cluster, che si trova nella sottodirectory ~/.config/tanzu/tkg/clusterconfigs, con le impostazioni specificate nell'interfaccia. Facoltativamente, è possibile esportare una copia di questo file di configurazione facendo clic su Esporta configurazione (Export Configuration).

3. Fare clic su Distribuisci cluster di gestione (Deploy Management Cluster).

   La distribuzione del cluster di gestione può richiedere diversi minuti. La prima esecuzione di tanzu mc create richiede più tempo delle esecuzioni successive perché deve estrarre le immagini del Docker necessarie nell'archivio immagini della macchina di bootstrap. Poiché le esecuzioni successive non richiedono questo passaggio, sono più rapide. È possibile seguire l'avanzamento della distribuzione del cluster di gestione nell'interfaccia del programma di installazione o nel terminale in cui è stato eseguito tanzu mc create --ui. Se la macchina in cui si esegue tanzu mc create viene arrestata o riavviata prima del completamento delle operazioni locali, la distribuzione non riesce. Se prima del completamento si chiude inavvertitamente il browser o la scheda del browser in cui la distribuzione è in esecuzione, la distribuzione continua nel terminale.

   

4. (Facoltativo) In Equivalente al comando CLI (CLI Command Equivalent) fare clic sul pulsante Copia (Copy) per copiare il comando della CLI per la configurazione specificata. Questo comando della CLI include il percorso del file di configurazione popolato dal programma di installazione.

5. (Solo vSphere) Dopo aver distribuito un cluster di gestione in vSphere, è necessario configurare gli indirizzi IP dei nodi del piano di controllo in modo che siano statici, come descritto in Configurazione delle prenotazioni DHCP per il piano di controllo (solo vSphere).

Passaggi successivi

• Salvare il file di configurazione: il programma di installazione salva la configurazione del cluster di gestione in ~/.config/tanzu/tkg/clusterconfigs generando un nome di file nel formato UNIQUE-ID.yaml. Questo file di configurazione ha una struttura semplice che imposta variabili con lettere maiuscole e caratteri di sottolineatura come CLUSTER_NAME. Al termine della distribuzione, è possibile rinominare il file di configurazione utilizzando un nome facile da ricordare e salvarlo in una posizione diversa per un utilizzo futuro. Il programma di installazione genera inoltre una specifica di oggetto basato sulla classe di tipo Kubernetes per l'oggetto Cluster del cluster di gestione, che viene salvato in un file con lo stesso nome del cluster di gestione. Questa specifica dell'oggetto basato sulla classe viene fornita solo a scopo informativo. La distribuzione di cluster di gestione dalla specifica di un oggetto basato sulla classe non è ancora supportata. Per ulteriori informazioni sui tipi di cluster in TKG 2.x, vedere Cluster del carico di lavoro in Informazioni su Tanzu Kubernetes Grid.
• Configurare la gestione delle identità: se è stata abilitata la gestione delle identità OIDC o LDAP per il cluster di gestione, è necessario eseguire i passaggi successivi alla distribuzione descritti in Completamento della configurazione della gestione delle identità per abilitare l'accesso.
• Registrare il cluster di gestione in Tanzu Mission Control: se si desidera registrare il cluster di gestione in Tanzu Mission Control, vedere Registrazione del cluster di gestione in Tanzu Mission Control.
• Distribuire i cluster del carico di lavoro: Una volta creato il cluster di gestione, è possibile distribuire cluster del carico di lavoro come descritto in Creazione di cluster del carico di lavoro in Creazione e gestione di cluster del carico di lavoro TKG 2.1 con la CLI di Tanzu.
• Distribuire un altro cluster di gestione: per distribuire più cluster di gestione, in una o in tutte le istanze di vSphere, Azure e AWS, vedere Gestione dei cluster di gestione. In questo argomento vengono inoltre fornite informazioni su come aggiungere cluster di gestione esistenti all'istanza della CLI, ottenere credenziali, scalare ed eliminare cluster di gestione, aggiungere spazi dei nomi, nonché accettare o rifiutare esplicitamente il programma CEIP.

Per informazioni su ciò che si è verificato durante la distribuzione del cluster di gestione e su come connettere kubectl al cluster di gestione, vedere Controllo e registrazione di un cluster di gestione autonomo appena distribuito.