Préparer le déploiement des clusters de gestion dans Microsoft Azure

Cette rubrique explique comment préparer Microsoft Azure pour l'exécution de Tanzu Kubernetes Grid.

Si vous installez Tanzu Kubernetes Grid sur Azure VMware Solution (AVS), vous l'installez sur un environnement vSphere. Reportez-vous aux sections Préparation d'Azure VMware Solution sur Microsoft Azure dans Préparer le déploiement de clusters de gestion pour un environnement VMware Cloud pour préparer votre environnement et Préparer le déploiement de clusters de gestion pour vSphere pour déployer des clusters de gestion.

Pour vous faciliter la tâche, une Liste de contrôle de préparation est disponible à la fin de cette page pour vous assurer que vous êtes prêt à déployer un cluster de gestion Tanzu Kubernetes Grid dans Azure.

Important

Tanzu Kubernetes Grid v2.4.x est la dernière version de TKG qui prend en charge la création de clusters de gestion TKG autonomes sur Azure. La possibilité de créer des clusters de gestion TKG autonomes sur Azure sera supprimée dans Tanzu Kubernetes Grid version v2.5.

À partir de maintenant, VMware vous recommande d'utiliser Tanzu Mission Control pour créer des clusters Azure AKS natifs au lieu de créer des clusters de gestion TKG sur Azure. Pour plus d'informations sur la création de clusters Azure AKS natifs avec Tanzu Mission Control, reportez-vous à la section Gestion du cycle de vie des clusters Azure AKS de la documentation de Tanzu Mission Control.

Pour plus d'informations, reportez-vous à la section Obsolescence des clusters de gestion et de charge de travail TKG sur AWS et Azure des Notes de mise à jour de VMware Tanzu Kubernetes Grid v2.4.

