Vous pouvez utiliser la CLI Tanzu pour déployer un cluster de gestion sur vSphere, Amazon Web Services (AWS) et Microsoft Azure avec une configuration que vous spécifiez dans un fichier de configuration YAML.
Avant de pouvoir déployer un cluster de gestion, vous devez vous assurer que votre environnement répond aux conditions requises pour la plate-forme cible.
TKG_CUSTOM_IMAGE_REPOSITORY
en tant que variable d'environnement.ImportantIl est fortement recommandé d'utiliser l'interface du programme d'installation Tanzu Kubernetes Grid plutôt que la CLI pour déployer votre premier cluster de gestion sur une plate-forme cible donnée. Lorsque vous déployez un cluster de gestion à l'aide de l'interface du programme d'installation, celle-ci renseigne un fichier de configuration de cluster pour le cluster de gestion avec les paramètres requis. Vous pouvez utiliser le fichier de configuration créé comme modèle pour les futurs déploiements à partir de la CLI vers cette plate-forme cible.
ImportantSur vSphere with Tanzu, vous n'avez pas besoin de déployer un cluster de gestion. Reportez-vous à la section Superviseur vSphere with Tanzu est un cluster de gestion.
t3.large
ou t3.xlarge
, reportez-vous à la page sur les types d'instances Amazon EC2.Avant de déployer un cluster de gestion sur AWS pour la première fois, vous devez créer une pile CloudFormation pour Tanzu Kubernetes Grid, tkg-cloud-vmware-com
, dans votre compte AWS. Cette pile CloudFormation inclut les ressources de gestion des identités et des accès (IAM) dont Tanzu Kubernetes Grid a besoin pour créer et exécuter des clusters sur AWS. Pour plus d'informations, reportez-vous à la section Autorisations définies par Tanzu Kubernetes Grid dans Préparer le déploiement de clusters de gestion sur AWS.
Si vous avez déjà créé la pile CloudFormation pour Tanzu Kubernetes Grid dans votre compte AWS, ignorez le reste de cette procédure.
Si vous n'avez pas déjà créé la pile CloudFormation pour Tanzu Kubernetes Grid dans votre compte AWS, assurez-vous que les variables d'authentification AWS sont définies dans l'environnement local ou dans votre chaîne de fournisseurs d'informations d'identification AWS par défaut. Pour obtenir des instructions, reportez-vous à la section Configurer des informations d'identification du compte AWS et la clé SSH.
Si vous avez configuré les informations d'identification AWS à plusieurs emplacements, les paramètres d'informations d'identification utilisés pour créer la pile CloudFormation sont appliqués dans l'ordre de priorité suivant :
AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, AWS_SESSION_TOKEN
et AWS_REGION
sont appliquées en premier.Informations d'identification stockées dans un fichier d'informations d'identification partagé dans le cadre de la chaîne de fournisseurs d'informations d'identification par défaut. Vous pouvez spécifier l'emplacement du fichier d'informations d'identification à utiliser dans la variable d'environnement local AWS_SHARED_CREDENTIAL_FILE
. Si cette variable d'environnement n'est pas définie, l'emplacement par défaut de $HOME/.aws/credentials
est utilisé. Si vous utilisez des profils d'informations d'identification, la commande utilise le nom de profil spécifié dans la variable de configuration de l'environnement local AWS_PROFILE
. Si vous ne spécifiez pas de valeur pour cette variable, le profil nommé default
est utilisé.
Pour obtenir un exemple de la manière dont la chaîne de fournisseurs d'informations d'identification AWS par défaut est interprétée pour les applications Java, reportez-vous à la section Utilisation des informations d'identification AWS de la documentation AWS.
Exécutez la commande suivante :
tanzu mc permissions aws set
Pour en savoir plus sur cette commande, exécutez tanzu mc permissions aws set --help
.
Importantla commande
tanzu mc permissions aws set
remplace l'utilitaire de ligne de commandeclusterawsadm
qui existait dans Tanzu Kubernetes Grid versions 1.1.x et antérieures. Pour les clusters de gestion et de charge de travail existants initialement déployés avec la version 1.1.x ou antérieure, continuez à utiliser la pile CloudFormation qui a été créée en exécutant la commandeclusterawsadm alpha bootstrap create-stack
. Pour les clusters Tanzu Kubernetes Grid 1.2 et versions ultérieures, utilisez la piletkg-cloud-vmware-com
.
Pour plus d'informations sur les configurations des différentes tailles d'instances de nœud pour Azure, par exemple, Standard_D2s_v3
ou Standard_D4s_v3
, reportez-vous à la section Tailles des machines virtuelles dans Azure.
Avant de créer un cluster de gestion à l'aide de l'interface de la CLI Tanzu, vous devez définir sa configuration dans un fichier de configuration YAML qui fournit la configuration de base pour le cluster. Lorsque vous déployez le cluster de gestion à partir de la CLI, vous spécifiez ce fichier à l'aide de l'option --file
de la commande tanzu mc create
.
La première exécution de la commande tanzu config init
crée le sous-répertoire ~/.config/tanzu/tkg
qui contient les fichiers de configuration Tanzu Kubernetes Grid.
Si vous avez précédemment déployé un cluster de gestion en exécutant tanzu mc create --ui
, le répertoire ~/.config/tanzu/tkg/clusterconfigs
contient des fichiers de configuration du cluster de gestion avec les paramètres enregistrés à partir de chaque appel de l'interface du programme d'installation. En fonction de l'infrastructure sur laquelle vous avez déployé le cluster de gestion, vous pouvez utiliser ces fichiers comme modèles pour les fichiers de configuration de cluster pour les nouveaux déploiements sur la même infrastructure. Vous pouvez également créer des fichiers de configuration de cluster de gestion à partir des modèles fournis dans cette documentation.
VMware recommande d'utiliser un fichier de configuration dédié pour chaque cluster de gestion, avec des paramètres de configuration spécifiques à une seule infrastructure.
Créez un fichier de configuration de cluster de gestion autonome en utilisant les instructions et les modèles ci-dessous.
Pour plus de détails sur chaque variable, reportez-vous à la Référence de variable du fichier de configuration.
Important- Comme décrit dans la section Configuration du cluster de gestion, les variables d'environnement remplacent les valeurs d'un fichier de configuration de cluster. Pour utiliser tous les paramètres d'un fichier de configuration de cluster, annulez les variables d'environnement conflictuelles avant de déployer le cluster de gestion à partir de la CLI. - La prise en charge des adresses IPv6 dans Tanzu Kubernetes Grid est limitée. Reportez-vous à la section Déployer des clusters sur IPv6 (vSphere uniquement). Si vous n'effectuez pas un déploiement dans un environnement de mise en réseau IPv6 uniquement, tous les paramètres d'adresse IP de vos fichiers de configuration doivent être IPv4. - Certains paramètres configurent des propriétés identiques. Par exemple, la propriété
SIZE
configure les mêmes paramètres d'infrastructure que toutes les propriétés de taille et de type du plan de contrôle et du nœud worker pour les différentes plates-formes cibles, mais à un niveau plus général. Dans ce cas, évitez de définir des propriétés conflictuelles ou redondantes.
Pour créer un fichier de configuration pour le déploiement d'un cluster de gestion autonome :
Copiez et collez le contenu du modèle pour votre plate-forme cible dans un éditeur de texte.
Copiez un modèle à partir de l'un des emplacements suivants :
Par exemple, si vous avez déjà déployé un cluster de gestion à partir de l'interface du programme d'installation, vous pouvez enregistrer le fichier dans l'emplacement par défaut pour les configurations de cluster, ~/.config/tanzu/tkg/clusterconfigs
.
Enregistrez le fichier avec une extension .yaml
et un nom approprié, par exemple aws-mgmt-cluster-config.yaml
.
Les sections suivantes décrivent comment mettre à jour les paramètres communs à toutes les plates-formes cibles, ainsi que les paramètres spécifiques à chacune des instances de vSphere, d'AWS et d'Azure.
Les paramètres de base pour la création du cluster de gestion définissent l'infrastructure sur laquelle déployer le cluster de gestion et d'autres paramètres de base. Ils sont communs à toutes les plates-formes cibles.
CLUSTER_PLAN
, spécifiez si vous souhaitez déployer un cluster de développement, qui fournit un nœud du plan de contrôle unique, ou un cluster de production, qui fournit un cluster de gestion hautement disponible avec trois nœuds du plan de contrôle. Spécifiez dev
ou prod
.Pour INFRASTRUCTURE_PROVIDER
, spécifiez aws
, azure
ou vsphere
.
INFRASTRUCTURE_PROVIDER: aws
INFRASTRUCTURE_PROVIDER: azure
INFRASTRUCTURE_PROVIDER: vsphere
Vous pouvez désactiver la participation au programme d'amélioration du produit (CEIP) VMware en définissant ENABLE_CEIP_PARTICIPATION
sur false
. Pour plus d'informations sur le programme d'amélioration du produit, reportez-vous aux sections Gérer la participation au programme d'amélioration du produit et https://www.vmware.com/solutions/trustvmware/ceip.html.
ENABLE_AUDIT_LOGGING
sur false
. Pour plus d'informations sur la journalisation d'audit, reportez-vous à la section Journalisation d'audit.CLUSTER_CIDR
pour le réseau de l'espace du cluster et SERVICE_CIDR
pour le réseau de service de cluster.Par exemple :
#! ---------------------------------------------------------------------
#! Basic cluster creation configuration
#! ---------------------------------------------------------------------
CLUSTER_NAME: aws-mgmt-cluster
CLUSTER_PLAN: dev
INFRASTRUCTURE_PROVIDER: aws
ENABLE_CEIP_PARTICIPATION: true
ENABLE_AUDIT_LOGGING: true
CLUSTER_CIDR: 100.96.0.0/11
SERVICE_CIDR: 100.64.0.0/13
Définissez IDENTITY_MANAGEMENT_TYPE
sur ldap
ou oidc
. Définissez cette option sur none
ou omettez de désactiver la gestion des identités. Il est vivement recommandé d'activer la gestion des identités pour les déploiements de production.
IDENTITY_MANAGEMENT_TYPE: oidc
IDENTITY_MANAGEMENT_TYPE: ldap
Pour configurer OIDC, mettez à jour les variables ci-dessous. Pour plus d'informations sur la configuration des variables, reportez-vous à la section Fournisseurs d'identité – OIDC de la Référence de variable du fichier de configuration.
Par exemple :
OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email
Pour configurer LDAP, annulez la mise en commentaire et mettez à jour les variables LDAP_*
avec des informations sur votre serveur LDAPS. Pour plus d'informations sur la configuration des variables, reportez-vous à la section Fournisseurs d'identité – LDAP de la Référence de variable du fichier de configuration.
Par exemple :
LDAP_BIND_DN: ""
LDAP_BIND_PASSWORD: ""
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: memberUid
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: (objectClass=posixAccount)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
LDAP_USER_SEARCH_USERNAME: uid
Pour pouvoir envoyer le trafic HTTP(S) sortant du cluster de gestion vers un proxy, par exemple dans un environnement à accès restreint à Internet, annulez la mise en commentaire et définissez les paramètres *_PROXY
. Les paramètres de proxy sont communs à toutes les plates-formes cibles. Vous pouvez choisir d'utiliser un proxy pour les demandes HTTP et un autre proxy pour les demandes HTTPS ou d'utiliser le même proxy pour les demandes HTTP et HTTPS. Vous ne pouvez pas modifier le proxy après avoir déployé le cluster.
Remarquesur vSphere, le trafic entre les machines virtuelles du cluster et vCenter ne peut pas être mis en proxy. Dans un environnement vSphere mis en proxy, vous devez définir
VSPHERE_INSECURE
surtrue
ou ajouter l'adresse IP ou le nom d'hôte vCenter à la listeTKG_NO_PROXY
.
TKG_HTTP_PROXY_ENABLED
: définissez cette option sur true
pour configurer un proxy.
TKG_PROXY_CA_CERT
: définissez cette option sur l'autorité de certification du serveur proxy si son certificat est auto-signé.
TKG_HTTP_PROXY
: il s'agit de l'URL du proxy qui gère les demandes HTTP. Pour définir l'URL, utilisez le format ci-dessous :
PROTOCOL://USERNAME:PASSWORD@FQDN-OR-IP:PORT
Où :
PROTOCOL
: la valeur doit être http
.USERNAME
et PASSWORD
: il s'agit du nom d'utilisateur et du mot de passe de votre proxy HTTP. Vous devez définir USERNAME
et PASSWORD
si le proxy nécessite une authentification.Remarque : lors du déploiement de clusters de gestion avec la CLI, les caractères non alphanumériques suivants ne peuvent pas être utilisés dans les mots de passe : # ` ^ | / \ ? % ^ { [ ] }" < >
.
FQDN-OR-IP
: il s'agit du nom de domaine complet ou de l'adresse IP de votre proxy HTTP.PORT
: il s'agit du numéro de port que votre proxy HTTP utilise.Par exemple, http://user:[email protected]:1234
.
TKG_HTTPS_PROXY
: il s'agit de l'URL du proxy qui gère les demandes HTTPS. Vous pouvez définir TKG_HTTPS_PROXY
sur la même valeur que TKG_HTTP_PROXY
ou fournir une valeur différente. Pour définir la valeur, utilisez le format d'URL de l'étape précédente, où :
PROTOCOL
: la valeur doit être http
.USERNAME
et PASSWORD
: il s'agit de vos nom d'utilisateur et mot de passe de proxy HTTPS. Vous devez définir USERNAME
et PASSWORD
si le proxy nécessite une authentification.Remarque : lors du déploiement de clusters de gestion avec la CLI, les caractères non alphanumériques suivants ne peuvent pas être utilisés dans les mots de passe : # ` ^ | / \ ? % ^ { [ ] }" < >
.
FQDN-OR-IP
: il s'agit du nom de domaine complet ou de l'adresse IP de votre proxy HTTPS.PORT
: il s'agit du numéro de port que votre proxy HTTPS utilise.Par exemple, http://user:[email protected]:1234
.
TKG_NO_PROXY
: cette option définit un ou plusieurs CIDR ou noms d'hôte de réseau séparés par des virgules qui doivent contourner le proxy HTTP(S), par exemple pour permettre au cluster de gestion de communiquer directement avec l'infrastructure qui s'exécute sur le même réseau, derrière le même proxy. N'utilisez pas d'espaces dans le paramètre de liste séparée par des virgules. Par exemple, noproxy.yourdomain.com,192.168.0.0/24
.
Sur vSphere, cette liste doit inclure :
VSPHERE_NETWORK
, qui inclut l'adresse IP du point de terminaison de plan de contrôle. Si vous définissez VSPHERE_CONTROL_PLANE_ENDPOINT
sur un nom de domaine complet, ajoutez également ce nom de domaine complet à la liste TKG_NO_PROXY
.En interne, Tanzu Kubernetes Grid ajoute localhost
, 127.0.0.1
, les valeurs de CLUSTER_CIDR
et SERVICE_CIDR
, .svc
et .svc.cluster.local
à la valeur que vous avez définie dans TKG_NO_PROXY
. Il ajoute également votre CIDR VPC AWS et 169.254.0.0/16
pour les déploiements vers AWS et votre CIDR VNET Azure, 169.254.0.0/16
et 168.63.129.16
pour les déploiements vers Azure. Pour vSphere, vous devez ajouter manuellement le CIDR de VSPHERE_NETWORK
, ce qui inclut l'adresse IP de votre point de terminaison de plan de contrôle, à TKG_NO_PROXY
. Si vous définissez VSPHERE_CONTROL_PLANE_ENDPOINT
sur un nom de domaine complet, ajoutez le nom de domaine complet et VSPHERE_NETWORK
à TKG_NO_PROXY
.
Importantsi les machines virtuelles du cluster doivent communiquer avec des services externes et des points de terminaison d'infrastructure dans votre environnement Tanzu Kubernetes Grid, assurez-vous que ces points de terminaison sont accessibles par les proxys que vous avez définis ci-dessus ou ajoutez-les à
TKG_NO_PROXY
. En fonction de la configuration de votre environnement, cela peut inclure, sans s'y limiter :
Par exemple :
#! ---------------------------------------------------------------------
#! Proxy configuration
#! ---------------------------------------------------------------------
TKG_HTTP_PROXY_ENABLED: true
TKG_PROXY_CA_CERT: "LS0t[...]tLS0tLQ==""
TKG_HTTP_PROXY: "http://myproxy.com:1234"
TKG_HTTPS_PROXY: "http://myproxy.com:1234"
TKG_NO_PROXY: "noproxy.yourdomain.com,192.168.0.0/24"
Par défaut, tous les nœuds de cluster exécutent Ubuntu v20.04, pour toutes les plates-formes cibles. Sur vSphere vous pouvez également déployer des clusters qui exécutent Photon OS sur leurs nœuds. Sur AWS, les nœuds peuvent également exécuter Amazon Linux 2. Pour l'architecture, l'option par défaut et la seule option actuelle est amd64
. Pour les paramètres de système d'exploitation et de version, reportez-vous à la section Configuration du nœud de la Référence de variable du fichier de configuration.
Par exemple :
#! ---------------------------------------------------------------------
#! Node configuration
#! ---------------------------------------------------------------------
OS_NAME: "photon"
OS_VERSION: "3"
OS_ARCH: "amd64"
La manière dont vous définissez la configuration et les tailles de calcul du nœud dépend de la plate-forme cible. Pour plus d'informations, reportez-vous aux sections Configuration du cluster de gestion pour vSphere, Configuration du configuration de cluster de gestion pour AWS ou Configuration du cluster de gestion pour Microsoft Azure.
Vous pouvez également mettre à jour les variables en fonction de vos préférences de déploiement et en suivant les directives décrites dans la section Contrôles de santé de la machine de la Référence de variable du fichier de configuration.
Par exemple :
ENABLE_MHC:
ENABLE_MHC_CONTROL_PLANE: true
ENABLE_MHC_WORKER_NODE: true
MHC_MAX_UNHEALTHY_CONTROL_PLANE: 60%
MHC_MAX_UNHEALTHY_WORKER_NODE: 60%
MHC_UNKNOWN_STATUS_TIMEOUT: 10m
MHC_FALSE_STATUS_TIMEOUT: 20m
Si vous déployez le cluster de gestion dans un environnement à accès restreint à Internet, annulez la mise en commentaire et mettez à jour les paramètres TKG_CUSTOM_IMAGE_REPOSITORY_*
. Ces paramètres sont communs à toutes les plates-formes cibles. Vous n'avez pas besoin de configurer les paramètres du registre d'images privé si :
TKG_CUSTOM_IMAGE_REPOSITORY_*
en exécutant la commande tanzu config set
, comme décrit dans la section Préparer un environnement à accès restreint à Internet. Les variables d'environnement définies en exécutant tanzu config set
remplacent les valeurs d'un fichier de configuration de cluster.Par exemple :
#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------
TKG_CUSTOM_IMAGE_REPOSITORY: "custom-image-repository.io/yourproject"
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: "LS0t[...]tLS0tLQ=="
Par défaut, les clusters que vous déployez avec la CLI Tanzu fournissent une mise en réseau de conteneur dans le cluster avec l'interface réseau de conteneur (CNI, Container Network Interface) Antrea.
Vous pouvez désactiver la traduction d'adresse réseau source (SNAT, Source Network Address Translation) pour le trafic de l'espace, implémenter les modes d'encapsulation de trafic hybrid
, noEncap
et NetworkPolicyOnly
, utiliser des proxys et des stratégies réseau, et implémenter Traceflow.
Pour plus d'informations sur Antrea, reportez-vous aux ressources suivantes :
Pour configurer ces fonctionnalités sur Antrea, annuler la mise en commentaire et mettez à jour les variables ANTREA_*
. Par exemple :
#! ---------------------------------------------------------------------
#! Antrea CNI configuration
#! ---------------------------------------------------------------------
ANTREA_NO_SNAT: true
ANTREA_NODEPORTLOCAL: true
ANTREA_NODEPORTLOCAL_ENABLED: true
ANTREA_NODEPORTLOCAL_PORTRANGE: 61000-62000
ANTREA_TRAFFIC_ENCAP_MODE: "encap"
ANTREA_PROXY: true
ANTREA_PROXY_ALL: true
ANTREA_PROXY_LOAD_BALANCER_IPS: false
ANTREA_PROXY_NODEPORT_ADDRS:
ANTREA_PROXY_SKIP_SERVICES: ""
ANTREA_POLICY: true
ANTREA_TRACEFLOW: true
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD: false
ANTREA_ENABLE_USAGE_REPORTING: false
ANTREA_EGRESS: true
ANTREA_EGRESS_EXCEPT_CIDRS: ""
ANTREA_FLOWEXPORTER: false
ANTREA_FLOWEXPORTER_COLLECTOR_ADDRESS: "flow-aggregator.flow-aggregator.svc:4739:tls"
ANTREA_FLOWEXPORTER_POLL_INTERVAL: "5s"
ANTREA_FLOWEXPORTER_ACTIVE_TIMEOUT: "5s"
ANTREA_FLOWEXPORTER_IDLE_TIMEOUT: "15s"
ANTREA_IPAM: false
ANTREA_KUBE_APISERVER_OVERRIDE: ""
ANTREA_MULTICAST: false
ANTREA_MULTICAST_INTERFACES: ""
ANTREA_NETWORKPOLICY_STATS: true
ANTREA_SERVICE_EXTERNALIP: true
ANTREA_TRAFFIC_ENCRYPTION_MODE: none
ANTREA_TRANSPORT_INTERFACE: ""
ANTREA_TRANSPORT_INTERFACE_CIDRS: ""
Continuez à mettre à jour les paramètres du fichier de configuration pour vSphere, AWS ou Azure. Pour les paramètres du fichier de configuration propres à chaque plate-forme cible, reportez-vous à la rubrique correspondante :
tanzu mc create
Après avoir créé ou mis à jour le fichier de configuration du cluster et téléchargé la nomenclature la plus récente, vous pouvez déployer un cluster de gestion en exécutant la commande tanzu mc create --file CONFIG-FILE
, où CONFIG-FILE
est le nom du fichier de configuration. Si votre fichier de configuration est le fichier de configuration par défaut ~/.config/tanzu/tkg/cluster-config.yaml
, vous pouvez omettre l'option --file
. Si vous souhaitez vérifier le manifeste Kubernetes indiquant que la commande tanzu mc create
s'appliquera, vous pouvez utiliser l'indicateur --dry-run
pour imprimer le manifeste sans apporter de modifications. Cet appel exécutera toujours les contrôles de validation décrits ci-dessous avant de générer le manifeste Kubernetes.
Attention :la commande
tanzu mc create
prend du temps pour s'exécuter entièrement. Lorsquetanzu mc create
est en cours d'exécution, n'exécutez pas d'appels supplémentaires detanzu mc create
sur la même machine de démarrage pour déployer plusieurs clusters de gestion, changer le contexte ou modifier~/.kube-tkg/config
.
Pour déployer un cluster de gestion, exécutez la commande tanzu mc create
. Par exemple :
tanzu mc create --file path/to/cluster-config-file.yaml
Lorsque vous exécutez tanzu mc create
, la commande effectue plusieurs contrôles de validation avant de déployer le cluster de gestion. Les vérifications sont différentes en fonction de l'infrastructure sur laquelle vous déployez le cluster de gestion.
Si l'une de ces conditions n'est pas satisfaite, la commande tanzu mc create
échoue.
Lorsque vous exécutez tanzu mc create
, vous pouvez suivre la progression du déploiement du cluster de gestion dans le terminal. La première exécution de tanzu mc create
prend plus de temps que les exécutions suivantes, car elle doit extraire les images Docker requises dans le magasin d'images sur votre machine de démarrage. Les exécutions suivantes ne nécessitent pas cette étape, elles sont donc plus rapides.
Si tanzu mc create
échoue avant le déploiement du cluster de gestion, vous devez nettoyer les artefacts sur votre machine de démarrage avant de réexécuter tanzu mc create
. Pour plus d'informations, reportez-vous à la rubrique Dépannage des problèmes de cluster de gestion. Si la machine sur laquelle vous exécutez tanzu mc create
s'arrête ou redémarre avant la fin des opérations locales, le déploiement échouera.
Si le déploiement réussit, un message de confirmation s’affiche dans le terminal :
Management cluster created! You can now create your first workload cluster by running tanzu cluster create [name] -f [file]
Pour plus d'informations sur ce qui s'est passé lors du déploiement du cluster de gestion, sur la connexion de kubectl
au cluster de gestion, sur la création d'espaces de noms et sur l'enregistrement du cluster de gestion dans Tanzu Mission Control, reportez-vous à la section Examiner et enregistrer un cluster de gestion autonome récemment déployé.