This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

Distribuzione di cluster di gestione da un file di configurazione

È possibile utilizzare la CLI di Tanzu per distribuire un cluster di gestione in vSphere, Amazon Web Services (AWS) e Microsoft Azure con una configurazione specificata in un file di configurazione YAML.

Prerequisiti

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

Prerequisiti generali

Prerequisiti dell'infrastruttura

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

In vSphere with Tanzu, 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 su quando creare un Virtual Private Cloud (VPC) e su quando invece riutilizzare un VPC esistente, vedere Utilizzo delle risorse nell'account Amazon Web Services.
  • Se è la prima volta che si distribuisce un cluster di gestione in AWS, creare uno stack CloudFormation per Tanzu Kubernetes Grid nell'account AWS seguendo le istruzioni disponibili in Creazione di risorse IAM di seguito.

Creazione di risorse IAM

Prima di distribuire un cluster di gestione in AWS per la prima volta, è necessario creare uno stack CloudFormation per Tanzu Kubernetes Grid, tkg-cloud-vmware-com, nell'account AWS. Questo stack CloudFormation include le risorse di gestione di identità e accessi (IAM) di cui Tanzu Kubernetes Grid necessita per creare 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.

  1. Se lo stack CloudFormation per Tanzu Kubernetes Grid è già stato creato nell'account AWS, ignorare il resto di questa procedura.

  2. Se lo stack CloudFormation per Tanzu Kubernetes Grid non è ancora stato creato nell'account AWS, assicurarsi che le variabili di autenticazione di AWS siano impostate nell'ambiente locale o nella catena di provider di credenziali predefinita di AWS. Per istruzioni, vedere Configurazione delle credenziali dell'account AWS e della chiave SSH.

    Se le credenziali di AWS sono state configurate in più posizioni, le impostazioni delle credenziali utilizzate per creare lo stack CloudFormation vengono applicate nell'ordine di priorità seguente:

    • Le credenziali impostate nelle variabili di ambiente locali AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN e AWS_REGION vengono applicate per prime.

    • Credenziali archiviate in un file di credenziali condivise come parte della catena di provider di credenziali predefinita. È possibile specificare la posizione del file delle credenziali da utilizzare nella variabile di ambiente locale AWS_SHARED_CREDENTIAL_FILE. Se questa variabile di ambiente non è definita, viene utilizzata la posizione predefinita $HOME/.aws/credentials. Se si utilizzano profili delle credenziali, il comando utilizza il nome del profilo specificato nella variabile di configurazione dell'ambiente locale AWS_PROFILE. Se non si specifica un valore per questa variabile, viene utilizzato il profilo denominato default.

      Per un esempio di come viene interpretata la catena di provider di credenziali di AWS predefinita per le app Java, vedere Uso delle credenziali di AWS nella documentazione di AWS.

  3. Eseguire il comando seguente:

    tanzu mc permissions aws set

    Per ulteriori informazioni su questo comando, eseguire tanzu mc permissions aws set --help.

Importante

il comando tanzu mc permissions aws set sostituisce l'utilità della riga di comando clusterawsadm che esisteva in Tanzu Kubernetes Grid v1.1.x e versioni precedenti. Per i cluster di gestione e i cluster del carico di lavoro esistenti distribuiti inizialmente con v1.1.x o versioni precedenti, continuare a utilizzare lo stack CloudFormation creato eseguendo il comando clusterawsadm alpha bootstrap create-stack. Per un cluster con Tanzu Kubernetes Grid v1.2 o versioni successive, utilizzare lo stack tkg-cloud-vmware-com.

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.


Creazione del file di configurazione del cluster

Prima di creare un cluster di gestione utilizzando la CLI di Tanzu, è necessario definirne la configurazione in un file di configurazione YAML che fornisca la configurazione di base per il cluster. Quando si distribuisce il cluster di gestione dalla CLI, specificare questo file utilizzando l'opzione --file del comando tanzu mc create.

