This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Clusters sur Azure

Cette rubrique décrit les méthodes de configuration des clusters de charge de travail Tanzu Kubernetes Grid (TKG) pour utiliser des fonctionnalités spécifiques à Microsoft Azure qui ne sont pas entièrement configurables dans le fichier de configuration plat du cluster ou dans la spécification d'objet de style Kubernetes.

Pour plus d'informations sur la configuration des clusters de charge de travail sur Azure à l'aide de fichiers de configuration et de spécifications d'objet, reportez-vous à la section Fichiers de configuration du cluster 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 charge de travail TKG sur Azure. La possibilité de créer des clusters de charge de travail TKG sur Azure sera supprimée dans la version v2.5 de Tanzu Kubernetes Grid.

À 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 charge de travail 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.

Clusters privés Azure

Par défaut, les clusters de gestion et de charge de travail Azure sont publics. Mais vous pouvez également les configurer pour qu'ils soient privés, ce qui signifie que leur serveur d'API utilise un équilibrage de charge interne (ILB, Internal Load Balancer) Azure et qu'il n'est donc accessible qu'à partir du propre réseau virtuel du cluster ou des réseaux virtuels homologues.

Pour rendre un cluster Azure privé, incluez les éléments suivants dans son fichier de configuration :

  • Définissez AZURE_ENABLE_PRIVATE_CLUSTER sur true.

  • (Facultatif) Définissez AZURE_FRONTEND_PRIVATE_IP sur une adresse interne pour l'équilibrage de charge du cluster.

    • Cette adresse doit être comprise dans la plage de son sous-réseau de plan de contrôle et ne doit pas être utilisée par un autre composant.
    • Si aucune valeur n'est définie, cette adresse est définie par défaut sur 10.0.0.100.

  • Définissez AZURE_VNET_NAME, AZURE_VNET_CIDR, AZURE_CONTROL_PLANE_SUBNET_NAME, AZURE_CONTROL_PLANE_SUBNET_CIDR, AZURE_NODE_SUBNET_NAME et AZURE_NODE_SUBNET_CIDR sur le réseau virtuel et les sous-réseaux que vous utilisez pour d'autres clusters privés Azure.

    • Étant donné que les clusters privés Azure ne sont pas accessibles en dehors de leur réseau virtuel, le cluster de gestion et tous les clusters de charge de travail et de services partagés qu'il gère doivent se trouver dans le même réseau virtuel privé.
    • La machine de démarrage, sur laquelle vous exécutez la CLI Tanzu pour créer et utiliser les clusters privés, doit également se trouver dans le même réseau virtuel privé.

  • (Facultatif) Définissez AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB et AZURE_ENABLE_NODE_OUTBOUND_LB sur true si vous avez besoin que les nœuds de plan de contrôle et worker puissent accéder à Internet via une connexion Internet Azure.

    • Par défaut, les clusters privés Azure créent une adresse IP publique pour chaque service Kubernetes de type Équilibrage de charge. Pour configurer le service d'équilibrage de charge pour utiliser plutôt une adresse IP privée, ajoutez l'annotation suivante à votre manifeste de déploiement :

      ---
metadata:
annotations:
  service.beta.kubernetes.io/azure-load-balancer-internal: "true"

Pour plus d'informations, reportez-vous à la section API Server Endpoint dans la documentation Azure du fournisseur d'API de cluster.

Clusters sur différents comptes Azure

Tanzu Kubernetes Grid peut exécuter des clusters de charge de travail sur plusieurs comptes de plate-forme cible. Par exemple, pour fractionner l'utilisation du cloud entre différentes équipes ou appliquer différents profils de sécurité aux charges de travail de production, de préparation et de développement.

