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, è possibile che non sia 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 di un file di configurazione del cluster di gestione

Prima di creare un cluster di gestione da un file di configurazione, è necessario creare il file. 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 un cluster di gestione autonomo:

  1. In un editor di testo, aprire un nuovo file con estensione .yaml e un nome appropriato, ad esempio aws-mgmt-cluster-config.yaml. Questo sarà il file di configurazione.

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

  2. Facendo riferimento all'argomento seguente corrispondente all'infrastruttura in uso, copiare e incollare il codice del modello nella parte superiore della pagina del file di configurazione:

  3. Configurare le impostazioni all'interno del file:

    • Seguire le istruzioni disponibili nel resto della pagina specifica dell'infrastruttura per configurare le opzioni specifiche dell'infrastruttura.
    • Seguire le istruzioni disponibili nel resto di questa pagina per configurare le impostazioni comuni a tutte le piattaforme di destinazione.

  4. Salvare il file.

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,offline_access
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: "cn=bind-user,ou=people,dc=example,dc=com"
LDAP_BIND_PASSWORD: "example-password"
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: &(objectClass=posixGroup)(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)(uid={})
LDAP_USER_SEARCH_NAME_ATTRIBUTE: 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: ""

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

Più ZD in vSphere Per eseguire il cluster di gestione o i relativi cluster del carico di lavoro in più zone di disponibilità, ora o successivamente, includere l'opzione --az-file con il file vsphere-zones.yaml descritto in Creare oggetti FailureDomain e DeploymentZone in Kubernetes:

tanzu mc create --file path/to/cluster-config-file.yaml --az-file path/to/vsphere-zones.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.

Convalida di più ZD Se si distribuisce il cluster di gestione definendo le risorse FailureDomains e DeploymentZones come descritto in Creare oggetti FailureDomain e DeploymentZone in Kubernetes, facendo successivamente riferimento ad esse con l'opzione --az-file nel comando tanzu mc create, il processo di creazione del cluster esegue per impostazione predefinita i seguenti controlli aggiuntivi:

* All vSphere zones and regions referenced in `VSphereFailureDomain`, `VSphereDeploymentZone`, and related Kubernetes objects exist in vSphere, are accessible, and have host groups, VM groups, and tags that also exist.
* Tag categories for the tags exist in vSphere and are logically consistent.
* vSphere AZ/zone and region configurations are logically consistent.
* `MATCHING_LABELS` configuration settings correspond to labels in the `VSphereDeploymentZone` objects.
* Zones referenced in Kubernetes are at the same level in vSphere.
* ResourcePools and Folders referenced in the `VSphereDeploymentZone` resources exist in vSphere.

Per impedire al processo di creazione del cluster di verificare che le zone e le regioni vSphere specificate nella configurazione esistano tutte, siano coerenti e siano definite allo stesso livello, impostare SKIP_MULTI_AZ_VERIFY su "true" nell'ambiente locale:

```
export SKIP_MULTI_AZ_VERIFY="true"
```

Non è possibile impostare questa variabile nel file di configurazione del cluster.

Uno scenario tipico per l'utilizzo di SKIP_MULTI_AZ_VERIFY si verifica quando si distribuisce un cluster di gestione autonomo che verrà utilizzato per creare cluster del carico di lavoro in esecuzione in più ZD in futuro, senza che le risorse vSphere per le ZD del cluster del carico di lavoro siano ancora state configurate.

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.3 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