Quando si esegue il comando tanzu config init per la prima volta, viene creata la sottodirectory ~/.config/tanzu/tkg contenente i file di configurazione di Tanzu Kubernetes Grid.

Se in precedenza è stato distribuito un cluster di gestione eseguendo tanzu mc create --ui, la directory ~/.config/tanzu/tkg/clusterconfigs contiene i file di configurazione del cluster di gestione con le impostazioni salvate da ogni chiamata dell'interfaccia del programma di installazione. In base all'infrastruttura in cui viene distribuito il cluster di gestione, è possibile utilizzare questi file come modelli per i file di configurazione del cluster per le nuove distribuzioni nella stessa infrastruttura. In alternativa, è possibile creare file di configurazione del cluster di gestione utilizzando i modelli disponibili in questa documentazione.

VMware consiglia di utilizzare un file di configurazione dedicato per ogni cluster di gestione, con le impostazioni di configurazione specifiche per una singola infrastruttura.

Creazione di un file di configurazione del cluster di gestione

Creare un file di configurazione del cluster di gestione autonomo utilizzando le istruzioni e i modelli seguenti.

Per informazioni dettagliate su ciascuna variabile, vedere Informazioni di riferimento sulle variabili del file di configurazione.

Importante

- Come descritto in Configurazione del cluster di gestione, le variabili di ambiente sostituiscono i valori di un file di configurazione del cluster. Per utilizzare tutte le impostazioni di un file di configurazione del cluster, annullare l'impostazione di eventuali variabili di ambiente in conflitto prima di distribuire il cluster di gestione dalla CLI. - Il supporto per gli indirizzi IPv6 in Tanzu Kubernetes Grid è limitato; vedere Distribuzione dei cluster in IPv6 (solo vSphere). Se non si esegue la distribuzione in un ambiente di rete solo IPv6, tutte le impostazioni degli indirizzi IP nei file di configurazione devono essere IPv4. - Alcuni parametri configurano proprietà identiche. Ad esempio, la proprietà SIZE configura le stesse impostazioni dell'infrastruttura di tutte le proprietà relative a tipo e dimensioni del piano di controllo e del nodo worker per le diverse piattaforme di destinazione, ma a un livello più generale. In questi casi, evitare di impostare proprietà in conflitto o ridondanti.

Per creare un file di configurazione per la distribuzione di un cluster di gestione autonomo:

  1. Copiare e incollare i contenuti del modello per la piattaforma di destinazione in un editor di testo.

    Copiare un modello da una delle posizioni seguenti:

    Ad esempio, se è già stato distribuito un cluster di gestione dall'interfaccia del programma di installazione, è possibile salvare il file nella posizione predefinita per le configurazioni del cluster, ovvero ~/.config/tanzu/tkg/clusterconfigs.

  2. Salvare il file con un'estensione .yaml e un nome appropriato, ad esempio aws-mgmt-cluster-config.yaml.

Le sezioni successive descrivono come aggiornare le impostazioni comuni a tutte le piattaforme di destinazione, nonché le impostazioni specifiche di vSphere, AWS e Azure.

Informazioni sulla configurazione della creazione del cluster di gestione di base

Le impostazioni di creazione del cluster di gestione di base definiscono l'infrastruttura in cui distribuire il cluster di gestione e altre impostazioni di base. Sono comuni a tutte le piattaforme di destinazione.

  • In CLUSTER_PLAN specificare se si desidera distribuire un cluster di sviluppo, che include un singolo nodo del piano di controllo o un cluster di produzione, che fornisce un cluster di gestione ad alta disponibilità con tre nodi del piano di controllo. Specificare dev o prod.

  • In INFRASTRUCTURE_PROVIDER specificare aws, azure o vsphere.

    INFRASTRUCTURE_PROVIDER: aws

    INFRASTRUCTURE_PROVIDER: azure

    INFRASTRUCTURE_PROVIDER: vsphere

  • Facoltativamente, disattivare Customer Experience Improvement Program (CEIP) di VMware impostando ENABLE_CEIP_PARTICIPATION su false. Per informazioni sul programma CEIP, vedere Gestione della partecipazione al programma CEIP e https://www.vmware.com/solutions/trustvmware/ceip.html.

  • Facoltativamente, disattivare la registrazione di controllo impostando ENABLE_AUDIT_LOGGING su false. Per informazioni sulla registrazione di controllo, vedere Registrazione di controllo.
  • Se gli intervalli CIDR consigliati 100.64.0.0/13 e 100.96.0.0/11 non sono disponibili, aggiornare CLUSTER_CIDR per la rete di pod del cluster e SERVICE_CIDR per la rete del servizio del cluster.

