This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

Contenu des notes de mise à jour

Mises à jour le : 6 juillet 2023

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés du 6 juillet 2023

Informations sur le build du 6 juillet 2023

ESXi 7.0 Update 3m | 3 mai 2023 | Build ISO 21686933

vCenter Server 7.0 Update 3n | 06 juillet 2023 | Build ISO 21958406

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 janvier 2023

Nouvelles fonctionnalités

  • Les clusters superviseurs prennent en charge Kubernetes 1.24 : cette version ajoute la prise en charge de Kubernetes 1.24 et annule celle de Kubernetes 1.21.

Versions de Kubernetes prises en charge pour les clusters superviseurs

Les versions prises en charge de Kubernetes dans cette publication sont les versions 1.24, 1.23 et 1.22. Les superviseurs s'exécutant sur Kubernetes version 1.21 seront mis à niveau automatiquement vers la version 1.22, afin de s'assurer que tous vos superviseurs sont exécutés sur les versions prises en charge de Kubernetes.

Nouveautés du 30 mars 2023

Informations sur le build du 30 mars 2023

ESXi 7.0 Update 3l | 30 mars 2023 | Build ISO 21424296

vCenter Server 7.0 Update 3l | 30 mars 2023 | Build ISO 21477706

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 janvier 2023

Nouvelles fonctionnalités :

  • Aucune, il s'agit simplement d'une version de correction de bogues.

Versions de Kubernetes prises en charge pour les clusters superviseurs

Les versions prises en charge de Kubernetes dans cette publication sont les versions 1.23, 1.22 et 1.21. Les superviseurs s'exécutant sur Kubernetes version 1.20 seront mis à niveau automatiquement vers la version 1.21, afin de s'assurer que tous vos superviseurs sont exécutés sur une version prise en charge de Kubernetes.

Problèmes résolus

Ce correctif corrige les problèmes suivants.

  • Avec l'activation de la fonctionnalité LRO (Large Receive Offload), les machines virtuelles de cluster Tanzu Kubernetes Grid qui utilisent Antrea-ENCAP peuvent rencontrer des problèmes de performances réseau.

  • L'activation du registre Harbor intégré sur le superviseur peut entraîner une configuration par défaut non sécurisée.

Nouveautés du 23 février 2023

Informations sur le build du 23 février 2023

ESXi 7.0 Update 3i | 8 décembre 2022 | Build ISO 20842708

vCenter Server 7.0 Update 3k | 23 février 2023 | Build ISO 21290409

VMware NSX Advanced Load Balancer avi-22.1.3 | 31 janvier 2023

Nouvelles fonctionnalités :

Superviseur

  • Les clusters superviseurs prennent en charge Kubernetes 1.23 : cette version ajoute la prise en charge de Kubernetes 1.23 et annule celle de Kubernetes 1.20. Les versions prises en charge de Kubernetes dans cette publication sont les versions 1.23, 1.22 et 1.21. Les superviseurs s'exécutant sur Kubernetes version 1.20 seront mis à niveau automatiquement vers la version 1.21, afin de s'assurer que tous vos superviseurs sont exécutés sur une version prise en charge de Kubernetes.

Nouveautés du 8 décembre 2022

Informations sur le build du 8 décembre 2022

ESXi 7.0 Update 3i | 8 décembre 2022 | Build ISO 20842708

vCenter Server 7.0 Update 3i | 8 décembre 2022 | Build ISO 20845200

VMware NSX Advanced Load Balancer avi-21.1.4-9009 | 7 avril 2022

Nouvelles fonctionnalités :

Nouvelle CRD SecurityPolicy : vSphere 7.0 Update 3i introduit une CRD SecurityPolicy pour que les utilisateurs appliquent une stratégie de sécurité basée sur NSX aux machines virtuelles et aux espaces dans le superviseur. Cela permet de configurer la « stratégie réseau Kubernetes » via du code en étendant la stratégie réseau Kubernetes via la CRD pour les espaces de noms de superviseur.

Support : la version de TLS utilisée dans le service kube-apiserver-authproxy-svc et les espaces système a été mise à jour vers TLS v1.2.

Nouveautés du 13 septembre 2022

Informations sur le build du 13 septembre 2022

ESXi 7.0 Update 3g | 13 septembre 2022 | Build ISO 20328353

vCenter Server 7.0 Update 3h | 13 septembre 2022 | Build ISO 20395099

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 29 mars 2022

Nouvelles fonctionnalités

  • Aucune, il s'agit simplement d'une version de correction de bogues.

Problèmes résolus :

Ce correctif résout le problème lié à la mise à niveau de vCenter Server vers la version 70u3f qui échouait, car le service WCP ne démarrait pas après la mise à niveau. L'erreur se produisait lorsque vous tentiez de mettre à niveau vCenter Server avec vSphere with Tanzu activé sur les versions antérieures à 70u3d. Les tentatives de mise à niveau de vCenter Server à partir d'une version antérieure à 70u3d vers vCenter Server 70u3d, puis vers vCenter Server 70u3f échouaient.

Pour en savoir plus sur le problème résolu, lisez l'article 89010 de la base de connaissances.

Nouveautés du 12 juillet 2022

Informations sur le build du 12 juillet 2022

ESXi 7.0 Update 3f | 12 juillet 2022 | Build ISO 20036589

vCenter Server 7.0 Update 3f | 12 juillet 2022 | Build ISO 20051473

VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 29 mars 2022

Nouvelles fonctionnalités

  • Cluster superviseur

    • Prise en charge de la valeur de chaîne de l'adresse IP de l'équilibrage de charge pour le service de VM : permet à un utilisateur de fournir une valeur de chaîne pour la valeur de spec.LoadBalancerIP qui représente un pool d'adresses IP créé et balisé dans NSX-T.

    • Sauvegarde et restauration des machines virtuelles de service de VM : VMware prend désormais en charge la sauvegarde et la restauration des machines virtuelles de service de VM sur site vSphere et VMware Cloud on AWS via un workflow complet et entièrement documenté qui prend en charge Veeam et d'autres fournisseurs de sauvegarde basés sur les API de stockage vSphere pour la protection des données (vADP, vSphere Storage APIs for Data Protection), garantissant une solution de protection des données plus complète et la disponibilité générale du service de VM sur VMware Cloud on AWS.

Nouveautés du 12 mai 2022

Informations sur le build du 12 mai 2022

ESXi 7.0 Update 3d | 29 mars 2022 | Build ISO 19482537

vCenter Server 7.0 Update 3e | 12 mai 2022 | Build ISO 19717403

VMware NSX Advanced Load Balancer 20.1.7-9154 | 29 mars 2022

Nouvelles fonctionnalités

  • Ajout de la prise en charge de la stratégie de sécurité réseau pour les machines virtuelles déployées via le service d'opérateur de machine virtuelle : vous pouvez créer des stratégies de sécurité sur NSX-T via des groupes de sécurité basés sur des balises. Il est désormais possible de créer une stratégie de sécurité basée sur NSX-T et de l'appliquer aux machines virtuelles déployées via un opérateur de machine virtuelle basé sur des balises NSX-T.

  • Les clusters superviseurs prennent en charge Kubernetes 1.22 : cette version prend désormais en charge Kubernetes 1.22 et annule la prise en charge de Kubernetes 1.19. Les versions prises en charge de Kubernetes dans cette publication sont les versions 1.22, 1.21 et 1.20. Les clusters superviseurs s'exécutant sur Kubernetes version 1.19 seront mis à niveau automatiquement vers la version 1.20, afin de s'assurer que tous vos clusters superviseurs sont exécutés sur les versions prises en charge de Kubernetes.

Considérations sur la mise à niveau

Si vous avez mis à niveau vCenter Server à partir d'une version antérieure à la version 7.0 Update 3c et que votre cluster superviseur se trouve sur Kubernetes 1.19.x, les espaces tkg-controller-manager passent à l'état CrashLoopBackOff, ce qui rend les clusters invités ingérables. Un message d'erreur semblable au message suivant s'affiche :

Une panique a été observée : adresse mémoire non valide ou déréférencement de pointeur nul

Solution : pour en savoir plus sur ce problème et le résoudre, consultez l'article 88443 de la base de connaissances.

Nouveautés du 29 mars 2022

Informations sur le build du 29 mars 2022

ESXi 7.0 Update 3d | 29 mars 2022 | Build ISO 19482537

vCenter Server 7.0 Update 3d | 29 mars 2022 | Build ISO 19480866

VMware NSX Advanced Load Balancer 20.1.7-9154 | 29 mars 2022

Nouvelles fonctionnalités

  • Aucune, il s'agit simplement d'une version de correction de bogues.

Problèmes résolus

  • Échec des installations du VIB Spherelet sur les hôtes vTPM

    • L'installation du VIB Spherelet échoue avec l'erreur Impossible de trouver un signataire approuvé : certificat auto-signé sur un hôte vTPM.

  • Instabilité du cluster superviseur suite à la mise à niveau de vSphere

    • Après la mise à niveau de vSphere de la version 7.0 Update 1 vers la version 7.0 Update 2, le cluster superviseur passe à l'état de configuration.

  • Blocage de l'activation du cluster superviseur lors de l'utilisation de NSX-T Advanced Load Balancer

    • L'activation du cluster superviseur avec NSX-T Advanced Load Balancer peut entraîner le blocage de la configuration en fonction de la configuration d'authentification par défaut.

Nouveautés du 21 octobre 2021

Informations sur le build du 21 octobre 2021

ESXi 7.0 Update 3 | 27 janvier 2022 | Build ISO 19193900

vCenter Server 7.0 Update 3a | 21 octobre 2021 | Build ISO 18778458

VMware NSX Advanced Load Balancer 20.1.7 | 21 octobre 2021 | Build ISO 18778458

IMPORTANT : VMware a supprimé ESXi 7.0 Update 3, 7.0 Update 3a et 7.0 Update 3b de tous les sites le 19 novembre 2021 en raison d'un problème affectant la mise à niveau. La build 19193900 de l'ISO ESXi 7.0 Update 3c remplace la build 18644231. Pour plus d'informations, reportez-vous aux Notes de mise à jour de VMware ESXi 7.0 Update 3c.

Nouvelles fonctionnalités

  • Tanzu Kubernetes Grid Service for vSphere

    • Activez les charges de travail en conteneur pour exploiter l'accélération GPU sur votre cluster Tanzu Kubernetes : les administrateurs vSphere peuvent désormais provisionner des machines virtuelles accélérées par GPU sur les clusters Tanzu Kubernetes et les développeurs peuvent désormais ajouter des machines virtuelles accélérées par GPU à leurs clusters Tanzu Kubernetes Grid à l'aide de commandes Kubernetes natives.

    • Version de Tanzu Kubernetes basée sur Ubuntu 20.04 : il s'agit de notre première version de Tanzu Kubernetes basée sur Ubuntu 20.04. Cette image a été optimisée et testée spécifiquement pour les charges de travail de GPU (AI/ML). Pour plus d'informations, reportez-vous aux Notes de mise à jour de la version de Tanzu Kubernetes.

Nouveautés du 5 octobre 2021

Informations sur le build du 28 septembre 2021

ESXi 7.0 Update 3 | 27 janvier 2022 | Build ISO 19193900

vCenter Server 7.0 Update 3 | 5 octobre 2021 | Build ISO 18700403

VMware NSX Advanced Load Balancer 20.1.6 | 5 octobre 2021 | Build ISO 18700403

IMPORTANT : VMware a supprimé ESXi 7.0 Update 3, 7.0 Update 3a et 7.0 Update 3b de tous les sites le 19 novembre 2021 en raison d'un problème affectant la mise à niveau. La build 19193900 de l'ISO ESXi 7.0 Update 3c remplace la build 18644231. Pour plus d'informations, reportez-vous aux Notes de mise à jour de VMware ESXi 7.0 Update 3c.

Nouvelles fonctionnalités

  • Cluster superviseur

    • Services vSphere : l'infrastructure des services vSphere permet désormais aux administrateurs vSphere de gérer les services de superviseur de manière asynchrone, notamment MinIO, Cloudian Hyperstore, Dell ObjectScale et Velero. La nature découplée des services de superviseur permet aux administrateurs d'ajouter de nouveaux services au catalogue de services en dehors d'une version de vCenter Server, ce qui renforce le potentiel de la communauté DevOps. Les services de superviseur sont uniquement disponibles dans les clusters de superviseur configurés avec la mise en réseau NSX-T Data Center. Pour plus d'informations sur la gestion des services de superviseur dans vSphere Client, reportez-vous à la documentation.

    • Prise en charge de vGPU dans le service de VM : les administrateurs vSphere peuvent désormais fournir un accès en libre-service aux développeurs pour la consommation de GPU via des machines virtuelles utilisant Kubernetes, en fonction des limites imposées par les classes de machine virtuelle. Les utilisateurs DevOps peuvent ensuite créer rapidement des machines virtuelles avec des GPU à l'aide de ces classes et images de machines virtuelles prédéfinies.

    • Activer la gestion de la charge de travail avec la mise en réseau DHCP : cette version ajoute le réseau DHCP comme autre chemin de configuration réseau afin de simplifier l'activation d'un POC plus rapide. Les administrateurs vSphere peuvent configurer le réseau de gestion et le réseau de charge de travail avec DHCP en sélectionnant simplement le réseau et le groupe de ports. Toutes les autres entrées, notamment DNS, NTP et adresses IP flottantes, sont automatiquement acquises à l'aide de DHCP.

    • Vérification de l'intégrité du réseau et de l'équilibrage de charge lors de l'activation : lors de l'activation, les contrôles de santé de la connectivité réseau, de DNS, de NTP et de l'équilibrage de charge confirment la réussite de l'activation de votre cluster superviseur, et affichent des messages d'erreur pour vous aider à établir un diagnostic et à prendre des mesures pour résoudre les problèmes courants. Pour plus d'instructions sur la résolution des messages d'erreur, consultez la documentation.

    • Les clusters superviseurs prennent en charge Kubernetes 1.21 : cette version ajoute la prise en charge de Kubernetes 1.21 et annule la prise en charge de Kubernetes 1.18. Les versions prises en charge de Kubernetes dans cette publication sont 1.21, 1.20 et 1.19. Les clusters superviseurs s'exécutant sur Kubernetes version 1.18 seront mis à niveau automatiquement vers la version 1.19, afin de s'assurer que tous vos clusters superviseurs sont exécutés sur les versions prises en charge de Kubernetes.

    • Étiquettes et annotations pour les espaces de noms de superviseur : les espaces de noms créés par les utilisateurs DevOps via le modèle en libre-service d'espace de noms peuvent désormais disposer d'étiquettes et d'annotations Kubernetes.

    • Modifier la configuration du cluster superviseur après l'activation : après l'activation des clusters superviseurs avec la pile de mise en réseau vSphere, les administrateurs vSphere peuvent désormais modifier les paramètres suivants à partir de l'API et de vSphere Client : Nom d'utilisateur et mot de passe de l'équilibrage de charge, domaines de recherche DNS du réseau de gestion et serveurs DNS du réseau de charge de travail, serveurs NTP, développement de la plage d'adresses IP du service et ajout d'un nouveau réseau de charge de travail. Pour les clusters utilisant la mise en réseau vSphere ou NSX-T, vous pouvez augmenter la taille du plan de contrôle après l'activation. Notez que vous pouvez uniquement augmenter la taille du cluster. La réduction de la taille n'est pas prise en charge à ce stade. Pour plus d'informations sur la modification des paramètres du cluster superviseur via vSphere Client, consultez la documentation.

    • Expiration de la clé de licence Tanzu : les administrateurs vSphere disposent désormais d'une plus grande flexibilité pour gérer les clés de licence de l'édition Tanzu expirées. Lors de l'expiration des clés de licence Tanzu, aucune mise en conformité ne se produit automatiquement, ce qui permet aux administrateurs d'obtenir et d'attribuer une nouvelle clé de licence sans affecter les opérations normales.

  • Tanzu Kubernetes Grid Service for vSphere

    • Prise en charge de RWX pour les volumes persistants vSAN : les charges de travail s'exécutant sur des clusters Tanzu Kubernetes peuvent désormais monter des volumes persistants basés sur vSAN avec RWX.

    • Mise à jour de Tanzu Kubernetes Grid Service v1alpha2 API : mises à jour apportées à Tanzu Kubernetes Cluster API exposant de nouveaux champs permettant une configuration améliorée de Tanzu Kubernetes Grid Service, notamment la prise en charge de plusieurs pools de nœuds worker. Désapprobation de l'API v1alpha1 en faveur de la nouvelle API v1alpha2. Pour plus d'informations, consultez la documentation.

    • Serveur de mesures : le serveur de mesures est désormais inclus par défaut dans les clusters Tanzu Kubernetes à partir de la version 1.20.9 et versions ultérieures, et de la version 1.21 de Tanzu Kubernetes.

    • Capacité de prise en charge de la topologie sans NAT (routée) : les clusters Tanzu Kubernetes peuvent désormais être créés avec une topologie de mise en réseau qui permet de router les nœuds de cluster en dehors du réseau du cluster. Pour plus d'informations, consultez la documentation.

Nouveautés du 24 août 2021

Informations sur le build du 24 août 2021

ESXi 7.0 Update 2c | 24 août 2021 | Build ISO 18426014

vCenter Server 7.0 Update 2c | 24 août 2021 | Build ISO 18356314

VMware NSX Advanced Load Balancer 20.1.5 | 24 août 2021 | Build ISO 18379150

