Déployer des clusters de gestion à partir d'un fichier de configuration

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.

Conditions requises

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.

Conditions préalables générales

  • Assurez-vous que vous avez respecté toutes les conditions requises et que vous avez suivi l'ensemble des procédures décrites dans la section Installer la CLI Tanzu et la CLI Kubernetes à utiliser avec des clusters de gestion autonomes.
  • 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 préparatoires à 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 déployez des clusters dans un environnement à accès restreint à Internet vers vSphere ou AWS, vous devez également effectuer les étapes décrites dans la section Préparer un environnement à accès restreint à Internet. Ces étapes incluent la définition de TKG_CUSTOM_IMAGE_REPOSITORY en tant que variable d'environnement.
  • Important

    Il 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.

  • Si vous prévoyez d'enregistrer le cluster de gestion dans Tanzu Mission Control, assurez-vous que vos clusters de charge de travail répondent aux conditions requises répertoriées dans la section Conditions requises pour l'enregistrement d'un cluster Tanzu Kubernetes dans Tanzu Mission Control de la documentation Tanzu Mission Control.

Conditions préalables à l'infrastructure

vSphere
Assurez-vous que vous avez respecté toutes les conditions requises répertoriées dans la section Préparer le déploiement des clusters de gestion dans vSphere.
Important

Sur vSphere with Tanzu, vous n'aurez peut-être pas besoin de déployer un cluster de gestion. Reportez-vous à la section Superviseur vSphere with Tanzu est un cluster de gestion.

AWS
Assurez-vous que vous avez respecté toutes les conditions requises répertoriées dans la section Préparer le déploiement des clusters de gestion sur AWS.
  • Pour plus d'informations sur les configurations des différentes tailles d'instances de nœud, par exemple, t3.large ou t3.xlarge, reportez-vous à la page sur les types d'instances Amazon EC2.
  • Pour savoir quand créer un Virtual Private Cloud (VPC) et quand réutiliser un VPC existant, reportez-vous à la section Utilisation des ressources dans votre compte Amazon Web Services.
  • Si vous déployez un cluster de gestion sur AWS pour la première fois, créez une pile CloudFormation pour Tanzu Kubernetes Grid dans votre compte AWS en suivant les instructions de la section Créer des ressources IAM ci-dessous.

Créer des ressources IAM

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.

  1. Si vous avez déjà créé la pile CloudFormation pour Tanzu Kubernetes Grid dans votre compte AWS, ignorez le reste de cette procédure.

  2. 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 :

    • Les informations d'identification définies dans les variables d'environnement local 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.

  3. 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.

Important

la commande tanzu mc permissions aws set remplace l'utilitaire de ligne de commande clusterawsadm 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 commande clusterawsadm alpha bootstrap create-stack. Pour les clusters Tanzu Kubernetes Grid 1.2 et versions ultérieures, utilisez la pile tkg-cloud-vmware-com.

Azure
Assurez-vous que vous avez respecté les conditions requises répertoriées dans la section Préparer le déploiement des clusters de gestion sur Microsoft Azure.

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.


Créer un fichier de configuration de cluster de gestion

Avant de créer un cluster de gestion à partir d'un fichier de configuration, vous devez créer le fichier. 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.

  • Pour utiliser le fichier de configuration d'un déploiement précédent que vous avez effectué à l'aide de l'interface du programme d'installation, effectuez une copie du fichier de configuration avec un nouveau nom, ouvrez-le dans un éditeur de texte et mettez à jour la configuration. Pour plus d'informations sur la mise à jour de tous les paramètres, reportez-vous à la Référence de variable du fichier de configuration.

La Référence de variable de fichier de configuration explique toutes les variables que le fichier de configuration peut inclure.

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.

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 un cluster de gestion autonome :

  1. Dans un éditeur de texte, ouvrez un nouveau fichier avec une extension .yaml et un nom approprié, par exemple aws-mgmt-cluster-config.yaml. Il s'agit de votre fichier de configuration.

    Si vous avez déjà déployé un cluster de gestion à partir de l'interface du programme d'installation, vous pouvez créer le fichier dans l'emplacement par défaut pour les configurations de cluster, ~/.config/tanzu/tkg/clusterconfigs.

  2. Pour faire référence à la rubrique ci-dessous qui correspond à votre infrastructure, copiez-collez le code de modèle en haut de la page dans votre fichier de configuration :

  3. Configurez les paramètres dans le fichier :

    • Pour configurer des options propres à l'infrastructure, suivez les instructions du reste de la page propre à l'infrastructure.
    • Suivez les instructions du reste de cette page pour configurer les paramètres communs à toutes les plates-formes cibles.

  4. Enregistrez le fichier.

Configurer les informations de base de la création du cluster de gestion

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.

  • Pour 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.

  • Vous pouvez également désactiver la journalisation d'audit en définissant ENABLE_AUDIT_LOGGING sur false. Pour plus d'informations sur la journalisation d'audit, reportez-vous à la section Journalisation d'audit.
  • Si les plages CIDR recommandées de 100.64.0.0/13 et 100.96.0.0/11 ne sont pas disponibles, mettez à jour 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