Ad esempio:

#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------

CLUSTER_NAME: aws-mgmt-cluster
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13

Configurazione della gestione delle identità

Impostare IDENTITY_MANAGEMENT_TYPE su ldap o oidc. Impostare su none oppure omettere il valore per disattivare la gestione delle identità. È consigliabile abilitare la gestione delle identità per le distribuzioni di produzione.

IDENTITY_MANAGEMENT_TYPE: oidc

IDENTITY_MANAGEMENT_TYPE: ldap

OIDC

Per configurare OIDC, aggiornare le variabili seguenti. Per informazioni su come configurare le variabili, vedere Provider di identità - OIDC in Informazioni di riferimento sulle variabili del file di configurazione.

Ad esempio:

OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

LDAP

Per configurare LDAP, rimuovere il commento dalle variabili LDAP_* e aggiornarle con le informazioni relative al server LDAPS. Per informazioni su come configurare le variabili, vedere Provider di identità - LDAP in Informazioni di riferimento sulle variabili del file di configurazione.

Ad esempio:

LDAP_BIND_DN: ""
LDAP_BIND_PASSWORD: ""
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: memberUid
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: (objectClass=posixAccount)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
LDAP_USER_SEARCH_USERNAME: uid

Configurazione dei proxy

Facoltativamente, per inviare traffico HTTP(S) in uscita dal cluster di gestione a un proxy, ad esempio in un ambiente con limitazioni Internet, rimuovere il commento e specificare le impostazioni di *_PROXY. Le impostazioni del proxy sono comuni a tutte le piattaforme di destinazione. È possibile scegliere di utilizzare un proxy per le richieste HTTP e un altro proxy per le richieste HTTPS oppure utilizzare lo stesso proxy per le richieste HTTP e HTTPS. Non è possibile modificare il proxy dopo aver distribuito il cluster.

Nota