Nouvelles fonctionnalités

  • Cluster superviseur

    • Les clusters superviseurs prennent en charge Kubernetes 1.20 : cette version ajoute la prise en charge de Kubernetes 1.20 et annule la prise en charge de Kubernetes 1.17. Les versions prises en charge de Kubernetes dans cette version sont 1.20, 1.19 et 1.18. Les clusters superviseurs s'exécutant sur Kubernetes version 1.17 seront mis à niveau automatiquement vers la version 1.18, afin de s'assurer que tous vos clusters superviseurs sont en cours d'exécution sur les versions prises en charge de Kubernetes.

    • Le plug-in Velero pour vSphere prend en charge les espaces vSphere : cette version prend en charge Velero 1.5.1 et le plug-in Velero pour vSphere 1.1.0 et versions ultérieures pour la sauvegarde et la restauration des espaces vSphere.

  • Tanzu Kubernetes Grid Service for vSphere

    • Nouvelles extensions Harbor et external-dns dans le cluster - Les opérateurs de plate-forme ont désormais accès à deux extensions supplémentaires prises en charge dans le cluster : Harbor et external-dns. Harbor est le registre de conteneurs gradués CNCF et external-dns est un outil populaire pour configurer dynamiquement les enregistrements DNS en fonction des services équilibrés en charge de Kubernetes.

    • Amélioration de la correction des nœuds de plan de contrôle : les clusters Tanzu Kubernetes corrigeront désormais automatiquement les pannes des nœuds de plan de contrôle communs qui fournissent une exécution de Kubernetes plus robuste.

    • Le plug-in Velero pour vSphere prend en charge les charges de travail du cluster Tanzu Kubernetes : cette version prend en charge Velero 1.5.1 et les versions ultérieures, ainsi que le plugin Velero pour vSphere 1.1.0 et les versions ultérieures pour la sauvegarde et la restauration des charges de travail s'exécutant sur les clusters Tanzu Kubernetes.

    • Prise en charge autonome de Velero pour les charges de travail du cluster Tanzu Kubernetes : cette version prend en charge Velero 1.6 pour la sauvegarde et la restauration de charges de travail du cluster Tanzu Kubernetes à l'aide de Velero autonome avec Restic.

Nouveautés du 27 avril 2021

Informations sur le build du 27 avril 2021

ESXi 7.0 | 9 mars 2021 | Build ISO 17630552

vCenter Server 7.0 | 27 avril 2021 | Build ISO 17920168

Nouvelles fonctionnalités

  • Cluster superviseur

    • Gestion des machines virtuelles à l'aide de Kubernetes via le service de machine virtuelle. Cette version ajoute le service de machine virtuelle aux services d'infrastructure inclus dans vSphere with Tanzu, ce qui permet aux développeurs de gérer des machines virtuelles Kubernetes natives. Le service de VM permet aux développeurs de déployer et de gérer des VM dans un espace de noms à l'aide des commandes Kubernetes. En même temps, l'administrateur vSphere peut gérer la consommation des ressources et la disponibilité du service, tout en offrant aux développeurs une expérience cloud native.

    • Création en libre-service d'espaces de noms pour les développeurs. Les administrateurs vSphere peuvent désormais créer et configurer un espace de noms de superviseur en tant que modèle d'espace de noms en libre-service. Ce modèle définit les limites de ressources et les autorisations d'utilisation. Les développeurs peuvent ensuite utiliser ce modèle pour provisionner un espace de noms et y exécuter des charges de travail, sans avoir à en demander un et à attendre l'approbation.

  • Tanzu Kubernetes Grid Service for vSphere

    • IMPORTANT : correctif CVE pour les TKR : de nouvelles versions de Tanzu Kubernetes sont disponibles pour résoudre le problème CVE-2021-30465.

    • IMPORTANT : correctif CVE pour l'extension d'entrée Contour : une nouvelle version de l'image Envoy pour résoudre les problèmes CVE-2021-28682, CVE-2021-28683 et CVE-2021-29258. Pour plus d'informations, reportez-vous à l'article de la base de connaissances associé.

    • Nouveau workflow pour l'utilisation des classes de machine virtuelle par défaut. Un nouveau workflow permet d'utiliser les classes de machine virtuelle par défaut pour provisionner des clusters Tanzu Kubernetes. Avant de créer un cluster, ajoutez les classes de machine virtuelle par défaut à l'espace de noms vSphere dans lequel vous provisionnez le cluster. Pour obtenir des conseils reportez-vous à la documentation.

    • Les Webhooks de mutation du système prennent désormais en charge le mode d'exécution de test. Les utilisateurs peuvent désormais intégrer des outils répandus tels que le fournisseur Terraform Kubernetes avec le service Tanzu Kubernetes Grid. Auparavant, les Webhooks du système ne prenaient pas en charge le mode d'exécution de test, qui était une condition requise pour la commande « plan » de Terraform.

    • Classes de VM personnalisées. Les clusters Tanzu Kubernetes peuvent consommer les classes de machine virtuelle personnalisées via le service de machine virtuelle. Cela permettra aux utilisateurs de configurer différentes quantités de CPU et de mémoire allouées aux machines virtuelles qui constituent un cluster Tanzu Kubernetes.

Nouveautés du 9 mars 2021

Informations sur le build du 9 mars 2021

ESXi 7.0 | 9 mars 2020 | Build ISO 17630552

vCenter Server 7.0 | 9 mars 2021 | Build ISO 17694817

VMware NSX Advanced Load Balancer | 12 octobre 2020 | 20.1.X

Nouvelles fonctionnalités

  • Cluster superviseur

    • Prise en charge de NSX Advanced Load Balancer pour un cluster superviseur configuré avec la mise en réseau VDS. Vous pouvez désormais activer un cluster superviseur avec NSX Advanced Load Balancer (Avi Networks) pour l'équilibrage de charge L4, ainsi que l'équilibrage de charge pour les nœuds de plan de contrôle des clusters superviseur et Tanzu Kubernetes. Pour obtenir des instructions sur la configuration de NSX Advanced Load Balancer, consultez la page de documentation.

    • Mise à niveau du cluster superviseur vers Kubernetes 1.19 avec mise à niveau automatique d'un cluster superviseur exécutant Kubernetes 1.16. Vous pouvez mettre à niveau le cluster superviseur vers Kubernetes 1.19. Avec cette mise à jour, les versions du cluster superviseur suivantes sont prises en charge : 1.19, 1.18 et 1.17. Les clusters superviseurs exécutant Kubernetes 1.16 seront automatiquement mis à niveau vers la version 1.17 après la mise à jour du système vCenter Server. Cela garantira que tous les clusters superviseurs s'exécutent avec la version de Kubernetes prise en charge.

    • Extension de PersistentVolumeClaims (PVC). Vous pouvez désormais développer les volumes existants en modifiant l'objet PersistentVolumeClaim, même lorsque le volume est en cours d'utilisation active. Cela s'applique aux volumes du cluster superviseur et des clusters Tanzu Kubernetes.

    • Gestion du cycle de vie du cluster superviseur à l'aide de vSphere Lifecycle Manager. Pour les clusters superviseurs configurés avec la mise en réseau NSX-T, vous pouvez utiliser vSphere Lifecycle Manager pour la configuration de l'infrastructure et la gestion du cycle de vie.

  • Tanzu Kubernetes Grid Service for vSphere

    • Prise en charge des registres de conteneurs privés. Les administrateurs vSphere et les opérateurs de plates-formes Kubernetes peuvent désormais définir des certificats d'autorité de certification (CA) supplémentaires à utiliser dans les clusters Tanzu Kubernetes pour approuver des registres de conteneur privé. Cette fonctionnalité permet aux clusters Tanzu Kubernetes d'extraire des images de conteneur à partir de registres de conteneur qui ont des certificats d'entreprise ou auto-signés. Vous pouvez configurer des autorités de certification privées par défaut pour les clusters Tanzu Kubernetes pour tout un cluster superviseur ou par cluster Tanzu Kubernetes. Pour en savoir plus sur la configuration de la prise en charge des registres de conteneur privé dans les clusters Tanzu Kubernetes, consultez la page de documentation.

    • Adresses IP définies par l'utilisateur pour le type de service : LoadBalancer avec NSX-T et NSX Advanced Load Balancer. Les opérateurs d'application Kubernetes peuvent désormais fournir un LoadBalancerIP défini par l'utilisateur lors de la configuration d'un type de service : LoadBalancer permettant un point de terminaison IP statique pour le service. Cette fonctionnalité avancée nécessite l'équilibrage de charge NSX-T ou NSX Advanced Load Balancer avec le cluster superviseur. Découvrez comment configurer cette fonctionnalité en accédant à la page de documentation.

    • ExternalTrafficPolicy et LoadBalancerSourceRanges pour le type de service : LoadBalancer avec NSX-T. Les opérateurs d'applications Kubernetes peuvent désormais configurer ExternalTrafficPolicy sur « local » pour que les services propagent l'adresse IP du client aux espaces de fin. Vous pouvez également définir loadBalancerSourceRanges pour les services de façon à limiter les adresses IP des clients qui peuvent accéder au service d'équilibrage de charge. Ces deux fonctionnalités avancées nécessitent l'équilibrage de charge NSX-T avec le cluster superviseur.

    • Indications et gestion de la version de Kubernetes. Vous pouvez désormais utiliser kubectl pour vérifier la compatibilité de TanzuKubernetesReleases avec l'environnement de cluster superviseur sous-jacent. En outre, les clusters Tanzu Kubernetes indiquent désormais si une mise à niveau de Kubernetes est disponible et recommandent les prochains TanzuKubernetesRelease(s) à utiliser. Pour plus d'informations sur l'utilisation de cette nouvelle fonctionnalité, consultez la page de documentation.

    • Aperçu rapide amélioré de l'état du cluster. Dans une version précédente, VMware développait les fichiers CRD WCPCluster et WCPMachine en mettant en œuvre des rapports d'état conditionnel pour faire apparaître les problèmes et les erreurs courants. Dans la version vSphere 7.0 Update 2, nous avons amélioré les fichiers CRD de TanzuKubernetesCluster pour qu'ils résument les rapports d'état conditionnel des composants des sous-systèmes, en fournissant des réponses immédiates et des conseils détaillés pour vous aider à résoudre les problèmes. Découvrez comment configurer cette fonctionnalité en accédant à la page de documentation.

    • Configuration du proxy HTTP pour chaque cluster Tanzu Kubernetes. Il est désormais possible de définir la configuration du proxy HTTP/HTTPS par cluster Tanzu Kubernetes ou, alternativement, de définir une configuration pour tout le cluster superviseur par le biais d'une configuration par défaut. Pour plus d'informations sur la configuration de cette fonctionnalité, consultez la page de documentation.

    • Prise en charge des extensions Tanzu Kubernetes Grid. Les extensions de cluster sont désormais entièrement prises en charge sur le service Tanzu Kubernetes Grid, y compris Fluent Bit, Contour, Prometheus, AlertManager et Grafana.

Considérations sur la mise à jour des clusters Tanzu Kubernetes

La version vSphere 7.0 Update 2 inclut une fonctionnalité qui met à jour automatiquement le cluster superviseur lors de la mise à jour de vCenter Server. Si des clusters Tanzu Kubernetes sont provisionnés dans votre environnement, lisez l'article 82592 de la base de connaissancesavant d'effectuer la mise à niveau vers vCenter Server 7.0 Update 2. L'article fournit des conseils sur l'exécution d'une vérification préalable pour déterminer si un cluster Tanzu Kubernetes devient incompatible après la mise à niveau automatique du cluster superviseur.

Problèmes résolus

  • Le certificat SSL du registre du conteneur intégré n'est pas copié sur les nœuds du cluster Tanzu Kubernetes

    • Lorsque le registre du conteneur intégré est activé pour un cluster superviseur, le certificat SSL Harbor n'est pas inclus dans les nœuds du cluster Tanzu Kubernetes créés sur ce cluster superviseur, et vous ne pouvez pas vous connecter au registre à partir de ces nœuds.

  • Après la mise à niveau de Tanzu Kubernetes Grid 1.16.8 vers la version 1.17.4, l'espace « guest-cluster-auth-svc » sur l'un des nœuds de plan de contrôle est bloqué à l'état « Création du conteneur »

    • Après la mise à niveau d'un cluster Tanzu Kubernetes depuis Tanzu Kubernetes Grid Service 1.16.8 vers la version 1.17.4, l'espace « guest-cluster-auth-svc » sur l'un des nœuds de plan de contrôle du cluster est bloqué à l'état « Création du conteneur »

  • L'utilisateur ne parvient pas à gérer les espaces existants sur un cluster Tanzu Kubernetes pendant ou après l'exécution d'une mise à jour du cluster

    • L'utilisateur ne parvient pas à gérer les espaces existants sur un cluster Tanzu Kubernetes pendant ou après l'exécution d'une mise à jour du cluster.

  • La tâche de mise à niveau du cluster Tanzu Kubernetes échoue avec le message « Expiration du délai d'attente pour l'approbation du contrôle de santé etcd ».

    • La tâche de mise à niveau dans l'espace de noms vmware-system-tkg associé à la mise à niveau d'un cluster Tanzu Kubernetes échoue avec le message d'erreur suivant : « Expiration du délai d'attente du contrôle de santé etcd à effectuer ». Ce problème est dû aux adresses PodIP manquantes pour les espaces etcd.

  • Antrea CNI n'est pas pris en charge dans la version actuelle de TKC

    • Lors du provisionnement d'un cluster Tanzu Kubernetes, l'erreur « Antrea CNI n'est pas pris en charge dans la version actuelle de TKC » est renvoyée.

      Option 1 (recommandée) : mettez à jour le cluster Tanzu Kubernetes pour utiliser la version de l'OVA qui prend en charge Antrea (v1.17.8 ou version ultérieure).

      Option 2 : dans le fichier YAML de spécification du cluster Tanzu Kubernetes, entrez « calico » dans la section spec.settings.network.cni.

      Option 3 : Modifiez le CNI par défaut sur Calico. Pour en savoir plus sur cette procédure, reportez-vous à la section de la documentation correspondante.

Nouveautés du 2 février 2021

Informations sur le build du 2 février 2021

ESXi 7.0 | 17 décembre 2020 | Build ISO 17325551

vCenter Server 7.0 | 2 février 2021 | Build ISO 17491101

Nouvelles fonctionnalités

  • Cluster superviseur

    • Mise à jour des clusters superviseurs utilisant la mise en réseau vSphere : vous pouvez désormais mettre à jour les clusters superviseurs qui utilisent la mise en réseau vSphere à partir d'une version antérieure de Kubernetes vers la version la plus récente disponible. Les nouvelles versions de cluster superviseur offrent également les fonctionnalités les plus récentes du service Tanzu Kubernetes Grid.

Problèmes résolus

  • Les nouvelles fonctionnalités du service Tanzu Kubernetes Grid n'étaient pas disponibles dans les superviseurs existants avec la mise en réseau vSphere

    • Dans la version précédente, les nouvelles fonctionnalités du service Tanzu Kubernetes Grid et les correctifs de bogues n'étaient disponibles que dans les clusters superviseurs récemment créés lorsque la mise en réseau vSphere était utilisée. Dans cette version, les utilisateurs peuvent désormais mettre à jour les clusters superviseurs avec la mise en réseau vSphere pour bénéficier des dernières fonctionnalités du service Tanzu Kubernetes Grid et des correctifs de bogues.

Nouveautés du 17 décembre 2020

Informations sur le build du 17 décembre 2020

ESXi 7.0 | 17 décembre 2020 | Build ISO 17325551

vCenter Server 7.0 | 17 décembre 2020 | Build ISO 17327517

Remarque : pour tirer parti des nouvelles fonctionnalités du service Tanzu Kubernetes Grid et des correctifs de bogue de cette version, vous devez créer un cluster superviseur si la mise en réseau vSphere est utilisée.

Nouvelles fonctionnalités

  • Cluster superviseur

    • Isolation de l'espace de noms du superviseur avec un routeur T1 dédié. Les clusters superviseurs qui utilisent le réseau NSX-T emploient une nouvelle topologie dans laquelle chaque espace de noms dispose de son propre routeur T1 dédié.

      • Les clusters superviseurs récemment créés utilisent automatiquement cette nouvelle topologie.

      • Les clusters superviseurs existants sont migrés vers cette nouvelle topologie au cours d'une mise à niveau.

    • Les clusters superviseurs prennent en charge NSX-T 3.1.0. Les clusters superviseurs sont compatibles avec NSX-T 3.1.0.

    • Prise en charge du cluster superviseur version 1.16.x supprimée. La version 1.16.x du cluster superviseur est à présent supprimée. Les clusters superviseurs exécutant la version 1.16.x doivent être mis à niveau vers une nouvelle version.

  • Tanzu Kubernetes Grid Service for vSphere

    • Prise en charge du proxy HTTP/HTTPS. Les clusters Tanzu Kubernetes nouvellement créés peuvent utiliser un proxy HTTP/HTTPS global pour le trafic de sortie ainsi que pour extraire des images de conteneur à partir de registres Internet.

    • Intégration au service de registre. Les clusters Tanzu Kubernetes nouvellement créés fonctionnent par défaut avec le service de registre vSphere. Les clusters existants, une fois mis à jour vers une nouvelle version, fonctionnent également avec le service de registre.

    • Stockage du nœud configurable. Les clusters Tanzu Kubernetes peuvent désormais monter un volume de stockage supplémentaire sur les machines virtuelles, augmentant ainsi la capacité de stockage disponible du nœud. Cela permet aux utilisateurs de déployer des images de conteneur plus volumineuses qui peuvent dépasser la taille de volume racine par défaut de 16 Go.

    • Amélioration des informations sur l'état. Les définitions de ressources personnalisées WCPCluster et WCPMachine implémentent désormais des rapports d'état conditionnels. Lagestion du cycle de vie des clusters Tanzu Kubernetes dépend d'un certain nombre de sous-systèmes (par exemple, le superviseur, le stockage, la mise en réseau) et déterminer les causes des pannes peut être compliqué. Désormais, les définitions de ressources personnalisées WCPCluster et WCPMachine indiquent l'état commun et les conditions d'échec pour faciliter le dépannage.