Conditions générales

  • La CLI Tanzu installée localement. Reportez-vous à la section Installer la CLI Tanzu et la CLI Kubernetes à utiliser avec des clusters de gestion autonomes.

  • Un compte Microsoft Azure avec les éléments suivants :

    • Autorisations requises pour créer un principal de service et lui attribuer le rôle Owner.
      Pour plus d'informations sur les rôles, reportez-vous à la page Rôles intégrés Azure.
    • Quotas de cœur de machine virtuelle (vCPU) suffisants pour vos clusters. Un compte Azure standard dispose d'un quota de 10 vCPU par région. La configuration requise pour les vCPU varie selon que vous utiliserez le plan prod ou dev. Pour en savoir plus sur les plans, reportez-vous à la section Plans de cluster de charge de travail.
      Les clusters Tanzu Kubernetes Grid requièrent 2 vCPU par nœud, ce qui se traduit par :
    • Cluster de gestion :
      • plan dev: 4 vCPU (1 principal, 1 travailleur)
      • plan prod: 8 vCPU (3 principaux, 1 travailleur)
    • Chaque cluster de charge de travail :
      • plan dev: 4 vCPU (1 principal, 1 travailleur)
      • plan prod: 12 vCPU (3 principaux, 3 travailleurs)

    • Par exemple, en supposant un cluster de gestion unique et tous les clusters ayant le même plan :

      Plan Clusters de charge de travail vCPU pour la charge de travail vCPU pour la gestion Nombre total de vCPU
      Dév. 1 4 4 8
      5 20 24
      Prod. 1 12 8 20
      5 60 68

    • Quotas d'adresses IP publiques suffisants pour vos clusters, y compris le quota d'adresses IP publiques Adresses IP publiques – standard (Public IP Addresses - Standard), Adresses IP publiques – basiques (Public IP Addresses - Basic) et Adresses IP publiques statiques (Static Public IP Addresses). Un compte Azure standard dispose d’un quota de 10 adresses IP publiques par région. Chaque cluster Tanzu Kubernetes Grid requière 2 adresses IP publiques, quel que soit le nombre de nœuds de plan de contrôle et de nœuds worker dont il dispose. Pour chaque objet de service Kubernetes de type LoadBalancer, 1 adresse IP publique est requise.

  • Le trafic est autorisé entre votre machine de démarrage locale et les référentiels d'images répertoriés dans le fichier de nomenclature (BoM) du cluster de gestion, sur le port 443, pour TCP.*
    • Le fichier de nomenclature se trouve sous ~/.config/tanzu/tkg/bom/ et son nom inclut la version Tanzu Kubernetes Grid. Par exemple, tkg-bom-v2.4.0+vmware.1 .yaml.
    • Exécutez une recherche DNS sur toutes les valeurs imageRepository pour rechercher leurs CNAMEs.
  • (Facultatif) OpenSSL installé localement, pour créer une paire de clés ou valider l'empreinte numérique du module de téléchargement. Reportez-vous à la section OpenSSL.

  • (Facultatif) Un réseau virtuel (VNet) avec :

    • Sous-réseau pour le nœud de plan de contrôle du cluster de gestion
    • Un groupe de sécurité réseau (NSG) dans le groupe de ressources de réseau virtuel du cluster qui se trouve sur le sous-réseau du plan de contrôle et qui dispose des règles de sécurité entrantes suivantes, pour activer les connexions SSH et au serveur d'API Kubernetes :
      • Autoriser TCP sur le port 22 pour n'importe quelle source et destination
      • Autorisez TCP sur le port 6443 pour n'importe quelle source et destination. Le port 6443 est l'emplacement où l'API Kubernetes est exposée sur les machines virtuelles dans les clusters que vous créez. Pour modifier ce port pour un cluster de gestion ou de charge de travail, définissez la variable CLUSTER_API_SERVER_PORT lors du déploiement du cluster.
    • Un sous-réseau pour les nœuds worker du cluster de gestion
    • Un NSG pour les nœuds worker du cluster de gestion qui se trouve dans le groupe de ressources du réseau virtuel du cluster et sur le sous-réseau de nœud worker du cluster

    Si vous n'utilisez pas de réseau virtuel existant, le processus d'installation en crée un nouveau.

  • L'interface de ligne de commande Azure est installée localement. Reportez-vous à la page Installer l'interface de ligne de commande Azure dans la documentation de Microsoft Azure.

  • Si vous déployez des services de type LoadBalancer sur des clusters de charge de travail basés sur une classe, configurez une passerelle NAT ou un autre serveur frontal comme décrit dans la section Les services LoadBalancer pour les clusters de charge de travail basés sur une classe sur Azure nécessitent une configuration manuelle de passerelle ou de serveur frontal.

*Ou reportez-vous à la section Préparer un environnement à accès restreint à Internet pour installer sans accès réseau externe.

Exemples de dimensionnement de cluster de gestion

Le tableau ci-dessous décrit des exemples de dimensionnement pour les clusters de gestion sur Azure. Utilisez ces données comme guide pour vous assurer que votre cluster de gestion est dimensionné afin de gérer le nombre de clusters de charge de travail que vous prévoyez de déployer. La colonne Taille de machine virtuelle du cluster de charge de travail répertorie les tailles de machines virtuelles utilisées pour les exemples dans la colonne Peut gérer….

Plan de cluster de gestion Taille de la VM du cluster de gestion Peut gérer … Taille de la VM du cluster de charge de travail
3 nœuds de plan de contrôle et 3 nœuds worker
  • Nœuds de plan de contrôle : Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
  • Nœuds Worker Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
 Exemples :
  • 5 clusters de charge de travail, chacun déployé avec 3 plans de contrôle et 200 nœuds worker ; ou
  • 10 clusters de charge de travail, chacun déployé avec 3 plans de contrôle et 50 nœuds worker
  • Nœuds de plan de contrôle : Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
  • Nœuds Worker Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