In vSphere, non è possibile utilizzare un proxy per il traffico dalle macchine virtuali del cluster a vCenter. In un ambiente vSphere con proxy, è necessario impostare VSPHERE_INSECURE su true oppure aggiungere l'indirizzo IP o il nome host di vCenter nell'elenco TKG_NO_PROXY.

  • TKG_HTTP_PROXY_ENABLED: impostare questo campo su true per configurare un proxy.

  • TKG_PROXY_CA_CERT: impostare questo campo sull'autorità di certificazione del server proxy se il certificato è autofirmato.

  • TKG_HTTP_PROXY: questo è l'URL del proxy che gestisce le richieste HTTP. Per impostare l'URL, utilizzare il formato seguente:

    PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT

    In cui:

    • (Obbligatorio) PROTOCOL: Deve essere http.
    • (Facoltativo) USERNAME e PASSWORD: Questo campo include il nome utente e la password del proxy HTTP. È necessario impostare USERNAME e PASSWORD se il proxy richiede l'autenticazione.

    Nota: quando si distribuiscono cluster di gestione con la CLI, nelle password non è possibile utilizzare i caratteri non alfanumerici seguenti: # ` ^ | / \ ? % ^ { [ ] }" < >.

    • (Obbligatorio) FQDN-OR-IP: questo è il nome di dominio completo o l'indirizzo IP del proxy HTTP.
    • (Obbligatorio) PORT: questo è il numero di porta utilizzato dal proxy HTTP.

    Ad esempio, http://user:[email protected]:1234.

  • TKG_HTTPS_PROXY: questo è l'URL del proxy che gestisce le richieste HTTPS. È possibile impostare TKG_HTTPS_PROXY sullo stesso valore di TKG_HTTP_PROXY o specificare un valore diverso. Per impostare il valore, utilizzare il formato dell'URL del passaggio precedente, in cui:

    • (Obbligatorio) PROTOCOL: Deve essere http.
    • (Facoltativo) USERNAME e PASSWORD: questo campo include il nome utente e la password del proxy HTTPS. È necessario impostare USERNAME e PASSWORD se il proxy richiede l'autenticazione.

    Nota: quando si distribuiscono cluster di gestione con la CLI, nelle password non è possibile utilizzare i caratteri non alfanumerici seguenti: # ` ^ | / \ ? % ^ { [ ] }" < >.

    • (Obbligatorio) FQDN-OR-IP: questo è il nome di dominio completo o l'indirizzo IP del proxy HTTPS.
    • (Obbligatorio) PORT: questo è il numero di porta utilizzato dal proxy HTTPS.

    Ad esempio, http://user:[email protected]:1234.

  • TKG_NO_PROXY: consente di impostare uno o più CIDR di rete o nomi host separati da virgola che devono ignorare il proxy HTTP(S), ad esempio per consentire al cluster di gestione di comunicare direttamente con l'infrastruttura eseguita nella stessa rete, dietro lo stesso proxy. Non utilizzare spazi nell'impostazione dell'elenco con valori separati da virgola. Ad esempio, noproxy.yourdomain.com,192.168.0.0/24.

    In vSphere, questo elenco deve includere:

    • L'indirizzo IP o il nome host di vCenter.
    • Il CIDR di VSPHERE_NETWORK, che include l'indirizzo IP dell'endpoint del piano di controllo. Se si imposta VSPHERE_CONTROL_PLANE_ENDPOINT su un nome di dominio completo, aggiungere tale nome di dominio completo anche nell'elenco TKG_NO_PROXY.

    Internamente, Tanzu Kubernetes Grid aggiunge localhost, 127.0.0.1, i valori di CLUSTER_CIDR e SERVICE_CIDR, .svc e .svc.cluster.local al valore impostato in TKG_NO_PROXY. Aggiunge inoltre il CIDR di AWS VPC e 169.254.0.0/16 per le distribuzioni in AWS e il CIDR di Azure VNET, 169.254.0.0/16 e 168.63.129.16 per le distribuzioni in Azure. Per vSphere, è necessario aggiungere manualmente il CIDR di VSPHERE_NETWORK, che include l'indirizzo IP dell'endpoint del piano di controllo, in TKG_NO_PROXY. Se si imposta VSPHERE_CONTROL_PLANE_ENDPOINT su un nome di dominio completo, aggiungere sia il nome di dominio completo sia VSPHERE_NETWORK in TKG_NO_PROXY.

    Importante

    se le macchine virtuali del cluster devono comunicare con i servizi esterni e gli endpoint dell'infrastruttura nell'ambiente Tanzu Kubernetes Grid, assicurarsi che tali endpoint siano raggiungibili dai proxy impostati in precedenza o aggiungerli in TKG_NO_PROXY. In base alla configurazione dell'ambiente, ciò può includere, a titolo esemplificativo:

    • Server OIDC o LDAP
    • Harbor
    • VMware NSX
    • NSX Advanced Load Balancer
    • CIDR di AWS VPC esterni al cluster

Ad esempio:

#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------

TKG_HTTP_PROXY_ENABLED: true
TKG_PROXY_CA_CERT: "LS0t[...]tLS0tLQ==""
TKG_HTTP_PROXY: "http://myproxy.com:1234"
TKG_HTTPS_PROXY: "http://myproxy.com:1234"
TKG_NO_PROXY: "noproxy.yourdomain.com,192.168.0.0/24"

Configurazione delle impostazioni del nodo