Pour déployer des clusters de charge de travail sur un autre compte de principal de service Azure différent de celui utilisé pour déployer le cluster de gestion, procédez comme suit :

  1. Créez l'autre compte Azure. Vous utilisez les détails de ce compte pour créer un objet AzureClusterIdentity à une étape ultérieure. Pour plus d'informations sur la création d'un compte de principal de service Azure, reportez-vous à la section Procédures : Utiliser le portail pour créer une application et un principal du service Azure AD pouvant accéder aux ressources dans la documentation Azure.

  2. Définissez le contexte de kubectl sur votre cluster de gestion :

    kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER

    Où MY-MGMT-CLUSTER est le nom de votre cluster de gestion.

  3. Créez un fichier secret.yaml avec le contenu suivant :

    apiVersion: v1
kind: Secret
metadata:
  name: SECRET-NAME
type: Opaque
data:
  clientSecret: CLIENT-SECRET

    Où :

    • SECRET-NAME est le nom de secret du mot de passe client.
    • CLIENT-SECRET est la clé secrète client de votre identité de principal de service. La clé secrète client doit être codée en base64.

  4. Utilisez le fichier pour créer l'objet Secret :

    kubectl apply -f secret.yaml

  5. Créez un fichier identity.yaml avec le contenu suivant :

    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: AzureClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
  namespace: EXAMPLE-NAMESPACE
spec:
  type: ManualServicePrincipal
  tenantID: AZURE-TENANT-ID
  clientID: CLIENT-ID
  clientSecret: {"name":"SECRET-NAME","namespace":"default"}
  allowedNamespaces:
    list:
    - CLUSTER-NAMESPACE-1
    - CLUSTER-NAMESPACE-1

    Où :

    • EXAMPLE-IDENTITY est le nom à utiliser pour l'objet AzureClusterIdentity.
    • EXAMPLE-NAMESPACE est l'espace de noms de votre objet AzureClusterIdentity.
    • AZURE-TENANT-ID est votre ID de locataire Azure.
    • CLIENT-ID est l'ID client (également appelé AppID) pour l'application Azure AD.
    • SECRET-NAME est le nom de secret du mot de passe client.
    • CLUSTER-NAMESPACE-1 et CLUSTER-NAMESPACE-2 sont des espaces de noms Kubernetes dont les clusters sont autorisés à utiliser les identités. Ces espaces de noms peuvent être sélectionnés à l'aide d'un groupe d'espaces de noms.

  6. Utilisez le fichier pour créer l'objet AzureClusterIdentity :

    kubectl apply -f identity.yaml

Le cluster de gestion peut désormais déployer des clusters de charge de travail sur l'autre compte à l'aide du nouvel objet AzureClusterIdentity.

Pour créer des clusters de charge de travail qui utilisent l’autre compte Azure, incluez les variables suivantes dans le fichier de configuration du cluster :

AZURE_IDENTITY_NAME: EXAMPLE-IDENTITY
AZURE_IDENTITY_NAMESPACE: EXAMPLE-NAMESPACE

Où :

  • EXAMPLE-IDENTITY est le nom à utiliser pour l'objet AzureClusterIdentity.
  • EXAMPLE-NAMESPACE est l'espace de noms de votre objet AzureClusterIdentity.

Après avoir créé le cluster de charge de travail, connectez-vous au portail Azure à l'aide de l'autre compte. Vous devriez alors voir le cluster en cours d'exécution.

Clusters compatibles GPU

