Preparazione della distribuzione dei cluster di gestione in Microsoft Azure

Questo argomento spiega come preparare Microsoft Azure per l'esecuzione di Tanzu Kubernetes Grid.

Se si sta installando Tanzu Kubernetes Grid in Azure VMware Solution (AVS), si sta eseguendo l'installazione in un ambiente vSphere. Vedere Preparazione di Azure VMware Solution in Microsoft Azure in Preparazione della distribuzione dei cluster di gestione in un ambiente VMware Cloud per preparare l'ambiente e Preparazione della distribuzione dei cluster di gestione in vSphere per distribuire i cluster di gestione.

Per comodità, alla fine di questa pagina è disponibile un Elenco di controllo della preparazione per assicurarsi di essere pronti per distribuire un cluster di gestione di Tanzu Kubernetes Grid in Azure.

Importante
Tanzu Kubernetes Grid v2.4.x è l'ultima versione di TKG che supporta la creazione di cluster di gestione TKG autonomi in Azure. La possibilità di creare cluster di gestione TKG autonomi in Azure verrà rimossa nella versione Tanzu Kubernetes Grid v2.5.

A partire da ora, VMware consiglia di utilizzare Tanzu Mission Control per creare cluster Azure AKS nativi anziché creare nuovi cluster di gestione TKG in Azure. Per informazioni su come creare cluster Azure AKS nativi con Tanzu Mission Control, vedere 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.

Requisiti generali

CLI di Tanzu installata in locale. Vedere Installazione della CLI di Tanzu e della CLI di Kubernetes per l'utilizzo con i cluster di gestione autonomi.

Un account Microsoft Azure con quanto segue:

Autorizzazioni necessarie per creare un'entità servizio e assegnare il ruolo Owner a tale entità.
Per ulteriori informazioni sui ruoli, vedere Ruoli predefiniti di Azure.
Quote di core della macchina virtuale (vCPU) sufficienti per i cluster. Un account Azure standard ha una quota di 10 vCPU per regione. I requisiti della vCPU dipendono dal fatto che si utilizzi il piano prod o il piano dev. Per ulteriori informazioni sui piani, vedere Piani dei cluster del carico di lavoro.
I cluster Tanzu Kubernetes Grid richiedono 2 vCPU per nodo, ovvero:
Cluster di gestione:
- Piano dev: 4 vCPU (1 principale, 1 worker)
- Piano prod: 8 vCPU (3 principali , 1 worker)
Ogni cluster del carico di lavoro:
- Piano dev: 4 vCPU (1 principale, 1 worker)
- Piano prod: 12 vCPU (3 principali , 3 worker)

Ad esempio, supponendo di avere un singolo cluster di gestione e tutti i cluster con lo stesso piano:

Piano	Cluster del carico di lavoro	vCPU per il carico di lavoro	vCPU per la gestione	vCPU totali
Dev	1	4	4	8
Dev	5	20	4	24
Prod	1	12	8	20
Prod	5	60	8	68

Quote di indirizzi IP pubblici sufficienti per i cluster, inclusa la quota per Indirizzi IP pubblici - Standard, Indirizzi IP pubblici - Base e Indirizzi IP pubblici statici. Un account Azure standard ha una quota di 10 indirizzi IP pubblici per regione. Ogni cluster Tanzu Kubernetes Grid richiede 2 indirizzi IP pubblici indipendentemente dal numero di nodi del piano di controllo e nodi worker che include. Per ogni oggetto servizio Kubernetes con tipo LoadBalancer, è necessario 1 indirizzo IP pubblico.