Per impostazione predefinita, tutti i nodi del cluster eseguono Ubuntu v20.04 per tutte le piattaforme di destinazione. In vSphere è possibile distribuire facoltativamente cluster che eseguono Photon OS nei relativi nodi. In AWS i nodi possono facoltativamente eseguire Amazon Linux 2. Per l'architettura, il valore predefinito e l'unica opzione al momento disponibile è amd64. Per le impostazioni del sistema operativo e della versione, vedere Configurazione del nodo in Informazioni di riferimento sulle variabili del file di configurazione.

Ad esempio:

#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------

OS_NAME: "photon"
OS_VERSION: "3"
OS_ARCH: "amd64"

La modalità di impostazione della configurazione e delle dimensioni dell'elaborazione dei nodi dipende dalla piattaforma di destinazione. Per informazioni, vedere Configurazione del cluster di gestione per vSphere, Configurazione del cluster di gestione per AWS o Configurazione del cluster di gestione per Microsoft Azure.

Configurazione dei controlli di integrità delle macchine

Facoltativamente, aggiornare le variabili in base alle preferenze di distribuzione e utilizzando le linee guida descritte nella sezione Controlli di integrità delle macchine di Informazioni di riferimento sulle variabili del file di configurazione.

Ad esempio:

ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 60%
MHC_MAX_UNHEALTHY_WORKER_NODE: 60%
MHC_UNKNOWN_STATUS_TIMEOUT: 10m
MHC_FALSE_STATUS_TIMEOUT: 20m

Configurazione di un registro immagini privato

Se si distribuisce il cluster di gestione in un ambiente con limitazioni Internet, rimuovere il commento e aggiornare le impostazioni TKG_CUSTOM_IMAGE_REPOSITORY_*. Queste impostazioni sono comuni a tutte le piattaforme di destinazione. Non è necessario configurare le impostazioni del registro immagini privato se:

  • Si distribuisce il cluster di gestione in un ambiente con limitazioni Internet e si impostano le variabili TKG_CUSTOM_IMAGE_REPOSITORY_* eseguendo il comando tanzu config set, come descritto in Preparazione di un ambiente con limitazioni Internet. Le variabili di ambiente impostate eseguendo tanzu config set sostituiscono i valori di un file di configurazione del cluster.
  • Si distribuisce il cluster di gestione in un ambiente che può accedere a Internet esterno.

Ad esempio:

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

TKG_CUSTOM_IMAGE_REPOSITORY: "custom-image-repository.io/yourproject"
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: "LS0t[...]tLS0tLQ=="

Configurazione della CNI di Antrea

Per impostazione predefinita, i cluster distribuiti con la CLI di Tanzu forniscono una rete di container nel cluster con l'interfaccia CNI (Container Network Interface) di Antrea.

Facoltativamente, è possibile disattivare SNAT (Source Network Address Translation) per il traffico del pod, implementare le modalità di incapsulamento del traffico hybrid, noEncap e NetworkPolicyOnly, utilizzare proxy e criteri di rete, nonché implementare Traceflow.

Per ulteriori informazioni su Antrea, vedere le risorse seguenti:

Per configurare facoltativamente queste funzionalità in Antrea, rimuovere il commento dalle variabili ANTREA_* e aggiornarle. Ad esempio:

#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------

ANTREA_NO_SNAT: true
ANTREA_NODEPORTLOCAL: true
ANTREA_NODEPORTLOCAL_ENABLED: true
ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
ANTREA_TRAFFIC_ENCAP_MODE: "encap"
ANTREA_PROXY: true
ANTREA_PROXY_ALL: true
ANTREA_PROXY_LOAD_BALANCER_IPS: false
ANTREA_PROXY_NODEPORT_ADDRS:
ANTREA_PROXY_SKIP_SERVICES: ""
ANTREA_POLICY: true
ANTREA_TRACEFLOW: true
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
ANTREA_ENABLE_USAGE_REPORTING: false
ANTREA_EGRESS: true
ANTREA_EGRESS_EXCEPT_CIDRS: ""
ANTREA_FLOWEXPORTER: false
ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
ANTREA_IPAM: false
ANTREA_KUBE_APISERVER_OVERRIDE: ""
ANTREA_MULTICAST: false
ANTREA_MULTICAST_INTERFACES: ""
ANTREA_NETWORKPOLICY_STATS: true
ANTREA_SERVICE_EXTERNALIP: true
ANTREA_TRAFFIC_ENCRYPTION_MODE: none
ANTREA_TRANSPORT_INTERFACE: ""
ANTREA_TRANSPORT_INTERFACE_CIDRS: ""