Problèmes résolus

  • Nouvelles classes de VM par défaut introduites dans vCenter Server 7.0 Update 1 manquantes

    • Après la mise à niveau vers vSphere 7.0.1 et l'exécution d'une mise à jour des espaces de noms vSphere du cluster superviseur, l'exécution de la commande « kubectl get virtualmachineclasses » ne répertorie pas les nouvelles tailles de classe de machines virtuelles (2x-large, 4x-large, 8x-large). Cela a été résolu et tous les clusters superviseurs seront configurés avec l'ensemble correct de classes de machines virtuelles par défaut.

Nouveautés du 6 octobre 2020

Informations sur le build du 6 octobre 2020

ESXi 7.0 | 6 octobre 2020 | Build ISO 16850804

vCenter Server 7.0 | 6 octobre 2020 | Build ISO 16860138

Nouvelles fonctionnalités

  • Cluster superviseur

    • Configuration des clusters superviseurs avec la mise en réseau vSphere . Nous avons introduit la mise en réseau vSphere pour les clusters superviseurs, ce qui vous permet de fournir une plate-forme prête pour les développeurs à l'aide de votre infrastructure réseau existante.

    • Prise en charge de l'équilibrage de charge HAproxy pour la configuration des clusters superviseurs avec la mise en réseau vSphere. Si vous configurez des clusters superviseurs avec la mise en réseau vSphere, vous devez ajouter un équilibrage de charge pour gérer vos charges de travail modernes. Vous pouvez déployer et configurer votre équilibrage de charge avec un fichier OVA HAproxy.

    • Gestion du cycle de vie du cluster superviseur à l'aide de vSphere Lifecycle Manager. Pour les clusters superviseurs configurés avec la mise en réseau vSphere, vous pouvez utiliser vSphere Lifecycle Manager pour la configuration de l'infrastructure et la gestion du cycle de vie.

    • Possibilité d'essayer vSphere with Tanzu sur votre matériel. Nous vous proposons désormais une version d'évaluation du produit si vous souhaitez activer un cluster superviseur sur votre matériel et tester cette plate-forme d'application moderne sans frais supplémentaires.

  • Tanzu Kubernetes Grid Service for vSphere

    • Exposition des versions de Kubernetes aux utilisateurs DevOps. Nous avons introduit une nouvelle définition de ressource personnalisée « TanzuKubernetesRelease » dans le cluster superviseur. Cette définition de ressource personnalisée fournit des informations détaillées à l'utilisateur DevOps sur les versions de Kubernetes qu'il peut utiliser dans ses clusters Tanzu Kubernetes.

    • Intégration de VMware Container Networking avec Antrea for Kubernetes. Nous avons intégré une version d'Antrea prise en charge commercialement en tant que CNI (Container Network Interface) par défaut pour les nouveaux clusters Tanzu Kubernetes. Antrea offre une suite complète de fonctionnalités de stratégie de réseau d'entreprise pour le service Tanzu Kubernetes Grid. Pour plus d'informations, lisez l'annonce de publication. Alors qu'Antrea est le CNI par défaut, les administrateurs de vSphere et les utilisateurs de DevOps peuvent toujours choisir Calico comme CNI pour les clusters Tanzu Kubernetes.

    • Prise en charge des environnements de cluster superviseur qui utilisent la mise en réseau vSphere. Nous prenons désormais en charge les environnements de cluster superviseur qui utilisent la mise en réseau vSphere de sorte que vous pouvez exploiter votre infrastructure réseau existante.

Problèmes résolus

  • Aucun élément. Il s'agit d'une version de la fonctionnalité.

Nouveautés du 25 août 2020

Informations sur le build du 25 août 2020

ESXi 7.0 | 23 juin 2020 | Build ISO 16324942

vCenter Server 7.0 | 25 août 2020 | Build ISO 16749653

Nouvelles fonctionnalités

  • Aucune, il s'agit simplement d'une version de correction de bogues.

Problèmes résolus

  • Utilisation élevée du CPU lors de la mise à niveau du correctif du 30 juillet

    • vCenter Server génère une utilisation élevée du CPU après la mise à niveau du correctif du 30 juillet. Ce problème est résolu.

  • Échec de l'activation du cluster superviseur en raison d'un certificat avec des fins de ligne Windows

    • L'activation du cluster superviseur peut échouer si le certificat contient des fins de ligne Windows. Ce problème est résolu.

Nouveautés du 30 juillet 2020

Informations sur le Build du 30 juillet 2020

ESXi 7.0 | 23 juin 2020 | Build ISO 16324942

vCenter Server 7.0 | 30 juillet 2020 | Build ISO 16620007

Nouvelles fonctionnalités

  • Cluster superviseur : nouvelle version de Kubernetes, prise en charge des certificats personnalisés et des modifications PNID

    • Le cluster superviseur prend désormais en charge Kubernetes 1.18.2 (ainsi que 1.16.7 et 1.17.4)

    • Le remplacement des certificats SSL de machine par des certificats personnalisés est désormais pris en charge

    • La mise à jour de vCenter PNID est désormais prise en charge lorsqu'il existe des clusters superviseurs dans l'instance de vCenter Server

  • Tanzu Kubernetes Grid Service for vSphere: nouvelles fonctionnalités ajoutées pour l'évolutivité, la mise en réseau et le stockage du cluster

    • L'opération d'évolutivité du cluster est désormais prise en charge pour les clusters de service Tanzu Kubernetes Grid

    • Les règles de pare-feu d'entrée sont désormais appliquées par défaut pour tous les clusters de services Tanzu Kubernetes Grid

    • Nouvelles versions de Kubernetes expédiées régulièrement de manière asynchrone vers les correctifs vSphere ; les versions actuelles sont 1.16.8, 1.16.12, 1.17.7, 1.17.8

  • Service réseau : nouvelle version de NCP

    • SessionAffinity est désormais pris en charge pour les services ClusterIP

    • IngressClass, PathType et le domaine de caractères génériques sont pris en charge pour l'entrée dans Kubernetes 1.18

    • L'authentification du client est désormais prise en charge dans le contrôleur d'entrée

  • Service de Registre : nouvelle version de Harbor

    • Le service de Registre est désormais mis à niveau vers 1.10.3

Pour plus d'informations et d'instructions sur la mise à niveau, reportez-vous à la documentation Mise à jour de clusters de vSphere with Tanzu.

Problèmes résolus

  • Problème de synchronisation NTP du cluster de services Tanzu Kubernetes Grid

Nouveautés du 23 juin 2020

Informations sur le build du 23 juin 2020

ESXi 7.0 | 23 juin 2020 | Build ISO 16324942

vCenter Server 7.0 | 23 juin 2020 | Build ISO 16386292

OVA des clusters Tanzu Kubernetes : v1.16.8+vmware.1-tkg.3.60d2ffd

Nouvelles fonctionnalités

  • Aucune, il s'agit simplement d'une version de correction de bogues.

Problèmes résolus

  • Échec de la mise à niveau d'un cluster du service Tanzu Kubernetes Grid

    • Nous avons résolu le problème d'échec possible d'une mise à niveau de cluster du service Tanzu Kubernetes Grid en raison de l'erreur « Error: unknown previous node »

  • Échec de la mise à niveau du cluster superviseur

    • Nous avons résolu le problème de blocage possible d'une mise à jour de cluster superviseur si le port Harbour intégré est dans un état d'échec

Nouveautés du 19 mai 2020

Informations sur le build du 19 mai 2020

ESXi 7.0 | 2 avril 2020 | Build ISO 15843807

vCenter Server 7.0 | 19 mai 2020 | Build ISO 16189094

OVA des clusters Tanzu Kubernetes : v1.16.8+vmware.1-tkg.3.60d2ffd

Nouvelles fonctionnalités

  • Tanzu Kubernetes Grid Service for vSphere : mise à niveau propagée et mise à niveau des services

    • Les clients peuvent désormais effectuer des mises à niveau propagées sur leurs nœuds Worker et leurs nœuds de plan de contrôle pour Tanzu Kubernetes Grid Service for vSphere, mais aussi mettre à niveau les services pvCSI, Calico et authsvc. Cela inclut les vérifications préalables et la compatibilité de la mise à niveau pour cette matrice de services.

    • Les mises à niveau propagées peuvent être utilisées pour la mise à l'échelle verticale des nœuds worker, c'est-à-dire pour modifier la classe de machine virtuelle de vos nœuds worker en une taille inférieure ou supérieure.

  • Cluster superviseur : prise en charge de la mise à niveau pour les nouvelles versions de Kubernetes

    • Le cluster superviseur prend désormais en charge Kubernetes 1.17.4

    • Le cluster superviseur prend désormais en charge la mise à niveau de Kubernetes 1.16.x vers la version 1.17.x

Problèmes résolus

  • Conflit de nom pour les espaces de noms supprimés

    • Nous avons résolu un problème au cours duquel, si un utilisateur supprimait un espace de noms vSphere, puis créait un espace de noms vSphere avec le même nom, un conflit de nom se produisait et empêchait de créer des clusters Tanzu Kubernetes.

  • Noms de distribution améliorés

    • Nous avons rendu la version de Kubernetes que vous exécutez plus lisible en déplaçant les informations de version OVF vers une colonne distincte.

Informations de build pour la version initiale de vSphere with Kubernetes

Informations sur le build du 2 avril 2020

ESXi 7.0 | 2 avril 2020 | Build ISO 15843807

vCenter Server 7.0 | 2 avril 2020 | Build ISO 15952498

OVA des clusters Tanzu Kubernetes : v1.16.8+vmware.1-tkg.3.60d2ffd

En savoir plus sur vSphere with Tanzu

VMware fournit différentes ressources que vous pouvez utiliser pour découvrir vSphere with Tanzu.

  • Apprenez à configurer, gérer et utiliser vSphere with Tanzu en consultant le guide Configuration et gestion de vSphere with Tanzu. Conçu pour les administrateurs système vSphere et les équipes DevOps, ce guide fournit des informations détaillées sur l'architecture, les services, les licences, la configuration système requise, la configuration et l'utilisation de vSphere with Tanzu.

  • Utilisez les guides de compatibilité VMware pour en savoir plus sur la compatibilité matérielle et l'interopérabilité des produits pour vSphere with Tanzu. vSphere with Tanzu a la même configuration matérielle requise que vSphere 7.0. Pour certaines configurations, l'utilisation de machines virtuelles NSX-T Edge est requise. Celles-ci ont leur propre sous-ensemble de compatibilité de CPU. Pour plus d'informations, reportez-vous au Guide d'installation de NSX-T Data Center.

  • Découvrez les langues disponibles pour vSphere with Tanzu dans la section Internationalisation des notes de mise à jour de vSphere 7.0. Il s'agit des mêmes langues que VMware fournit pour vSphere.

  • Affichez les informations de copyright et de licences pour les composants open source de vSphere with Tanzu dans la section Open source des notes de mise à jour de vSphere 7.0. Les notes de mise à jour de vSphere 7.0 vous indiquent également où télécharger les composants open source de vSphere.