Il traffico è consentito tra la macchina di bootstrap locale e i repository di immagini elencati nel file Bill of Materials (BoM) del cluster di gestione, nella porta 443, per TCP.*
- Il file BoM si trova in ~/.config/tanzu/tkg/bom/ e il suo nome include la versione di Tanzu Kubernetes Grid. Ad esempio, tkg-bom-v2.4.0+vmware.1 .yaml.
- Eseguire una ricerca DNS in tutti i valori imageRepository per trovare i record CNAME.
(Facoltativo) OpenSSL installato in locale per creare una nuova coppia di chiavi o convalidare l'identificazione personale del pacchetto di download. Vedere OpenSSL.
(Facoltativo) Una rete virtuale (VNet) con:
- Una subnet per il nodo del piano di controllo del cluster di gestione
- Un gruppo di sicurezza di rete nel gruppo di risorse VNet del cluster che si trova nella subnet del piano di controllo e dispone delle seguenti regole di sicurezza in entrata, per abilitare le connessioni al server dell'API di SSH e Kubernetes:
  - Consenti TCP nella porta 22 per qualsiasi origine e destinazione
  - Consenti TCP nella porta 6443 per qualsiasi origine e destinazione. La porta 6443 è quella in cui l'API di Kubernetes è esposta nelle macchine virtuali dei cluster creati. Per modificare questa porta per un cluster di gestione o del carico di lavoro, impostare la variabile CLUSTER_API_SERVER_PORT quando si distribuisce il cluster.
- Una subnet per i nodi worker del cluster di gestione
- Un gruppo di sicurezza di rete per i nodi worker del cluster di gestione che si trovano nel gruppo di risorse VNet del cluster e nella subnet del nodo worker del cluster
Se non si utilizza una VNet esistente, il processo di installazione ne crea una nuova.
La CLI di Azure installata in locale. Vedere Installazione della CLI di Azure nella documentazione di Microsoft Azure.
Se si distribuiranno servizi di tipo LoadBalancer in cluster del carico di lavoro basati sulla classe, configurare un gateway NAT o un altro front-end come descritto in I servizi LoadBalancer per i cluster del carico di lavoro basati sulla classe in Azure richiedono la configurazione manuale del gateway o di front-end .

*In alternativa, vedere Preparazione di un ambiente con limitazioni Internet per l'installazione senza accesso alla rete esterna.

Esempi di dimensionamento del cluster di gestione

La tabella seguente descrive esempi di dimensionamento per i cluster di gestione in Azure. Utilizzare questi dati come linee guida per assicurarsi che le dimensioni del cluster di gestione vengano modificate per gestire il numero di cluster del carico di lavoro che si intende distribuire. La colonna Dimensioni macchina virtuale carico di lavoro include le dimensioni delle macchine virtuali utilizzate per gli esempi nella colonna Può gestire….

Piano del cluster di gestione	Dimensioni macchina virtuale cluster di gestione	Può gestire…	Dimensioni macchina virtuale cluster carico di lavoro
3 nodi del piano di controllo e 3 nodi worker	Nodi piano di controllo: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB) Nodi worker: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB)	Esempi: 5 cluster del carico di lavoro, ciascuno dei quali distribuito con 3 nodi del piano di controllo e 200 nodi worker; oppure 10 cluster del carico di lavoro, ciascuno dei quali distribuito con 3 nodi del piano di controllo e 50 nodi worker	Nodi piano di controllo: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB) Nodi worker: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB)
3 nodi del piano di controllo e 3 nodi worker	Nodi piano di controllo: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB) Nodi worker: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB)	Esempio: un cluster del carico di lavoro, distribuito con 3 piani di controllo e 250 nodi worker	Nodi piano di controllo: `Standard_D4s_v3` (CPU: 4; memoria: 16 GB; SSD: 32 GB) Nodi worker: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB)
3 nodi del piano di controllo e 3 nodi worker	Nodi piano di controllo: `Standard_D4s_v3` (CPU: 4; memoria: 16 GB; SSD: 32 GB) Nodi worker: `Standard_D4s_v3` (CPU: 4; memoria: 16 GB; SSD: 32 GB)	Esempio: 199 cluster del carico di lavoro, ciascuno distribuito con 3 piani di controllo e 3 nodi worker	Nodi piano di controllo: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB) Nodi worker: `Standard_D2s_v3` (CPU: 2; memoria: 8GB; SSD: 16 GB)

Creazione di gruppi di sicurezza di rete di Azure per la VNet esistente

