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.
ImportanteTanzu Kubernetes Grid v2.4.x è l'ultima versione di TKG che supporta la creazione di cluster di gestione TKG autonomi in AWS e Azure. La possibilità di creare cluster di gestione TKG autonomi in AWS e Azure verrà rimossa nella versione Tanzu Kubernetes Grid v2.5.
A partire da ora, VMware consiglia di utilizzare Tanzu Mission Control per creare cluster AWS EKS e Azure AKS nativi anziché creare nuovi cluster di gestione TKG autonomi o nuovi cluster del carico di lavoro TKG in AWS e Azure. Per informazioni su come creare cluster AWS EKS e Azure AKS nativi con Tanzu Mission Control, vedere Gestione del ciclo di vita dei cluster AWS EKS e Gestione del ciclo di vita dei cluster Azure AKS nella documentazione di Tanzu Mission Control.
Per ulteriori informazioni, vedere Deprecazione dei cluster di gestione e del carico di lavoro TKG in AWS e Azure nelle Note di rilascio di VMware Tanzu Kubernetes Grid v2.4.
Prima di poter distribuire un cluster di gestione, è necessario assicurarsi che l'ambiente soddisfi i requisiti per la piattaforma di destinazione.
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.
Ogni piattaforma di destinazione ha prerequisiti aggiuntivi per la distribuzione del cluster di gestione.
NotaIn vSphere with Tanzu in vSphere 8, non è necessario distribuire un cluster di gestione. Vedere Il supervisore vSphere with Tanzu è un cluster di gestione.
t3.large
o t3.xlarge
, vedere Tipi di istanze di Amazon EC2.Standard_D2s_v3
o Standard_D4s_v3
, vedere Dimensioni delle macchine virtuali in Azure.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
.
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.
Attenzioneil completamento del comando
tanzu mc create
richiede tempo. Mentretanzu mc create
è in esecuzione, non eseguire ulteriori chiamate ditanzu 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.
Fare clic sul pulsante Distribuisci (Deploy) per VMware vSphere, Amazon EC2 o Microsoft Azure.
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.
chrome
, firefox
, safari
, ie
, edge
o none
.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.
AttenzioneL'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:
http://127.0.0.1:8080
, utilizzare --bind
per eseguire l'interfaccia da un'altra porta locale.--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:
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
Nella macchina dell'interfaccia utente locale, passare all'indirizzo IP della macchina remota per accedere all'interfaccia del programma di installazione.
Le opzioni per configurare la piattaforma di destinazione dipendono dal provider utilizzato.
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.
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]
.
(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.
Fare clic su Connetti (Connect).
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.
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.3 con la CLI di Tanzu.
Se vSphere with Tanzu è abilitato, l'interfaccia del programma di installazione indica che è possibile utilizzare il servizio TKG come modalità preferita di esecuzione dei carichi di lavoro Kubernetes. In questo caso non è necessario un cluster di gestione autonomo. Offre 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 di TKG (Deploy TKG Management Cluster) consente di continuare a distribuire un cluster di gestione autonomo per vSphere 7 o vSphere 8 e come richiesto per Azure VMware Solution.
Nel menu a discesa Data center (Datacenter), selezionare il data center in cui distribuire il cluster di gestione.
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).
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.
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à.
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).
Importantese è la prima volta che si distribuisce un cluster di gestione in Azure con una nuova versione di Tanzu Kubernetes Grid, ad esempio v2.3, 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.
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.
AZURE_ENVIRONMENT
.Incollare nella casella di testo i contenuti della chiave pubblica SSH, ad esempio .ssh/id_rsa.pub
.
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).
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:
10.0.0.0/16
.10.0.0.0/24
.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).
Alcune delle opzioni per configurare il cluster di gestione dipendono dal provider in uso.
Nella sezione Impostazioni cluster di gestione (Management Cluster Settings) selezionare il riquadro Sviluppo (Development) o Produzione (Production).
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.
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.
(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.
(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.
Configura impostazioni aggiuntive specifiche per la piattaforma di destinazione.
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.
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.
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.
(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.
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.
Configurare le zone di disponibilità:
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.
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à.
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à.
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).
Fare clic su Avanti (Next).
La configurazione di NSX Advanced Load Balancer si applica solo alle distribuzioni di vSphere.
ImportanteIn 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.
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.
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
.
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
.
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.
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.
(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:
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:
Impostare kubectl
sul contesto del cluster di gestione.
kubectl config use-context management-cluster@admin
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
Fare clic su Avanti (Next) per configurare i 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.
release : beta
, environment : staging
o environment : production
. Per ulteriori informazioni, vedere Etichette e selettori nella documentazione di Kubernetes.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.
Questa sezione si applica solo alle distribuzioni di vSphere.
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.
In Specifica delle zone di disponibilità scegliere dove posizionare i nodi del cluster di gestione, quindi compilare le specifiche:
Nessuna ZD: Per posizionare i nodi in base al cluster, all'host o al pool di risorse, selezionare il cluster, l'host o il pool di risorse in cui posizionare i nodi.
ZD basate su cluster: Per distribuire i nodi in più cluster di elaborazione in un data center, specificare le zone di disponibilità in uno dei modi seguenti:
ZD basate su un gruppo di host: Per distribuire i nodi in più host in un singolo cluster di elaborazione, specificare le ZD in uno dei modi seguenti:
NotaSe 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.
Questa sezione è la stessa per tutte le piattaforme di destinazione, anche se alcune delle informazioni da specificare dipendono dal provider che si sta utilizzando.
Nella sezione Rete Kubernetes (Kubernetes Network) configurare la rete per i servizi di Kubernetes e fare clic su Avanti (Next).
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).(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.
ImportanteNon è possibile modificare il proxy dopo aver distribuito il cluster.
Per aggiungere le informazioni del proxy HTTP:
http://
. Ad esempio, http://myproxy.com:1234
.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.
NotaNelle password non è possibile utilizzare caratteri non alfanumerici quando si distribuiscono cluster di gestione con l'interfaccia del programma di installazione.
Per aggiungere le informazioni del proxy HTTPS:
Se si desidera utilizzare un URL diverso per il traffico HTTPS, eseguire i passaggi seguenti:
http://
. Ad esempio, http://myproxy.com:1234
.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.
NotaNelle password non è possibile utilizzare caratteri non alfanumerici quando si distribuiscono cluster di gestione con l'interfaccia del programma di installazione.
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
.
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.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.
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.
ImportanteSe 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.
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.
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à.
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.
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
.secret
ottenuto dal provider OIDC.openid,groups,email
.user_name
, email
o code
.groups
.host:port
.Specificare gli attributi di ricerca utente.
OU=Users,OU=domain,DC=io
.uid, sAMAccountName
.Specificare gli attributi di ricerca gruppo.
OU=Groups,OU=domain,DC=io
.cn
.distinguishedName, dn
.member
.Incollare i contenuti del certificato CA del server LDAPS nella casella di testo CA root (Root CA).
(Facoltativo) Verificare le impostazioni LDAP.
Immettere un nome utente e un nome per il gruppo.
NotaIn Tanzu Kubernetes Grid v1.4.x e versioni successive, questi campi vengono ignorati e vengono ripristinati
cn
per il nome utente eou
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.
Fare clic su Avvia (Start).
Dopo aver completato la verifica, se vengono visualizzati altri errori, è necessario esaminarli attentamente nei passaggi successivi.
NotaQuesto 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.
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).
Il menu a discesa Immagine sistema operativo (OS Image) include immagini del sistema operativo che soddisfano tutti i criteri seguenti:
ova
, ami
e azure
di BoM.version
, id
e sku
.Questa sezione è la stessa per tutte le piattaforme di destinazione.
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.
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).
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.
(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.
(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).
~/.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.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.