Cette rubrique explique comment configurer un cluster de charge de travail avant de le déployer sur Amazon Web Services (AWS) 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 AWS, 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 se connecter à votre compte AWS et créer les ressources que le cluster utilisera. Par exemple, vous pouvez spécifier les tailles des machines virtuelles de nœud de plan de contrôle et worker, distribuer les nœuds entre les zones de disponibilité et partager des VPC entre les clusters.
Pour obtenir la liste complète des options que vous devez spécifier lors du déploiement de clusters de charge de travail sur AWS, reportez-vous à la section Référence de variable de fichier de configuration.
RemarquePour améliorer la sécurité dans un environnement à locataires multiples AWS, déployez les clusters de charge de travail sur un compte AWS différent de celui utilisé pour déployer le cluster de gestion. Pour déployer des clusters de charge de travail sur plusieurs comptes AWS, reportez-vous à la section Clusters sur différents comptes AWS.
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 AWS. Vous pouvez copier ce modèle et le mettre à jour pour déployer des clusters de charge de travail sur AWS.
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.
À l'exception des options décrites dans les sections sous le modèle, la manière dont vous configurez les variables des clusters de charge de travail spécifiques à AWS 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 de gestion pour AWS.
#! ---------------------------------------------------------------------
#! Cluster creation basic configuration
#! ---------------------------------------------------------------------
#! CLUSTER_NAME:
CLUSTER_PLAN: dev
NAMESPACE: default
# CLUSTER_API_SERVER_PORT:
CNI: antrea
IDENTITY_MANAGEMENT_TYPE: none
#! ---------------------------------------------------------------------
#! Node configuration
#! AWS-only MACHINE_TYPE settings override cloud-agnostic SIZE settings.
#! ---------------------------------------------------------------------
# SIZE:
# CONTROLPLANE_SIZE:
# WORKER_SIZE:
CONTROL_PLANE_MACHINE_TYPE: t3.large
NODE_MACHINE_TYPE: m5.large
# NODE_MACHINE_TYPE_1: ""
# NODE_MACHINE_TYPE_2: ""
# CONTROL_PLANE_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT: 1
# WORKER_MACHINE_COUNT_0:
# WORKER_MACHINE_COUNT_1:
# WORKER_MACHINE_COUNT_2:
#! ---------------------------------------------------------------------
#! AWS Configuration
#! ---------------------------------------------------------------------
AWS_REGION:
# AWS_LOAD_BALANCER_SCHEME_INTERNAL: false
AWS_NODE_AZ: ""
# AWS_NODE_AZ_1: ""
# AWS_NODE_AZ_2: ""
# AWS_VPC_ID: ""
# AWS_PRIVATE_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID: ""
# AWS_PUBLIC_SUBNET_ID_1: ""
# AWS_PRIVATE_SUBNET_ID_1: ""
# AWS_PUBLIC_SUBNET_ID_2: ""
# AWS_PRIVATE_SUBNET_ID_2: ""
# AWS_VPC_CIDR: 10.0.0.0/16
# AWS_PRIVATE_NODE_CIDR: 10.0.0.0/24
# AWS_PUBLIC_NODE_CIDR: 10.0.1.0/24
# AWS_PRIVATE_NODE_CIDR_1: 10.0.2.0/24
# AWS_PUBLIC_NODE_CIDR_1: 10.0.3.0/24
# AWS_PRIVATE_NODE_CIDR_2: 10.0.4.0/24
# AWS_PUBLIC_NODE_CIDR_2: 10.0.5.0/24
# AWS_SECURITY_GROUP_APISERVER_LB: ""
# AWS_SECURITY_GROUP_BASTION: ""
# AWS_SECURITY_GROUP_CONTROLPLANE: ""
# AWS_SECURITY_GROUP_LB: ""
# AWS_SECURITY_GROUP_NODE: ""
# AWS_IDENTITY_REF_KIND: ""
# AWS_IDENTITY_REF_NAME: ""
# AWS_CONTROL_PLANE_OS_DISK_SIZE_GIB: 80
# AWS_NODE_OS_DISK_SIZE_GIB: 80
AWS_SSH_KEY_NAME:
BASTION_HOST_ENABLED: true
#! ---------------------------------------------------------------------
#! 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: ""
Lorsque vous déployez un cluster sur AWS, définissez AWS_REGION sur la région dans laquelle vous souhaitez déployer le cluster. Vous pouvez définir AWS_REGION dans le fichier de configuration de cluster, une variable d'environnement local ou un profil d'informations d'identification, comme décrit dans la section Configurer les informations d'identification du compte AWS.
Lorsque vous créez un cluster prod dans plusieurs zones de disponibilité sur AWS, Tanzu Kubernetes Grid distribue uniformément ses nœuds de plan de contrôle et worker entre les zones de disponibilité (AZ) que vous avez spécifiées dans la configuration de votre cluster. Cela inclut les clusters de charge de travail qui sont configurés avec l'un des éléments suivants :
CONTROL_PLANE_MACHINE_COUNT supérieur au nombre de nœuds de plan de contrôle par défautWORKER_MACHINE_COUNT supérieur au nombre de nœuds worker par défautPar exemple, si vous spécifiez WORKER_MACHINE_COUNT: 5, Tanzu Kubernetes Grid déploie deux nœuds worker dans la première zone de disponibilité, deux nœuds worker dans la deuxième zone de disponibilité et un nœud worker dans la troisième zone de disponibilité. Vous pouvez éventuellement personnaliser ce mécanisme de placement par zone de disponibilité par défaut pour les nœuds worker en suivant les instructions de la section Configuration des paramètres de placement par zone de disponibilité pour les nœuds worker ci-dessous. Vous ne pouvez pas personnaliser le mécanisme de placement par zone de disponibilité par défaut pour les nœuds de plan de contrôle.
Lors de la création d'un cluster prod dans plusieurs zones de disponibilité sur AWS, vous pouvez éventuellement spécifier le nombre de nœuds worker que la commande tanzu cluster create crée dans chacune des trois zones de disponibilité.
Pour ce faire :
Incluez les variables suivantes dans votre fichier de configuration du cluster :
WORKER_MACHINE_COUNT_0 : Définit le nombre de nœuds worker dans la première zone de disponibilité, AWS_NODE_AZ.WORKER_MACHINE_COUNT_1 : Définit le nombre de nœuds worker dans la deuxième zone de disponibilité, AWS_NODE_AZ_1.WORKER_MACHINE_COUNT_2 : Définit le nombre de nœuds worker dans la troisième zone de disponibilité, AWS_NODE_AZ_2.Définissez ces variables en plus d'autres paramètres obligatoires et facultatifs, comme décrit dans la section Modèle de cluster de charge de travail ci-dessus.
Créez le cluster. Par exemple :
tanzu cluster create my-prod-cluster -f my-prod-cluster-config.yaml
Si vous souhaitez créer des services de type LoadBalancer dans le cluster, vous devez ajouter la balise kubernetes.io/cluster/YOUR-CLUSTER-NAME=shared aux sous-réseaux publics que vous prévoyez d'utiliser pour votre cluster de charge de travail.
L'ajout de la balise kubernetes.io/cluster/YOUR-CLUSTER-NAME=shared aux sous-réseaux publics vous permet de créer des services de type LoadBalancer après le déploiement du cluster. Pour ajouter cette balise, puis déployer le cluster, procédez comme suit :
Collectez l'ID ou les ID du ou des sous-réseaux publics dans votre VPC que vous souhaitez utiliser pour le cluster. Pour déployer un cluster de charge de travail prod, vous devez fournir trois sous-réseaux.
Créez la balise requise en exécutant la commande suivante :
aws ec2 create-tags --resources YOUR-PUBLIC-SUBNET-ID-OR-IDS --tags Key=kubernetes.io/cluster/YOUR-CLUSTER-NAME,Value=shared
Où :
YOUR-PUBLIC-SUBNET-ID-OR-IDS est l'ID ou les ID du ou des sous-réseaux publics que vous avez collectés à l'étape précédente.YOUR-CLUSTER-NAME est le nom du cluster de charge de travail que vous prévoyez de créer.Par exemple :
aws ec2 create-tags --resources subnet-00bd5d8c88a5305c6 subnet-0b93f0fdbae3436e8 subnet-06b29d20291797698 --tags Key=kubernetes.io/cluster/my-cluster,Value=shared
Configurer le cluster.
Créez le cluster. Par exemple :
tanzu cluster create my-cluster -f my-cluster-config.yaml
Reportez-vous aux sections ci-dessous pour obtenir des exemples de configurations de cluster avancées sur AWS :
Pour déployer un cluster de charge de travail qui tire parti des machines virtuelles basées sur NVIDIA GPU disponibles sur AWS :
Dans le fichier de configuration du cluster, définissez NODE_MACHINE_TYPE, pour les nœuds worker, sur un type de machine virtuelle compatible GPU, tel que g4dn.8xlarge.
Déployez le cluster avec le fichier de configuration du cluster :
tanzu cluster create MY-GPU-CLUSTER -f MY-GPU-CONFIG
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 AWS 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.
Pour tester le cluster compatible GPU, exécutez le test d'ajout de vecteur CUDA VectorAdd dans la documentation NVIDIA.
Pour tester 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.
Lorsque vous créez un cluster de charge de travail prod à partir d'un cluster de gestion dev qui s'exécute sur AWS, vous devez définir un sous-ensemble de variables supplémentaires dans le fichier de configuration du cluster avant d'exécuter la commande tanzu cluster create. Cela permet à Tanzu Kubernetes Grid de créer le cluster et de répartir ses nœuds de plan de contrôle et worker entre les zones de disponibilité.
Pour créer un cluster de charge de travail prod à partir d'un cluster de gestion dev sur AWS, procédez comme suit :
Définissez les variables suivantes dans le fichier de configuration du cluster :
PLAN sur prod.AWS_NODE_AZ : AWS_NODE_AZ a été défini lorsque vous avez déployé votre cluster de gestion dev. Pour le cluster de charge de travail prod, ajoutez AWS_NODE_AZ_1 et AWS_NODE_AZ_2.AWS_PUBLIC_SUBNET_ID (VPC existant) : AWS_PUBLIC_NODE_CIDR ou AWS_PUBLIC_SUBNET_ID a été défini lorsque vous avez déployé votre cluster de gestion dev. Pour le cluster de charge de travail prod, ajoutez l'une des options suivantes :
AWS_PUBLIC_NODE_CIDR_1 et AWS_PUBLIC_NODE_CIDR_2AWS_PUBLIC_SUBNET_ID_1 et AWS_PUBLIC_SUBNET_ID_2AWS_PRIVATE_SUBNET_ID (VPC existant) : AWS_PRIVATE_NODE_CIDR ou AWS_PRIVATE_SUBNET_ID a été défini lorsque vous avez déployé votre cluster de gestion dev. Pour le cluster de charge de travail prod, ajoutez l'une des options suivantes :
AWS_PRIVATE_NODE_CIDR_1 et AWS_PRIVATE_NODE_CIDR_2AWS_PRIVATE_SUBNET_ID_1 et AWS_PRIVATE_SUBNET_ID_2(Facultatif) Personnalisez le mécanisme de placement par zone de disponibilité par défaut pour les nœuds worker que vous prévoyez de déployer en suivant les instructions de la section Configuration des paramètres de placement par zone de disponibilité pour les nœuds worker. Par défaut, Tanzu Kubernetes Grid distribue uniformément les nœuds worker prod entre les zones de disponibilité.
Déployez le cluster en exécutant la commande tanzu cluster create. Par exemple :
tanzu cluster create my-cluster -f my-cluster-config.yaml
Vous pouvez déployer des clusters de charge de travail entre plusieurs comptes AWS si vos clusters Kubernetes sont connectés à Internet ou déployés dans des VPC homologues via l'homologation VPC ou la passerelle de transit AWS.
Pour préparer un compte AWS secondaire pour le déploiement de clusters de charge de travail, préparez le compte secondaire et configurez les relations de confiance entre celui-ci et le compte de cluster de gestion comme suit :
Tout d'abord, vous devez configurer des rôles IAM dans le compte AWS secondaire.
Pour ce faire, utilisez la commande tanzu mc permissions aws. Suivez le même processus que celui décrit dans la section Créer des ressources IAM de Déployer des clusters de gestion à partir d'un fichier de configuration.
Pour activer un cluster de gestion dans un compte AWS afin de déployer des clusters de charge de travail dans un compte AWS secondaire, vous devez d'abord configurer une stratégie d'approbation dans le compte secondaire.
Pour ce faire, recherchez les controllers.tkg.cloud.vmware.com créés par les tanzu mc permissions aws dans le compte secondaire. Modifiez ensuite la relation de confiance comme suit :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
},
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "arn:aws:iam::MANAGEMENT-ACCOUNT-ID:root"
},
}
]
}
Où MANAGEMENT-ACCOUNT-ID est l'ID de compte AWS dans lequel le cluster de gestion est déployé.
Après avoir configuré la stratégie d'approbation, activez le rôle IAM control-plane.tkg.cloud.vmware.com du compte du cluster de gestion pour assumer le rôle IAM controllers.tkg.cloud.vmware.com dans le compte secondaire.
Pour ce faire, attachez une nouvelle stratégie ou ajoutez une stratégie en ligne comme suit :
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::SECONDARY-ACCOUNT-ID:role/controllers.tkg.cloud.vmware.com"
}
]
}
Où SECONDARY-ACCOUNT-ID est l'ID de compte AWS du compte secondaire.
AWSClusterRoleIdentity dans le cluster de gestionPour configurer le nouveau rôle IAM entre comptes dans le cluster de gestion, vous devez créer un objet de ressource AWSClusterRoleIdentity dans Kubernetes comme suit :
apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4
kind: AWSClusterRoleIdentity
metadata:
name: IDENTITY-NAME
spec:
allowedNamespaces: {}
durationSeconds: 900
roleARN: "arn:aws:iam::SECONDARY-ACCOUNT-ID:role/controllers.tkg.cloud.vmware.com"
sourceIdentityRef:
kind: AWSClusterControllerIdentity
name: default
Où :
IDENTITY-NAME est tout élément qui identifie la ressource. Par exemple, un nom qui représente le compte de développement d'une branche d'activité (LOB-dev)SECONDARY-ACCOUNT-ID est l'ID des étapes de configuration précédentes.Les ressources AWSClusterRoleIdentity sont étendues globalement. Vous pouvez définir le champ allowedNamespaces pour limiter les espaces de noms autorisés à gérer les clusters à l'aide du rôle IAM, en définissant sa valeur sur une liste explicite d'espaces de noms ou sur un sélecteur. Reportez-vous à la section Sécuriser l'accès aux identités (Secure Access to Identities) du site The Cluster API Book.
Après avoir créé la ressource AWSClusterRoleIdentity, vous pouvez l'utiliser pour déployer un cluster de charge de travail sur le compte AWS secondaire.
Pour ce faire, incluez la ligne suivante dans le fichier de configuration de cluster et exécutez la commande tanzu cluster create avec l'une des options standard :
AWS_IDENTITY_REF_NAME: IDENTITY-NAME
Où IDENTITY-NAME est le nom du AWSClusterRoleIdentity créé à l'étape précédente.
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.