3 nœuds de plan de contrôle et 3 nœuds worker
  • Nœuds de plan de contrôle : Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
  • Nœuds Worker Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
 Exemple : Un cluster de charge de travail, déployé avec 3 plans de contrôle et 250 nœuds worker
  • Nœuds de plan de contrôle : Standard_D4s_v3 (CPU : 4 ; mémoire : 16 Go ; SSD : 32 Go)
  • Nœuds Worker Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
3 nœuds de plan de contrôle et 3 nœuds worker
  • Nœuds de plan de contrôle : Standard_D4s_v3 (CPU : 4 ; mémoire : 16 Go ; SSD : 32 Go)
  • Nœuds Worker Standard_D4s_v3 (CPU : 4 ; mémoire : 16 Go ; SSD : 32 Go)
 Exemple : 199 clusters de charge de travail, chacun déployé avec 3 plans de contrôle et 3 nœuds worker
  • Nœuds de plan de contrôle : Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)
  • Nœuds Worker Standard_D2s_v3 (CPU : 2 ; mémoire : 8 Go ; SSD : 16 Go)

Créer des NSG Azure pour le réseau virtuel existant

Les clusters de gestion et de charge de travail Tanzu Kubernetes Grid sur Azure nécessitent la définition de deux groupes de sécurité réseau (Network Security Group, NSG) sur leur réseau virtuel et dans leur groupe de ressources de réseau virtuel :

  • Un NSG nommé CLUSTER-NAME-controlplane-nsg et associé au sous-réseau du plan de contrôle du cluster.

  • Un NSG nommé CLUSTER-NAME-node-nsg et associé au sous-réseau du nœud worker du cluster.

    Où CLUSTER-NAME est le nom du cluster.

    Attention :

    L'octroi de noms de NSG qui ne suivent pas le format ci-dessus peut empêcher le déploiement.

Si vous spécifiez un réseau virtuel existant pour le cluster de gestion, vous devez créer ces NSG comme décrit dans les Conditions générales ci-dessus. Un réseau virtuel existant pour un cluster de gestion est spécifié avec Sélectionnez un réseau virtuel existant (Select an existing VNet) dans l'interface du programme d'installation ou AZURE_VNET_NAME dans son fichier de configuration.

Si vous ne spécifiez pas de réseau virtuel existant pour le cluster, le processus de déploiement crée un nouveau réseau virtuel et les NSG requis.

Pour savoir comment configurer le réseau virtuel, les groupes de ressources et les sous-réseaux du cluster, reportez-vous au tableau Microsoft Azure de la Référence de variable du fichier de configuration.

Enregistrer Tanzu Kubernetes Grid en tant qu'application cliente Azure

Tanzu Kubernetes Grid gère les ressources Azure en tant qu'application cliente enregistrée qui accède à Azure via un principal de service. Pour créer le principal de service et configurer son accès aux ressources Azure, vous pouvez utiliser la commande az ad sp create-for-rbac.

  1. Connectez-vous à l'interface de ligne de commande Azure en exécutant az login.

  2. Créez un principal de service et attribuez-lui le rôle Owner:

    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"

    Où :

    • APP-NAME est n'importe quel nom à donner à votre principal de service
    • SUBSCRIPTION-ID et RESOURCE-GROUP sont votre ID d'abonnement Azure et votre groupe de ressources de réseau virtuel
    • APP-ID est la valeur appId renvoyée par az ad sp create-for-rbac

    Par exemple, pour créer et attribuer le rôle Owner à un principal de service nommé 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"

    Enregistrez la sortie. Vous utiliserez ces informations dans les étapes de la procédure Accepter la licence de l'image de base et ultérieurement, lors du déploiement d'un cluster de gestion. Pour obtenir la liste complète des options prises en charge par az ad sp create-for-rbac, reportez-vous à la section az ad sp create-for-rbac dans la documentation d'Azure.

Accepter la licence de l'image de base