Problèmes résolus

  • La carte de service de VM sur la page Résumé de l'espace de noms disparaît après une mise à niveau de vCenter vers la version vCenter Server 7.0 Update 2c

    Après une mise à niveau de vCenter de vCenter Server 7.0 Update 2a vers vCenter Server 7.0 Update 2c, les espaces de noms préexistants créés avant la mise à niveau n'affichent pas la carte Classe de VM et Bibliothèques de contenu sous la vue Résumé de l'espace de noms. Ce problème est spécifique de la source vCenter Server 7.0 Update 2a et ne doit pas affecter la mise à niveau de versions antérieures telles que vCenter Server 7.0 Update 2.

    Pour les espaces de noms affectés, la mise à niveau du cluster superviseur doit restaurer les cartes dans la vue Résumé de l'espace de noms.

  • Certaines opérations sur des machines virtuelles créées avec le service de VM peuvent échouer en raison d'une version de matériel de machine virtuelle incompatible

    Les opérations sur les machines virtuelles échouent si la version de matériel de la machine virtuelle de l'image OVF ne prend pas en charge l'opération. Par exemple, pour une image avec une version de matériel virtuel vmx-11, l'attachement d'un volume persistant échoue avec l'erreur suivante :

    Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed

    Solution : aucune.

  • Lors de la mise à niveau du cluster superviseur, des espaces vSphere supplémentaires peuvent être créés et bloqués à l'état en attente si le set Démon est utilisé

    Lors de la mise à niveau du cluster superviseur, le contrôleur du set Démon crée des espaces vSphere supplémentaires pour chaque nœud de plan de contrôle du superviseur. Cela est dû à un problème Kubernetes en amont.

    Solution : ajoutez NodeSelector/NodeAffinity à la spécification d'espace vSphere, de sorte que le contrôleur du set Démon puisse ignorer les nœuds du plan de contrôle pour la création d'espaces.

  • Échec intermittent de la création de l'espace :

    Certains environnements ont signalé un échec intermittent de la création de l'espace avec l'erreur suivante : « Échec de l'obtention de l'image. Expiration de la connexion avec une erreur Aucun chemin vers l'hôte ». Elle est causée par un délai d'expiration de 3 secondes par défaut lors de la demande d'extraction d'image.

    Pour augmenter la valeur du délai d'expiration par défaut, contactez GSS.

  • Le service de superviseur peut se bloquer si VC comprend un grand nombre d'hôtes déconnectés :

    Dans les environnements où de nombreux hôtes sont déconnectés en raison d'un nom d'utilisateur et d'un mot de passe incorrects, le service de superviseur peut s'être bloqué et ne pas être en mesure de redémarrer.

    Ce problème est résolu dans la dernière version.

  • La configuration d'un cluster superviseur avec NSX-T Data Center peut échouer sur vCenter Server 7.0 Update 3

    La configuration d'un cluster superviseur avec NSX-T Data Center peut échouer à installer le VIB Spherelet sur les hôtes ESXi avec l'erreur suivante :

    Could not find a trusted signer: self signed certificate

    Un VIB Spherelet auto-signé est intégré à vCenter Server 7.0 Update 3. Cependant, si le démarrage sécurisé n'est pas activé sur les hôtes ESXi qui font partie du cluster vSphere, ou si les hôtes ne disposent pas de vSphere Life Cycle Manager (vLCM) activé sur le cluster, l'activation du cluster superviseur réussit. Ce problème est résolu dans la dernière version.

  • La mise à niveau de vCenter vers la version 70u3f échoue, car le service WCP n'a pas démarré

    Reportez-vous à l'article 89010 de la base des connaissances

    Il est possible d'appliquer cette solution à vCenter Server 7.0u3f lui-même qui se trouve en état d'échec ou à vCenter Server 7.0u3d qui précède avant de commencer la mise à niveau vers la version 7.0u3f.

    1. Connectez-vous à la session SSH de vCenter Server avec des informations d'identification racine.

    2. Connectez-vous à la base de données WCP à l'aide de la commande ci-dessous :

    PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost

    3. Exécutez la commande suivante pour vérifier les entrées dont l'élément instance_id est null :

    SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;

    4. Mettez à jour l'élément instance_id dans cluster_db_configs vers l'UUID aléatoire où il est nul :

    UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;

    5. Le service WCP (et tout autre service qui n'a pas démarré après la mise à niveau) doit être redémarré une fois que l'entrée de base de données a été corrigée.

    service-control --status --all

    service-control --restart --all (--stop or --start)

    ou

    service-control --restart wcp (--stop or --start)

    6. Exécutez à nouveau les étapes 2 et 3 pour vérifier que l'élément instance_id n'est pas NULL. vCenter Server doit à présent être en cours d'exécution.

    7. À ce stade, si l'utilisateur a appliqué cette solution à vCenter Server 70u3d, poursuivez la mise à niveau vers vCenter Server 70u3f ou, si l'utilisateur a appliqué la solution à vCenter Server 70u3f, consultez le programme d'installation de l'interface VAMI (VMware Appliance Management Interface) ou celui de l'interface de ligne de commande et reprenez la mise à niveau.

  • La fonctionnalité Stratégie de sécurité peut ne pas être disponible après la mise à niveau

    Si NSX-T 3.1.x/3.0.x est présent, et que vCenter, puis Supervisor et enfin NSX-T, sont mis à niveau vers la version 3.2 ou une version ultérieure, la fonctionnalité SecurityPolicy peut ne pas être disponible, du fait que NCP n'a pas conscience de la mise à niveau de NSX-T.

  • Amélioration des performances de débit réseau sur les machines virtuelles de cluster Tanzu Kubernetes Grid qui utilisent Antrea-ENCAP avec LRO activé

    Ajout d'optimisations de chemin de données pour améliorer les performances de débit réseau pour les clusters Tanzu Kubernetes Grid qui utilisent Antrea-ENCAP avec LRO activé.

    Aucun

  • L'activation du registre Harbor intégré sur le superviseur peut entraîner une configuration par défaut non sécurisée

    Si vous avez effectué les étapes décrites dans la section Activer le registre Harbor intégré sur le cluster superviseur, une configuration par défaut non sécurisée peut être présente sur le registre Harbor intégré. Des informations supplémentaires sur ce sujet sont disponibles dans l'article 91452 de la base de connaissances VMware.

    Solution : il est possible de résoudre ce problème en installant cette version ou en mettant en œuvre une solution temporaire, comme décrit dans l'article 91452 de la base de connaissances.

Problèmes connus

Les problèmes connus sont classés comme suit :

Cluster superviseur

  • <span style="color:#FF0000">NEW:</span> Lors de la suppression de plusieurs FCD et volumes de banques de données partagées comme vSAN, vous pouvez constater des modifications de performances

    Les modifications des performances peuvent être dues à un problème résolu. Tant qu'il n'était pas corrigé, le problème entraînait le maintien des FCD et des volumes périmés dans la banque de données après l'échec d'une opération de suppression de FCD.

    Solution : aucune. L'opération de suppression fonctionne comme d'habitude malgré la modification des performances.

  • Lorsque vous déplacez un nœud ESXi déconnecté d'un cluster, mais qu'il reste sous le même centre de données, les espaces et les PVC exécutés sur le nœud restent à l'état Arrêt en cours

    Si un hôte ESXi est dans l'état Pas de réponse en raison d'un PSOD et que vous le sortez du cluster et le placez sous le même centre de données, les espaces et les PVC exécutés sur l'hôte sont bloqués à l'état Arrêt en cours. Le problème se produit même lorsqu'un nœud de secours est disponible dans le cluster.

    Il se produit généralement dans la situation suivante :

    1. Vous activez le service de partenaires sur le cluster superviseur et créez des instances du service.

    2. Un nœud ESXi sur lequel les instances de service s'exécutent subit un PSOD.

    3. Vous déconnectez l'hôte qui ne répond pas et le sortez du cluster sous le même centre de données.

      Lorsque l'hôte est placé en dehors du cluster, vous pouvez constater que les espaces et les PVC présents sur le nœud restent dans l'état Arrêt en cours.

    Solution : supprimez l'hôte de l'inventaire au lieu de le déplacer hors du cluster sous le même centre de données.

  • La création d'un espace échoue parfois sur un cluster superviseur lorsque DRS est défini en mode manuel.

    Les fonctionnalités HA et DRS automatisé doivent être activées sur les clusters sur lesquels vous activez la gestion de la charge de travail. L'activation de la gestion de la charge de travail sur les clusters sur lesquels HA et DRS ne sont pas activés ou sur lequel DRS s'exécute en mode manuel peut entraîner un comportement incohérent et des échecs de création d'espaces.

    Solution : activez DRS sur le cluster et définissez-le sur Entièrement automatisé ou Partiellement automatisé. Assurez-vous également que HA est activé sur le cluster.

  • La classe de stockage s'affiche lorsque vous exécutez kubectl get sc même après la suppression de la stratégie de stockage correspondante.

    Si vous exécutez kubectl get sc après la création d'une stratégie de stockage, ajoutez la stratégie à un espace de noms, puis supprimez la stratégie, la réponse de la commande répertorie toujours la classe de stockage correspondante.

    Solution : exécutez kubectl describe namespace pour voir les classes de stockage réellement associées à l'espace de noms.

  • Toutes les classes de stockage sont retournées lorsque vous exécutez kubectl describe storage-class ou kubectl get storage-class sur un cluster superviseur au lieu de retourner uniquement celles de l'espace de noms de superviseur.

    Lorsque vous exécutez la commande kubectl describe storage-class ou kubectl get storage-class sur un cluster superviseur, la commande renvoie toutes les classes de stockage au lieu de retourner uniquement celles de l'espace de noms de superviseur.

    Solution : déduisez les noms de classe de stockage associés à l'espace de noms à partir du nom détaillé du quota.

  • Le bouton de point de terminaison de partage de l'API Kubernetes ignore le nom de domaine complet, même s'il est configuré

    Même si le nom de domaine complet est configuré pour l'adresse IP du plan de contrôle Kubernetes pour l'espace de noms du cluster superviseur, le bouton Partager l'espace de noms fournit l'adresse IP au lieu du nom de domaine complet.

    Solution : partagez manuellement l'espace de noms du cluster superviseur avec le nom de domaine complet.

  • Impossible d'accéder à l'équilibrage de charge via l'identifiant kubectl vSphere

    Vous ne pouvez pas accéder au serveur d'API via l'identifiant kubectl vSphere lors de l'utilisation d'un point de terminaison à équilibrage de charge.

    Solution : ce problème peut se produire de deux façons.

    1. Vérifiez si le serveur d'API est accessible via le plan de contrôle <curl -k https://vip:6443 (ou 443)>

      1. Si vous ne parvenez pas à accéder à l'équilibreur de charge à partir du serveur d'API, le serveur d'API n'est pas encore opérationnel.

      2. Solution : attendez quelques minutes que le serveur d'API devienne accessible.

    2. Vérifiez si l'état du nœud de la machine virtuelle Edge est actif.

      1. Connectez-vous à NSX Manager.

      2. Accédez à Système > Infrastructure > Nœuds > Nœuds de transport Edge. L'état du nœud doit être actif.

      3. Accédez à Mise en réseau > Équilibrages de charge > Serveurs virtuels. Recherchez les VIP qui se terminent par kube-apiserver-lb-svc-6443 et kube-apiserver-lb-svc-443. Si leur état n'est pas activé, utilisez la solution suivante.

      4. Solution : redémarrez la machine virtuelle Edge. La machine virtuelle Edge doit être reconfigurée après le redémarrage.

  • Affichage d'erreurs de délai d'expiration pendant la configuration du cluster de vSphere with Tanzu

    Lors de la configuration du cluster, les messages d'erreur suivants peuvent s'afficher :

    Api request to param0 failed

    ou

    Config operation for param0 node VM timed out

    Solution : aucune. L'activation de vSphere with Tanzu peut prendre de 30 à 60 minutes. Si le message d'expiration param0 ou d'autres messages similaires s'affichent, il ne s'agit pas d'erreurs et vous pouvez les ignorer en toute sécurité.

  • La désactivation et la réactivation immédiate d'un service de vSphere dans vSphere with Tanzu entraînent la perte de réactivité d'un espace de noms correspondant dans l'instance de vCenter Server.

    Lorsque le service vSphere est désactivé et immédiatement réactivé, l'espace de noms dans le cluster superviseur est supprimé et recréé. Toutefois, l'espace de noms correspondant dans l'instance de vCenter Server reste dans l'état « Terminaison ». Par conséquent, les quotas de ressources ne peuvent pas être attribués à l'espace de noms dans l'instance de vCenter Server et les ingénieurs DevOps ne peuvent pas créer de ressources telles que des espaces et des PVC sur l'espace de noms. En outre, le déploiement du plug-in d'interface utilisateur échoue, car l'espace de l'opérateur de service ne peut pas s'exécuter.

    Vous pouvez obtenir les journaux de la plate-forme d'application en exécutant la commande suivante sur le cluster superviseur : kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0.

    Solution :

    avant de réactiver le service, attendez que l'espace de noms soit complètement supprimé de l'instance de vCenter Server.

    Si l'espace de noms est bloqué à l'état d'arrêt, procédez comme suit :

    1. Désactivez de nouveau le service.

    2. Redémarrez le service wcp dans l'instance de vCenter Server.

    3. Attendez que l'espace de noms soit supprimé. Cette étape peut prendre un certain temps.

    4. Réactivez le service.

  • Échec de l'activation du registre de conteneur avec une erreur

    Lorsque l'utilisateur active le registre de conteneur à partir de l'interface utilisateur, l'activation échoue après 10 minutes avec une erreur de délai d'expiration.

    Solution : désactivez le registre de conteneur et essayez de l'activer de nouveau. Notez que l'erreur de délai d'expiration peut se produire à nouveau.

  • L'activation d'un cluster après sa désactivation échoue avec une erreur.

    L'activation d'un cluster peu après la désactivation du cluster peut créer un conflit dans le processus de réinitialisation du mot de passe du compte de service. L'action d'activation échoue avec une erreur.

    Solution : redémarrez avec la commande vmon-cli --restart wcp.

  • La suppression d'une balise d'image de conteneur dans un registre de conteneur intégré peut supprimer toutes les balises d'image qui partagent la même image de conteneur physique

    Plusieurs images avec des balises différentes peuvent être envoyées vers un projet dans un registre de conteneur intégré à partir de la même image de conteneur. Si l'une des images du projet est supprimée, toutes les autres images avec des balises différentes qui sont envoyées à partir de la même image seront supprimées.

    Solution : cette opération ne peut pas être annulée. Transférez de nouveau l'image vers le projet.

  • L'échec de l'opération de purge sur un projet de registre entraîne l'état d'erreur du projet

    Lorsque vous effectuez une opération de purge sur un projet de registre, le projet s'affiche temporairement comme étant dans un état d'erreur. Vous ne pourrez ni envoyer ni extraire d'images de ce type de projet. À intervalles réguliers, le projet sera vérifié et tous les projets qui sont en état d'erreur seront supprimés et recréés. Dans ce cas, tous les membres du projet précédent seront rajoutés au projet recréé et tous les référentiels et images qui existaient précédemment dans le projet seront supprimés, ce qui terminera efficacement l'opération de purge.

    Solution : aucune.

  • Échec de l'activation du registre de conteneur lorsque la capacité de stockage est inférieure à 2 000 mébioctets

    Il existe une exigence de capacité de stockage totale minimale pour le registre de conteneur, représentée par le champ « limite » dans VMODL. Cela est dû au fait que certains espaces Kubernetes doivent disposer d'un espace de stockage suffisant pour fonctionner correctement. Pour obtenir la fonctionnalité de registre de conteneur, il existe une capacité minimale de 5 gigaoctets. Notez que cette limite n'offre aucune garantie d'amélioration des performances ou d'augmentation du nombre ou de la taille des images pouvant être prises en charge.

    Solution : ce problème peut être évité en déployant le registre de conteneur avec une capacité totale supérieure. Le volume de stockage recommandé est d'au moins 5 gigaoctets.

  • Si vous remplacez le certificat TLS de l'équilibrage de charge NSX pour le cluster Kubernetes, vous risquez de ne pas parvenir à vous connecter au registre Harbor intégré à partir d'un client Docker ou de l'interface utilisateur de Harbor

    Pour remplacer le certificat TLS de l'équilibrage de charge NSX pour le cluster Kubernetes, dans l'interface utilisateur de vSphere accédez à Configurer > Espaces de noms > Certificats > Équilibrage de charge NSX > Actions, puis cliquez sur Remplacer le certificat. Lorsque vous remplacez le certificat NSX, la connexion au registre Harbor intégré à partir d'un client Docker ou de l'interface utilisateur de Harbor peut échouer avec l'erreur unauthorized: authentication required ou Invalid user name or password.

    Solution : redémarrez l'espace de l'agent du registre dans l'espace de noms vmware-system-registry :

    1. Exécutez la commande kubectl get pod -n vmware-system-registry.

    2. Supprimez la sortie de l'espace en exécutant la commande kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry .

    3. Patientez jusqu'au redémarrage de l'espace.

  • Les espaces déployés avec DNSDefault utiliseront les paramètres clusterDNS

    Tout espace vSphere déployé dans des clusters superviseur qui utilisent DNSDefault recommencera à utiliser les paramètres clusterDNS configurés pour le cluster

    Solution : aucune.

  • Tous les hôtes d'un cluster peuvent être mis à jour simultanément lors de la mise à niveau d'un cluster superviseur

    Dans certains cas, tous les hôtes d'un cluster seront mis à jour en parallèle lors du processus de mise à niveau du cluster superviseur. Cela entraînera une interruption de service pour tous les espaces s'exécutant sur ce cluster.

    Solution : lors de la mise à niveau du cluster superviseur, ne redémarrez pas wcpsvc ou ne supprimez/n'ajoutez pas d'hôtes.

  • La mise à niveau du cluster superviseur peut être bloquée indéfiniment si VMCA est utilisé comme autorité de certification intermédiaire

    La mise à niveau du cluster superviseur peut être bloquée indéfiniment à l'état « configuration » si VMCA est actuellement utilisé comme autorité de certification intermédiaire.

    Solution : basculez vers une autorité de certification non intermédiaire pour VMCA et supprimez toutes les machines virtuelles de plan de contrôle bloquées à l'état « configuration ».

  • Le déploiement de l'espace vSphere échoue si une stratégie de stockage pour laquelle le chiffrement est activé est attribuée à des disques éphémères d'espace.

    Si une stratégie de stockage pour laquelle le chiffrement est activé est utilisée pour des disques éphémères d'espace, la création de l'espace vSphere échoue avec l'erreur « Échec d'AttachVolume.Attach pour le volume ».

    Solution : Utilisez une stratégie de stockage sans chiffrement pour les disques éphémères d'espace.

  • La mise à niveau du cluster superviseur se bloque à 50 % lors de l'affichage de « La mise à niveau d'un cluster d'espaces de noms est à l'étape hôte »

    Le problème se produit lorsqu'un espace vSphere se bloque à l'état TERMINAISON pendant la mise à niveau du nœud du plan de contrôle Kubernetes. Le contrôleur du nœud du plan de contrôle tente de mettre à niveau le processus Spherelet et, pendant cette phase, des espaces vSphere sont évincés ou éliminés sur ce nœud du plan de contrôle pour annuler l'enregistrement du nœud dans le plan de contrôle Kubernetes. Par conséquent, la mise à niveau du cluster superviseur se bloque à une version antérieure jusqu'à ce que les espaces vSphere en état TERMINAISON soient supprimés de l'inventaire.

    Solution :

    1. Connectez-vous à l'hôte ESXi sur lequel l'espace vSphere est bloqué à l'état TERMINAISON.

    2. Supprimez les espaces vSphere TERMINAISON à l'aide des commandes suivantes :

    # vim-cmd vmsvc/getallvms

    # vim-cmd vmsvc/destroy

    Après cette étape, les espaces vSphere s'affichent à l'état inactif dans vSphere Client.

    3. Supprimez les espaces vSphere inactifs en ajoutant d'abord un utilisateur au groupe ServiceProviderUsers.

    a.) Connectez-vous à vSphere Client, sélectionnez Administration -> Utilisateurs et groupes -> Créer un utilisateur, puis cliquez sur Groupes.

    b.) Recherchez ServiceProviderUsers ou le groupe Administrateurs et ajoutez un utilisateur au groupe.

    4. Connectez-vous à vSphere Client avec l'utilisateur qui vient d'être créé et supprimez les espaces vSphere inactifs.

    5. Dans kubectl, utilisez la commande suivante :

    kubectl patch pod -p -n '{"metadata":{"finalizers":null}}'

  • L'interface utilisateur de gestion de la charge de travail renvoie l'erreur de licence suivante : Aucun des hôtes connectés à cette instance de vCenter ne dispose d'une licence pour la gestion de la charge de travail

    Après avoir correctement activé la gestion de la charge de travail sur un cluster vSphere, l'erreur de licence suivante peut se produire après le redémarrage de l'instance de vCenter Server ou la mise à niveau d'hôtes ESXI sur lesquels la gestion de la charge de travail est activée : Aucun des hôtes connectés à cette instance de vCenter ne dispose d'une licence pour la gestion de la charge de travail. Il s'agit d'une erreur d'interface utilisateur esthétique. Votre licence doit toujours être valide et les charges de travail doivent toujours être en cours d'exécution.

    Solution : effacez le cache du navigateur pour vSphere Client.

  • Les environnements vSphere volumineux peuvent nécessiter une synchronisation prolongée sur un cloud avec le contrôleur VMware NSX Advanced Load Balancer

    Les environnements vSphere avec des inventaires qui contiennent plus de 2 000 hôtes ESXi et 45 000 machines virtuelles peuvent nécessiter jusqu'à 2 heures pour se synchroniser sur un cloud à l'aide d'un contrôleur NSX Advanced Load Balancer.

    Solution : aucune

  • Le registre de conteneur privé du cluster superviseur peut devenir défectueux après la modification du certificat racine VMware Certificate Authority (VMCA) sur un système vCenter Server 7.0 Update 2

    Après avoir modifié le certificat racine de l'autorité de certification VMware (VMCA) sur un système vCenter Server 7.0 Update 2, le registre de conteneur privé du cluster superviseur peut devenir défectueux et les opérations de registre peuvent cesser de fonctionner comme prévu. Le message d'état de santé suivant du registre du conteneur s'affiche sur l'interface utilisateur de configuration du cluster :

    Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority

    Solution :

    Redémarrez manuellement l'espace de l'agent de registre dans l'espace de noms vmware-system-registry sur le cluster vSphere Kubernetes :

    1. Exécutez la commande kubectl get pod -n vmware-system-registry pour obtenir un espace d'agent de registre.

    2. Supprimez la sortie de l'espace en exécutant la commande kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry.

    3. Patientez jusqu'au redémarrage de l'espace.

    4. Actualisez le registre d'images sur l'interface utilisateur de la configuration du cluster et l'état de santé devrait rapidement s'afficher comme étant en cours d'exécution.

  • Les projets des espaces de noms récemment créés sur le cluster superviseur ne sont pas automatiquement créés sur le registre de conteneur privé

    Les projets peuvent ne pas être créés automatiquement sur le registre de conteneur privé pour les espaces de noms nouvellement créés sur un cluster superviseur. L'état du registre du conteneur est toujours affiché comme étant sain, mais aucun projet n'est affiché dans le registre du conteneur du cluster lorsqu'un nouvel espace de noms est créé. Vous ne pouvez pas transférer ou extraire des images vers les projets des nouveaux espaces de noms sur le registre du conteneur.

    Solution :

    1. exécutez la commande kubectl get pod -n vmware-system-registry pour obtenir l'espace de l'agent de registre.

    2. Supprimez la sortie de l'espace en exécutant la commande kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry.

    3. Patientez jusqu'au redémarrage de l'espace.

    4. Connectez-vous au registre de conteneur privé pour vérifier que les projets sont créés pour les espaces de noms sur le cluster.

  • Vous pouvez observer l'erreur ErrImgPull lors de la création d'espaces avec 10 réplicas

    Ce problème peut survenir lorsque vous tentez d'utiliser un déploiement avec 10 espaces de réplica dans un fichier YAML. Lorsque vous tentez de créer des espaces avec ce fichier YAML à l'aide du registre de conteneur privé, sur 10 réplicas, au moins 7 peuvent réussir et 3 peuvent échouer avec l'erreur « ErrImgPull ».

    Solution : utilisez un maximum de 5 ensembles de réplicas.

  • Le contrôleur NSX Advanced Load Balancer n'est pas pris en charge lorsque le système vCenter Server est déployé avec un port personnalisé

    Vous ne pouvez pas enregistrer le système vCenter Server dans le contrôleur NSX Advanced Load Balancer, car il n'existe aucune option pour fournir un port vCenter Server personnalisé dans l'interface utilisateur du contrôleur NSX Advanced Load Balanced lors de l'enregistrement.

    Le contrôleur NSX Advanced Load Balancer fonctionne uniquement lorsque le système vCenter Server est déployé avec les ports par défaut 80 et 443.

  • Lorsque vous effectuez un repointage de domaine sur l'instance de vCenter Server qui contient déjà des clusters superviseurs en cours d'exécution, les clusters superviseurs passeront à l'état Configuration

    Le repointage de domaine n'est pas pris en charge sur les instances de vCenter Server qui disposent de clusters superviseurs. Lorsque vous tentez d'effectuer le repointage de domaine, les clusters superviseurs existants passent à l'état Configuration, et les machines virtuelles de plan de contrôle et du cluster Tanzu Kubernetes n'apparaissent plus dans l'inventaire sous la vue Hôtes et clusters.

    Solution : aucune.

  • L'attribution de balises et d'attributs personnalisés ne fonctionne pas pour les VM créées à l'aide de Kubernetes dans un cluster superviseur

    Lorsque vous tentez d'attribuer des balises ou des attributs personnalisés à une VM créée dans un cluster superviseur via le client UI vSphere ou à l'aide de vAPI, l'opération échoue avec le message « Une erreur s'est produite lors de l'attachement de balises ».

    Solution : aucune.

  • Les développeurs autorisés à accéder aux espaces de noms en libre-service ne peuvent pas accéder aux ressources à l'échelle du cluster telles que les classes de stockage

    Lorsque les développeurs tentent de lister les classes de stockage à l'échelle du cluster à l'aide de la commande kubectl

    kubectl get storageclass -n test-ns or kubectl get storageclass

    Ils rencontrent l'erreur suivante.

    Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope

    Solution : Ce comportement est attendu, car les développeurs n'ont accès qu'aux classes de stockage attribuées au modèle d'espace de noms auquel ils ont accès. Cela est déterminé préalablement par l'administrateur vSphere.

    La commande ci-dessous permet de lister les classes de stockage associées à l'espace de noms.

    kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE>

  • L'utilisation de « kubectl apply -f » pour accéder à un espace de noms en libre-service échoue

    La tentative de création d'un espace de noms à l'aide d'un manifeste avec kubectl apply -f échoue avec l'erreur

    Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope

    Solution : les développeurs peuvent plutôt utiliser la commande kubectl create -f pour créer un espace de noms.

  • La création d'espaces vSphere dans un espace de noms en libre-service échoue par intermittence

    Vous pouvez rencontrer l'erreur « impossible de créer des espaces de ressources » lors de la tentative de création d'un espace vSphere dans un espace de noms créé à l'aide du modèle d'espace de noms en libre-service.

    Solution : attendez quelques secondes après la création de l'espace de noms pour créer des espaces vSphere dans l'espace de noms.

  • Les développeurs ne peuvent pas ajouter des étiquettes et des annotations aux espaces de noms créés à l'aide du modèle d'espace de noms en libre-service

    La tentative de spécification d'étiquettes et d'annotations dans le manifeste utilisé pour créer ou modifier un espace de noms à l'aide de la commande kubectl apply -f échouera avec l'erreur

    Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""

    Solution : Ajoutez les étiquettes et les annotations requises au manifeste de l'espace de noms et utilisez plutôt kubectl create -f afin d'ajouter des étiquettes et des annotations.

  • Vous ne pouvez pas utiliser le modèle d'espace de noms tant qu'une mise à niveau du cluster superviseur est en cours d'exécution

    Lorsque vous démarrez une mise à niveau du cluster superviseur, toutes les tâches liées au modèle d'espace de noms, telles que l'activation, la désactivation ou les mises à jour, restent dans une file d'attente jusqu'à la fin de la mise à niveau.

    Solution : attendez la fin de l'opération de mise à niveau avant d'utiliser des commandes pour manipuler le modèle d'espace de noms.

  • Les tentatives d'attachement d'un volume persistant à un espace sur un cluster Tanzu Kubernetes échouent avec le message d'erreur « CNS : échec de l'attachement du disque, car le contrôleur SCSI est manquant »

    Lorsque vous tentez d'attacher un volume persistant à un espace sur un cluster Tanzu Kubernetes, vos tentatives échouent et l'espace reste dans un état d'attente. Le message d'erreur indique que le contrôleur SCSI est manquant même si un contrôleur PVSCSI est configuré pour la machine virtuelle du nœud worker.

    Ce problème peut se produire lorsque la machine virtuelle du nœud worker atteint sa limite de volume de blocs de 60 volumes. Toutefois, Kubernetes ignore les limites de volume vSphere et les planifications bloquent la création de volumes sur ce nœud.

    Solution : ajoutez un nœud worker au cluster. Supprimez l'espace pour planifier son déploiement sur le nouveau nœud worker.

  • La suppression d'un espace avec état après une session vCenter Server inactive et les tentatives de réutilisation ou de suppression ultérieures de son volume dans le cluster Tanzu Kubernetes peuvent entraîner des pannes et un comportement imprévisible

    Lorsque vous supprimez un espace avec état après un jour ou deux d'inactivité, son volume semble être correctement détaché de la machine virtuelle de nœud du cluster Tanzu Kubernetes. Toutefois, lorsque vous tentez de créer un espace avec état avec ce volume ou de supprimer le volume, vos tentatives échouent, car le volume est toujours attaché à la machine virtuelle du nœud dans l'instance de vCenter Server.

    Solution : utilisez l'API CNS pour détacher le volume de la machine virtuelle du nœud afin de synchroniser l'état du volume dans le cluster Tanzu Kubernetes et l'instance de vCenter Server. Redémarrez également le contrôleur CSI dans le cluster superviseur pour renouveler la session inactive.

  • La mise à niveau du cluster superviseur est bloquée ou ne se termine pas en raison de l'épuisement de la plage d'adresses IP sur le réseau de charge de travail principal du cluster superviseur (si vous utilisez Mise en réseau vSphere) ou les CIDR d'espace réseau du cluster NCP (si vous utilisez le plugin NSX-T Container).

    La mise à niveau du cluster superviseur est bloquée à l'état En attente avec le message : « La mise à niveau du cluster d'espaces de noms est en provision d'une nouvelle étape maître ».

    Les nouvelles machines virtuelles du plan de contrôle déployées lors de la mise à niveau du cluster ne reçoivent qu'une seule interface réseau. Les machines virtuelles du plan de contrôle doivent disposer de 2 interfaces réseau, l'une connectée au réseau de gestion et l'autre au réseau de charge de travail.

    Certains espaces système, tels que coredns, qui est censé être déployé sur la nouvelle machine virtuelle du plan de contrôle, peuvent être bloqués à l'état En attente.

    Solution : supprimez un petit nombre de charges de travail (VM, VM d'espace, clusters TKG) pour libérer suffisamment d'adresses IP afin de terminer le processus de mise à niveau. Au moins 3 adresses IP doivent être libérées.

  • Mettez à jour les paires clé-valeur ou les informations d'identification de registre pour une configuration de service de superviseur

    Vous souhaiterez peut-être modifier les paires clé-valeur de registre de configuration d'un service de superviseur, car vous avez entré des informations d'identification de connexion incorrectes ou le mot de passe de registre peut avoir expiré.

    Solution :

    1. Créez une ressource secrète sur le cluster superviseur.

    kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=

    2. Mettez à jour la référence de service pour la ressource de service de superviseur.

    # kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services

    3. Mettez à jour la session spec.config :

    spec:

    config:

    secretNamespace: vmware-system-supervisor-services

    secretRef: new-secret

  • Les plug-ins d'interface utilisateur de Tanzu Kubernetes Grid Service et du service de superviseur ne fonctionnent pas

    Lorsque le système vCenter Server est signé par un certificat d'autorité de certification personnalisé et que le cluster superviseur est activé, le plug-in de l'interface utilisateur du service Tanzu Kubernetes et les plug-ins de l'interface utilisateur du service de superviseur déployés dans vSphere Client ne fonctionnent pas. Les plug-ins de l'interface utilisateur rencontrent des problèmes d'authentification SSL lorsqu'ils tentent de communiquer avec leurs serveurs principaux respectifs dans le cluster superviseur. Le plug-in de Tanzu Kubernetes Grid Service affiche l'erreur suivante :

    The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details

    Solution : ajoutez la racine d'approbation dans un fichier distinct (pas dans vmca.pem) dans /etc/ssl/certs et régénérez les hachages à l'aide de c_rehash. Vous devez effectuer cette opération sur les trois machines virtuelles du plan de contrôle.

    Notez qu'il n'est pas recommandé de modifier /etc/ssl/certs/vmca.pem, car le contenu de ce fichier sera remplacé par update-controller lors de chaque synchronisation du cluster.

    Tenez compte du fait que si l'une des machines virtuelles du plan de contrôle dans le cluster superviseur est redéployée (par exemple, après le redimensionnement des machines virtuelles du plan de contrôle ou en raison d'une opération de réparation), le certificat ajouté manuellement à /etc/ssl/certs sera perdu et la solution devra être réappliquée à cette machine virtuelle.

  • Blocage du cluster superviseur dans l'état de configuration

    Après la configuration d'un cluster vSphere en tant que cluster superviseur, celui-ci se bloque à l'état de configuration. Vous ne pouvez pas créer d'espaces vSphere ni de clusters Tanzu Kubernetes.

    Solution : Redémarrez le service mcs à l'aide de la commande suivante :

    vmon-cli restart wcp

    Pour obtenir des instructions plus détaillées, reportez-vous à la documentation.

  • La commande « kubectl get virtualmachineimages » ne renvoie aucun résultat, même lorsque la bibliothèque de contenu associée est remplie avec des images de machine virtuelle

    Si la bibliothèque de contenu utilisée par le service de machine virtuelle est activée avec une stratégie de sécurité, le service de machine virtuelle ne parvient pas à lire les images et les machines virtuelles ne peuvent pas être déployées à l'aide des images de cette bibliothèque de contenu.

    Solution : Dissociez la bibliothèque de contenu de la stratégie de sécurité de l'espace de noms de superviseur. Supprimez le paramètre « Stratégie de sécurité OVF par défaut » de la bibliothèque de contenu appropriée, puis associez de nouveau la bibliothèque de contenu à l'espace de noms.

  • Les développeurs voient des propriétés POWERSTATE incorrectes pour les machines virtuelles avec vGPU et périphériques de relais qui sont gérées par le service de machine virtuelle lorsque leur hôte entre en mode de maintenance.

    Lorsqu'un hôte entre en mode de maintenance, les machines virtuelles disposant de vGPU et de périphériques de relais gérées par le service de VM sont automatiquement mises hors tension par DRS. Toutefois, la sortie de la commande kubectl get vm affiche l'état d'alimentation précédent et les machines virtuelles. Cela entraîne l'affichage de POWERSTATE=poweredOn même lorsque la machine virtuelle est hors tension sur vCenter.

    aucune.

  • Sur un cluster superviseur avec NSX-T, les hôtes ESXi peuvent continuer à utiliser des VIB Spherelet auto-signés

    Si vous avez configuré ou mis à niveau votre cluster superviseur avec la version de Kubernetes disponible dans vCenter Server 7.0 Update 3 et que vous avez mis à niveau la version Kubernetes de votre cluster superviseur vers une version disponible dans vCenter Server 7.0 Update 3a, le ou les hôtes ESXi peuvent continuer à utiliser des VIB Spherelet auto-signés. Cela se produit, car la version du VIB Spherelet auto-signé installée sur vCenter Server 7.0 Update 3 et vCenter Server 7.0 Update 3a sont identiques. Ce problème ne s'applique pas à un cluster superviseur configuré avec la pile de mise en réseau vSphere.

    Solution 1 :

    Si le cluster vSphere n'est pas basé sur vSphere Lifecycle Manager, procédez comme suit pour installer les VIB Spherelet certifiés par VMware :

    1. Mettez un hôte ESXi en mode de maintenance et attendez qu'il soit marqué comme « Non prêt » par le cluster superviseur.

    2. Déplacez cet hôte en dehors du cluster pour le définir en tant qu'hôte autonome et attendez que la désinstallation des VIB Spherelet et NSX-T soit effectuée.

    3. Replacez l'hôte dans le cluster, quittez le mode de maintenance et attendez que les nouveaux VIB Spherelet et NSX-T soient configurés à nouveau.

    4. Répétez les étapes ci-dessus pour chaque hôte ESXi dans le cluster.

    Si le cluster superviseur est activé dans vSphere Lifecycle Manager, désactivez-le, puis reconfigurez-le.

    Solution 2 :

    Une fois l'instance de vCenter Server mise à niveau vers vCenter Server 7.0 Update 3a, désactivez le cluster superviseur et reconfigurez-le. Cela s'applique aux clusters activés dans vSphere Lifecycle Manager ainsi qu'aux clusters non-vLCM/VUM.

  • Certains espaces vSphere affichent un état NodeAffinity après le redémarrage de l'hôte ou la mise à niveau du cluster superviseur

    Après avoir redémarré l'hôte ou mis à niveau le cluster superviseur, vous pouvez voir un état NodeAffinity pour certains espaces vSphere. Ce comportement est dû à un problème Kubernetes en amont dans lequel le planificateur Kubernetes crée des espaces redondants avec un état NodeAffinity dans le cluster après le redémarrage de kubelet. Le fonctionnement du cluster n'est pas affecté par ce problème. Pour plus d'informations sur le problème Kubernetes en amont, consultez la page https://github.com/kubernetes/kubernetes/issues/92067.

    Solution : supprimez les espaces redondants avec l'état NodeAffinity.

  • L'opérateur de service vDPp et les espaces d'instance activés sur vSphere with Tanzu passent à l'état En attente après la mise à niveau de votre environnement vers la version 7.0 Update 3e ou une version ultérieure

    Ce problème se produit si la version du service de partenaires installée sur le cluster superviseur ne prend pas en charge Kubernetes version 1.22. Après la mise à niveau de votre environnement vSphere with Tanzu vers la version 7.0 Update 3e ou une version ultérieure compatible avec la version 1.22, le service devient incompatible. Par conséquent, les espaces d'opérateur et d'instance passent à l'état En attente.

    Les tentatives de mise à niveau du service vers une version plus récente échouent.

    Solution : mettez à niveau le service vDPp vers une version compatible avec Kubernetes 1.22 avant de mettre à niveau vSphere with Tanzu vers la version 7.0 Update 3e.

  • La mise à niveau automatique d'un cluster de Kubernetes 1.19.1 vers la version 1.20.8 ne progresse pas

    Dans de rares occasions, la mise à niveau automatique d'un cluster Kubernetes 1.19.1 vers la version 1.20.8 peut échouer avec l'erreur suivante :

    Tâche de mise à niveau introuvable. Relancez la mise à niveau.

    Solution : lancez manuellement la mise à niveau du cluster.

  • Les opérations sur l'espace de noms de superviseur peuvent échouer s'il a été réutilisé après une courte période :

    Lorsqu'un espace de noms de superviseur est supprimé, puis recréé avec le même nom après une courte période, les opérations peuvent échoué en raison d'une entrée non valide dans le cache.

    Ce problème est résolu dans la dernière version.

  • Le bundle de support de superviseur inclut le bundle de support VC

    Lors de la génération d'un bundle de support de superviseur, le bundle de support VC n'est pas inclus automatiquement.

    Ce problème est résolu dans la dernière version.

  • Contenu de la liste de contrôle de support réseau non localisé

    Lors de l'activation de la gestion de la charge de travail, il est possible de télécharger une liste de contrôle du réseau. Son contenu n'est pas localisé.

    Ce problème est résolu dans la dernière version.

  • Dans une configuration de cluster Tanzu Kubernetes mis à l'échelle, un problème OOM est observé sur les espaces système WCP capi-kubeadm-control-plane-controller-manager

    Ce problème est documenté dans l'article de la base de connaissances

    https://kb.vmware.com/s/article/88914

    Consultez l'article de la base de connaissances

  • Blocage de la mise à niveau du cluster superviseur à l'étape de mise à niveau des composants en raison de l'échec de la mise à niveau de TKG ou de CAPW.

    Ce problème est documenté dans l'article de la base de connaissances

    https://kb.vmware.com/s/article/88854

  • La stratégie de sécurité ne supprime pas les règles mises à jour.

    Si une CR de stratégie de sécurité qui contient les règles A et B est créée, puis mise à jour avec une stratégie modifiant les règles en B et C, la règle A est toujours appliquée.

    Solution : Supprimez la stratégie de sécurité et recréez-la avec les règles mises à jour.

  • Les équilibrages de charge et les clusters Tanzu Kubernetes ne sont pas créés lorsqu'il existe deux groupes SE sur NSX Advanced Load Balancer.

    Si un deuxième groupe SE est ajouté à NSX Advanced Load Balancer avec ou sans SE, ou avec des services virtuels qui lui sont attribués, la création de clusters superviseurs ou de clusters Tanzu Kubernetes échoue et les clusters superviseurs existants ne peuvent pas être mis à niveau. La création du service virtuel sur le contrôleur NSX Advanced Load Balancer échoue avec l'erreur suivante :

    « La commande get() a renvoyé plusieurs ServiceEngineGroup, elle en a renvoyé 2 »

    Par conséquent, les nouveaux équilibrages de charge sont inutilisables et vous ne pouvez pas créer de nouveaux clusters de charge de travail.

    Pour plus d'informations, consultez l'article 90386 de la base de connaissances VMware.

    Solution : Seul le groupe SE « Default-Group » doit être utilisé pour la création de VirtualService ; supprimez tous les autres groupes SE de NSX Advanced Load Balancer, à l'exception du groupe par défaut, et recommencez l'opération.

  • La stratégie de sécurité mise à jour n'est pas appliquée.

    Si une CR de stratégie de sécurité qui contient les règles A et B est créée, puis mise à jour avec une modification des règles en B et C, la règle A est toujours en vigueur et n'est pas supprimée.

    Solution : Créez et appliquez une nouvelle stratégie qui inclut les règles B et C, puis supprimez l'ancienne stratégie contenant les règles A et B.

  • L'API de gestion de l'espace de noms peut parfois renvoyer une erreur HTTP 500, échec de l'autorisation d'une demande

    Une demande à la gestion de la charge de travail peut échouer par intermittence. L'API renvoie un code d'état 500 et aucune demande ne sera traitée. Vous trouverez un message de journal indiquant : « Une erreur inattendue s'est produite lors de l'autorisation ». Ce problème est intermittent, mais il est plus susceptible de se produire lorsque la gestion de la charge de travail subit une charge, par exemple lors de la configuration active d'un ou de plusieurs superviseurs.

    Solution : Réessayez l'opération que vous étiez en train de tenter lorsque l'erreur s'est produite.

  • Par intermittence, le cluster superviseur peut rester dans l'état CONFIGURATION ou ERREUR.

    Lors de l'activation, de la mise à niveau ou du redéploiement d'un autre nœud d'un cluster superviseur, celui-ci peut rester dans l'état CONFIGURATION ou ERREUR et afficher le message d'erreur suivant :

    « Échec de la demande d'API à VMware vCenter Server (vpxd). Détails « ServerFaultCode : Une erreur système générale s'est produite : les codes d'erreur vix = (1, 0) » peuvent être bloqués. »

    Les journaux appropriés sont disponibles dans : /var/log/vmware/wcp/wcpsvc.log

    Supprimez l'instance de vSphere Agent Manager (EAM) correspondant à la machine virtuelle du plan de contrôle qui rencontre le problème pour forcer le redéploiement du nœud.

  • Les PV restent dans l'état Terminé après la suppression réussie des PVC

    Après la suppression d'un PersistentVolumeClaim (PVC), le PersistentVolume (PV) correspondant peut rester dans un état Terminé dans le superviseur. En outre, vSphere Client peut afficher plusieurs tâches « deleteVolume » ayant échoué.

    1. Authentifiez-vous sur le superviseur :

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    2. Obtenez le nom du volume persistant à l'état Arrêt en cours :

    kubectl get pv

    3. Notez le handle de volume à partir du volume persistant :

    kubectl describe pv <pv-name>

    4. À l'aide du handle de volume de l'étape précédente, supprimez la ressource personnalisée CnsVolumeOperationRequest dans le superviseur :

    kubectl delete cnsvolumeoperationrequest delete-<volume-handle>

    Remarque : avant de supprimer un PV, assurez-vous qu'il n'est pas utilisé par d'autres ressources dans le cluster.