I cluster di gestione e i cluster del carico di lavoro di Tanzu Kubernetes Grid in Azure richiedono la definizione di due gruppi di sicurezza di rete nella VNet e nel relativo gruppo di risorse VNet:

Un gruppo di sicurezza di rete denominato CLUSTER-NAME-controlplane-nsg e associato alla subnet del piano di controllo del cluster
Un gruppo di sicurezza di rete denominato CLUSTER-NAME-node-nsg e associato alla subnet del nodo worker del cluster

In cui CLUSTER-NAME è il nome del cluster.

Attenzione
L'assegnazione ai gruppi di sicurezza di rete di nomi che non seguono il formato precedente può impedire la distribuzione.

Se si specifica una VNet esistente per il cluster di gestione, è necessario creare questi gruppi di sicurezza di rete in base alle indicazioni della sezione Requisiti generali precedente. Una VNet esistente per un cluster di gestione viene specificata tramite Seleziona VNet esistente nell'interfaccia del programma di installazione o AZURE_VNET_NAME nel relativo file di configurazione.

Se non si specifica una VNet esistente per il cluster, il processo di distribuzione crea una nuova VNet e i gruppi di sicurezza di rete necessari.

Per informazioni su come configurare la VNet, i gruppi di risorse e le subnet del cluster, vedere la tabella Microsoft Azure in Informazioni di riferimento sulle variabili del file di configurazione.

Registrazione di Tanzu Kubernetes Grid come app client di Azure

Tanzu Kubernetes Grid gestisce le risorse di Azure come un'applicazione client registrata che accede ad Azure tramite un'entità servizio. Per creare l'entità servizio e configurarne l'accesso alle risorse di Azure, è possibile utilizzare il comando az ad sp create-for-rbac.

Accedere alla CLI di Azure eseguendo az login.

Creare un'entità servizio e assegnare il ruolo Owner a tale entità:

az ad sp create-for-rbac --role "Owner" --name "APP-NAME" --scopes /subscriptions/SUBSCRIPTION-ID/resourceGroups/RESOURCE-GROUP
az role assignment create --assignee APP-ID --role "Owner"

In cui:

APP-NAME è un nome qualsiasi da assegnare all'entità servizio
SUBSCRIPTION-ID e RESOURCE-GROUP sono l'ID sottoscrizione di Azure e il gruppo di risorse VNet
APP-ID è il valore appId restituito da az ad sp create-for-rbac

Ad esempio, per creare e assegnare il ruolo Owner a un'entità servizio denominata tkg:

$ az ad sp create-for-rbac --role "Owner" --name "tkg" --scopes /subscriptions/c789uce3-aaaa-bbbb-cccc-a51b6b0gb405/resourceGroups/myrg
Creating 'Owner' role assignment under scope '/subscriptions/c789uce3-aaaa-bbbb-cccc-a51b6b0gb405'
The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
'name' property in the output is deprecated and will be removed in the future. Use 'appId' instead.
{
 "appId": "c407cfd4-aaaa-bbbb-cccc-80af703eb0ed",
 "displayName": "tkg",
 "name": "c407cfd4-aaaa-bbbb-cccc-80af703eb0ed",
 "password": "R6yM_.aaaabbbbccccdddd111122223333",
 "tenant": "9c117323-aaaa-bbbb-cccc-9ee430723ba3"
}
$ az role assignment create --assignee c407cfd4-aaaa-bbbb-cccc-80af703eb0ed --role "Owner"

Prendere nota dell'output. Queste informazioni verranno utilizzate nei passaggi della sezione Accettazione della licenza dell'immagine di base seguente e successivamente durante la distribuzione di un cluster di gestione. Per l'elenco completo delle opzioni supportate da az ad sp create-for-rbac, vedere az ad sp create-for-rbac nella documentazione di Azure.

Accettazione della licenza dell'immagine di base

Per eseguire macchine virtuali del cluster di gestione in Azure, accettare la licenza per la versione di Kubernetes di base e il sistema operativo della macchina.

Eseguire il comando az vm image terms accept specificando --plan e ID sottoscrizione.

