Cette rubrique explique comment configurer un cluster de charge de travail avant de le déployer dans Microsoft Azure avec un cluster de gestion autonome. Pour obtenir des informations générales sur la configuration des clusters de charge de travail, reportez-vous à la section Configurer des clusters de charge de travail.
Pour configurer un cluster de charge de travail avant de le déployer sur Azure, vous créez un fichier de configuration de cluster ou un fichier de spécification d’objet de style Kubernetes. Lorsque vous transmettez l'un de ces fichiers à l'option -f de tanzu cluster create, la CLI Tanzu utilise les informations de configuration définies dans le fichier pour vous connecter à votre compte Azure et créer les ressources que le cluster utilisera.
Pour obtenir la liste complète des options que vous devez spécifier lors du déploiement de clusters de charge de travail sur Azure, reportez-vous à la section Référence de variable de fichier de configuration.
Pour créer un fichier de configuration de cluster, vous pouvez utiliser le modèle dans la section Modèle de cluster de travail ci-dessous. Après avoir créé le fichier de configuration, passez à la section Créer des clusters de charge de travail.
Le modèle ci-dessous inclut toutes les options pertinentes pour le déploiement de clusters de charge de travail sur Azure. Vous pouvez copier ce modèle et le mettre à jour pour déployer des clusters de charge de travail sur Azure.
Les marques de commentaire sont supprimées pour les options obligatoires. Elles sont ajoutées pour les paramètres facultatifs. Les valeurs par défaut sont incluses le cas échéant.
La manière dont vous configurez les variables des clusters de charge de travail spécifiques à Azure est identique pour les clusters de gestion et les clusters de charge de travail. Pour plus d'informations sur la configuration des variables, reportez-vous aux sections Déployer des clusters de gestion à partir d'un fichier de configuration et Configuration du cluster pour Azure.
#! ---------------------------------------------------------------------
#! Cluster creation basic configuration
#! ---------------------------------------------------------------------
# CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
# CLUSTER_API_SERVER_PORT:
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none
#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------
# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
# AZURE_CONTROL_PLANE_MACHINE_TYPE: "Standard_D2s_v3"
# AZURE_NODE_MACHINE_TYPE: "Standard_D2s_v3"
# CONTROL_PLANE_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT_0:
# WORKER_MACHINE_COUNT_1:
# WORKER_MACHINE_COUNT_2:
# AZURE_CONTROL_PLANE_OS_DISK_SIZE_GIB: 128
# AZURE_CONTROL_PLANE_OS_DISK_STORAGE_ACCOUNT_TYPE: Premium_LRS
# AZURE_NODE_OS_DISK_SIZE_GIB: 128
# AZURE_NODE_OS_DISK_STORAGE_ACCOUNT_TYPE: Premium_LRS
# AZURE_CONTROL_PLANE_DATA_DISK_SIZE_GIB: 256
# AZURE_ENABLE_NODE_DATA_DISK: false
# AZURE_NODE_DATA_DISK_SIZE_GIB: 256
#! ---------------------------------------------------------------------
#! Azure Configuration
#! ---------------------------------------------------------------------
AZURE_ENVIRONMENT: "AzurePublicCloud"
AZURE_TENANT_ID:
AZURE_SUBSCRIPTION_ID:
AZURE_CLIENT_ID:
AZURE_CLIENT_SECRET:
AZURE_LOCATION:
AZURE_SSH_PUBLIC_KEY_B64:
# AZURE_ENABLE_ACCELERATED_NETWORKING: true
# AZURE_RESOURCE_GROUP: ""
# AZURE_VNET_RESOURCE_GROUP: ""
# AZURE_VNET_NAME: ""
# AZURE_VNET_CIDR: "10.0.0.0/16"
# AZURE_CONTROL_PLANE_SUBNET_NAME: ""
# AZURE_CONTROL_PLANE_SUBNET_CIDR: "10.0.0.0/24"
# AZURE_CONTROL_PLANE_SUBNET_SECURITY_GROUP: ""
# AZURE_NODE_SUBNET_NAME: ""
# AZURE_NODE_SUBNET_CIDR: "10.0.1.0/24"
# AZURE_NODE_SUBNET_SECURITY_GROUP: ""
# AZURE_NODE_AZ: ""
# AZURE_NODE_AZ_1: ""
# AZURE_NODE_AZ_2: ""
# AZURE_CUSTOM_TAGS:
# AZURE_ENABLE_PRIVATE_CLUSTER: false
# AZURE_FRONTEND_PRIVATE_IP: "10.0.0.100"
# AZURE_ENABLE_CONTROL_PLANE_OUTBOUND_LB: false
# AZURE_ENABLE_NODE_OUTBOUND_LB: false
# AZURE_CONTROL_PLANE_OUTBOUND_LB_FRONTEND_IP_COUNT: 1
# AZURE_NODE_OUTBOUND_LB_FRONTEND_IP_COUNT: 1
# AZURE_NODE_OUTBOUND_LB_IDLE_TIMEOUT_IN_MINUTES: 4
# AZURE_IMAGE_ID:
# AZURE_IMAGE_RESOURCE_GROUP:
# AZURE_IMAGE_NAME:
# AZURE_IMAGE_SUBSCRIPTION_ID:
# AZURE_IMAGE_GALLERY:
# AZURE_IMAGE_PUBLISHER:
# AZURE_IMAGE_OFFER:
# AZURE_IMAGE_SKU:
# AZURE_IMAGE_THIRD_PARTY:
# AZURE_IMAGE_VERSION:
# AZURE_IDENTITY_NAME:
# AZURE_IDENTITY_NAMESPACE:
#! ---------------------------------------------------------------------
#! Machine Health Check configuration
#! ---------------------------------------------------------------------
ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_UNKNOWN_STATUS_TIMEOUT: 5m
MHC_FALSE_STATUS_TIMEOUT: 12m
#! ---------------------------------------------------------------------
#! Common configuration
#! ---------------------------------------------------------------------
# TKG_CUSTOM_IMAGE_REPOSITORY: ""
# TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: false
# TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: ""
# TKG_HTTP_PROXY: ""
# TKG_HTTPS_PROXY: ""
# TKG_NO_PROXY: ""
# TKG_PROXY_CA_CERT: ""
ENABLE_AUDIT_LOGGING: false
ENABLE_DEFAULT_STORAGE_CLASS: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
# OS_NAME: ""
# OS_VERSION: ""
# OS_ARCH: ""
#! ---------------------------------------------------------------------
#! Autoscaler configuration
#! ---------------------------------------------------------------------
ENABLE_AUTOSCALER: false
# AUTOSCALER_MAX_NODES_TOTAL: "0"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s"
# AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m"
# AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m"
# AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m"
# AUTOSCALER_MIN_SIZE_0:
# AUTOSCALER_MAX_SIZE_0:
# AUTOSCALER_MIN_SIZE_1:
# AUTOSCALER_MAX_SIZE_1:
# AUTOSCALER_MIN_SIZE_2:
# AUTOSCALER_MAX_SIZE_2:
#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------
# ANTREA_NO_SNAT: false
# ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
# ANTREA_TRAFFIC_ENCAP_MODE: "encap"
# ANTREA_EGRESS_EXCEPT_CIDRS: ""
# ANTREA_NODEPORTLOCAL_ENABLED: true
# ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
# ANTREA_PROXY_ALL: false
# ANTREA_PROXY_NODEPORT_ADDRS: ""
# ANTREA_PROXY_SKIP_SERVICES: ""
# ANTREA_PROXY_LOAD_BALANCER_IPS: false
# ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
# ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
# ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "30s"
# ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
# ANTREA_KUBE_APISERVER_OVERRIDE:
# ANTREA_TRANSPORT_INTERFACE:
# ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
# ANTREA_MULTICAST_INTERFACES: ""
# ANTREA_MULTICAST_IGMPQUERY_INTERVAL: "125s"
# ANTREA_TUNNEL_TYPE: geneve
# ANTREA_ENABLE_USAGE_REPORTING: false
# ANTREA_ENABLE_BRIDGING_MODE: false
# ANTREA_DISABLE_TXCHECKSUM_OFFLOAD: false
# ANTREA_DNS_SERVER_OVERRIDE: ""
# ANTREA_MULTICLUSTER_ENABLE: false
# ANTREA_MULTICLUSTER_NAMESPACE: ""
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 (NSG) sur le réseau virtuel du cluster et dans son groupe de ressources de réseau virtuel :
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.
Si vous spécifiez un réseau virtuel existant pour un cluster de charge de travail, vous devez créer ces NSG dans Azure. Un réseau virtuel existant pour un cluster de charge de travail est spécifié avec 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.
Reportez-vous au tableau Microsoft Azure dans la Référence de variable de fichier de configuration de CLI Tanzu pour savoir comment configurer le réseau virtuel, les groupes de ressources et les sous-réseaux du cluster.
Reportez-vous aux sections ci-dessous pour obtenir des exemples de configurations de cluster avancées sur 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.
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.
(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.
Tanzu Kubernetes Grid peut exécuter des clusters de charge de travail sur plusieurs comptes de fournisseurs d'infrastructure. 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 :
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.
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.
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.Utilisez le fichier pour créer l'objet Secret :
kubectl apply -f secret.yaml
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: ServicePrincipal
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.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.
Il existe deux façons de déployer des clusters de charge de travail compatibles avec NVIDIA GPU sur Azure :
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.
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 :
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.
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.
Installez une stratégie de cluster GPU et un opérateur GPU sur le cluster :
Définissez le contexte kubectl context sur le cluster, s'il ne s'agit pas déjà du contexte actuel.
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 :
Appliquez la stratégie de cluster :
kubectl apply clusterpolicy-crd.yaml
Appliquez l'opérateur GPU :
kubectl apply gpu-operator-components.yaml
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.
RemarqueCette 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 :
Pour configurer le cluster de gestion afin de créer des clusters GPU :
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.
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
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
Pour créer un cluster de charge de travail de GPU :
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.
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.
Créez le cluster en le transmettant à kubectl apply :
kubectl apply -f MY-GPU-CLUSTER-MANIFEST
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.
Pour tester un cluster compatible GPU :
Testez le traitement GPU en exécutant le test d'ajout de vecteur CUDA VectorAdd dans la documentation NVIDIA.
Testez l’opérateur GPU :
Augmentez le nombre de nœuds worker du cluster de charge de travail :
tanzu cluster scale MY-GPU-CLUSTER -w 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.
Vous pouvez utiliser la CLI Tanzu pour convertir un fichier de configuration de cluster en fichier de spécification d'objet de style Kubernetes pour un cluster de charge de travail basé sur une classe sans déployer le cluster. Pour créer le fichier, transmettez l'option --dry-run à tanzu cluster create et enregistrez la sortie dans un fichier. Utilisez les mêmes options et le même --file de configuration que vous utiliseriez pour créer le cluster. Par exemple :
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
Passez à la section Créer des clusters de charge de travail.