Mise en réseau

  • Le déploiement d'une machine virtuelle NSX Edge échoue sur des réseaux lents.

    Il existe un délai d'expiration combiné de 60 minutes pour le déploiement de NSX Edge OVF et l'enregistrement de la machine virtuelle NSX Edge. Dans les réseaux plus lents ou les environnements avec un stockage plus lent, si le temps écoulé pour le déploiement et l'enregistrement du dispositif Edge dépasse ce délai d'expiration de 60 minutes, l'opération échouera.

    Solution : nettoyez les dispositifs Edge et redémarrez le déploiement.

  • Les dispositifs Edge NSX ne sont pas mis à jour si les paramètres DNS, NTP ou Syslog de vCenter Server sont modifiés après la configuration du cluster.

    Les paramètres DNS, NTP et Syslog sont copiés de vCenter Server vers les machines virtuelles NSX Edge lors de la configuration du cluster. Si l'un de ces paramètres vCenter Server est modifié après la configuration, les dispositifs NSX Edge ne sont pas mis à jour.

    Solution : utilisez les API NSX Manager pour mettre à jour les paramètres DNS, NTP et Syslog de vos dispositifs NSX Edge.

  • La configuration du réseau de gestion NSX Edge fournit uniquement la configuration du sous-réseau et de la passerelle sur une sélection de groupes de ports.

    Le menu déroulant de compatibilité du réseau de gestion NSX Edge affichera les informations de sous-réseau et de passerelle uniquement si les cartes VMKnic ESXi sont configurées sur l'hôte et qu'elles sont sauvegardées par un DVPG sur le VDS sélectionné. Si vous sélectionnez un port de groupes distribué sans carte VMKnic attachée, vous devez fournir un sous-réseau et une passerelle pour la configuration réseau.

    Solution : utilisez l'une des solutions suivantes :

    • Groupe de ports discret : où aucun VMK ne réside actuellement. Vous devez fournir les informations appropriées sur le sous-réseau et la passerelle pour ce groupe de ports.

    • Groupe de ports de gestion partagé : C'est là que réside le VMK de gestion des hôtes ESXi. Les informations sur le sous-réseau et la passerelle seront automatiquement récupérées.

  • Impossible d'utiliser le VLAN 0 lors de la configuration du cluster

    Lorsque vous tentez d'utiliser le VLAN 0 pour les points de terminaison de tunnel de superposition ou la configuration de liaison montante, l'opération échoue avec le message suivant :

    Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network. Please use a VLAN ID between 1-4094

    Solution : activez manuellement la prise en charge de VLAN 0 en appliquant l'un des processus suivants :

    1. SSH dans votre instance de VC déployée (racine/vmware).

    2. Ouvrez /etc/vmware/wcp/nsxdsvc.yaml. Un contenu semblable à celui-ci s'affichera : 

    logging: 
  level: debug
  maxsizemb: 10

    a. pour activer la prise en charge de VLAN0 pour les réseaux de superposition de cluster NSX, ajoutez les lignes suivantes à /etc/vmware/wcp/nsxdsvc.yaml et enregistrez le fichier.

    experimental:
 supportedvlan: 
  hostoverlay: 
    min: 0 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    b. Pour activer la prise en charge de VLAN0 pour les réseaux de superposition NSX Edge, ajoutez les lignes suivantes à /etc/vmware/wcp/nsxdsvc.yaml et enregistrez le fichier.

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 0 
    max: 4094 
  edgeuplink: 
    min: 1 
    max: 4094

    c. Pour activer la prise en charge de VLAN0 pour les réseaux de liaison montante NSX Edge, ajoutez les lignes suivantes à /etc/vmware/wcp/nsxdsvc.yaml et enregistrez le fichier.

    experimental: 
 supportedvlan: 
  hostoverlay: 
    min: 1 
    max: 4094 
  edgeoverlay: 
    min: 1 
    max: 4094 
  edgeuplink: 
    min: 0 
    max: 4094

    3. Redémarrez le service de gestion de la charge de travail avec vmon-cli --restart wcp.

  • vSphere with Tanzu et NSX-T ne peuvent pas être activés sur un cluster où l'image de vSphere Lifecycle Manager est activée.

    vSphere with Tanzu et NSX-T ne sont pas compatibles avec l'image de vSphere Lifecycle Manager. Ils sont uniquement compatibles avec les lignes de base de vSphere Lifecycle Manager. Lorsque l'image de vSphere Lifecycle Manager est activée sur un cluster, vous ne pouvez pas activer vSphere with Tanzu ou NSX-T sur ce cluster.

    Solution : déplacer des hôtes vers un cluster sur lequel l'image de vSphere Lifecycle Manager est désactivée. Vous devez utiliser un cluster avec les lignes de base de vSphere Lifecycle Manager. Une fois les hôtes déplacés, vous pouvez activer NSX-T, puis vSphere with Tanzu sur ce nouveau cluster.

  • Lorsque la mise en réseau de vSphere with Tanzu est configurée avec NSX-T, le paramètre « ExternalTrafficPolicy : local » n'est pas pris en charge

    Pour les services Kubernetes de type LoadBalancer, la configuration « ExternalTrafficPolicy : local » n'est pas prise en charge.

    Solution : aucune.

  • Lorsque la mise en réseau de vSphere with Tanzu est configurée avec NSX-T, le nombre de services de type LoadBalancer qu'un cluster Tanzu Kubernetes peut prendre en charge est limité par la plage NodePort du cluster superviseur

    Chaque VirtualMachineService de type LoadBalancer est convertie en un service Kubernetes de type LoadBalancer et un point de terminaison Kubernetes. Le nombre maximal de services Kubernetes de type LoadBalancer pouvant être créés dans un cluster superviseur est de 2 767. Cela inclut ceux créés sur le cluster superviseur et ceux créés dans les clusters Tanzu Kubernetes.

    Solution : aucune.

  • Le contrôleur NSX Advanced Load Balancer ne prend pas en charge la modification du PNID de l'instance de vCenter Server.

    Une fois que vous avez configuré le cluster superviseur avec NSX Advanced Load Balancer, vous ne pouvez pas modifier le PNID de l'instance de vCenter Server.

    Solution : si vous devez modifier le PNID de l'instance de vCenter Server, supprimez le contrôleur NSX Advanced Load Balancer, modifiez le PNID de l'instance de vCenter Server, puis redéployez et configurez le contrôleur NSX Advanced Load Balancer avec le nouveau PNID de l'instance de vCenter Server.

  • Dans les environnements vSphere Distributed Switch (vDS), il est possible de configurer des clusters Tanzu Kubernetes avec des plages de CIDR réseau qui se chevauchent ou sont en conflit avec celles du cluster superviseur, ce qui peut empêcher les composants de communiquer.

    Dans les environnements vDS, aucune validation de réseau n'est effectuée lors de la conception, lorsque vous configurez les plages de CIDR pour le cluster superviseur ou lorsque vous configurez les plages de CIDR pour les clusters Tanzu Kubernetes. Par conséquent, deux problèmes peuvent survenir :

    1) Vous créez un cluster superviseur avec des plages de CIDR qui sont en conflit avec les plages de CIDR par défaut réservées aux clusters Tanzu Kubernetes.

    2) Vous créez un cluster Tanzu Kubernetes avec une plage de CIDR personnalisée qui chevauche la plage de CIDR utilisée pour les clusters superviseurs.

    Solution : Pour les environnements vDS, lorsque vous configurez un cluster superviseur, n'utilisez pas l'une des plages de CIDR par défaut utilisées pour les clusters Tanzu Kubernetes, notamment la plage 192.168.0.0/16, qui est réservée aux services, et la plage 10.96.0.0/12, qui est réservée aux espaces. Reportez-vous également à la section « Paramètres de configuration des clusters Tanzu Kubernetes » dans la documentation de vSphere with Tanzu.

    Pour les environnements vDS, lorsque vous créez un cluster Tanzu Kubernetes, n'utilisez pas la même plage de CIDR que celle utilisée pour le cluster superviseur.

  • Échec de la création du réseau virtuel du cluster invité lors de l'attachement de plus de 18 étiquettes personnalisées

    Si l'utilisateur souhaite créer un cluster invité et des machines virtuelles sous un espace de noms, il peut ajouter un maximum de 18 étiquettes personnalisées pour l'espace de noms. Sinon, le réseau virtuel du cluster invité sous l'espace de noms ne peut pas être créé.

    Supprimez les étiquettes de l'espace de noms jusqu'à ce que leur nombre total soit inférieur ou égal à 18. Le mécanisme de nouvelle tentative NCP réessaiera de créer l'espace de noms, mais en fonction de l'intervalle, cela peut prendre jusqu'à 6 heures.

  • Prise en charge de la zone de transport créée via l'API de stratégie pour WCP

    Si une zone de transport NSX a été créée via l'API de stratégie, l'activation du superviseur peut avoir échoué. La création d'une zone de transport NSX via l'API de stratégie est désormais prise en charge, tout en maintenant la compatibilité descendante avec la zone de transport NSX créée avec l'API MP.

    Ce problème est résolu dans la dernière version.

  • Vous ne pouvez pas utiliser NSX Advanced Load Balancer avec un système vCenter Server en utilisant une topologie Embedded Linked Mode.

    Lorsque vous configurez le contrôleur NSX Advanced Load Balancer, vous pouvez le configurer sur plusieurs clouds. Toutefois, vous n'avez pas la possibilité de sélectionner plusieurs clouds lors de l'activation de vSphere with Tanzu, car seule l'option Cloud par défautest prise en charge. Par conséquent, vous ne pouvez pas utiliser NSX Advanced Load Balancer avec une version de vCenter Server utilisant une topologie Embedded Linked Mode.

    Configurez l'équilibrage de charge NSX pour chaque instance de vCenter Server.