Configurazione delle variabili specifiche di IaaS

Continuare ad aggiornare le impostazioni del file di configurazione per vSphere, AWS o Azure. Per le impostazioni del file di configurazione specifiche per ogni piattaforma di destinazione, vedere l'argomento corrispondente:

Esecuzione del comando tanzu mc create

Dopo aver creato o aggiornato il file di configurazione del cluster e aver scaricato il file BoM più recente, è possibile distribuire un cluster di gestione eseguendo il comando tanzu mc create --file CONFIG-FILE, in cui CONFIG-FILE è il nome del file di configurazione. Se il file di configurazione è il file predefinito ~/.config/tanzu/tkg/cluster-config.yaml, è possibile omettere l'opzione --file. Se si desidera esaminare il manifesto Kubernetes che verrà applicato dal comando tanzu mc create, è possibile utilizzare facoltativamente il flag --dry-run per stampare il manifesto senza apportare modifiche. Questa chiamata eseguirà comunque i controlli di convalida descritti di seguito prima di generare il manifesto di Kubernetes.

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.

Per distribuire un cluster di gestione, eseguire il comando tanzu mc create. Ad esempio:

tanzu mc create --file path/to/cluster-config-file.yaml

Controlli di convalida

Quando si esegue tanzu mc create, il comando esegue diversi controlli di convalida prima di distribuire il cluster di gestione. I controlli sono diversi in base all'infrastruttura in cui si distribuisce il cluster di gestione.

vSphere
Il comando verifica che l'infrastruttura di vSphere di destinazione soddisfi i requisiti seguenti:
  • Le credenziali di vSphere fornite sono valide.
  • I nodi soddisfano i requisiti di dimensione minimi.
  • Il modello dell'immagine di base esiste in vSphere ed è valido per la versione di Kubernetes specificata.
  • Le risorse richieste, inclusi il pool di risorse, i datastore e la cartella, sono presenti in vSphere.
AWS
Il comando verifica che l'infrastruttura di AWS di destinazione soddisfi i requisiti seguenti:
  • Le credenziali di AWS fornite sono valide.
  • Lo stack CloudFormation è presente.
  • Il tipo di istanza del nodo è supportato.
  • Regione e ZD corrispondono.
Azure
Il comando verifica che l'infrastruttura di Azure di destinazione soddisfi i requisiti seguenti:
  • Le credenziali di Azure fornite sono valide.
  • La chiave SSH pubblica è codificata nel formato base64.
  • Il tipo di istanza del nodo è supportato.

Se una di queste condizioni non viene soddisfatta, il comando tanzu mc create non riesce.

Monitoraggio dello stato di avanzamento

Quando si esegue tanzu mc create, è possibile seguire l'avanzamento della distribuzione del cluster di gestione nel terminale. 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.

Se tanzu mc create non riesce prima della distribuzione del cluster di gestione, è necessario pulire gli artefatti nella macchina di bootstrap prima di eseguire nuovamente tanzu mc create. Per informazioni dettagliate, vedere l'argomento Risoluzione dei problemi relativi al cluster di gestione. 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 la distribuzione riesce, nel terminale viene visualizzato un messaggio di conferma:

Management cluster created! You can now create your first workload cluster by running tanzu cluster create [name] -f [file]

Passaggi successivi

  • 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 i cluster del carico di lavoro come descritto 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, su come connettere kubectl al cluster di gestione, su come creare gli spazi dei nomi e su come registrare il cluster di gestione con Tanzu Mission Control, vedere Controllo e registrazione di un cluster di gestione autonomo appena distribuito .

check-circle-line exclamation-circle-line close-line
Scroll to top icon