Il existe deux façons de déployer des clusters de charge de travail compatibles avec NVIDIA GPU sur Azure :

  • Créer un cluster de charge de travail avec des workers GPU et installer manuellement une stratégie GPU et un opérateur sur le cluster.
  • (Version d'évaluation technique) Configurer le cluster de gestion avec un objet ClusterResourceSet (CRS) pour créer automatiquement un ou plusieurs clusters de charge de travail compatibles GPU.

Les sous-sections ci-dessous expliquent ces deux approches et comment tester les clusters compatibles GPU.

Déployer un cluster unique et le rendre compatible GPU

Pour déployer un cluster de charge de travail et le configurer manuellement afin de tirer parti des machines virtuelles NVIDIA GPU disponibles sur Azure :

  1. Dans le fichier de configuration du cluster, définissez AZURE_NODE_MACHINE_TYPE, pour les nœuds worker, sur un type de machine virtuelle compatible GPU, tel que Standard_NC4as_T4_v3.

  2. Déployez le cluster avec le fichier de configuration du cluster :

    tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG

    Où MY-GPU-CLUSTER est un nom que vous attribuez au cluster.

  3. Installez une stratégie de cluster GPU et un opérateur GPU sur le cluster :

    1. Définissez le contexte kubectl context sur le cluster, s'il ne s'agit pas déjà du contexte actuel.

    2. Téléchargez les ressources NVIDIA GPU requises à partir du référentiel Azure du fournisseur d'API de cluster et enregistrez-les dans votre répertoire actuel :

    3. Appliquez la stratégie de cluster :

      kubectl apply clusterpolicy-crd.yaml

    4. Appliquez l'opérateur GPU :

      kubectl apply gpu-operator-components.yaml

  4. Exécutez kubectl get pods -A. Vous devez voir des listes pour les espaces gpu-operator- dans l'espace de noms default et les espaces nvidia- dans l'espace de noms gpu-operator-resources.

Configurer le cluster de gestion pour les déploiements de clusters GPU (version d'évaluation technique)

Remarque

Cette fonctionnalité est dans l'état Version d'évaluation technique non pris en charge. Reportez-vous à la section États des fonctionnalités TKG.

Vous pouvez configurer le cluster de gestion pour créer automatiquement des clusters de charge de travail compatibles GPU chaque fois que vous ajoutez gpu: nvidia aux étiquettes du manifeste du cluster. Pour ce faire, installez un objet ClusterResourceSet (CRS) et activez-le comme suit :

  1. Pour configurer le cluster de gestion afin de créer des clusters GPU :

    1. Dans la page d'échange d'exemple VMware {code}, recherchez le GPU CRS for TKG et téléchargez le fichier gpu-crs.yaml pour Tanzu Kubernetes Grid v1.4.

    2. Définissez le contexte de kubectl selon le contexte de votre cluster de gestion :

      kubectl config use-context my-management-cluster-admin@my-management-cluster

    3. Appliquez le fichier CRS au cluster de gestion à l'aide de l'option --server-side pour gérer la taille importante des données ConfigMap :

      kubectl apply -f gpu-crs.yaml --server-side

  2. Pour créer un cluster de charge de travail de GPU :

    1. Dans le fichier de configuration du cluster, définissez AZURE_NODE_MACHINE_TYPE, pour les nœuds worker, sur un type de machine virtuelle compatible GPU, tel que Standard_NC4as_T4_v3.

    2. Utilisez la commande tanzu cluster create avec l'option --dry-run pour générer un manifeste de déploiement à partir du fichier de configuration du cluster :

      tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG --dry-run > MY-GPU-CLUSTER-MANIFEST

      Où MY-GPU-CLUSTER est un nom que vous attribuez au cluster.

    3. Créez le cluster en le transmettant à kubectl apply :

      kubectl apply -f MY-GPU-CLUSTER-MANIFEST

    4. Exécutez kubectl get pods -A. Vous devez voir des listes pour les espaces gpu-operator- dans l'espace de noms default et les espaces nvidia- dans l'espace de noms gpu-operator-resources.

Tester les clusters compatibles GPU

Pour tester un cluster compatible GPU :

  1. Testez le traitement GPU en exécutant le test d'ajout de vecteur CUDA VectorAdd dans la documentation NVIDIA.

  2. Testez l’opérateur GPU :

    1. Augmentez le nombre de nœuds worker du cluster de charge de travail :

      tanzu cluster scale MY-GPU-CLUSTER -w 2

    2. Exécutez de nouveau la commande kubectl get pods -A. Vous devez voir des espaces gpu-operator- et nvidia- supplémentaires répertoriés pour les nœuds ajoutés.

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