Stockage

  • <span style="color:#FF0000">NEW:</span> les tentatives d'exécution de l'opération Supprimer un disque sur une banque de données vSAN Direct échouent avec l'erreur VimFault - Impossible de terminer l'opération

    Vous pouvez observer cette erreur lorsque l'un des scénarios suivants se produit:

    • Dans le cadre de l'opération Supprimer un disque, tous les volumes persistants placés sur la banque de données vSAN Direct sont déplacés vers une autre banque de données vSAN Direct sur le même hôte ESXi. Le déplacement peut échouer si aucun espace n'est disponible sur les banques de données vSAN Direct cibles. Pour éviter ce problème, assurez-vous que les banques de données vSAN Direct cibles disposent d'un espace de stockage suffisant pour exécuter des applications.

    • L'opération Supprimer un disque peut également échouer lorsque les banques de données vSAN Direct sur l'hôte ESXi disposent d'un stockage suffisant. Cela peut se produire lorsque l'opération de déplacement du volume persistant sous-jacent générée par l'opération parente Supprimer un disque prend plus de 30 minutes en raison de la taille du volume. Dans ce cas, vous pouvez observer que la reconfiguration de l'espace vSphere sous-jacent reste en cours dans la vue Tâches.

      L'état En cours indique que même si l'opération Supprimer un disque expire et échoue, le déplacement du volume persistant sous-jacent effectué par la reconfiguration de l'espace vSphere n'est pas interrompu.

    Solution :

    une fois la tâche de reconfiguration de l'espace vSphere effectuée, exécutez à nouveau l'opération Supprimer un disque. L'opération Supprimer un disque s'exécute correctement.

  • L'extension d'un PVC de cluster superviseur en mode hors ligne ou en ligne n'entraîne pas l'extension d'un PVC de cluster Tanzu Kubernetes correspondant

    Un espace qui utilise le PVC du cluster Tanzu Kubernetes ne peut pas utiliser la capacité étendue du PVC du cluster superviseur, car le système de fichiers n'a pas été redimensionné.

    Solution : Redimensionnez le PVC du cluster Tanzu Kubernetes à une taille égale ou supérieure à celle du PVC du cluster superviseur.

  • Non concordance de taille du PVC TKG provisionné statiquement par rapport au volume sous-jacent

    Le provisionnement statique dans Kubernetes ne vérifie pas si les tailles de volume PV et de sauvegarde sont identiques. Si vous créez statiquement un PVC dans un cluster Tanzu Kubernetes et que la taille du PVC est inférieure à la taille du PVC de cluster superviseur sous-jacent correspondant, vous pouvez être en mesure d'utiliser plus d'espace que celui que vous demandez dans le PV. Si la taille du PVC que vous créez statiquement dans le cluster Tanzu Kubernetes est supérieure à la taille du PVC du cluster superviseur sous-jacent, vous risquez d'obtenir l'erreur No space left on device même avant d'avoir épuisé la taille demandée dans le PV du cluster Tanzu Kubernetes.

    Solution :

    1. Dans le PV du cluster Tanzu Kubernetes, modifiez persistentVolumeReclaimPolicy en Retain.

    2. Notez le volumeHandle du PV du cluster Tanzu Kubernetes, puis supprimez le PVC et le PV dans le cluster Tanzu Kubernetes.

    3. Recréez statiquement le PVC et le PV du cluster Tanzu Kubernetes à l'aide du volumeHandle et définissez le stockage sur la même taille que celle du PVC du cluster superviseur correspondant.

  • Les tentatives de création d'un PVC à partir d'un espace de noms de superviseur ou d'un cluster TKG échouent si le provisionneur csi.vsphere.vmware.com externe perd son bail pour le choix du leader

    Lorsque vous tentez de créer un PVC à partir d'un espace de noms de superviseur ou d'un cluster TKG à l'aide de la commande kubectl, vos tentatives peuvent échouer. Le PVC reste dans l'état en attente. Si vous décrivez le PVC, le champ Événements affiche les informations suivantes dans une disposition en tableau :

    • Type : Normal

    • Motif : ExternalProvisioning

    • Âge : 56s (x121 over 30m)

    • De : persistentvolume-controller

    • Message : waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator

    Solution :

    1. vérifiez que tous les conteneurs de l'espace vsphere-csi-controller à l'intérieur de l'espace de noms vmware-system-csi sont en cours d'exécution.

      kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi

    2. Vérifiez les journaux du provisionneur externe à l'aide de la commande suivante.

      kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c csi-provisioner

      L'entrée suivante indique que le conteneur de l'en-tête du provisionneur externe a perdu son choix de leader :

      I0817 14:02:59.582663 1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading

    3. Supprimez cette instance de vsphere-csi-controller.

      kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi

    Kubernetes créera une nouvelle instance du contrôleur CSI et tous les sidecars seront réinitialisés.

  • Toutes les opérations PVC, telles que créer, attacher, détacher ou supprimer un volume, échouent, car CSI ne peut pas se connecter au système vCenter Server

    En plus des échecs d'opération, les informations de santé du volume et le CR du pool de stockage ne peuvent pas être mis à jour dans le cluster superviseur. Les journaux CSI et Syncer affichent des erreurs sur l'impossibilité de se connecter au système vCenter Server.

    CSI se connecte au système vCenter Server en tant qu'utilisateur de solution spécifique. Le mot de passe de cet utilisateur SSO est alterné par wcpsvc toutes les 24 heures et le nouveau mot de passe est transféré dans un secret que le pilote CSI lit pour se connecter au système vCenter Server. Si le nouveau mot de passe ne peut pas être transféré dans un secret, le mot de passe périmé est conservé dans le cluster superviseur et les opérations du pilote CSI échouent.

    Ce problème affecte la plate-forme de persistance des données vSAN et toutes les opérations de volume CSI.

    Solution :

    en général, le service WCP fournit le mot de passe mis à jour à CSI qui s'exécute dans le cluster Kubernetes. Parfois, la livraison du mot de passe échoue en raison d'un problème, par exemple, un problème de connectivité ou une erreur dans une partie antérieure du processus de synchronisation. Le CSI continue d'utiliser l'ancien mot de passe et finit par verrouiller le compte après un trop grand nombre d'échecs d'authentification.

    Assurez-vous que le cluster WCP est dans un état sain et en cours d'exécution. Aucune erreur ne doit être signalée pour ce cluster sur la page Gestion de la charge de travail. Une fois que les problèmes entraînant l'échec de la synchronisation ont été résolus, forcez l'actualisation du mot de passe pour déverrouiller le compte verrouillé.

    Pour forcer la réinitialisation du mot de passe :

    1. Arrêtez wcpsvc :

      vmon-cli -k wcp

    2. Modifiez l'heure de la rotation du dernier mot de passe sur une valeur inférieure, par exemple 1, en modifiant la troisième ligne dans /etc/vmware/wcp/.storageUser sur 1.

    3. Démarrez wcpsvc :

      vmon-cli -i wcp

    wcpsvc réinitialise le mot de passe, ce qui déverrouille le compte et fournit le nouveau mot de passe au cluster.