In Tanzu Kubernetes Grid v2.4.0, il valore dell'immagine del cluster --plan predefinito è k8s-1dot27dot5-ubuntu-2004, in base alla versione di Kubernetes 1.27.5 e al sistema operativo della macchina Ubuntu 20.04. Eseguire il comando seguente:

az vm image terms accept --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot27dot5-ubuntu-2004 --subscription AZURE_SUBSCRIPTION_ID

In cui AZURE_SUBSCRIPTION_ID è l'ID sottoscrizione di Azure.

È necessario ripetere questa operazione per accettare la licenza dell'immagine di base per ogni versione di Kubernetes o sistema operativo che si desidera utilizzare quando si distribuiscono cluster e ogni volta che si esegue l'aggiornamento a una nuova versione di Tanzu Kubernetes Grid.

Creazione di una coppia di chiavi SSH (facoltativa)

I cluster di gestione vengono distribuiti da una macchina denominata macchina di bootstrap utilizzando la CLI di Tanzu. Per connettersi ad Azure, la macchina di bootstrap deve fornire la chiave pubblica che fa parte di una coppia di chiavi SSH. Se la macchina di bootstrap non dispone già di una coppia di chiavi SSH, è possibile utilizzare uno strumento come ssh-keygen per generarne una.

Nella macchina di bootstrap, eseguire il seguente comando ssh-keygen.
```
ssh-keygen -t rsa -b 4096 -C "[email protected]"
```
Al prompt Enter file in which to save the key (/root/.ssh/id_rsa): premere Invio per accettare il file predefinito.
Immettere e ripetere una password per la coppia di chiavi.
Aggiungere la chiave privata all'agente SSH in esecuzione nella macchina e immettere la password creata nel passaggio precedente.
```
ssh-add ~/.ssh/id_rsa
```
Aprire il file .ssh/id_rsa.pub in un editor di testo in modo da poterlo copiare e incollare facilmente quando si distribuisce un cluster di gestione.

Elenco di controllo della preparazione

Utilizzare questo elenco di controllo per assicurarsi di essere pronti per la distribuzione di un cluster di gestione Tanzu Kubernetes Grid in Azure:

CLI di Tanzu installata
- eseguire tanzu version. Per un elenco delle versioni della CLI compatibili con Tanzu Kubernetes Grid v2.4, vedere Product Interoperability Matrix.
Account Azure
- Accedere al portale Web di Azure in https://portal.azure.com.
CLI di Azure installata
- eseguire az version. L'output include la versione corrente della CLI di Azure come indicato in Installazione della CLI di Azure nella documentazione di Microsoft Azure.
App tkg registrata
- Nel portale di Azure selezionare Active Directory > Registrazioni app > Applicazioni di proprietà e verificare che l'app tkg sia elencata come configurata nella sezione Registrazione di Tanzu Kubernetes Grid come app client di Azure precedente e con un segreto corrente.
- In alternativa, nella CLI di Azure eseguire az ad sp show --id.
Licenza dell'immagine della macchina virtuale di base accettata
- eseguire az vm image terms show --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot27dot5-ubuntu-2004. L'output deve contenere "accepted": true.

Passaggi successivi

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à. * Per informazioni concettuali sulla gestione delle identità e sul controllo degli accessi in Tanzu Kubernetes Grid, vedere Informazioni sulla gestione di identità e accessi.

Se si utilizza Tanzu Kubernetes Grid in un ambiente con una connessione Internet esterna, dopo aver configurato la gestione delle identità, è possibile distribuire cluster di gestione in Azure.

Distribuzione dei cluster di gestione con l'interfaccia del programma di installazione. Questa è l'opzione preferita per le prime distribuzioni.
Distribuzione di cluster di gestione da un file di configurazione. Questo è il metodo più complicato, che consente una maggiore flessibilità della configurazione.
Se si desidera distribuire cluster in vSphere e AWS, nonché in Azure, vedere Preparazione della distribuzione dei cluster di gestione in vSphere e Preparazione della distribuzione dei cluster di gestione in Amazon AWS per la configurazione necessaria per tali piattaforme.