Pour exécuter des machines virtuelles de cluster de gestion sur Azure, acceptez la licence pour leur version Kubernetes de base et leur système d'exploitation de machine.

Exécutez la commande az vm image terms accept, en spécifiant le --plan et votre ID d'abonnement.

Dans Tanzu Kubernetes Grid v2.4.0, la valeur par défaut de l'image de cluster --plan est k8s-1dot27dot5-ubuntu-2004, selon Kubernetes version 1.27.5 et le système d'exploitation de la machine, Ubuntu 20.04. Exécutez la commande suivante :

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

Où AZURE_SUBSCRIPTION_ID correspond à votre ID d'abonnement Azure.

Vous devez répéter cette opération pour accepter la licence d'image de base pour chaque version de Kubernetes ou du système d'exploitation que vous souhaitez utiliser lorsque vous déployez des clusters, et chaque fois que vous effectuez une mise à niveau vers une nouvelle version de Tanzu Kubernetes Grid.

Créer une paire de clés SSH (facultatif)

Vous déployez des clusters de gestion à partir d'une machine appelée machine de démarrage, à l'aide de la CLI Tanzu. Pour se connecter à Azure, la machine de démarrage doit fournir la partie de clé publique d'une paire de clés SSH. Si votre machine de démarrage ne dispose pas déjà d'une paire de clés SSH, vous pouvez utiliser un outil tel que ssh-keygen pour en générer une.

  1. Sur votre machine de démarrage, exécutez la commande suivante ssh-keygen.

    ssh-keygen -t rsa -b 4096 -C "[email protected]"

  2. À l'invite Enter file in which to save the key (/root/.ssh/id_rsa):, appuyez sur Entrée pour accepter les valeurs par défaut.

  3. Entrez et répétez un mot de passe pour la paire de clés.

  4. Ajoutez la clé privée à l'agent SSH exécuté sur votre machine et entrez le mot de passe que vous avez créé à l'étape précédente.

    ssh-add ~/.ssh/id_rsa

  5. Ouvrez le fichier .ssh/id_rsa.pub dans un éditeur de texte afin de pouvoir le copier et le coller facilement lorsque vous déployez un cluster de gestion.

Liste de contrôle de préparation

Utilisez cette liste de contrôle pour vous assurer que vous êtes prêt à déployer un cluster de gestion Tanzu Kubernetes Grid sur Azure :

  • CLI Tanzu installée

  • Compte Azure

    • Connectez-vous au portail Web Azure à l'adresse https://portal.azure.com.

  • Azure CLI installé

  • Application tkg enregistrée

    • Dans le portail Azure, sélectionnez Active Directory > Inscriptions des applications > Applications propriétaires et vérifiez que votre application tkg est répertoriée comme configurée dans Enregistrer Tanzu Kubernetes Grid en tant qu'application cliente Azure ci-dessus et avec une clé secrète actuelle.
    • Dans l'interface de ligne de commande Azure, exécutez az ad sp show --id.

  • Licence de l'image de la VM de base acceptée

    • Exécutez az vm image terms show --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot27dot5-ubuntu-2004. La sortie doit contenir "accepted": true.

Tâches suivantes

Pour les déploiements de production, il est vivement recommandé d'activer la gestion des identités pour vos clusters : * Pour plus d'informations sur les étapes de préparation à effectuer avant de déployer un cluster de gestion, reportez-vous à la section Obtenir les détails de votre fournisseur d'identité dans Configurer la gestion des identités. * Pour obtenir des informations conceptuelles sur la gestion des identités et le contrôle d'accès dans Tanzu Kubernetes Grid, reportez-vous à la section À propos de la gestion des identités et des accès.

Si vous utilisez Tanzu Kubernetes Grid dans un environnement disposant d'une connexion Internet externe, une fois que vous avez configuré la gestion des identités, vous êtes prêt à déployer des clusters de gestion sur Azure.

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