Configurer la gestion des identités

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

OIDC

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,offline_access
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

LDAP

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: "cn=bind-user,ou=people,dc=example,dc=com"
LDAP_BIND_PASSWORD: "example-password"
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: &(objectClass=posixGroup)(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)(uid={})
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid

Configurer des proxys

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.

Remarque

sur 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 sur true ou ajouter l'adresse IP ou le nom d'hôte vCenter à la liste TKG_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ù :

    • (Obligatoire) PROTOCOL: la valeur doit être http.
    • (Facultatif) 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 : # ` ^ | / \ ? % ^ { [ ] }" < >.

    • (Obligatoire) FQDN-OR-IP: il s'agit du nom de domaine complet ou de l'adresse IP de votre proxy HTTP.
    • (Obligatoire) 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ù :

    • (Obligatoire) PROTOCOL: la valeur doit être http.
    • (Facultatif) 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 : # ` ^ | / \ ? % ^ { [ ] }" < >.

    • (Obligatoire) FQDN-OR-IP: il s'agit du nom de domaine complet ou de l'adresse IP de votre proxy HTTPS.
    • (Obligatoire) 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 :

    • L'adresse IP ou le nom d'hôte vCenter.
    • Le CIDR de 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.

    Important

    si 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 :

    • Votre serveur OIDC ou LDAP
    • Harbor
    • VMware NSX
    • NSX Advanced Load Balancer
    • Les CIDR VPC AWS externes au cluster

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"

Configurer les paramètres de nœud

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.

Configurer les contrôles de santé de la machine

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

Configurer un registre d'images privé

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 :

  • Vous déployez le cluster de gestion dans un environnement à accès restreint à Internet et vous avez défini les variables 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.
  • Si vous déployez le cluster de gestion dans un environnement ayant accès à l'Internet externe.

Par exemple :

#! ---------------------------------------------------------------------
#! Image repository configuration
#! ---------------------------------------------------------------------

TKG_CUSTOM_IMAGE_REPOSITORY: "custom-image-repository.io/yourproject"
TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE: "LS0t[...]tLS0tLQ=="

Configurer la CNI Antrea

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: ""

Exécuter la commande 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. Lorsque tanzu mc create est en cours d'exécution, n'exécutez pas d'appels supplémentaires de tanzu 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

Contrôles de validation

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.

vSphere
La commande vérifie que l'infrastructure vSphere cible répond aux exigences suivantes :
  • Les informations d'identification vSphere que vous avez fournies sont valides.
  • Les nœuds répondent aux exigences de taille minimale.
  • Le modèle d'image de base existe dans vSphere et est valide pour la version de Kubernetes spécifiée.
  • Les ressources requises, y compris le pool de ressources, les banques de données et le dossier, existent dans vSphere.
AWS
La commande vérifie que l'infrastructure AWS cible répond aux exigences suivantes :
  • Les informations d’identification AWS que vous avez fournies sont valides.
  • La pile CloudFormation existe.
  • Le type d’instance de nœud est pris en charge.
  • La région et la zone de disponibilité correspondent.
Azure
La commande vérifie que l'infrastructure Azure cible répond aux exigences suivantes :
  • Les informations d’identification Azure que vous avez fournies sont valides.
  • La clé SSH publique est codée au format base64.
  • Le type d’instance de nœud est pris en charge.

Si l'une de ces conditions n'est pas satisfaite, la commande tanzu mc create échoue.

Surveillance de la progression

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]

Tâches suivantes

  • Configurer la gestion des identités : si vous avez activé la gestion des identités OIDC ou LDAP pour le cluster de gestion, vous devez effectuer les étapes de post-déploiement décrites dans la section Terminer la configuration de la gestion des identités pour activer l'accès.
  • Enregistrez votre cluster de gestion dans Tanzu Mission Control : si vous souhaitez enregistrer votre cluster de gestion dans Tanzu Mission Control, reportez-vous à la section Enregistrer votre cluster de gestion dans Tanzu Mission Control.
  • Déployer des clusters de charge de travail : Une fois votre cluster de gestion créé, vous pouvez déployer des clusters de charge de travail, comme décrit dans la section Création et gestion de clusters de charge de travail TKG 2.4 avec la CLI Tanzu.
  • Déployer un autre cluster de gestion : Pour déployer plusieurs clusters de gestion, sur une ou sur l'ensemble des instances de vSphere, d'Azure et d'AWS, reportez-vous à la section Gestion de vos clusters de gestion. Cette rubrique fournit également des informations sur l'ajout de clusters de gestion existants à votre instance de CLI, l'obtention d'informations d'identification, la mise à l'échelle et la suppression de clusters de gestion, l'ajout d'espaces de noms et la manière d'accepter ou de refuser le CEIP.

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é.

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