Dépannage des problèmes de cluster de gestion

Cette rubrique inclut des conseils pour vous aider à dépanner les déploiements de clusters de gestion autonomes.

Pour plus d'informations sur le dépannage de clusters de charge de travail, reportez-vous à la section Dépannage des problèmes de clusters de charge de travail. Vous trouverez une solution supplémentaire aux problèmes connus de cette version dans les Notes de mise à jour ou dans les articles de la base de connaissances VMware.

Conditions préalables

Certaines des procédures ci-dessous utilisent la CLI kind. Pour installer kind, reportez-vous à la section Installation dans la documentation kind.

087bf3b4 (Mises à jour des notes de mises à jour pour Ghost (#1178))

Tâches courantes

Se connecter aux nœuds de cluster avec SSH

Vous pouvez utiliser SSH pour vous connecter à des nœuds individuels de clusters de gestion autonomes ou de clusters de charge de travail. Pour ce faire, la paire de clés SSH que vous avez créée lors du déploiement du cluster de gestion doit être disponible sur la machine sur laquelle vous exécutez la commande SSH. Par conséquent, vous devez exécuter les commandes ssh sur la machine sur laquelle vous exécutez les commandes tanzu.

Les clés SSH que vous enregistrez dans le cluster de gestion et qui sont utilisées par les clusters de charge de travail que vous déployez à partir du cluster de gestion sont associées aux comptes d’utilisateurs suivants :

• Le cluster de gestion vSphere et les nœuds Tanzu Kubernetes s'exécutant sur Photon OS et Ubuntu : capv
• Nœuds de bastion AWS : ubuntu
• Cluster de gestion AWS et nœuds Tanzu Kubernetes s'exécutant sur Ubuntu : ubuntu
• Cluster de gestion AWS et nœuds Tanzu Kubernetes s'exécutant sur Amazon Linux : ec2-user
• Cluster de gestion Azure et nœuds Tanzu Kubernetes (toujours Ubuntu) : capi

Pour vous connecter à un nœud à l’aide de SSH, exécutez l’une des commandes suivantes à partir de la machine que vous utilisez comme machine de démarrage :

• Nœuds vSphere : ssh capv@node-address
• Nœuds de bastion AWS, cluster de gestion et nœuds de charge de travail sur Ubuntu : ssh ubuntu@node-address
• Cluster de gestion AWS et nœuds Tanzu Kubernetes s'exécutant sur Amazon Linux : ssh ec2-user@node-address
• Nœuds Azure : ssh capi@node-address

Étant donné que la clé SSH est présente sur le système sur lequel vous exécutez la commande ssh, aucun mot de passe n'est requis.

Supprimer des utilisateurs, des contextes et des clusters avec kubectl

Pour nettoyer votre état kubectl en supprimant certains ou l'ensemble de ses utilisateurs, contextes et clusters :

1. Ouvrez votre fichier ~/.kube-tkg/config.

2. Pour les objets user que vous souhaitez supprimer, exécutez la commande suivante :

   kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
   

   Où USERNAME est la propriété name de chaque objet user de niveau supérieur, comme indiqué dans le fichier config.

3. Pour les objets context que vous souhaitez supprimer, exécutez la commande suivante :

   kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
   

   Où CONTEXT-NAME est la propriété name de chaque objet context de niveau supérieur, comme indiqué dans le fichier config, généralement de la forme contexts.mycontext-admin@mycontext.

4. Pour les objets cluster que vous souhaitez supprimer, exécutez la commande suivante :

   kubectl config unset clusters.CLUSTER-NAME --kubeconfig ~/.kube-tkg/config
   

   Où CLUSTER-NAME est la propriété name de chaque objet cluster de niveau supérieur, comme indiqué dans le fichier config.

5. Si les fichiers config répertorient le contexte actuel sous la forme d'un cluster que vous avez supprimé, annulez le contexte :

   kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
   

6. Si vous avez supprimé des clusters de gestion suivis par la CLI tanzu, supprimez-les de l'état de la CLI tanzu en exécutant tanzu context delete, comme décrit dans la section Supprimer les clusters de gestion à partir de la configuration de votre CLI Tanzu.

Désactivez nfs-utils sur les nœuds Photon OS

Problème

Dans Tanzu Kubernetes Grid v1.1.2 et versions ultérieures, nfs-utils est activé par défaut. Si vous n'avez pas besoin de nfs-utils, vous pouvez le supprimer des machines virtuelles de nœud de cluster.

Solution

Pour désactiver nfs-utils sur les clusters que vous déployez avec Tanzu Kubernetes Grid v1.1.2 ou version ultérieure, utilisez SSH pour vous connecter aux machines virtuelles de nœud de cluster et exécutez la commande suivante :

tdnf erase nfs-utils

Plate-forme cible

Un problème de balisage des ressources CAPA entraîne un échec du rapprochement lors du déploiement et de la mise à niveau du cluster de gestion AWS

Problème

En raison d'un problème de balisage des ressources dans le fournisseur d'API de cluster AWS (CAPA, Cluster API Provider AWS) en amont, les déploiements hors ligne ne peuvent pas accéder à l'API ResourceTagging, ce qui entraîne des échecs de rapprochement lors de la création ou de la mise à niveau du cluster de gestion.

Solution

dans un environnement AWS hors ligne, définissez EXP_EXTERNAL_RESOURCE_GC=false dans votre environnement local ou dans le fichier de configuration du cluster de gestion avant d'exécuter tanzu mc create ou tanzu mc upgrade.

Échec de la validation, erreur d'informations d'identification sur AWS

Problème

L'exécution de tanzu management-cluster create ou de tanzu mc create échoue avec une erreur semblable à la suivante :

Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain

Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request

Solution

Tanzu Kubernetes Grid utilise la chaîne de fournisseurs d'informations d'identification AWS par défaut. Avant de créer un cluster de gestion ou de charge de travail sur AWS, vous devez configurer vos informations d'identification de compte AWS, comme décrit dans la section Configurer les informations d'identification AWS.

Échec de la validation, erreur de conditions juridiques sur Azure

Problème

Avant de créer un cluster de gestion ou de charge de travail autonome sur Azure, vous devez accepter les conditions juridiques qui concernent l'image de machine virtuelle utilisée par les nœuds de cluster. L'exécution de tanzu mc create ou de tanzu cluster create sans avoir accepté la licence échoue avec une erreur telle que :

User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.

Solution

Si cela se produit, acceptez les conditions juridiques et réessayez :

• Cluster de gestion : Reportez-vous à la section Accepter la licence de l'image de base
• Cluster de charge de travail : Reportez-vous aux instructions relatives à Azure dans la section Déployer un cluster avec une version de Kubernetes non définie par défaut.

Cluster de gestion

Nettoyage après l'échec du déploiement d'un cluster de gestion

Problème

Une tentative infructueuse de déploiement d'un cluster de gestion autonome laisse des objets inactifs dans votre infrastructure de cloud et sur votre machine de démarrage.

Solution

1. Surveillez votre sortie de commande tanzu mc create dans le terminal ou dans l'interface du programme d'installation de Tanzu Kubernetes Grid. Si la commande échoue, elle imprime un message d'aide qui inclut les éléments suivants : « Échec lors du déploiement du cluster de gestion… Pour nettoyer les ressources créées par le cluster de gestion : tkg delete mc… ».
2. Exécutez tanzu mc delete YOUR-CLUSTER-NAME. Cette commande supprime les objets qu'elle a créés dans votre infrastructure et localement.

Vous pouvez également utiliser les autres méthodes décrites ci-dessous :

• Nettoyage de machine de démarrage :

  • Pour supprimer un cluster kind, utilisez la CLI kind. Par exemple :

    kind get clusters
    kind delete cluster --name tkg-kind-example1234567abcdef
    

  • Pour supprimer des objets Docker, utilisez la CLI docker. Par exemple, docker rm, docker rmi et docker system prune -a --volumes.

    Attention : si vous exécutez des processus Docker qui ne sont pas liés à Tanzu Kubernetes Grid sur votre système, supprimez individuellement les objets Docker inutiles.

• Nettoyage de la plate-forme cible :

  • vSphere : Localisez, mettez hors tension et supprimez les machines virtuelles et les autres ressources qui ont été créées par Tanzu Kubernetes Grid.
  • AWS : Connectez-vous à votre tableau de bord Amazon EC2 et supprimez les ressources manuellement ou utilisez une solution automatisée.
  • Azure : Dans Groupes de ressources (Resource Groups) ouvrez votre AZURE_RESOURCE_GROUP. Utilisez les cases à cocher pour sélectionner et supprimer les ressources créées par Tanzu Kubernetes Grid, dont le nom contient un horodatage.

Impossible de supprimer le cluster de gestion sur AWS

Problème

Après l'exécution de tanzu mc delete sur AWS, tanzu mc get et d'autres commandes de la CLI Tanzu ne répertorient plus le cluster de gestion supprimé, mais :

• Le cluster n'est pas supprimé de l'infrastructure AWS et ses nœuds s'affichent toujours dans le tableau de bord d'Amazon EC2
• Les journaux du cluster de gestion affichent l'erreur cluster infrastructure is still being provisioned: VpcReconciliationFailed.

Solution

Ce comportement se produit lorsque TKG utilise des informations d'identification de compte AWS expirées ou non valides. Pour empêcher cette situation ou pour récupérer à partir de celle-ci :

• Empêcher (Prevent) : Mettez à jour les informations d'identification du compte AWS, comme décrit dans la section Configurer les informations d'identification du compte AWS à l'aide de profils d'informations d'identification AWS ou de variables d'environnement statiques locales.

  • Vous ne pouvez pas utiliser les informations d'identification de profil d'instance AWS pour supprimer un cluster de gestion.

• Récupérer (Recover) à l'aide du tableau de bord EC2 : Supprimer manuellement les nœuds du cluster de gestion du tableau de bord EC2

• Récupérer (Recover) à l'aide de l'interface de ligne de commande (CLI) :

  1. Dans le cluster kind qui reste sur la machine de démarrage en raison de l'échec de la suppression du cluster de gestion, corrigez le secret des informations d'identification AWS :

     kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
     

  2. Modifiez le secret afin d'inclure les informations d'identification AWS :

     [default]
     aws_access_key_id = <key id>
     aws_secret_access_key = <access_key>
     region = <region>
     

  3. Exécutez de nouveau la commande tanzu mc delete.

Le cluster kind est conservé après la suppression du cluster de gestion

Problème

L'exécution de tanzu mc delete supprime le cluster de gestion, mais ne parvient pas à supprimer le cluster local kind de la machine de démarrage.

Solution

1. Répertoriez tous les clusters kind en cours d'exécution et supprimez celui qui ressemble à tkg-kind-unique_ID :

   kind delete cluster --name tkg-kind-unique_ID
   

2. Répertoriez tous les clusters en cours d'exécution et identifiez le cluster kind.

   docker ps -a
   

3. Copiez l'ID de conteneur du cluster kind et supprimez-le.

   docker kill container-ID
   

Machines bloquées après l'échec du déploiement du cluster de gestion

Problème

Votre cluster de gestion autonome ne parvient pas à se déployer, car les machines sont bloquées, en attente de correction.

Solution

Pour un cluster de gestion que vous avez déployé avec le plan dev, qui ne dispose que d'un seul nœud de plan de contrôle, vous devez redéployer le cluster de gestion. Pour les clusters de gestion avec plusieurs nœuds de plan de contrôle, vous pouvez identifier et supprimer les machines bloquées.

1. Récupérez l’état du cluster de gestion. Par exemple :

   kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
   

2. Recherchez les noms des machines bloquées à partir de la sortie de l'étape précédente. Une machine bloquée est marquée comme WaitingForRemediation. Par exemple, le nom de la machine bloquée est my-mgmt-cluster-zpc7t dans la sortie suivante :

   status:
     conditions:
     - lastTransitionTime: "2021-08-25T15:44:23Z"
       message: KCP can't remediate if current replicas are less or equal then 1
       reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
       severity: Warning
       status: "False"
       type: Ready
   

3. Augmentez les valeurs de délai d'expiration du contrôle de santé de la machine pour les nœuds de plan de contrôle au-delà de la valeur par défaut, 5m. Par exemple :

   tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
   

   Pour plus d'informations sur la mise à jour d'un objet MachineHealthCheck, reportez-vous à la section Créer ou mettre à jour un objet MachineHealthCheck dans Configurer les contrôles de santé de la machine pour les clusters de charge de travail.

4. Définissez kubectl sur le contexte de votre cluster de gestion. Par exemple :

   kubectl config use-context mgmt-cluster-admin@mgmt-cluster
   

5. Supprimez les machines bloquées.

   kubectl delete machine MACHINE-NAME
   

   Où MACHINE-NAME est le nom de la machine que vous avez localisée à une étape précédente.

6. Attendez que le contrôleur KubeadmControlPlane redéploie la machine.

Restaurer le répertoire ~/.config/tanzu

Problème

Le répertoire ~/.config/tanzu sur la machine de démarrage a été supprimé ou endommagé accidentellement. La CLI Tanzu crée et utilise ce répertoire, et ne peut pas fonctionner sans celui-ci.

Solution

Pour restaurer le contenu du répertoire ~/.config/tanzu :

1. Pour identifier les clusters de gestion Tanzu Kubernetes Grid existants, exécutez :

   kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
   

   La sortie de la commande répertorie les noms et les contextes de tous les clusters de gestion créés ou ajoutés par la CLI Tanzu.

2. Pour chaque cluster de gestion répertorié dans la sortie, restaurez-le dans le répertoire ~/.config/tanzu et la CLI en exécutant :

   tanzu context create --management-cluster --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
   

L'exécution de tanzu management-cluster créé sur macOS entraîne une erreur de version kubectl

Problème

Si vous exécutez la commande tanzu management-cluster create ou tanzu mc create sur macOS avec la dernière version stable de Docker Desktop, l'opération échoue avec le message d'erreur suivant :

Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.26.8

Cela se produit, car Docker Desktop fait des liens symboliques avec une ancienne version de kubectl dans le chemin d'accès.

Solution

Placez une version plus récente prise en charge de kubectl dans le chemin avant la version de Docker.

Récupérer les informations d’identification du cluster de gestion

Si vous avez perdu les informations d'identification d'un cluster de gestion autonome, par exemple, en supprimant par inadvertance le fichier .kube-tkg/config sur le système sur lequel vous exécutez les commandes tanzu, vous pouvez récupérer les informations d'identification à partir du nœud du plan de contrôle du cluster de gestion.

1. Exécutez tanzu mc create pour recréer le fichier .kube-tkg/config.
2. Obtenez l’adresse IP publique du nœud de plan de contrôle du cluster de gestion depuis vSphere, AWS ou Azure.

3. Utilisez SSH pour vous connecter au nœud de plan de contrôle du cluster de gestion.

   Reportez-vous à la section Connexion aux nœuds de cluster avec SSH ci-dessus pour obtenir les informations d'identification à utiliser pour chaque plate-forme cible.

4. Accédez au fichier admin.conf pour le cluster de gestion.

   sudo vi /etc/kubernetes/admin.conf
   

   Le fichier admin.conf contient le nom du cluster, le nom d'utilisateur du cluster, le contexte du cluster et les données du certificat client.

5. Copiez le nom du cluster, le nom d'utilisateur du cluster, le contexte du cluster et les données du certificat client dans le fichier .kube-tkg/config sur le système sur lequel vous exécutez les commandes tanzu.

Pinniped

L'ajout de la gestion des identités externes à un déploiement existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT factice

Problème

L'intégration d'un fournisseur d'identité externe à un déploiement TKG existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT factice dans le fichier de configuration du cluster de gestion utilisé pour créer le secret de module complémentaire, comme décrit dans la section Générer le secret de module complémentaire Pinniped pour le cluster de gestion

La désactivation de Pinniped nécessite la suppression manuelle du Secret sur les clusters hérités

Problème

Lorsque vous désactivez la gestion des identités externes sur un cluster de gestion, l'objet Pinniped Secret inutilisé reste présent sur les clusters de charge de travail hérités.

Si un utilisateur tente ensuite d'accéder au cluster à l'aide d'un ancien kubeconfig, une fenêtre contextuelle de connexion s'affiche et échoue.

Solution

supprimez manuellement le code Pinniped Secret du cluster hérité, comme décrit dans la section Désactiver la gestion des identités.

Échec de la tâche de post-déploiement Pinniped

Problème

La mise à niveau vers Tanzu Kubernetes Grid v2.3 renvoie une erreur semblable à la suivante :

 Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again

Solution

Cette erreur peut se produire si la tâche de post-déploiement Pinniped est en conflit avec le processus de mise à niveau d'un composant. Procédez comme suit pour supprimer et redéployer la tâche.

1. Supprimer la tâche de post-déploiement Pinniped.

   kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
   

2. Attendez environ 5 minutes que kapp-controller redéploie la tâche de post-déploiement.

3. Vérifiez l'état de l'application Pinniped.

   kubectl get app -n tkg-system pinniped
   NAME       DESCRIPTION           SINCE-DEPLOY   AGE
   pinniped   Reconcile succeeded   5s             49m
   

   Si la DESCRIPTION affiche Reconciling, attendez quelques minutes, puis vérifiez de nouveau. Une fois qu'elle affiche Reconcile succeeded passez à l'étape suivante.

4. Vérifier l'état de la tâche de post-déploiement Pinniped.

   kubectl get jobs -n pinniped-supervisor
   NAME                             COMPLETIONS   DURATION   AGE
   pinniped-post-deploy-job-ver-1   1/1           9s         62s
   

Erreur d'authentification Pinniped sur le cluster de charge de travail après la mise à niveau du cluster de gestion

Problème

Vous avez mis à niveau récemment votre cluster de gestion. Lorsque vous tentez de vous authentifier sur un cluster de charge de travail associé à ce cluster de gestion, vous recevez un message d'erreur semblable au message suivant :

Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority

Solution

Cela se produit, car la copie du bundle d'autorité de certification du superviseur Pinniped que le cluster de charge de travail utilise est obsolète. Pour mettre à jour le bundle d'autorité de certification du superviseur, procédez comme suit :

1. Définissez le contexte kubectl sur le cluster de gestion.

2. Obtenez le bundle d'autorité de certification codé en base64 et le point de terminaison issuer à partir de pinniped-info ConfigMap :

   kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
   

3. Obtenez la section values.yaml à partir du secret du module complémentaire Pinniped pour le cluster de charge de travail :

   kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
   

   Ce secret se trouve sur le cluster de gestion.

4. Dans le fichier values.yaml créé ci-dessus, mettez à jour la clé supervisor_ca_bundle_data pour qu'elle corresponde au bundle d'autorité de certification à partir de pinniped-info ConfigMap. En outre, assurez-vous que le supervisor_svc_endpoint correspond au point de terminaison issuer.

5. Appliquez votre mise à jour en codant en base64 le fichier values.yaml modifié et en le remplaçant dans le secret du cluster de charge de travail. Cette commande diffère selon le système d'exploitation de votre environnement. Par exemple :

   Linux :

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
   

   macOS :

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
   

6. Sur le cluster de charge de travail, vérifiez que l'application Pinniped a correctement rapproché les modifications :

   kubectl get app pinniped -n tkg-system
   

7. Authentifiez-vous sur le cluster. Par exemple :

   kubectl get pods -A --kubeconfig my-cluster-credentials
   

Espaces

Des espaces sont bloqués en attente sur le cluster en raison de la connectivité vCenter

Problème

Lorsque vous exécutez kubectl get pods -A sur le cluster créé, certains espaces restent en attente.

Vous exécutez la commande kubectl describe pod -n pod-namespace pod-name sur un espace affecté et vous voyez l'événement suivant :

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

Solution

Assurez-vous que des règles de connectivité et de pare-feu sont en place pour assurer la communication entre le cluster et vCenter. Pour connaître les conditions requises en matière de ports et de protocoles de pare-feu, reportez-vous aux listes vSphere dans la page VMware Ports and Protocols.

CLI Tanzu

La CLI Tanzu ne peut pas accéder au cluster de gestion

Problème

L'exécution des commandes de CLI tanzu renvoie une erreur semblable à la suivante :

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

Solution

Reportez-vous aux sections Mettre à jour le certificat de cluster de gestion dans votre configuration de la CLI Tanzu et Impossible d'accéder aux clusters à l'aide des commandes de CLI tkg/tanzu dans Tanzu Kubernetes Grid.

Windows CMD : caractères superflus dans les en-têtes de colonne de sortie de CLI

Problème

Dans l'invite de commande Windows (CMD), la sortie de commande de CLI Tanzu formatée en colonnes inclut des caractères superflus dans les en-têtes de colonne. Ce problème ne se produit pas avec le terminal Windows ou PowerShell.

Solution

sur les machines de démarrage Windows, exécutez la CLI Tanzu depuis votre terminal Windows.

L'interface de ligne de commande (CLI) indique temporairement de manière incorrecte l'état des nœuds récemment supprimés lors de la désactivation de MHC

Problème

Lorsque les contrôles de santé de la machine (MHCs) sont désactivés, les commandes de la CLI Tanzu telles que tanzu cluster status peuvent ne pas signaler l'état à jour du nœud pendant la recréation de l'infrastructure.

Solution

aucune.

Interface du programme d'installation de Tanzu Kubernetes Grid

L'interface utilisateur de Tanzu Kubernetes Grid ne s'affiche pas correctement sous Windows

Problème

Lorsque vous exécutez la commande tanzu management-cluster create --ui ou tanzu mc create --ui sur un système Windows, l'interface utilisateur s'ouvre dans votre navigateur par défaut, mais les graphiques et le style ne sont pas appliqués. Cela se produit, car un registre Windows est défini sur application/x-css.

Solution

1. Dans la recherche Windows, entrez regedit pour ouvrir l'utilitaire Éditeur du Registre.
2. Développez HKEY_CLASSES_ROOT et sélectionnez .js.
3. Cliquez avec le bouton droit sur Type de contenu et sélectionnez Modifier.
4. Définissez la valeur sur application/javascript, puis cliquez sur OK.
5. Exécutez de nouveau la commande tanzu mc create --ui pour relancer l'interface utilisateur.

NSX Advanced Load Balancer

Avec NSX ALB, vous ne pouvez pas créer de clusters avec des noms identiques

Problème

Si vous utilisez NSX Advanced Load Balancer pour les charges de travail (AVI_ENABLE) ou le plan de contrôle (AVI_CONTROL_PLANE_HA_PROVIDER), le contrôleur Avi peut ne pas parvenir à distinguer les clusters portant des noms identiques.

Solution :

définissez une valeur CLUSTER_NAME unique pour chaque cluster. ne créez pas plusieurs clusters de gestion avec la même valeur CLUSTER_NAME, même à partir de différentes machines de démarrage.

Échec des demandes vers la VIP de NSX Advanced Load Balancer avec le message no route to host

Problème

Si le nombre total de services de type LoadBalancer est élevé, et si tous les moteurs de service sont déployés sur le même réseau L2, les demandes envoyées à l'adresse IP virtuelle de NSX Advanced Load Balancer peuvent échouer avec le message no route to host.

Cela se produit, car la limite de débit ARP par défaut sur les moteurs de service est de 100.

Solution

Définissez la limite de débit ARP sur un nombre plus élevé. Ce paramètre n'est pas modifiable dans NSX Advanced Load Balancer Essentials, mais il l'est dans NSX Advanced Load Balancer Enterprise Edition.

Erreur AKODeploymentConfig ignorée lors de la création du cluster de gestion

Problème

L'exécution de tanzu management-cluster create pour créer un cluster de gestion avec NSX ALB génère l'erreur no matches for kind AKODeploymentConfig in version networking.tkg.tanzu.vmware.com/v1alpha1.

Solution

Vous pouvez ignorer cette erreur. Pour plus d'informations, reportez-vous à cet article de la base de connaissances.

Multus CNI échoue sur medium et les espaces plus petits avec NSX Advanced Load Balancer

Problème

Sur vSphere, les clusters de charge de travail avec des nœuds worker medium ou plus petits exécutant le module Multus CNI avec NSX ALB peuvent échouer avec des erreurs Insufficient CPU ou d'autres erreurs.

Solution

pour utiliser Multus CNI avec NSX ALB, déployez des clusters de charge de travail avec des nœuds worker de taille large ou extra-large.

Mise à niveau

Échec de la mise à niveau des clusters sur Azure

Problème

Sur Azure, la mise à niveau des clusters de gestion et des clusters de charge de travail échoue avec des erreurs telles que context deadline exceeded ou unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Cela se produit, car les opérations sur Azure prennent parfois plus de temps que sur d'autres plates-formes.

Solution

exécutez la commande tanzu management-cluster upgrade ou tanzu cluster upgrade de nouveau, en spécifiant un délai d'expiration plus long dans l'indicateur --timeout. Le délai d'expiration par défaut est 30 ms.

La mise à niveau échoue pour les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure

Problème

Dans TKG v2.3, les composants qui transforment un cluster générique en cluster de gestion autonome TKG sont intégrés dans un module Carvel tkg-pkg. Les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure ne disposent pas d'un secret de configuration requis par le processus de mise à niveau pour installer tkg-pkg, ce qui entraîne l'échec de la mise à niveau.

Solution

suivez les étapes supplémentaires répertoriées dans la section Mettre à niveau des clusters de gestion autonomes pour les clusters de gestion autonomes créés dans TKG v1.3 ou version antérieure.