VMware Tanzu Kubernetes Grid Service for vSphere

  • Un cluster Tanzu Kubernetes se bloque à l'état « Mise à jour » après la mise à niveau du cluster superviseur

    Lorsqu'un cluster superviseur est mis à niveau, il peut déclencher une mise à jour continue de tous les clusters Tanzu Kubernetes afin de propager les nouveaux paramètres de configuration. Au cours de ce processus, un cluster TKC précédemment en cours d'exécution peut se bloquer lors de la phase « mise à jour ». Un cluster Tanzu Kubernetes « en cours d'exécution » indique uniquement la disponibilité du plan de contrôle et il est possible que le plan de contrôle et les nœuds Worker requis n'aient pas été créés. Un tel cluster Tanzu Kubernetes peut faire échouer les contrôles de santé qui sont exécutés lors de la mise à jour continue initiée à la fin de la mise à niveau du cluster superviseur. Cela entraîne le blocage du cluster Tanzu Kubernetes dans la phase « mise à jour » et peut être confirmé en examinant les événements sur les ressources KubeadmControlPlane associées au cluster Tanzu Kubernetes. Les événements émis par la ressource seront semblables à celui ci-dessous :

    Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked

    Solution : aucune.

  • Le cluster Tanzu Kubernetes continue d'accéder à la stratégie de stockage supprimée

    Lorsqu'un administrateur VI supprime une classe de stockage dans l'espace de noms vCenter Server, l'accès à cette classe de stockage n'est pas supprimé pour les clusters Tanzu Kubernetes qui l'utilisent déjà.

    Solution :

    1. en tant qu'administrateur VI, après la suppression d'une classe de stockage de l'espace de noms vCenter Server, créez une nouvelle stratégie de stockage avec le même nom.

    2. Ajoutez à nouveau la stratégie de stockage existante ou celle que vous venez de recréer à l'espace de noms de superviseur. Les instances de TanzuKubernetesCluster utilisant cette classe de stockage doivent désormais être entièrement opérationnelles.

    3. Pour chaque ressource de TanzuKubernetesCluster utilisant la classe de stockage que vous souhaitez supprimer, créez une nouvelle instance de TanzuKubernetesCluster à l'aide d'une classe de stockage différente et utilisez Velero pour migrer les charges de travail dans le nouveau cluster.

    4. Lorsque plus aucun TanzuKubernetesCluster ou PersistentVolume n'utilise la classe de stockage, celle-ci peut être supprimée en toute sécurité.

  • Le certificat SSL du registre du conteneur intégré n'est pas copié sur les nœuds du cluster Tanzu Kubernetes

    Lorsque le registre du conteneur intégré est activé pour un cluster superviseur, le certificat SSL Harbor n'est pas inclus dans les nœuds du cluster Tanzu Kubernetes créés sur ce cluster superviseur, et vous ne pouvez pas vous connecter au registre à partir de ces nœuds.

    Solution : copiez et collez le certificat SSL depuis le plan de contrôle du cluster superviseur sur les nœuds worker du cluster Tanzu Kubernetes.

  • Les images de machine virtuelle ne sont pas disponibles dans la bibliothèque de contenu.

    Lorsque plusieurs instances de vCenter Server sont configurées en mode Embedded Linked Mode, l'interface utilisateur permet à l'utilisateur de sélectionner une bibliothèque de contenu créée sur une instance différente de vCenter Server. Si vous sélectionnez une bibliothèque de ce type, les utilisateurs DevOps ne disposeront plus des images de machine virtuelle pour provisionner le cluster Tanzu Kubernetes. Dans ce cas, « kubectl Get virtualmachineimages » ne renvoie aucun résultat.

    Solution : lorsque vous associez une bibliothèque de contenu au cluster superviseur pour les images de machine virtuelle du cluster Tanzu Kubernetes, choisissez une bibliothèque créée dans la même instance de vCenter Server dans laquelle réside le cluster superviseur. Vous pouvez également créer une bibliothèque de contenu locale qui prend également en charge le provisionnement dans un emplacement isolé des clusters Tanzu Kubernetes.

  • Vous ne pouvez pas provisionner de nouveaux clusters Tanzu Kubernetes ou monter en charge des clusters existants, car l'abonné de la bibliothèque de contenu ne peut pas se synchroniser avec l'éditeur.

    Lorsque vous configurez une bibliothèque de contenu avec abonnement pour les OVA de cluster Tanzu Kubernetes, un certificat SSL est généré et vous êtes invité à l'approuver manuellement en confirmant son empreinte numérique. Si le certificat SSL est modifié après la configuration initiale de la bibliothèque, le nouveau certificat doit être de nouveau approuvé en mettant à jour l'empreinte numérique.

    Modifiez les paramètres de la bibliothèque de contenu avec abonnement. Cela lancera une sonde de l'URL d'abonnement, même si aucune modification n'est demandée sur la bibliothèque. La sonde détecte que le certificat SSL n'est pas approuvé et vous invite à l'approuver.

  • Tanzu Kubernetes version 1.16.8 est incompatible avec vCenter Server 7.0 Update 1.

    Tanzu Kubernetes version 1.16.8 est incompatible avec vCenter Server 7.0 Update 1. Vous devez mettre à jour les clusters Tanzu Kubernetes vers une version ultérieure avant d'effectuer une mise à jour des espaces de noms vSphere vers la version U1.

    Avant d'effectuer une mise à jour des espaces de noms vSphere vers vCenter Server 7.0 Update 1, mettez à jour chaque cluster Tanzu Kubernetes exécutant la version 1.16.8 vers une version ultérieure. Pour plus d'informations, reportez-vous à la Liste des versions de Tanzu Kubernetes dans la documentation.

  • Après la mise à niveau du plan de contrôle de la charge de travail vers vCenter Server 7.0 Update 1, les nouvelles tailles de classe de machine virtuelle ne sont pas disponibles.

    Description : après la mise à niveau vers vSphere 7.0.1 et l'exécution d'une mise à jour des espaces de noms vSphere du cluster superviseur, l'exécution de la commande « kubectl get virtualmachineclasses » pour les clusters Tanzu Kubernetes ne répertorie pas les nouvelles tailles de classe de machine virtuelle (2x-large, 4x-large, 8x-large).

    Solution : aucune. Les nouvelles tailles de classe de machine virtuelle peuvent uniquement être utilisées avec une nouvelle installation du plan de contrôle de la charge de travail.

  • Expiration du délai lorsque Tanzu Kubernetes version 1.17.11 vmware.1-tkg.1 tente de se connecter au serveur DNS du cluster avec le CNI Calico.

    Tanzu Kubernetes version 1.17.11+vmware.1-tkg.1 présente un problème de noyau Photon OS qui empêche l'image de fonctionner comme prévu avec le CNI Calico.

    Solution : pour Tanzu Kubernetes version 1.17.11, l'image identifiée sous la forme « v1.17.11+vmware.1-tkg.2.ad3d374.516 » résout le problème avec Calico. Pour exécuter Kubernetes 1.17.11, utilisez cette version au lieu de la version « v1.17.11+vmware.1-tkg.1.15f1e18.489 ». Vous pouvez également utiliser une autre version de Tanzu Kubernetes, telle que la version 1.18.5, 1.17.8 ou 1.16.14.

  • Lorsque la mise en réseau de vSphere with Tanzu est configurée avec NSX-T Data Center, la mise à jour d'un service « ExternalTrafficPolicy: Local » vers « ExternalTrafficPolicy: Cluster » rendra l'adresse IP de l'équilibrage de charge de ce service inaccessible aux maîtres SV.

    Lorsqu'un service Kubernetes de type LoadBalancer est initialement créé dans des clusters de charge de travail avec ExternalTrafficPolicy: Local, puis mis à jour ultérieurement vers ExternalTrafficPolicy: Cluster, l'accès à l'adresse IP loadBalancer de ce service sur les machines virtuelles du cluster superviseur est abandonné.

    Solution : Supprimez le service et recréez-le avec ExternalTrafficPolicy: Cluster.

  • Utilisation élevée du CPU sur les nœuds du plan de contrôle du cluster Tanzu Kubernetes

    Un problème connu existe dans le projet Kubernetes en amont au cours duquel kube-controller-manager entre parfois en boucle, ce qui entraîne une utilisation élevée du CPU et peut affecter la fonctionnalité des clusters Tanzu Kubernetes. Vous remarquerez peut-être que le processus kube-controller-manager consomme une quantité de CPU supérieure à la quantité prévue et produit des journaux répétés indiquant failed for updating Node.Spec.PodCIDRs.

    Solution : supprimez l'espace kube-controller-manager qui se trouve dans le nœud du plan de contrôle avec ce problème. L'espace sera recréé et le problème ne doit plus se reproduire.

  • Vous ne pouvez pas mettre à jour les clusters Tanzu Kubernetes créés avec K8s 1.16 vers la version 1.19

    Le fichier de configuration de Kubelet est généré lors de l'exécution de kubeadm init, puis répliqué lors des mises à niveau du cluster. Dans la version 1.16, kubeadm init génère un fichier config qui définit resolvConf sur /etc/resolv.conf qui est ensuite remplacé par un indicateur de ligne de commande --resolv-conf pointant vers /run/systemd/resolve/resolv.conf. Dans les versions 1.17 et 1.18, kubeadm continue de configurer Kubelet avec l'indicateur --resolv-conf approprié. Dans la version 1.19, kubeadm ne configure plus l'indicateur de ligne de commande et utilise plutôt le fichier de configuration Kubelet. En raison du processus de réplication lors des mises à niveau des clusters, un cluster 1.19 mis à niveau à partir de la version 1.16 inclura un fichier config dans lequel resolvConf vers /etc/resolv.conf au lieu de /run/systemd/resolve/resolv.conf.

    Solution : avant de mettre à niveau un cluster Tanzu Kubernetes vers la version 1.19, reconfigurez le fichier de configuration Kubelet pour qu'il pointe vers le fichier resolv.conf correct. Dupliquez manuellement le ConfigMap kubelet-config-1.18 vers kubelet-config-1.19 dans l'espace de noms kube-system, puis modifiez les données du nouveau ConfigMap's pour qu'elles pointent vers resolvConf sur /run/systemd/resolve/resolv.conf.

  • Lorsque la mise en réseau du cluster superviseur est configurée avec NSX-T, après la mise à jour d'un service à partir de « ExternalTrafficPolicy: Local » vers « ExternalTrafficPolicy: Cluster », les demandes envoyées aux nœuds du plan de contrôle du cluster superviseur à l'adresse IP de l'équilibrage de charge de ce service échouent

    Lorsque vous créez un service sur un cluster Tanzu Kubernetes avec ExternalTrafficPolicy: Local et que vous mettez à jour ultérieurement le service vers ExternalTrafficPolicy: Cluster, kube-proxy crée une règle de table IP de manière incorrecte sur les nœuds du plan de contrôle du cluster superviseur pour bloquer le trafic destiné à l'adresse IP de l'équilibrage de charge du service. Par exemple, si ce service dispose de l'adresse IP 192.182.40.4 de l'équilibrage de charge, la règle de table IP suivante est créée sur l'un des nœuds du plan de contrôle :

    -A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

    Par conséquent, l'accès à cette adresse IP est abandonné.

    Solution : supprimez le service et recréez-le avec ExternalTrafficPolicy: Cluster.

  • Après avoir activé les paramètres de proxy HTTP et/ou d'approbation dans la spécification TkgServiceConfiguration, tous les clusters préexistants sans paramètres de proxy/d'approbation hériteront des paramètres de proxy/d'approbation globaux lors de leur mise à jour.

    Vous pouvez modifier la spécification TkgServiceConfiguration pour configurer le service TKG, notamment en spécifiant le CNI par défaut, le proxy HTTP et les certificats d'approbation. Toutes les modifications de configuration apportées à la spécification TkgServiceConfiguration s'appliquent globalement aux clusters Tanzu Kubernetes provisionnés ou mis à jour par ce service. Vous ne pouvez pas ignorer la configuration globale à l'aide de paramètres définis pour chaque cluster.

    Par exemple, si vous modifiez la spécification TkgServiceConfiguration et activez un proxy HTTP, tous les nouveaux clusters provisionnés par ce cluster héritent de ces paramètres de proxy. Tous les clusters préexistants sans serveur proxy héritent également de la configuration du proxy global lorsque le cluster est modifié ou mis à jour. Dans le cas d'un proxy HTTP/S qui prend en charge la configuration par cluster, vous pouvez mettre à jour la spécification de cluster avec un serveur proxy différent, mais vous ne pouvez pas supprimer le paramètre de proxy global. Si le proxy HTTP est globalement défini, vous devez l'utiliser ou le remplacer par un serveur proxy différent.

    Solution : remarquez que la spécification TkgServiceConfiguration s'applique globalement. Si vous ne souhaitez pas que tous les clusters utilisent un proxy HTTP, ne l'activez pas au niveau global. Activez-le au niveau du cluster.

  • Dans les très grands déploiements de cluster superviseur avec de nombreux clusters et VM Tanzu Kubernetes, les espaces vmop-controller-manager peuvent échouer en raison d'une erreur outOfMemory, ce qui empêche de gérer le cycle de vie des clusters Tanzu Kubernetes

    Dans le cluster superviseur, l'espace vmop-controller-manager est responsable de la gestion du cycle de vie des VM qui constituent les clusters Tanzu Kubernetes. Lorsque le cluster contient un très grand nombre de VM (plus de 850 VM par cluster superviseur), l'espace vmop-controller-manager peut entrer dans une boucle OutOfMemory CrashLoopBackoff. Lorsque cela se produit, la gestion du cycle de vie des clusters Tanzu Kubernetes est interrompue jusqu'à ce que l'espace vmop-controller-manager fonctionne à nouveau.

    Réduisez le nombre total de nœuds worker de cluster Tanzu Kubernetes gérés dans un cluster superviseur en supprimant des clusters ou en réduisant leur taille.

  • La mise à niveau d'une version antérieure à la version 6.5 de vSphere vers vSphere 7 with Tanzu peut renvoyer une erreur indiquant que le type PhotonOS n'est pas pris en charge.

    Après la mise à niveau réussie d'un environnement vSphere 6 vers vSphere 7 with Tanzu, la tentative de déploiement d'un cluster Tanzu Kubernetes entraîne un message d'erreur qui indique que PhotonOS n'est « pas pris en charge ». Spécifiquement :

    impossible de créer ou de mettre à jour la VirtualMachine : le Webhook d'admission « default.validating.virtualmachine.vmoperator.vmware.com » a refusé la demande : GuestOS non pris en charge pour osType vmwarePhoton64Guest sur l'image v1.19.7---vmware.1-tkg.1.fc82c41'

    Si vous avez mis à niveau vers vSphere 7 with Tanzu à partir d'une version de vSphere antérieure à vSphere 6.5 (telle que vSphere 6), vous devez vous assurer que le niveau de compatibilité par défaut des VM est défini sur au moins « ESXi 6.5 et versions ultérieures » pour que PhotonOS s'affiche comme un système d'exploitation invité pris en charge. Pour ce faire, sélectionnez le cluster vSphere sur lequel la gestion de la charge de travail est activée, cliquez avec le bouton droit et choisissez Modifier la compatibilité VM par défaut. Sélectionnez « ESXi 6.5 et versions ultérieures ».

  • Après le provisionnement d'un cluster Tanzu Kubernetes à l'aide d'une machine virtuelle de petite taille, puis le déploiement d'une charge de travail sur ce cluster, le nœud worker passe à l'état NotReady et une boucle continue de tentatives de réapprovisionnement du nœud.

    Description : sur un petit ou très petit nœud worker pour un cluster, le processus /bin/opm peut consommer une partie excessive de la mémoire de la machine virtuelle, ce qui entraîne une erreur de mémoire insuffisante pour le nœud worker.

    Solution : évitez d'utiliser la classe de machine virtuelle petite ou très petite pour les nœuds worker, même pour le développement éphémère ou les clusters de test. Il est recommandé d'avoir une classe de machine virtuelle minimale pour un nœud worker dans n'importe quel environnement. Pour plus d'informations, reportez-vous aux Classes de machine virtuelle par défaut dans la documentation.

  • La synchronisation des versions de Tanzu Kubernetes à partir d'une bibliothèque de contenu abonnée échoue avec le message d'erreur de demande HTTP suivant : « impossible d'authentifier le certificat SSL pour l'hôte wp-content.vmware.com. »

    Description : lorsque vous configurez une bibliothèque de contenu abonnée pour les fichiers OVA du cluster Tanzu Kubernetes, un certificat SSL est généré pour wp-content.vmware.com. Vous êtes invité à approuver manuellement le certificat en confirmant l'empreinte numérique du certificat. Si le certificat SSL est modifié après la configuration initiale de la bibliothèque, le nouveau certificat doit être de nouveau approuvé en mettant à jour l'empreinte numérique. Le certificat SSL actuel de la bibliothèque de contenu expire à la fin du mois de juin 2021. Les clients qui se sont abonnés à wp-content.vmware.com verront leur synchronisation de bibliothèque de contenu échouer et devront mettre à jour l'empreinte numérique en suivant les étapes de la solution. Pour plus d'informations, reportez-vous à l'article de la base de connaissances VMware https://kb.vmware.com/s/article/85268.

    Solution : Ouvrez une session sur vCenter Server au moyen de vSphere Client. Sélectionnez la bibliothèque de contenu abonnée et cliquez sur Modifier les paramètres. Cette action lancera une sonde de l'URL d'abonnement, même si aucune modification n'est demandée sur la bibliothèque. La sonde détecte que le certificat SSL n'est pas approuvé et vous invite à l'approuver. Dans le menu déroulant Actions qui s'affiche, sélectionnez Continuer et l'empreinte digitale est mise à jour. Vous pouvez maintenant procéder à la synchronisation du contenu de la bibliothèque.

  • TKGS ne prend pas en charge la modification simultanée de la classe de VM et de la montée en puissance du nœud.

    Les clients peuvent rencontrer des échecs après l'application d'une mise à jour au cluster impliquant à la fois une modification VMClass et une évolutivité verticale des nœuds.

    Modifiez la configuration TKC pour modifier uniquement l'un des deux champs et réappliquez la modification.

  • Symptôme : une mise à jour continue inattendue du cluster s'est produite après la mise à jour d'une étiquette ou d'un rejet dans la spécification du cluster.

    Description : lors de l'utilisation de l'API TKGS v1alpha2, la modification du paramètre spec.topology.nodePools[*].labels ou spec.topology.nodePools[*].taints d'un pool de nœuds déclenche une mise à jour continue de ce pool de nœuds.

    Solution : aucune.

  • Symptôme : après une mise à jour du cluster, les rejets et étiquettes ajoutés manuellement à un pool de nœuds ne sont plus présents.

    Description : à l'aide de l'API TKGS v1alpha2, lors de la mise à jour d'un cluster, le système ne conserve pas les paramètres spec.topology.nodePools[*].taints et spec.topology.nodePools[*].labels ajoutés manuellement et présents avant la mise à jour.

    Solution : une fois la mise à jour terminée, rajoutez manuellement les champs d'étiquettes et de rejets.

  • Symptôme : le cluster Tanzu Kubernetes est bloqué dans une phase de création, car l'une des machines virtuelles du plan de contrôle n'a pas obtenu d'adresse IP.

    Description : le cluster Tanzu Kubernetes est bloqué dans une phase de création, car l'une des machines virtuelles du plan de contrôle n'a pas obtenu d'adresse IP.

    Solution : utilisez Tanzu Kubernetes 1.20.7 ou version ultérieure pour éviter ce problème.

  • Symptôme : lors de la création d'un cluster Tanzu Kubernetes, le processus est bloqué dans un état de mise à jour avec la raison « WaitingForNetworkAddress ».

    Description : les machines virtuelles du plan de contrôle et les nœuds worker sont sous tension, mais aucune adresse IP ne leur est attribuée. Cela peut être dû à un manque de mémoire de vmware-tools et à l'absence de redémarrage.

    Solution : ce problème spécifique est résolu dans Tanzu Kubernetes 1.20.7 et versions ultérieures. Vous pouvez également résoudre le problème en augmentant la mémoire de la machine virtuelle. La classe de machine virtuelle best-effort-xsmall fournit uniquement 2 Go de mémoire. Utilisez une classe de machine virtuelle disposant de davantage de mémoire pour déployer des clusters Tanzu Kubernetes.

  • Symptôme : les espaces de noms vSphere en libre-service sont bloqués dans l'état « Suppression en cours ».

    Description : après la suppression d'un espace de noms vSphere, le processus est bloqué dans un état « Suppression en cours » pendant plusieurs heures sans progression.

    Solution : utilisez kubectl pour rechercher les objets Kubernetes restants qui n'ont pas encore été supprimés de l'espace de noms. S'il reste des objets liés à kubeadm-control-plane, redémarrez les espaces capi-kubeadm-control-plane-controller-manager. Cette action doit mettre à nouveau en file d'attente les objets à supprimer.

    REMARQUE : il s'agit d'une opération avancée. Contactez le support VMware avant d'effectuer cette opération.

  • L'API TKC v1alpha2 ne bloque pas la création de TKC avec une instance de TKr incompatible

    À partir de la version 7.0.3 MP2, les instances de TKr antérieures à la version 1.18.x sont incompatibles, mais l'API TKC permet toujours la création d'instances de TKC avec une version antérieure à la version v1.18.x et ne bloque pas la création d'un objet TKC lorsqu'il est créé avec une instance de TKr incompatible. Ces instances de TKC ne seront jamais créés.

    Supprimez les instances de TKC qui ne sont pas en cours d'exécution et qui ont été créées avec des instances de TKr incompatibles, puis recréez-les avec une version compatible.

Plate-forme de persistance des données vSAN

  • Un plug-in d'interface utilisateur vDPP n'est pas déployé dans vSphere Client et un message d'erreur indique que le téléchargement du plug-in a été tenté à partir d'un cluster superviseur qui n'existe plus

    Le problème peut se produire lorsque vous déployez un plug-in d'interface utilisateur vDPP sur un cluster, puis que vous supprimez ce cluster. Cependant, les entrées périmées liées à ce plug-in d'interface utilisateur vDPP restent dans le gestionnaire d'extensions vCenter. Si vous créez ultérieurement un cluster, vos tentatives d'installation de la même version du plug-in d'interface utilisateur vDPP sur ce cluster échouent, car vSphere Client utilise les entrées périmées pour télécharger le plug-in à partir de l'ancien cluster inexistant.

    Solution :

    1. accédez au gestionnaire d'extensions vCenter à l'aide de https://vc-ip/mob and et localisez l'extension du plug-in.

    2. Supprimez toutes les entrées ClientInfo et ServerInfo qui contiennent le nom de l'ancien cluster.

    3. Dans le tableau ClientInfo, sélectionnez l'instance de ClientInfo ayant le numéro de version le plus élevé et remplacez son type vsphere-client-remote-backup par vsphere-client-remote.

  • Un espace vSphere dans un cluster superviseur reste à l'état d'attente sans l'annotation vm-uuid

    Parfois, un espace peut rester à l'état d'attente pendant un long moment. Cela se produit généralement lorsque vous utilisez une plate-forme de persistance des données vSAN (vDPP, vSAN Data Persistence platform) et peut être dû à une erreur interne ou à des actions de l'utilisateur.

    Lorsque vous utilisez la commande kubectl pour interroger l'instance de l'espace, l'annotation vmware-system-vm-uuid/vmware-system-vm-moid est introuvable dans les annotations de métadonnées.

    Solution : utilisez la commande kubectl delete pod pending_pod_name pour supprimer l'espace. Si l'espace fait partie d'un ensemble avec état, il est automatiquement recréé.

  • Une instance d'un service vDPP ne parvient pas à se déployer lorsque les PVC locaux de l'hôte de ses deux espaces de réplica sont liés au même nœud de cluster

    Parfois, une instance d'un service de plate-forme de persistance des données vSAN, tel que MinIO ou Cloudian, peut entrer dans un état lorsque ses deux espaces de réplica disposent de leurs PVC locaux hôtes alloués sur le même nœud de cluster. Normalement, deux réplicas de la même instance ne peuvent disposer d'un stockage local d'hôte sur le même nœud de cluster. Si cela se produit, l'un des espaces de réplica peut rester dans un état d'attente pendant une durée indéfinie, ce qui entraîne des échecs de déploiement de l'instance.

    Les symptômes que vous observez pendant les pannes incluent tous les éléments suivants :

    • La santé de l'instance est jaune.

    • Au moins un espace de l'instance reste dans un état en attente pendant plus de 10 minutes.

    • L'espace en attente et l'un des espaces de réplica en cours d'exécution de la même instance ont leur PVC local hôte alloué sur le même nœud du cluster.

    Les scénarios d'échec pouvant entraîner ce problème sont les suivants :

    • Certains nœuds du cluster ne disposent pas de ressources de stockage suffisantes pour l'instance.

    • Le nombre de réplicas est supérieur au nombre de nœuds dans le cluster. Cela peut être dû au fait qu'un ou plusieurs nœuds sont temporairement indisponibles.

    Solution :

    1. Assurez-vous que votre cluster dispose de suffisamment de ressources de stockage et que le nombre de nœuds de cluster est supérieur au nombre de réplicas d'instance.

    2. Supprimez l'espace en attente et tous ses PVC locaux d'hôte.

    L'opérateur de service doit recréer les données de volume sur le nouveau nœud sur lequel l'espace est planifié. Cela peut prendre un certain temps, en fonction de la taille du volume et de la quantité de données valides sur celui-ci.

  • Après qu'un nœud ESXi a quitté la maintenance en mode Assurer l'accessibilité, le rejet appliqué au nœud pendant la maintenance peut toujours persister sur le nœud

    Ce problème peut survenir lorsque vous utilisez la plate-forme de persistance des données vSAN (vDPP, vSAN Data Persistence Platform) pour créer des instances de services de partenaires. Après que le nœud ESXi a quitté la maintenance en mode Assurer l'accessibilité, vous pouvez toujours trouver le rejet persistant node.vmware.com/drain=planned-downtime:NoSchedule sur le nœud.

    En général, le problème se produit lors de ces actions :

    1. Un service de partenaires est activé sur le cluster superviseur et les instances du service sont créées.

    2. Un nœud ESXi est placé en maintenance en mode Assurer l'accessibilité.

    3. Le nœud passe sans problème en mode de maintenance, en mode Assurer l'accessibilité.

    4. Le rejet node.vmware.com/drain=planned-downtime:NoSchedule est appliqué sur le nœud.

    5. Le nœud quitte le mode de maintenance.

    Une fois que le nœud a quitté le mode de maintenance, utilisez la commande suivante pour vous assurer qu'il ne reste aucun rejet sur le nœud :

    kubectl describe node | grep Taints

    Solution :

    si le rejet node.vmware.com/drain=planned-downtime:NoSchedule est présent sur l'hôte, supprimez-le manuellement :

    kubectl taint nodes nodeNamekey=value:Effect-

    Remarque : n'oubliez pas d'inclure un trait d'union à la fin de la commande.

    Suivez cet exemple :

    kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule-

  • Après une récupération APD, les espaces de service persistants qui s'exécutent sur la plate-forme de persistance des données vSAN peuvent rester dans un état d'attente avec des erreurs AttachVolume

    Après le protocole ADP et la récupération des hôtes ESXi, un espace de l'instance de service vDPP peut rester dans l'état d'attente. Si vous exécutez la commande kubectl -n instance_namespace describe pod name_of_pod_in_pending, vous pouvez voir les erreurs AttachVolume.

    Si l'espace reste dans l'état d'attente plus de 15 minutes, il est peu probable qu'il sorte de cet état.

    Solution : supprimez l'espace en attente à l'aide de la commande suivante : kubectl -n instance_namespace delete pod name_of_pod_in_pending. L'espace est recréé et doit passer à l'état d'exécution.

Service de VM

  • <span style="color:#FF0000">NEW:</span> Les tentatives de déploiement d'un espace vSphere et d'une machine virtuelle de service de VM portant le même nom provoquent des erreurs et un comportement imprévisible

    Vous pouvez observer des échecs et des erreurs, ou d'autres comportements problématiques. Vous pouvez rencontrer ces problèmes lorsqu'un espace vSphere s'exécute dans un espace de noms et que vous tentez de déployer une machine virtuelle de service de VM avec le même nom dans le même espace de noms, ou inversement.

    Solution : n'utilisez pas les mêmes noms pour les espaces et les machines virtuelles vSphere dans le même espace de noms.

  • Un ensemble limité d'images de VM est disponible pour l'utilisation avec le service de VM

    Lors d'une tentative d'utilisation d'une image de VM qui n'est pas compatible avec le service de VM, le message suivant s'affiche lors de la création de la VM

    Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image

    Solution : utilisez uniquement les images de VM provenant de VMware Marketplace qui ont été validées pour fonctionner avec le service de VM.

  • Les images de machine virtuelle dont les noms ne sont pas conformes à DNS ne peuvent pas être utilisées

    Si le nom d'une image OVF dans une bibliothèque de contenu n'est pas conforme au nom de sous-domaine DNS, le service de VM ne créera pas d'image VirtualMachineImage à partir de l'image OVF. Par conséquent, kubectl get vmimage ne listera pas les images dans un espace de noms et les développeurs ne pourront pas utiliser cette image.

    Solution : Utilisez des noms conformes aux noms de sous-domaine DNS pour les images OVF.

  • Les images OVF en double n'apparaissent pas en tant qu'images VirtualMachineImages dupliquées

    Les images OVF avec le même nom dans différentes bibliothèques de contenu ne s'affichent pas comme des images VirtualMachineImages différentes

    Solution : Utilisez des noms uniques pour les images OVF dans les bibliothèques de contenu configurées avec le service de VM.

  • Les VM créées par le service de VM n'autorisent pas l'accès au Web ou à la console distante

    Les machines virtuelles créées par le service VM n'autorisent pas l'accès à la console distante. Par conséquent, les administrateurs ne peuvent pas se connecter à la machine virtuelle à l'aide des options Lancer la console Web et Lancer Remote Console de vSphere Web Client.

    Solution : les administrateurs peuvent accéder à la console de la VM en se connectant à l'hôte ESXi sur lequel se trouve la VM.

  • Les machines virtuelles avec vGPU et périphériques de relais qui sont gérées par le service de VM sont mises hors tension lorsque l'hôte ESXi passe en mode de maintenance

    Le service de VM permet aux ingénieurs DevOps de créer des machines virtuelles attachées à des vGPU ou à des périphériques de relais. Normalement, lorsqu'un hôte ESXi passe en mode de maintenance, DRS génère une recommandation pour de telles machines virtuelles qui s'exécutent sur l'hôte. Un administrateur vSphere peut ensuite accepter la recommandation de déclencher vMotion.

    Cependant, les machines virtuelles avec vGPU et périphériques de relais qui sont gérées par le service de VM sont automatiquement mises hors tension. Cela peut affecter temporairement les charges de travail s'exécutant dans ces machines virtuelles. Les machines virtuelles sont automatiquement mises sous tension dès que l'hôte sort du mode de maintenance.

    Solution : aucune.

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