Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

Nouveautés du 25 juin 2024

VMware vSphere 8.0 Update 3 | 25 juin 2024 

vCenter Server 8.0 Update 3 | 25 juin 2024 | Build ISO 24022515

VMware ESXi 8.0 Update 3 | 25 juin 2024 | Build ISO 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 11 octobre 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 3.0 | 25 juin 2024

vSphere IaaS Control Plane 8.0 Update 3 présente les nouvelles fonctionnalités et améliorations suivantes :

  • Rotation automatique du certificat TKG et du superviseur : cette version apporte un nouveau mécanisme de rotation des certificats. Les certificats du cluster superviseur et TKG sont automatiquement alternés avant leur expiration. Si la rotation automatique échoue, vous en êtes informé dans vCenter et vous devrez renouveler les certificats manuellement.

  • Prise en charge du superviseur, de l'espace vSphere et du cluster TKG sur un cluster vSAN étendu : à partir de cette version, vous pouvez configurer le superviseur pour qu'il s'exécute sur un cluster vSAN étendu. Cette configuration est uniquement prise en charge dans un environnement vierge. Cela signifie que votre cluster vSAN doit être étendu et que la gestion de la charge de travail et la bibliothèque de contenu n'ont pas encore été configurées. Ces deux composants doivent être configurés avec les stratégies de stockage de cluster vSAN étendu. Pour plus d'informations, consultez la documentation.

  • La classe de VM pour les machines virtuelles de service de VM est désormais étendue à l'espace de noms : dans cette version, lorsque vous utilisez kubectl pour répertorier les classes de machine virtuelle, vous pouvez uniquement afficher les classes de machine virtuelle qui sont étendues à l'espace de noms vSphere spécifique. Auparavant, les classes de machine virtuelle étaient une ressource étendue au cluster et il était difficile de déterminer quelles machines virtuelles étaient attribuées et disponibles pour un espace de noms spécifique.

  • Sauvegarde et restauration du superviseur : la sauvegarde et la restauration du superviseur sont désormais prises en charge sur vSphere. Vous pouvez désormais configurer des sauvegardes pour un superviseur dans le cadre d'une sauvegarde vCenter et restaurer un superviseur à partir d'une sauvegarde en cas de récupération d'urgence, d'un échec de la mise à niveau, d'une panne et d'autres scénarios de récupération. Reportez-vous à la section Sauvegarde et restauration du plan de contrôle du superviseur.

  • Sauvegarde et restauration de machines virtuelles de service de VM : la sauvegarde et la restauration des machines virtuelles de service de VM sont désormais prises en charge sur vSphere. Vous pouvez utiliser n'importe quel fournisseur de sauvegarde basé sur VADP pour protéger vos machines virtuelles de service de VM. En cas de panne ou d'autres scénarios impliquant une perte de données, vous pouvez restaurer les machines virtuelles dans l'espace de noms vSphere à partir d'une sauvegarde.

  • L'API VM Operator v1alpha2 est désormais disponible : la nouvelle version de l'API VM Operator, v1alpha2, est disponible. Cette version offre une prise en charge améliorée du fournisseur de démarrage, notamment la prise en charge en ligne de Cloud-Init et de Windows, la configuration améliorée de la mise en réseau d'invité, les capacités d'état augmenté, la prise en charge des portails de disponibilité définis par l'utilisateur, la documentation améliorée de la nouvelle API VirtualMachineWebConsoleRequest et d'autres fonctionnalités. 

  • Exploitez Fluent Bit pour le transfert de journaux sur le superviseur : la prise en charge du transfert de journaux des journaux du plan de contrôle du superviseur et des journaux système vers une plate-forme de surveillance des journaux externe est désormais disponible. Pour plus d'informations, consultez la documentation.

  • Prise en charge du registre privé pour les services de superviseur : vous pouvez désormais définir les détails du registre privé qui permettront aux charges de travail déployées en tant que service de superviseur d'extraire des images et des modules d'un registre privé. Il s'agit d'une exigence courante pour la prise en charge d'un environnement isolé. Pour plus d'informations, consultez la documentation.

  • Améliorations du workflow de mise à niveau du superviseur : vous pouvez désormais initier des vérifications préalables à la mise à niveau du superviseur lors du lancement d'une mise à niveau de la version de Kubernetes du superviseur. La mise à jour est effectuée uniquement lorsque toutes les vérifications préalables réussissent. Cette version offre la possibilité de reprendre le processus de mise à niveau des composants à partir du point d'échec précédent. Pour plus d'informations, consultez la section Mettre à niveau le superviseur.

  • Le superviseur prend en charge Kubernetes 1.28 : dans cette version, le superviseur prend en charge Kubernetes 1.28 et ne prend plus en charge Kubernetes 1.25.

Versions de Kubernetes prises en charge pour les superviseurs :

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

Tanzu Kubernetes Grid Service for vSphere

  • TKG Service en tant que service de superviseur : cette version dissocie les composants TKG Service de vCenter et les regroupe en tant que service de superviseur que vous pouvez mettre à jour et gérer indépendamment des versions de vCenter et du superviseur. Vous trouverez les notes de mise à jour de TKG Service ici.

  • Prise en charge du déploiement des clusters TKG Service sur un cluster vSAN étendu : cette version prend en charge le déploiement de clusters TKG Service sur la topologie de cluster étendu vSAN. Pour plus d'informations sur la configuration de la haute disponibilité pour les clusters TKG Service sur un cluster vSAN étendu, reportez-vous à la documentation.

  • Mise à l'échelle automatique des clusters TKG Service : cette version prend en charge l'installation du module de mise à l'échelle automatique du cluster sur un cluster TKG Service pour activer la montée et la réduction de charge automatisées des nœuds worker. 

  • Sauvegarder et restaurer des clusters TKG : cette version prend en charge la sauvegarde et la restauration de la base de données du superviseur, qui inclut l'objet Espace de noms vSphere et les machines virtuelles de cluster TKG. Notez que les charges de travail du cluster TKG doivent être sauvegardées et restaurées séparément.

  • Prise en charge de l'intégration d'Antrea-NSX et du service de proxy de gestion NSX : cette version prend en charge l'intégration de clusters TKG à l'aide d'Antrea CNI avec NSX Manager pour l'observabilité et le contrôle de la mise en réseau des clusters.

  • MachineHealthCheck configurable : cette version prend en charge la configuration de MachineHealthCheck pour les clusters v1beta1.

  • Configuration PSA à l'échelle du cluster : cette version prend en charge la configuration de PSA à l'échelle du cluster lors de la création ou de la mise à jour du cluster.

  • Mises à jour de l'installation du module standard : cette version inclut des mises à jour de la documentation pour l'installation du module standard sur les clusters de service TKG. 

  • Mises à jour de l'API v1beta1 pour le provisionnement des clusters TKG : cette version inclut les modifications suivantes de l'API v1beta1 :

    • podSecurityStandard a été ajouté pour l'implémentation de PSA à l'échelle du cluster.

    • controlPlaneCertificateRotation a été mis à jour. 

  • Prise en charge de la mise à l'échelle des volumes de nœuds de plan de contrôle pour un cluster TKG.

Mises à jour de l'internationalisation

À partir de la prochaine version majeure, nous allons réduire le nombre de langues prises en charge. Les trois langues prises en charge seront les suivantes :

  • Japonais

  • Espagnol

  • Français

Les langues suivantes ne seront plus prises en charge :

  • Italien, Allemand, Portugais du Brésil, Chinois traditionnel, Coréen, Chinois simplifié

Impact :

  • Les utilisateurs qui utilisent les langues obsolètes ne recevront plus de mises à jour ni de support dans ces langues.

  • Toutes les interfaces utilisateur, la documentation d'aide et le support client seront disponibles uniquement en anglais ou dans les trois langues prises en charge mentionnées ci-dessus.

Nouveautés du 26 mars 2024

VMware vSphere 8.0 Update 2c | 26 mars 2024 

ESXi 8.0 Update 2b | 29 février 2024 | Build ISO 23305546

vCenter Server 8.0 Update 2c | 26 mars 2024 | Build ISO 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 11 octobre 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 mai 2023

vSphere IaaS Control Plane 8.0 Update 2c présente les nouvelles fonctionnalités et améliorations suivantes :

Nouvelles fonctionnalités

  • Prise en charge de TKr 1.27 : cette version a été modifiée pour prendre en charge TKr 1.27 sur vSphere 8.x lors de sa publication ultérieure. Pour plus d'informations, reportez-vous aux Notes de mise à jour de VMware Tanzu Kubernetes.

  • Prise en charge de la mise à niveau de vCenter 7.x vers vCenter 8.x : pour les utilisateurs qui exécutent TKr 1.27.6 sur vSphere 7.x, cette version fournit un chemin de mise à niveau vers vCenter 8.x. TKr 1.27.6 était publié pour vSphere 7.x et n'était pas compatible avec vCenter 8.x. Reportez-vous à l'article de la base de connaissances 96501.

Problèmes résolus

  • Après la mise à niveau vers vCenter 8.0 Update 2b, le service géré par vmon wcp peut être dans l'état STOPPED et l'application de correctifs vCenter peut échouer.

  • L'annulation du lien vers une bibliothèque ou la suppression d'un espace de noms avec une bibliothèque partagée supprime les éléments associés de la bibliothèque de contenu.

Nouveautés du 29 février 2024

VMware vSphere 8.0 Update 2b | 29 février 2024 

ESXi 8.0 Update 2b | 29 février 2024 | Build ISO 23305546

vCenter Server 8.0 Update 2b | 29 février 2024 | Build ISO 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 11 octobre 2023

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 mai 2023

vSphere IaaS Control Plane 8.0 Update 2b présente les nouvelles fonctionnalités et améliorations suivantes :

Nouvelles fonctionnalités

  • Prise en charge de la configuration des classes de machines virtuelles de service de VM via vSphere Client : le service de VM sur le superviseur prend en charge le déploiement de machines virtuelles avec n'importe quelle configuration actuellement prise en charge avec les machines virtuelles vSphere. Pour configurer le CPU, la mémoire, le matériel, les périphériques de sécurité et les périphériques de relais pour les classes de machine virtuelle, vous pouvez désormais utiliser l'assistant de classe de machine virtuelle dans vSphere Client. À l'aide de vSphere Client, vous simplifiez le processus de définition et de gestion des machines virtuelles de service de VM utilisées pour l'exécution de charges de travail AI/ML.

  • Les superviseurs prennent en charge la configuration de cloud Avi : si vous utilisez NSX Advanced Load Balancer, également appelé Avi Load Balancer, vous pouvez désormais configurer un cloud Avi pour chaque superviseur. Cela permet à plusieurs instances de vCenter Server et de centres de données d'utiliser une instance Avi unique, ce qui évite d'avoir à configurer une instance d'Avi pour chaque instance de vCenter Server ou de centre de données déployant un superviseur.

  • Prise en charge de la connexion via le nom de domaine complet : pour le superviseur et les clusters TKG, vous pouvez désormais remplacer l'adresse IP dans les fichiers kubeconfigs générés par un nom de domaine complet valide. Le nom de domaine complet et l'adresse IP doivent être ajoutés au DNS pour garantir une résolution de nom d'hôte appropriée.

  • Les superviseurs prennent en charge Kubernetes 1.27 : le superviseur prend désormais en charge Kubernetes 1.27 et interrompt la prise en charge de Kubernetes 1.24.

Versions de Kubernetes prises en charge

  • Les versions de Kubernetes prises en charge dans cette version sont 1.27, 1.26 et 1.25. Les superviseurs s'exécutant sur Kubernetes 1.24 effectuent une mise à niveau automatique vers la version 1.25 pour garantir la compatibilité.

Mise à niveau vers la version 8.0 Update 2b

La mise à niveau de n'importe quelle version de vSphere 8.x antérieure à la version 8.0 Update 2 vers la version 8.0 Update 2b lancera une mise à jour continue de tous les clusters TKGS provisionnés pour propager les modifications suivantes :

  • La version 8.0 Update 2 contient des modifications pour les TKR vSphere 7 et vSphere 8 dans le contrôleur TKGS dans le cadre de clusterClass.

  • Étant donné que les clusters TKGS de la version 1.23 et des versions ultérieures sont compatibles avec la version 8.0 Update 2b, tous les clusters TKGS font l'objet d'une mise à niveau propagée.

Problèmes résolus

  • Le processus de mise à niveau du superviseur est bloqué à 20 %.

Nouveautés du 21 septembre 2023

VMware vSphere 8.0.2 | 21 septembre 2023

ESXi 8.0.2 | 21 septembre 2023 | Build 22380479

vCenter Server 8.0.2 | 21 septembre 2023 | Build 22385739

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

HAProxy Community Edition 2.2.2, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 mai 2023

vSphere IaaS Control Plane 8.0 Update 2 présente les nouvelles fonctionnalités et améliorations suivantes :

Superviseur

  • Le service de VM prend désormais en charge les VM avec système d'exploitation Windows, les GPU et toutes les autres options disponibles pour les VM vSphere traditionnelles : le service de VM prend désormais en charge le déploiement de VM avec n'importe quelle configuration actuellement prise en charge avec les VM vSphere, en établissant la parité complète avec les VM traditionnelles sur vSphere, mais pour les VM déployées dans le cadre d'Iaas (Infrastructure en tant que service) sur le superviseur. Cela inclut la prise en charge du provisionnement des machines virtuelles Windows parallèlement aux machines virtuelles Linux, ainsi que tous les périphériques matériels, de sécurité, de périphériques, de prise en charge personnalisée ou multi-cartes réseau et de relais pris en charge sur vSphere. Vous pouvez désormais provisionner des machines virtuelles de charge de travail à l'aide de GPU pour prendre en charge les charges de travail d'AI/ML.

  • Service d'image de VM : les équipes DevOps, les développeurs et les autres utilisateurs de machines virtuelles peuvent publier et gérer des images de machine virtuelle en libre-service à l'aide du service d'image de machine virtuelle. Le service permet aux utilisateurs de publier, de modifier et de supprimer des images à l'aide d'API K8s dans un registre d'images étendu à l'espace de noms de superviseur. Le service d'image de VM est créé automatiquement dans chaque région CCS et projet CCS, et l'ensemble d'images du registre d'images est étendue par persona et niveau d'utilisation, soit au niveau global, soit au niveau du projet. Les images peuvent être utilisées pour le déploiement de machines virtuelles via le service de VM.

    Notez que cette fonctionnalité introduit un nouveau format pour le nom de l'image de machine virtuelle. Pour plus d'informations sur la résolution des problèmes potentiels causés par la modification du nom, reportez-vous à la section Modifications apportées au format de nom d'image de machine virtuelle dans vSphere 8.0 U2.

  • Importer et exporter la configuration du superviseur : dans les versions précédentes, l'activation du superviseur était un processus manuel sans possibilité d'enregistrer des configurations. Dans la version actuelle, vous pouvez désormais exporter et partager la configuration du superviseur avec des homologues dans un format lisible par l'utilisateur ou dans un système de contrôle de source, importer des configurations vers un nouveau superviseur et répliquer une configuration standard sur plusieurs superviseurs. Pour plus d'informations sur l'exportation et l'importation de la configuration du superviseur, consultez la documentation.

  • Amélioration de l'utilisation des GPU grâce à la réduction de la fragmentation : le positionnement des charges de travail prend désormais en considération le GPU et DRS tente de placer des charges de travail avec des exigences de profil similaires sur le même hôte. Cela améliore l'utilisation des ressources, ce qui réduit les coûts, car moins de ressources matérielles de GPU doivent être acquises pour atteindre le niveau de performance souhaité.

  • Le superviseur prend en charge Kubernetes 1.26 : cette version ajoute la prise en charge de Kubernetes 1.26 et annule celle de Kubernetes 1.23. Les versions prises en charge de Kubernetes dans cette publication sont les versions 1.26, 1.25 et 1.24. Les superviseurs s'exécutant sur Kubernetes version 1.23 seront mis à niveau automatiquement vers la version 1.24, afin de s'assurer que tous vos superviseurs sont exécutés sur les versions prises en charge de Kubernetes.

  • Prise en charge de NSX Advanced Load Balancer pour un superviseur configuré avec la mise en réseau NSX : vous pouvez désormais activer un 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 superviseurs et Tanzu Kubernetes Grid avec mise en réseau NSX. Pour obtenir des instructions sur la configuration de NSX Advanced Load Balancer avec NSX, consultez la page de documentation.

  • Prise en charge de Telegraf pour la diffusion en continu des mesures et des événements : vous pouvez désormais configurer Telegraf via les API Kubernetes pour transférer des mesures du superviseur vers tous les services de mesures compatibles avec la version intégrée de Telegraf. Pour plus d'informations sur la configuration de Telegraf, reportez-vous à la documentation.

Tanzu Kubernetes Grid sur le superviseur

  • Conformité au STIG pour les TKR sur vSphere 8.0 : avec vSphere U2, tous les clusters Tanzu Kubernetes Grid de version supérieure à la version 1.23.x sont conformes au guide relatif à la mise en œuvre technique de la sécurité (Security Technical Implementation Guide, STIG) et à la documentation relative aux exceptions que vous pouvez trouver ici. Ces améliorations représentent une étape importante vers la simplification du processus de mise en conformité et vous permettent de répondre plus facilement aux exigences en matière de conformité afin que vous puissiez utiliser rapidement et en toute confiance Tanzu Kubernetes Grid sur le marché fédéral américain et dans d'autres secteurs réglementés.

  • Activer le déploiement du plan de contrôle pour les certificats arrivant à expiration : l'API v1beta1 pour le provisionnement de clusters TKG basés sur une ClusterClass est mise à jour pour permettre aux clusters de renouveler automatiquement leurs certificats de machine virtuelle de nœud de plan de contrôle avant leur expiration. Cette configuration peut être ajoutée en tant que variable à la spécification du cluster. Pour plus d'informations, reportez-vous à la documentation de l'

    API de cluster v1beta1.

  • Prise en charge des snapshots CSI pour les TKR : les clusters TKG provisionnés avec Tanzu Kubernetes version 1.26.5 ou ultérieure prennent en charge les snapshots de volume CSI, ce qui vous aide à répondre à vos exigences en matière de protection des données. Les snapshots de volume vous fournissent un moyen normalisé de copier le contenu d'un volume à un moment précis sans créer de volume entièrement nouveau. 

  • Installation et gestion des modules Tanzu : nouveau référentiel et publication consolidés pour l'installation et la gestion des modules Tanzu sur des clusters TKG. Pour connaître tous vos besoins en modules, reportez-vous à la publication « Installation et utilisation de modules VMware Tanzu ».

  • Améliorations des ClusterClass personnalisées : le workflow d'implémentation de clusters ClusterClass personnalisés est simplifié pour vSphere 8 U2.

  • Mises à jour continues pour les clusters TKG : lors de la mise à niveau vers vSphere 8 U2, vous pouvez vous attendre à des mises à jour continues pour les clusters TKG provisionnés dans les scénarios suivants :

    • Lors de la mise à niveau de n'importe quelle version de vSphere 8 précédemment publiée vers vSphere 8 U2, car :

      • vSphere 8 U2 contient des modifications STIG de niveau Kubernetes pour les TKR dans le cadre de la ClusterClass

      • À partir de la version 1.23, les clusters TKG feront l'objet d'une mise à jour continue pour être compatibles avec v8.0 U2

    • Lors de la mise à niveau de n'importe quelle version de vSphere 7 vers vSphere 8 U2, car :

      • Les fournisseurs CAPI sous-jacents doivent être déplacés depuis CAPW vers CAPV

      • Les clusters existants doivent être migrés de clusters CAPI sans classe vers des clusters CAPI basés sur une classe

Problèmes résolus

  • Les fichiers journaux d'audit sous /var/log/audit/ sur les machines virtuelles du plan de contrôle du superviseur peuvent atteindre une très grande taille et remplir le disque racine. Vous devez voir des erreurs « no space left on device » dans les journaux indiquant cet état. Cela peut entraîner l'échec de différents aspects de la fonctionnalité du plan de contrôle du superviseur (tels que les API Kubernetes).

Nouveautés du 27 juillet 2023

VMware vSphere 8.0.1c | 27 juillet 2023

ESXi 8.0.1c | 27 juillet 2023 | Build 22088125

vCenter Server 8.0.1c | 27 juillet 2023 | Build 22088981

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

HAProxy Community Edition 2.2.2, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 18 mai 2023

Nouvelles fonctionnalités

  • Les superviseurs prennent en charge Kubernetes 1.25 : cette version prend en charge Kubernetes 1.25 et ne prend plus en charge Kubernetes 1.22.

  • Tanzu Kubernetes Grid 2.2.0 sur le superviseur : gestion des clusters Tanzu Kubernetes Grid 2.2.0 sur le superviseur.

Versions de Kubernetes prises en charge

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

Support

  • Obsolescence de la création de vRegistry : la création de l'instance de Harbor intégrée, vRegistry, est obsolète. Les instances existantes de vRegistry continueront à fonctionner, mais la création de nouvelles instances de vRegistry est abandonnée. Les API de création de vRegistry ont été marquées comme ayant été abandonnées et la possibilité de déployer de nouvelles instances de vRegistry sera supprimée dans une prochaine version. Nous vous recommandons d'utiliser Harbor comme service de superviseur pour gérer vos images et référentiels de conteneur à des fins d'optimisation des performances et des fonctionnalités. Pour migrer l'instance de vRegistry existante vers Harbor en tant que service de superviseur, reportez-vous à la section Migrer des images du registre intégré vers Harbor pour plus d'informations sur la migration.

Problèmes résolus

  • Un nouveau message d'alerte s'affiche dans vSphere Client pour avertir de l'expiration des certificats sur le superviseur ou les clusters TKG. L'alerte fournit des informations détaillées, notamment le nom du superviseur et la date d'expiration du certificat. En outre, elle contient un lien vers KB 90627 qui explique étape par étape comment remplacer les certificats affectés.

  • La commande kubectl get clustervirtualmachineimages renvoie une erreur ou No resources found. Dans les versions précédentes, lors de l'utilisation de la commande kubectl get clustervirtualmachineimages, une erreur survenait. Cependant, après la mise à niveau vers la version 8.0 Update 1c, la commande renvoie désormais le message suivant : No resources found. Pour récupérer des informations sur les images de machine virtuelle, utilisez plutôt la commande suivante : kubectl get virtualmachineimages

  • La CNI acheminée par antrea-nsx ne fonctionne pas avec les clusters v1alpha3 Tanzu Kubernetes sur les versions vSphere IaaS Control Plane 8.x.

  • Le délai d'expiration de purge du nœud n'est pas correctement propagé pour les clusters v1beta1.

Nouveautés du 18 avril 2023

VMware vSphere 8.0.1 | 18 avril 2023

ESXi 8.0.1 | 18 avril 2023 | Build 21495797

vCenter Server 8.0.1 | 18 avril 2023 | Build 21560480

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

HAProxy Community Edition 2.2.2, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 octobre 2022

Nouvelles fonctionnalités

Superviseur

  • Les services de superviseur sont désormais disponibles sur les superviseurs basés sur VDS : auparavant, la disponibilité des services de superviseur était limitée aux superviseurs basés sur NSX uniquement. Avec la version actuelle, vous pouvez déployer Harbor, Contour, le stockage d'objets S3 et les services de superviseur Velero sur des superviseurs basés sur VDS. Remarque : les capacités du service de superviseur sur les superviseurs basés sur VDS requièrent une mise à jour d'ESXi vers la version 8.0 U1.

  • Prise en charge des services de VM pour toutes les images Linux : vous pouvez désormais utiliser CloudInit pour personnaliser les images Linux au format OVF conformément à la spécification d'image du service de VM et utiliser le modèle OVF via vAppConfig pour activer le déploiement d'images Linux héritées.

  • Prise en charge de la console Web pour les machines virtuelles de service : après le déploiement d'une machine virtuelle du service de VM, en tant qu'ingénieur DevOps, vous avez désormais la possibilité de lancer une session de console Web pour cette machine virtuelle à l'aide de l'interface de ligne de commande kubectl pour activer le dépannage et le débogage dans le système d'exploitation invité sans impliquer l'administrateur vSphere pour obtenir l'accès à la machine virtuelle invitée.

  • Conformité du superviseur : guides relatifs à la mise en œuvre technique de la sécurité pour les versions 8 du superviseur vSphere IaaS Control Plane. Pour plus d'informations, reportez-vous à la section Sécurisation renforcée STIG Tanzu.

Tanzu Kubernetes Grid 2.0 sur le superviseur

EXIGENCE CRITIQUE pour les clients vSpere IaaS Control Plane 8.0.0 GA

Remarque : cette exigence ne s'applique pas aux bibliothèques de contenu que vous utilisez pour les machines virtuelles provisionnées via le service de VM. Elle s'applique uniquement à la bibliothèque de contenu TKR.

Si vous avez déployé vSphere IaaS Control Plane 8.0.0 GA, avant d'effectuer la mise à niveau vers vSphere IaaS Control Plane 8 U1, vous devez créer une bibliothèque de contenu TKR temporaire pour éviter un problème connu qui entraîne le basculement des espaces du contrôleur TKG en CrashLoopBackoff lorsque des TKR TKG 2.0 sont transférées vers la bibliothèque de contenu existante. Pour éviter ce problème, procédez comme suit.

  1. Créez une bibliothèque de contenu abonnée avec une URL d'abonnement temporaire pointant vers https://wp-content.vmware.com/v2/8.0.0/lib.json.

  2. Synchronisez tous les éléments de la bibliothèque de contenu temporaire.

  3. Associez la bibliothèque de contenu temporaire à chaque espace de noms vSphere dans lequel vous avez déployé un cluster TKG 2.

  4. Exécutez la commande kubectl get tkr et vérifiez que toutes les TKR sont créées.

  5. À ce stade, le contrôleur TKG doit être dans un état d'exécution, ce que vous pouvez vérifier en répertoriant les espaces dans l'espace de noms du superviseur.

  6. Si l'état du contrôleur TKG est CrashLoopBackOff (CLBO), redémarrez le déploiement du contrôleur TKG à l'aide de la commande suivante :

    kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

  7. Procédez à la mise à niveau vers vSphere IaaS Control Plane 8 Update 1.

  8. Mettez à jour chaque espace de noms vSphere pour utiliser la bibliothèque de contenu abonnée d'origine à l'adresse https://wp-content.vmware.com/v2/latest/lib.json.

Problèmes résolus

  • Les clusters Tanzu Kubernetes Grid 2.0 provisionnés avec l'API v1beta1 doivent être basés sur la ClusterClass par défaut

    Si vous créez un cluster Tanzu Kubernetes Grid 2.0 sur le superviseur à l'aide de l'API v1beta1, le cluster doit être basé sur la ClusterClass tanzukubernetescluster par défaut. Le système n'effectue pas le rapprochement d'un cluster basé sur une ClusterClass différente.

Nouveautés du 30 mars 2023

ESXi 8.0.0c | 30 mars 2023 | Build 21493926

vCenter Server 8.0.0c | 30 mars 2023 | Build 21457384

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

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 octobre 2022

Problèmes résolus :

  • Problème de configuration par défaut de Harbor non sécurisée

    Cette version résout le problème de configuration par défaut non sécurisée de Harbor qui se produit si vous avez activé le registre Harbor intégré sur le superviseur 7.0 ou 8.0.

    Résolu dans vCenter version 8.0.0c. Pour obtenir des informations détaillées sur ce problème et comment le résoudre en installant cette version ou en appliquant une solution temporaire, consultez l'article 91452 de la base de connaissances VMware.

  • Après une mise à niveau vers vCenter Server 8.0b, les tentatives de connexion à un superviseur et à des clusters TKG échouent

    Les composants exécutés dans vCenter Server 8.0b ne sont pas rétrocompatibles avec les superviseurs déployés à l'aide de vCenter Server dans les versions antérieures.

    Solution : mettez à niveau le système vCenter Server vers une version plus récente ou mettez à niveau tous les superviseurs déployés.

Nouveautés du 14 février 2023

ESXi 8.0.0b | 14 février 2023 | Build 21203435

vCenter Server 8.0.0b | 14 février 2023 | Build 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15 juillet 2022

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 octobre 2022

Nouvelles fonctionnalités :

  • Ajout de la prise en charge de l'émetteur d'autorité de certification Cert-Manager du cluster : donne aux administrateurs la possibilité de définir et de déployer un émetteur d'autorité de certification étendu au cluster sur un superviseur en tant que service de superviseur. Le déploiement d'un émetteur d'autorité de certification étendu au cluster permet aux consommateurs de l'espace de noms de superviseur de demander et de gérer des certificats signés par l'émetteur d'autorité de certification. 

En plus de cette nouvelle fonctionnalité, la version fournit des correctifs de bogues.

Problèmes résolus :

  • Remplissage du disque racine des VM du plan de contrôle du superviseur

    Les fichiers journaux d'audit sous /var/log/audit/ sur les machines virtuelles du plan de contrôle du superviseur peuvent atteindre une très grande taille et remplir le disque racine. Vous devez voir des erreurs « no space left on device » dans les journaux indiquant cet état. Cela peut entraîner l'échec de différents aspects de la fonctionnalité du plan de contrôle du superviseur (tels que les API Kubernetes).

    Ce problème a été résolu dans la version vSphere 8.0.0b.

Nouveautés du 15 décembre 2022

ESXi 8.0 | 11 octobre 2022 | Build 20513097

vCenter Server 8.0.0a | 15 décembre 2022 | Build 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 15 juillet 2022

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 octobre 2022

Nouvelles fonctionnalités

  • Ajout de Harbor en tant que service de superviseur : fournit une instance de Harbor avec l'ensemble de ses fonctions (registre d'images OCI) s'exécutant sur le superviseur. L'instance de Harbor donne aux administrateurs Harbor la possibilité de créer et de gérer des projets et des utilisateurs, ainsi que de configurer l'analyse d'images.

  • Désapprobation de vRegistry : l'instance de Harbor intégrée, appelée vRegistry, sera supprimée dans une version ultérieure. À la place, vous pouvez utiliser Harbor comme service de superviseur. Pour plus d'informations sur la migration, reportez-vous à la section « Migrer des images du registre intégré vers Harbor ».

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

  • API de zone vSphere : une zone vSphere est une construction qui vous permet d'attribuer des zones de disponibilité aux clusters vSphere afin de rendre les clusters superviseur et Tanzu Kubernetes hautement disponibles. Dans vSphere 8.0, la fonctionnalité de création et de gestion de zone vSphere était disponible dans vSphere Client. Avec la version vSphere 8.0.0a, les utilisateurs peuvent créer et gérer des zones vSphere à l'aide de DCLI ou de l'explorateur d'API de vSphere Client. La prise en charge complète des liaisons SDK (par exemple, Java, Python, etc.) sera disponible dans une version ultérieure.

Considérations relatives à la mise à niveau :

  • Une mise à jour continue des clusters Tanzu Kubernetes se produit dans les scénarios de mise à niveau du superviseur suivants :

    • Lors de la mise à niveau de la version 8.0 vers la version 8.0.0a, suivie de la mise à niveau d'un superviseur à partir d'une version quelconque de Kubernetes vers la version 1.24 du superviseur Kubernetes, et lorsque l'une des conditions suivantes est remplie.

      • Si vous utilisez des paramètres de proxy avec une liste nonempty noProxy sur un cluster Tanzu Kubernetes

      • Si vRegistry est activé sur le superviseur. Cette configuration n'est disponible que sur les superviseurs basés sur NSX.

    • Lors de la mise à niveau d'une version vSphere 7.0 vers vSphere 8.0.0a.

Problèmes résolus :

  • Les clés de licence Tanzu 7 sont prises en charge dans vSphere 8, au lieu des clés de licence Tanzu 8

    vCenter 8.0 prend en charge les clés de licence Tanzu 7 au lieu des clés de licence Tanzu 8. Ce problème n'affecte pas votre capacité à utiliser entièrement les fonctionnalités de Tanzu sur vCenter 8.0. Pour plus d'informations, reportez-vous à l'article 89839 de la base de connaissances VMware avant de modifier les licences Tanzu dans votre déploiement de vCenter 8.0.

  • Les équilibrages de charge et les clusters invités ne sont pas créés lorsqu'il existe deux groupes SE sur NSX-ALB.

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

    get() returned more than one ServiceEngineGroup – it returned 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, reportez-vous à l'article 90386 de la base de connaissances VMware.

Nouveautés du 11 octobre 2022

VMware vSphere 8.0 | 11 octobre 2022

ESXi 8.0 | 11 octobre 2022 | Build 20513097

vCenter 8.0 | 11 octobre 2022 | Build 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 7 avril 2022

HAProxy 2.2.2 Community Edition, Data Plane API 2.1.0

Tanzu Kubernetes Grid 2.0 | 11 octobre 2022

vSphere IaaS Control Plane 8.0 présente les nouvelles fonctionnalités et améliorations suivantes :

  • Surveillance de la configuration de la gestion de la charge de travail : vous pouvez désormais suivre plus en détail l'état de l'activation, de la désactivation et de la mise à niveau du superviseur. Une fois que vous avez initié une activation, une désactivation ou une mise à niveau du superviseur, celui-ci tente d'atteindre l'état souhaité en accédant à diverses conditions associées aux différents composants du superviseur, tels que les machines virtuelles du plan de contrôle. Vous pouvez suivre l'état de chaque condition, afficher les avertissements associés, réessayer l'état, afficher les conditions atteintes et leurs horodatages.

  • Zones vSphere : une zone vSphere est une nouvelle construction qui vous permet d'attribuer des zones de disponibilité aux clusters vSphere. Le déploiement d'un superviseur sur des zones vSphere vous permet de provisionner des clusters Tanzu Kubernetes Grid dans des zones de disponibilité et des domaines de pannes spécifiques. Cela permet aux charges de travail de s'étendre sur plusieurs clusters, ce qui augmente la résilience aux pannes matérielles et logicielles.

  • Superviseur de plusieurs clusters : en utilisant les zones vSphere, vous pouvez déployer un superviseur sur plusieurs clusters vSphere afin de fournir des domaines de haute disponibilité et de panne pour les clusters Tanzu Kubernetes Grid. Vous pouvez ajouter un cluster vSphere à une zone de vSphere distincte et activer un superviseur qui s'étend sur plusieurs zones vSphere. Cela assure le basculement et la résilience aux pannes matérielles et logicielles localisées. Lorsqu'une zone ou un cluster vSphere est mis hors ligne, le superviseur détecte la panne et redémarre les charges de travail sur une autre zone de vSphere. Vous pouvez utiliser des zones vSphere dans des environnements qui couvrent des distances tant que les maximales de latence ne sont pas dépassées. Pour plus d'informations sur les exigences en matière de latence, reportez-vous à la section Configuration requise pour le déploiement zonal du superviseur.

  • Le superviseur prend 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 les versions prises en charge de Kubernetes.

  • Fournir des stratégies réseau cohérentes avec les CRD SecurityPolicy : la définition de ressources personnalisées SecurityPolicy permet de configurer des contrôles de sécurité réseau pour les machines virtuelles et les espaces vSphere dans un espace de noms de superviseur.

  • Tanzu Kubernetes Grid 2.0 sur le superviseur : Tanzu Kubernetes Grid est désormais passé à la version 2.0. Tanzu Kubernetes Grid 2.0 est l'aboutissement d'innovations considérables au sein de la communauté Tanzu et Kubernetes. Il constitue la base d'un ensemble commun d'interfaces sur les clouds privés et publics avec Tanzu Kubernetes Grid. Les deux nouvelles fonctionnalités majeures de cette version sont les suivantes :

    • ClusterClass - Tanzu Kubernetes Grid 2.0 prend désormais en charge ClusterClass. ClusterClass fournit une interface alignée en amont qui remplace le cluster Tanzu Kubernetes et qui apporte des capacités de personnalisation à notre plate-forme Tanzu Kubernetes Grid. ClusterClass permet aux administrateurs de définir des modèles qui fonctionneront avec les exigences de leur environnement d'entreprise tout en réduisant les formules standard et en permettant la personnalisation déléguée.

    • Carvel - Carvel fournit à Kubernetes un ensemble d'outils à un seul objectif fiables et composables qui facilitent la création, la configuration et le déploiement d'applications. En particulier, kapp et kapp-controller assurent la gestion, la compatibilité et le cycle de vie des modules via un ensemble d'outils déclaratifs alignés en amont. Associés à ytt pour la création de modèles, ils offrent une capacité de gestion des modules flexible et gérable.

  • Nouvelle structure de documentation et nouvelle page de lancement dans vSphere 8 : la documentation de vSphere IaaS Control Plane dispose désormais d'une structure améliorée qui reflète mieux les workflows avec le produit et vous permet d'avoir une expérience plus axée sur le contenu. Vous pouvez également accéder à toute la documentation technique disponible pour vSphere IaaS Control Plane depuis la nouvelle page de lancement de la documentation.


Installation et mises à niveau de cette version

Lisez la documentation Installation et configuration de vSphere IaaS Control Plane pour obtenir des instructions sur l'installation et la configuration de vSphere IaaS Control Plane. Pour plus d'informations sur la mise à jour de vSphere IaaS Control Plane, reportez-vous à la documentation Mise à jour de vSphere IaaS Control Plane.

Lorsque vous effectuez vos mises à niveau, gardez à l'esprit les points suivants :

  • Avant d'effectuer la mise à jour vers vCenter Server 8.0, assurez-vous que la version de Kubernetes de tous les superviseurs est au minimum la version 1.21 et de préférence la dernière version prise en charge. La version de Tanzu Kubernetes des clusters Tanzu Kubernetes Grid doit être la version 1.21 et de préférence la dernière version prise en charge.

  • Les mises à niveau de TKR TKGS hérité vers TKR TKG 2 sont autorisées à partir de la version vSphere IaaS Control Plane 8.0 MP1. Reportez-vous aux Notes de mise à jour des versions Tanzu Kuberentes pour obtenir la matrice des versions prises en charge. Reportez-vous à la documentation Utilisation de TKG sur le superviseur avec vSphere IaaS Control Plane pour obtenir des informations sur la mise à niveau.

Problèmes connus

Problèmes connus du superviseur

  • Dans vSphere 8.0 Update 3, les options de remplacement réseau ne sont plus présentes sur la page de création de l'espace de noms vSphere

    Avant la version 8.0 Update 3, un administrateur vSphere pouvait fournir une configuration réseau personnalisée au lieu de la configuration réseau par défaut utilisée lors de la création d'un espace de noms vSphere. Dans la version 8.0 Update 3, l'option d'interface utilisateur permettant de remplacer la configuration réseau n'est pas disponible.

    Solution : vous pouvez utiliser DCLI pour créer l'espace de noms vSphere avec une configuration réseau personnalisée.

  • Parfois, les hôtes ESXi peuvent ne pas parvenir à rejoindre un cluster superviseur, car le module vds-vsip ne peut pas être chargé

    Lorsque les hôtes ESXi ne parviennent pas à rejoindre le cluster superviseur, vous pouvez voir l'erreur suivante dans le fichier journal des hôtes ESXi : /var/run/log/spherelet.log:

    cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

    Ce problème peut se produire lors d'une mise à niveau du cluster superviseur, d'une mise à niveau de certificat ou de toute autre modification de configuration du superviseur qui redémarre spherelet.

    Solution : redémarrez les hôtes ESXi qui ne peuvent pas charger le module vds-vsip.

  • Les tentatives de mise à niveau de votre environnement vSphere IaaS Control Plane de la version 7.0 Update 3o vers la version 8.0 Update 3 avec un superviseur utilisant de très petites machines virtuelles de plan de contrôle échouent avec une erreur

    Après la mise à niveau de vCenter de la version 7.0 Update 3o vers la version 8.0 Update 3, le superviseur configuré avec des VM de plan de contrôle Très petite ne peut pas être mis à niveau de Kubernetes v1.26.8 vers v1.27.5.

    Vous pouvez observer les erreurs suivantes : Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

    Solution : avant la mise à niveau, augmentez la taille des machines virtuelles du plan de contrôle de Très petite à Petite ou à une taille supérieure. Reportez-vous à la section Modifier la taille du plan de contrôle d'un superviseur.

  • Après la mise à niveau de vCenter et de votre environnement vSphere IaaS Control Plane vers vSphere 8.0 U3, les tentatives de création d'espaces vSphere échouent si le superviseur utilise Kubernetes version 1.26

    Après la mise à niveau de votre environnement vers vSphere 8.0 U3 et la mise à niveau de votre superviseur vers Kubernetes version 1.26, les opérations de création d'espaces vSphere échouent lorsque le système tente d'extraire l'image. Vous pouvez observer l'erreur failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface même si le cluster est compatible avec un réseau statique.

    Solution : mettez à niveau vSphere IaaS Control Plane et le superviseur vers Kubernetes version 1.27 ou ultérieure.

  • Parfois, lorsque vous tentez simultanément de supprimer un snapshot de volume et d'effectuer une opération de restauration de PVC, les opérations ne se terminent pas en raison de dépendances internes

    Les problèmes peuvent se produire dans les circonstances suivantes. Vous démarrez une opération de restauration pour un snapshot de volume et elle prend plus de temps à se terminer ou est réessayée à cause de différentes raisons internes. En attendant, vous déclenchez la suppression du snapshot source. Par conséquent, les deux opérations entrent en collision et ne se terminent pas. La suppression du snapshot continue d'échouer en raison d'une opération de restauration en cours pour ce snapshot, tandis que l'opération de restauration commence à échouer, car la suppression du snapshot a été déclenchée.

    Solution : pour résoudre ce problème, vous devez supprimer la PVC restaurée pour arrêter l'opération de restauration et laisser la suppression du snapshot se poursuivre. Dans ce cas, les données de snapshot seront perdues et ne peuvent pas être restaurées, car le snapshot est supprimé après la suppression de la PVC restaurée.

  • Les machines virtuelles de service de VM ne peuvent pas utiliser de PVC lorsque le paramètre volumeBindingMode dans la classe de stockage est défini sur WaitForFirstConsumer

    Lorsque vous utilisez ce type de PVC pour les machines virtuelles de service de VM, un comportement imprévisible et des erreurs se produisent. Par exemple, vous pouvez observer une erreur Waiting for first consumer to be created before binding.

    Solution : les machines virtuelles de service de VM prennent en charge les PVC avec volumeBidingMode immédiat dans la classe de stockage, mais ne prennent pas en charge WaitForFirstConsumer.

  • Un nouveau modèle de licence modifie le comportement de NSX Container Plugin (NCP) dans l'environnement VMware vSphere IaaS Control Plane

    Dans la version 8.0 Update 3, la licence NSX Distributed Firewall (DFW) est proposée en tant que licence de module complémentaire distincte. Sans cette licence, NCP dans l'environnement VMware vSphere IaaS Control Plane ajuste les règles DFW sur NSX, ce qui entraîne un comportement imprévisible.

    Par exemple, sans la licence DFW, les nouvelles stratégies de sécurité et de réseau créées pour VMware vSphere IaaS Control Plane ne fonctionnent pas, car NCP ne peut pas ajouter de règles sur NSX Manager. En outre, les ressources, telles que les espaces dans un espace de noms récemment créé, peuvent être accessibles à partir d'un autre espace de noms. En revanche, avec la licence DFW, un espace de noms récemment créé ne doit pas être accessible à partir d'un autre espace de noms par défaut.

    Solution : la licence NSX Distributed Firewall (DFW) est proposée en tant que licence complémentaire distincte sur NSX Manager. Pour éviter tout problème, ajoutez la licence à NSX Manager.

  • Velero vSphere Operator s'installe correctement, mais les tentatives d'instanciation d'une instance de Velero peuvent échouer

    Velero vSphere Operator déploie ses espaces d'opérateur sur les machines virtuelles du plan de contrôle, tandis que les instances de Velero se déploient en tant qu'espaces vSphere.

    Le problème de déploiement peut se produire lorsque vCenter a été mis à niveau vers la version 8.x et que le superviseur utilise la mise en réseau VDS. Toutefois, les hôtes ESXi pour ce superviseur n'ont pas été mis à niveau et utilisent une version asynchrone antérieure à la version 8.x. Dans ce scénario, les hôtes ESXi ne peuvent pas déployer d'espaces vSphere. Par conséquent, lorsque Velero vSphere Operator s'installe correctement, il ne parvient pas à instancier une instance de Velero lorsque l'administrateur tente de l'utiliser.

    Solution : pour vous assurer que le service de superviseur Velero fonctionne correctement, vous devez d'abord mettre à niveau ESXi vers la version 8.x, puis mettre à niveau vCenter et le superviseur vers la même version 8.x.

  • L'espace VM Operator se bloque en raison de ressources insuffisantes à grande échelle

    Si la réalisation des ressources VirtualMachine prend beaucoup de temps lorsqu'elles sont à grande échelle, par exemple, des milliers de machines virtuelles, cela peut être dû au blocage de l'espace VM Operator en raison d'une mémoire insuffisante.

    Solution : pour obtenir la solution et plus d'informations, reportez-vous à l'article 88442 de la base de connaissances.

  • Après la mise à niveau vers vCenter 8.0 Update 2b, l'état du service wcp géré par vmon peut être STOPPED et l'application de correctifs à vCenter peut échouer

    Ce problème se produit uniquement lorsque vous mettez à niveau vCenter 8.0 Update 1 ou version ultérieure vers vCenter 8.0 Update 2b, et que vous disposez d'au moins un superviseur qui utilise la topologie de mise en réseau VDS et se trouve sur Kubernetes 1.24.

    Solution : pour éviter ce problème, mettez à niveau le superviseur vers Kubernetes 1.25 ou version ultérieure avant de mettre à niveau vCenter vers la version 8.0 Update 2b. Pour plus d'informations, contactez le support client.

  • Les opérations de superviseur échouent lorsque la taille des certificats vCenter personnalisés est supérieure à 8 Ko

    Dans vSphere 8.0 Update 2b, la taille de clé maximale d'une demande de signature de certificat dans un système vCenter passe de 16 384 bits à 8 192 bits. Lorsque la taille de clé de votre certificat est supérieure à 8 192 bits, vous pouvez observer un comportement imprévisible des opérations de superviseur. Par exemple, des opérations telles que l'activation ou la mise à niveau du superviseur peuvent échouer.

    Solution :

    Régénérez tous les certificats vCenter dont la taille de clé est supérieure à 8 192 bits.

    1. Identifiez les certificats dont la taille de clé est supérieure à 8 192 bits.

      for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done

    2. Remplacez tous les certificats dont la taille de clé est supérieure à 8 192 bits.

    3. Enregistrez à nouveau vCenter dans NSX si vous utilisez NSX.

    4. Redémarrez le service WCP.

    Pour plus d'informations, reportez-vous à l'article 96562 de la base de connaissances.

  • Les modèles peuvent être supprimés de la bibliothèque de contenu dans vCenter lorsque la bibliothèque est liée à plusieurs espaces de noms vSphere

    Vous pouvez observer ce problème lorsqu'une bibliothèque est liée à plusieurs espaces de noms dans vSphere IaaS Control Plane et que le lien de la bibliothèque avec un espace de noms est annulé ou qu'un espace de noms est supprimé.

    Solution :

    Évitez d'utiliser une bibliothèque locale si vous souhaitez lier la bibliothèque à plusieurs espaces de noms. Créez plutôt une bibliothèque publiée sur vCenter et chargez tous les modèles dans la bibliothèque publiée. Créez ensuite une bibliothèque abonnée qui synchronisera les modèles de la bibliothèque publiée sur la même instance de vCenter et liera cette bibliothèque abonnée à plusieurs espaces de noms. Dans ce cas, même lorsqu'une bibliothèque est dissociée d'un espace de noms ou qu'un espace de noms est supprimé, les éléments de bibliothèque ne sont pas supprimés de vCenter.

  • Des erreurs se produisent lorsque vous utilisez les instances de REST API de VMware vSphere Automation pour créer ou mettre à jour une classe de VM et inclure des champs d'entier dans configSpec

    Vous pouvez observer les erreurs suivantes lorsque configSpec inclut des champs entiers, tels que numCPU ou memoryMB :

    Erreur inconnue - vcenter.wcp.vmclass.configspec.invalid: json: unsupported discriminator kind: struct.

    Erreur inconnue - vcenter.wcp.vmclass.configspec.invalid: json: cannot unmarshal string into Go struct field VirtualMachineConfigSpec.<fieldName> of type int32.

    Ce problème se produit en raison d'un problème connu dans le point de terminaison VAPI qui analyse les JSON configSpec REST bruts avec des entiers et transmet les entiers sous forme de chaînes, ce qui entraîne des échecs. Le problème se produit uniquement lorsque vous utilisez les instances de REST API via VMware Developer Center.

    Solution : au lieu des instances de REST API, utilisez DCLI ou vSphere Client pour créer ou mettre à jour les classes de machine virtuelle.

    Vous pouvez également utiliser vSphere Automation SDK pour Python/Java. L'exemple suivant explique comment utiliser le service de transcodeur de protocole public pour convertir un objet VirtualMachineConfigSpec (vim.vm.ConfigSpec) obtenu à partir de vCenter à l'aide de pyvmomi. La dernière entrée de l'exemple montre comment analyser un fichier JSON conçu manuellement. L'objet peut ensuite être envoyé à l'API VirtualMachineClasses.

  • Une fois que vous avez appliqué une licence vSphere VMware Foundation valide à un superviseur, la page Gestion de la charge de travail continue d'afficher l'ancienne licence d'évaluation avec un avertissement d'expiration

    Vous pouvez rencontrer ce problème si le superviseur est activé avec une licence d'évaluation et que vous appliquez la licence vSphere VMware Foundation au superviseur. Toutefois, la nouvelle licence n'apparaît pas sur la page Gestion de la charge de travail dans vSphere Client sous vCenter > Gestion de la charge de travail > Superviseurs > Superviseur. vSphere Client continue d'afficher l'avertissement avec l'ancienne date d'expiration de la licence d'évaluation, même si la nouvelle clé de licence a été appliquée correctement.

    Solution : aucune. La nouvelle licence s'affiche correctement dans vSphere Client sous Administration > Licences > Ressources > Superviseurs.

  • La règle de stratégie de sécurité mise à jour dans la CRD de stratégie de sécurité ne prend pas effet si la règle ajoutée ou supprimée n'est pas la dernière

    En tant que DevOps, vous pouvez configurer la CRD de stratégie de sécurité pour appliquer une stratégie de sécurité basée sur NSX à un espace de noms de cluster superviseur. Lorsque vous mettez à jour la CRD et que vous ajoutez ou supprimez une règle de stratégie de sécurité, la règle mise à jour ne prend pas effet, sauf s'il s'agit de la dernière règle de la liste de règles.

    Solution : ajoutez la règle à la fin de la liste de règles ou utilisez une stratégie de sécurité distincte pour l'ajout ou la suppression de règles.

  • Les modifications apportées au format du nom de l'image de machine virtuelle dans vSphere 8.0 U2 peuvent entraîner des problèmes lorsque d'anciens noms d'image de machine virtuelle sont utilisés

    Avant vSphere 8.0 Update 2, le nom d'une ressource d'image de machine virtuelle était dérivé du nom d'un élément de bibliothèque de contenu. Par exemple, si un élément de bibliothèque de contenu était nommé photonos-5-x64, sa ressource VirtualMachineImage correspondante était également nommée photonos-5-x64. Cela entraînait des problèmes lorsque des éléments de bibliothèque de différentes bibliothèques portaient le même nom.

    Dans vSphere 8.0 Update 2, le service d'image de machine virtuelle a été introduit pour gérer les images de machine virtuelle en libre-service. Reportez-vous à la section Création et gestion des bibliothèques de contenu pour des machines virtuelles autonomes dans vSphere IaaS Control Plane.

    Cette nouvelle fonctionnalité permet d'associer des bibliothèques de contenu à un espace de noms ou à l'intégralité du cluster superviseur, et nécessite que les noms des ressources d'image de machine virtuelle dans les clusters Kubernetes soient uniques et déterministes. Par conséquent, pour éviter d'éventuels conflits avec les noms d'éléments de bibliothèque, les images de machine virtuelle suivent désormais le nouveau format d'attribution de nom vmi-xxx. Toutefois, cette modification peut entraîner des problèmes dans vSphere 8.0 Update 2 si vous utilisez des YAML de machine virtuelle précédents qui référencent d'anciens noms d'image, tels que photonos-5-x64 ou centos-stream-8.

    Solution :

    1. Utilisez les commandes suivantes pour récupérer des informations sur les images de machine virtuelle :

      • Pour afficher les images associées à leurs espaces de noms, exécutez kubectl get vmi -n <namespace>.

      • Pour extraire les images disponibles dans le cluster, exécutez kubectl get cvmi.

    2. Après avoir obtenu le nom de la ressource d'image répertorié sous la colonne NAME, mettez à jour le nom dans votre spécification de déploiement de machine virtuelle.

  • Lors d'une mise à niveau automatique du superviseur, le processus du service WCP sur vSphere peut déclencher une panique et s'arrêter de manière inattendue

    Vous pouvez remarquer un fichier de vidage de mémoire généré pour le processus du service WCP.

    Solution : aucune. Le processus VMON redémarre automatiquement le service WCP et le service WCP reprend la mise à niveau sans aucun autre problème.

  • La mise à niveau de superviseur s'interrompt et présente les états ErrImagePull et Échec du fournisseur dans les espaces vSphere. Il est possible que les volumes persistants attachés aux espaces vSphere (y compris les services de superviseur) ne puissent pas être détachés en cas d'échecs ErrImagePull.

    Les volumes persistants peuvent ne pas être détachés pour les espaces vSphere en échec avec ErrImagePull. Cela peut entraîner une cascade d'échecs d'espaces vSphere, car les volumes persistants requis sont attachés à l'instance défaillante. Lors de la mise à niveau du superviseur, les espaces vSphere se trouvant dans le superviseur peuvent passer à l'état provider failed et cesser de répondre.

    Solution : supprimez les instances des espaces vSphere en échec auxquels des volumes persistants sont attachés. Il est important de noter que les réclamations de volume persistant (Persistent Volume Claim, PVC) et les volumes persistants (PV) qui sont associés aux espaces vSphere peuvent être conservés. Après avoir terminé la mise à niveau, recréez les espaces vSphere à l'aide de la même PodSpecPVC pour maintenir l'intégrité des données et la fonctionnalité. Pour atténuer ce problème, créez des espaces vSphere à l'aide de ReplicaSets (DaemonSet, Deployment) pour maintenir un ensemble stable d'espaces de réplica vSphere en cours d'exécution à un moment donné.

  • La mise à niveau du superviseur est bloquée à 50 % et la mise à niveau de Pinniped échoue en raison de la sélection du leader

    Les espaces Pinniped sont bloqués dans l'état En attente lors du déploiement et la mise à niveau du superviseur échoue lors de la mise à niveau du composant Pinniped.

    Les étapes à suivre pour résoudre ce problème sont les suivantes :

    1. Exécutez kubectl get pods -n vmware-system-pinniped pour vérifier l'état des espaces Pinniped.

    2. Exécutez kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml pour vérifier que holderIdentity n'est pas l'un des espaces Pinniped dans l'état En attente.

    3. Exécutez kubectl delete leases -n vmware-system-pinniped pinniped-supervisor pour supprimer l'objet de bail pour le superviseur Pinniped dont l'espace inactif est holderIdentity.

    4. Exécutez de nouveau kubectl get pods -n vmware-system-pinniped pour vous assurer que tous les espaces sous vmware-system-pinniped sont actifs et en cours d'exécution.

  • Un nœud hôte ESXi ne peut pas passer en mode de maintenance lorsque la VM du plan de contrôle du superviseur est dans l'état sous tension

    Dans la configuration du superviseur avec NSX Advanced Load Balancer, l'hôte ESXi ne parvient pas à passer en mode de maintenance si la VM du moteur de service Avi est sous tension, ce qui a une incidence sur la mise à niveau d'hôte ESXi et de NSX en mode de maintenance.

    Solution : mettez hors tension la VM du moteur de service Avi afin qu'ESXi puisse passer en mode de maintenance.

  • Impossible de recevoir le trafic en boucle à l'aide de ClusterIP avec des espaces vSphere sur VDIS

    Si une application dans un espace vSphere tente d'atteindre une clusterIP servie dans le même espace vSphere (dans un autre conteneur), le DLB dans VSIP ne peut pas router le trafic vers l'espace vSphere.

    Solution : aucune.

  • Les stratégies réseau ne sont pas appliquées dans un superviseur basé sur VDS

    Le fichier YAML de service existant qui utilise NetworkPolicy ne nécessite aucune modification. La stratégie réseau ne sera pas appliquée si elle est présente dans le fichier.

    Solution : Vous devez définir des règles basées sur des stratégies sur la mise en réseau pour VDS. pour permettre la prise en charge de la stratégie réseau, la prise en charge de la mise en réseau NSX est requise.

  • L'espace de noms d'un service Carvel peut continuer à s'afficher dans vSphere Client après la désinstallation du service du superviseur

    Si la désinstallation du service Carvel prend plus de 20 minutes sur le superviseur, son espace de noms peut toujours s'afficher dans vSphere Client après la désinstallation du service.

    Les tentatives de réinstallation du service sur le même superviseur échouent jusqu'à ce que l'espace de noms soit supprimé. Le message ns_already_exist_error s'affiche lors de la réinstallation.

    L'entrée suivante s'affiche dans le fichier journal :

    /var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"

    Solution : supprimez manuellement l'espace de noms de vSphere Client.

    1. Dans le menu d'accueil de vSphere Client, sélectionnez Gestion de la charge de travail.

    2. Cliquez sur l'onglet Espaces de noms.

    3. Dans la liste des espaces de noms, sélectionnez l'espace de noms non effacé, puis cliquez sur le bouton SUPPRIMER pour le supprimer.

  • La mise à niveau des hôtes ESXi de la version 7.0 Update 3 vers la version 8.0 sans mise à niveau du superviseur fait que les hôtes ESXi apparaissent comme non prêts et que les charges de travail sont mises hors ligne

    Lorsque vous mettez à niveau les hôtes ESXi qui font partie d'un superviseur de vSphere 7.0 Update 3 vers vSphere 8.0 et que vous ne mettez pas à niveau la version de Kubernetes du superviseur, les hôtes ESXi s'affichent comme non prêts et les charges de travail s'exécutant sur les hôtes sont mises hors ligne.

    Solution : mettez à niveau la version de Kubernetes du superviseur vers la version 1.21, 1.22 ou 1.23 au minimum.

  • Lors de la mise à niveau en un clic de vCenter Server, le superviseur n'est pas mis à niveau automatiquement

    Si la version de Kubernetes du superviseur est antérieure à la version 1.22, lors de la mise à niveau en un clic du système vCenter Server vers la version 8.0, le superviseur ne peut pas effectuer la mise à niveau automatique vers la version minimale de Kubernetes prise en charge pour la version 8.0, à savoir 1.23.

    Solution : avant de mettre à niveau le système vCenter Server vers la version 8.0, mettez à niveau la version Kubernetes du superviseur vers la version 1.22. Si vous avez déjà mis à niveau le système vCenter Server vers la version 8.0, mettez manuellement à niveau la version Kubernetes du superviseur vers la version 1.23.

  • Si vous modifiez des règles dans une ressource personnalisée de stratégie de sécurité, les règles périmées peuvent ne pas être supprimées

    Ce problème peut se produire lorsque vous mettez à jour la stratégie de sécurité. Par exemple, vous créez une ressource personnalisée de stratégie de sécurité qui contient les règles A et B, puis vous mettez à jour la stratégie en modifiant les règles en B et C. En conséquence, la règle A n'est pas supprimée. Le plan de gestion de NSX continue d'afficher la règle A en plus des règles B et C.

    Solution : supprimez la stratégie de sécurité, puis recréez-la.

  • Après une mise à niveau de vCenter Server et de vSphere IaaS Control Plane, un cluster Tanzu Kubernetes Grid ne peut pas terminer sa mise à niveau en raison de volumes qui apparaissent comme attachés aux nœuds du cluster

    Lorsque la mise à niveau du cluster Tanzu Kubernetes Grid échoue, vous pouvez remarquer un volume qui s'affiche comme étant attaché aux nœuds du cluster et qui n'est pas effacé. Cela peut être dû à un problème dans Kubernetes en amont.

    Solution :

    1. obtenez des informations sur le nœud de cluster TKG sur lequel la planification est désactivée à l'aide de la commande suivante :

      kubectl get node tkc_node_name -o yaml

      Exemple :

      # kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

      Vérifiez si ce nœud dispose de volumes CSI vSphere dans la propriété status.volumeAttached. S'il existe des volumes, passez à l'étape suivante.

    2. Vérifiez qu'aucun espace n'est en cours d'exécution sur le nœud identifié à l'étape 1. Utilisez la commande suivante :

      kubectl get pod -o wide | grep tkc_node_name

      Exemple :

      kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      La sortie vide de cette commande indique qu'il n'y a pas d'espaces. Passez à l'étape suivante, car la sortie de l'étape 1 affiche un volume attaché au nœud qui ne dispose d'aucun espace.

    3. Obtenez des informations sur tous les objets de nœud pour vous assurer que le même volume est attaché à un autre nœud :

      kubectl get node -o yaml

      Exemple :

      Le même nom de volume s'affiche dans deux objets de nœud de cluster TKG.

      On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...

    4. Recherchez le PV en fonction du handle de volume dans le nom du volume.

      Dans l'exemple ci-dessus, le nom du volume est kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd et le handle de volume est 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd.

      Obtenez tous les PV et recherchez le handle de volume ci-dessus à l'aide de la commande suivante :

      kubectl get pv -o yaml

      Dans l'exemple ci-dessus, le PV avec ce handle de volume est pvc-59c73cea-4b75-407d-8207-21a9a25f72fd.

    5. Utilisez la commande volumeattachment pour rechercher le PV trouvé à l'étape précédente :

      kubectl get volumeattachment | grep pv_name

      Exemple :

      # kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

      Vous pouvez observer une pièce jointe de volume attachée à un nœud gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 au lieu de nœud gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95. Cela indique que status.volumeAttached dans gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 est incorrect.

    6. Supprimez l'entrée volumeAttached de l'objet de nœud :

      kubectl edit node tkc_node_name

      Exemple :

      kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      Supprimez l'entrée de volume périmé de status.volumeAttached.

    7. Répétez les étapes ci-dessus pour tous les volumes périmés de la propriété status.volumeAttached.

    8. Si WCPMachines existe toujours, supprimez-le manuellement et attendez quelques minutes pour rapprocher le cluster.

      # kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

  • Si un administrateur vSphere configure un modèle d'espace de noms en libre-service avec des limites de ressources qui dépassent la capacité du cluster, aucune alerte n'est déclenchée.

    Lorsque les administrateurs vSphere configurent des limites de ressources qui dépassent la capacité du cluster, les ingénieurs DevOps peuvent utiliser le modèle pour déployer des espaces vSphere avec des ressources élevées. En conséquence, les charges de travail peuvent échouer.

    Solution : aucune.

  • Lorsque vous supprimez un espace de noms de superviseur qui contient un cluster Tanzu Kubernetes Grid, les réclamations de volume persistant présentes dans le superviseur peuvent rester à l'état Arrêt en cours

    Vous pouvez observer ce problème lorsqu'un conflit de ressources se produit pendant que le système supprime l'espace de noms et détache les volumes des espaces du cluster Tanzu Kubernetes Grid.

    La suppression de l'espace de noms de superviseur reste incomplète et vSphere Client indique l'état de l'espace de noms comme étant Arrêt en cours. Les réclamations de volumes persistants qui étaient attachés à des espaces dans le cluster Tanzu Kubernetes Grid restent également à l'état Arrêt en cours.

    Si vous exécutez les commandes suivantes, l'erreur Operation cannot be fulfilled on persistentvolumeclaims peut s'afficher :

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

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

    failed to update PersistentVolumeClaim: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\". Error: Operation cannot be fulfilled on persistentvolumeclaims \\\"<pvc-name>\\\": the object has been modified; please apply your changes to the latest version and try again\

    Solution :

    utilisez les commandes suivantes pour résoudre le problème :

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

    kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

  • Lors de la suppression de plusieurs FCD et volumes de banques de données partagées comme vSAN, vous pouvez remarquer 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.

  • Si un utilisateur DevOps démarre des opérations de volume ou des déploiements d'applications avec état lors du redémarrage de vCenter Server, les opérations peuvent échouer

    Le problème se produit, car le compte d'utilisateur de gestion du stockage de la charge de travail est verrouillé et le plug-in CSI vSphere qui s'exécute sur le superviseur ne parvient pas à s'authentifier. Par conséquent, les opérations de volume échouent avec des erreurs InvalidLogin.

    Le fichier journal /var/log/vmware/vpxd/vpxd.log affiche le message suivant :

    Authentication failed: The account of the user trying to authenticate is locked. :: The account of the user trying to authenticate is locked. :: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})

    Solution :

    1. obtenez le délai de déverrouillage du compte.

      1. Dans vSphere Client, accédez à Administration, puis cliquez sur Configuration sous Single Sign On.

      2. Cliquez sur l'onglet Sélectionner les comptes.

      3. Sous Stratégie de verrouillage, obtenez le délai de déverrouillage en secondes.

    2. Authentifiez-vous auprès du superviseur à l'aide du plug-in vSphere pour kubectl.

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

    3. Notez le nombre de réplicas d'origine pour le déploiement de vsphere-csi-controller dans l'espace de noms vmware-system-csi.

      kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'

      original-replica-count

    4. Réduisez le nombre de réplicas de déploiement vsphere-csi-controller à zéro.

      kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi

    5. Attendez le nombre de secondes indiqué sous Délai de déverrouillage.

    6. Augmentez le nombre de réplicas de déploiement vsphere-csi-controller jusqu'à la valeur d'origine.

      kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

Problèmes connus de TKG sur le superviseur

  • Lorsque vous mettez à niveau votre environnement vSphere IaaS Control Plane 7.0.x vers vSphere 8.0.x, tous les clusters TKG v1.27.6 deviennent incompatibles

    vSphere 8.0.x ne prend pas en charge TKR 1.27.6.

    Par conséquent, les clusters TKG v1.27.6 deviennent incompatibles après la mise à niveau de vSphere IaaS Control Plane 7.0.x vers vSphere 8.0.x. Vous ne recevrez aucun avertissement de vérification préalable lors de la mise à niveau du superviseur.

    Solution :

  • La mise sous tension des nœuds worker du cluster TKG échoue avec l'erreur VIF restore activity already completed for attachment ID dans le journal à partir de l'espace nsx-ncp

    La mise sous tension des nœuds worker du cluster TKG échoue avec l'erreur suivante :

    nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

    NCP enregistre une erreur :

    VIF restore activity already completed for attachment ID

    Lorsqu'une machine virtuelle d'un nœud de cluster TKG créée après une sauvegarde de NSX migre avec vMotion immédiatement après la restauration de NSX, NCP ne peut pas restaurer le port de la machine virtuelle, car l'ID d'attachement est réutilisé dans vMotion et bloque la demande de restauration de NCP.

    Solution :

    1. Accédez à NSX Manager pour obtenir les ports de segment qui doivent être supprimés. Ils ont un nom d'affichage au format <vm name>.vmx@<attachment id>

    2. Avant de supprimer le port récemment créé, recherchez l'hôte sur lequel la machine virtuelle s'exécute et désactivez ops-agent en exécutant /etc/init.d/nsx-opsagent stop sur l'hôte.

    3. Supprimez le port à l'aide de NSX API https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true

    4. Activez ops-agent en exécutant /etc/init.d/nsx-opsagent start sur l'hôte.

    5. Attendez que NCP restaure le port.

  • Les espaces, les PV et les PVC d'un cluster TKG peuvent être bloqués dans un état Terminating lors du nettoyage du cluster TKG ou lors de la récupération à partir d'une interruption de service des hôtes ESXi

    Dans le cadre du processus normal de suppression et de nettoyage du cluster TKG, tous les déploiements, les Statefulsets, les PVC, les PV et les objets similaires sont supprimés. Toutefois, pour les clusters TKG basés sur TKR v1.24 et versions antérieures, certains PV peuvent être bloqués dans un état Terminating en raison d'erreurs DetachVolume. Ce problème se produit lorsque des erreurs DetachVolume sur un objet VolumeAttachment entraînent la non-suppression des finaliseurs sur VolumeAttachment, ce qui entraîne l'échec de la suppression des objets associés. Ce scénario peut également se produire en cas d'interruption de service dans les hôtes ESXi.

    Solution : exécutez la commande suivante dans le cluster TKG pour supprimer les finaliseurs des VolumeAttachment avec une erreur detachError :

    kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments

  • Cluster TGK inaccessible après la sauvegarde et la restauration

    Si un espace de noms vSphere est créé après une sauvegarde NSX et configuré avec un CIDR d'entrée/sortie personnalisé, une fois NSX restauré à partir d'une sauvegarde, NCP ne parvient pas à terminer le processus de restauration et les clusters TKG sur l'espace de noms vSphere ne sont pas disponibles. NCP échoue pendant le processus de restauration avec une erreur telle que la suivante :

    NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

    Solution : si une sauvegarde du superviseur a été effectuée à peu près en même temps que la sauvegarde NSX, mais avant la création de l'espace de noms vSphere affecté, restaurez également le superviseur à partir de la sauvegarde. Vous pouvez également supprimer l'espace de noms vSphere et les clusters TKG associés, attendre que NCP se resynchronise, puis recréer les ressources supprimées.

  • Cluster TKG inaccessible après la sauvegarde et la restauration NSX

    Lorsqu'un superviseur est configuré avec un CIDR d'entrée personnalisé, après une restauration de sauvegarde NSX, les clusters TKG peuvent devenir indisponibles, car le composant NCP ne peut pas valider correctement l'adresse IP virtuelle d'entrée des clusters TKG.

    Solution : à l'aide de NSX API, configurez manuellement des adresses IP virtuelles pour les clusters TKG dans NSX pour restaurer l'accès.

  • Impossible de mettre à niveau les clusters Tanzu Kubernetes Grid existants configurés avec un serveur proxy vers un superviseur vSphere 8

    RÉSOLU : Ce problème connu est résolu dans la version vSphere 8 with Tanzu MP1.

    Si vous avez configuré un cluster Tanzu Kubernetes Grid existant avec un serveur proxy, vous ne pouvez pas mettre à niveau ce cluster d'un superviseur vSphere 7 vers Tanzu Kubernetes Grid 2.0 sur un superviseur vSphere 8.

    Solution : le contenu du champ noProxy est en conflit avec les vérifications de mise à niveau. Étant donné que ce champ est requis si la section proxy est ajoutée à la spécification du cluster, vous devez supprimer la configuration du proxy dans son intégralité avant d'effectuer la mise à niveau vers vSphere 8.

  • Blocage de l'espace antrea-resource-init sur l'état En attente

    Après la mise à niveau de la version de Tanzu Kubernetes d'un cluster Tanzu Kubernetes Grid, l'espace antrea-resource-init peut être à l'état En attente.

    Solution : redémarrez l'espace sur le superviseur.

  • Les clusters Tanzu Kubernetes Grid v1.21.6 peuvent passer à l'état FALSE et certaines machines peuvent ne pas migrer

    Après la mise à niveau vers vCenter Server 8 et la mise à jour du superviseur, les clusters Tanzu Kubernetes Grid v1.21.6 peuvent passer à l'état FALSE et certaines wcpmachines peuvent ne pas migrer vers des vspheremachines.

    Solution : aucune

  • Par défaut, le mot de passe du compte vmware-system-user expire dans 60 jours pour les clusters TKG exécutant TKR version 1.23.8---vmware.2-tkg.2-zshippable

    Dans le cadre de la sécurisation renforcée STIG pour les clusters TKR version 1.23.8--vmware.2-tkg.2-zshippable, le compte vmware-system-user est configuré pour expirer dans 60 jours. Cela peut avoir une incidence sur les utilisateurs qui utilisent le compte vmware-system-user pour se connecter par SSH aux nœuds de cluster.

    Reportez-vous à l'article de la base de connaissances suivant pour mettre à jour l'expiration du mot de passe de vmware-system-user et autoriser les sessions SSH sur les nœuds de cluster TKG si nécessaire : https://kb.vmware.com/s/article/90469.

  • L'espace tanzu-capabilities-controller-manager redémarre en permanence et accède à CLBO sur le cluster TKC dans vSphere IaaS Control Plane 8.0.0a

    Suite à des problèmes d'autorisation de compte de service, l'espace tanzu-capabilities-controller-manager sur le cluster TKG sera bloqué dans un CLBO (retour en boucle d'écran d'incident désactivé) lors de l'utilisation de TKR version 1.23.8+vmware.2-tkg.2-zshippable.

    Solution : ajoutez les autorisations requises au compte de service de capacités tanzu-capabilities-manager-sa sur le cluster TKC.

    1. Suspendre le rapprochement du module de capacités sur le cluster TKC :

      kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

    2. Créez un fichier capabilities-rbac-patch.yaml :

      apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

    3. Corrigez le rôle de cluster de capacités sur l'instance du cluster TKC :

      //Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

    4. Supprimez tanzu-capabilities-controller-manager sur le cluster TKC.

  • Les clusters Tanzu Kubernetes Grid 2.0 sur un superviseur déployé sur trois zones vSphere ne prennent pas en charge les machines virtuelles avec vGPU et stockage d'instances.

    Les clusters Tanzu Kubernetes Grid 2.0 provisionnés sur une instance de superviseur déployée sur trois zones vSphere ne prennent pas en charge les machines virtuelles avec vGPU et stockage d'instances.

    Solution : aucune

  • TKR version 1.22.9 est répertorié dans l'image de bibliothèque de contenu, mais pas dans la commande kubectl

    La bibliothèque de contenu pour les images TKR répertorie TKR v1.22.9. La commande kubectl get tkr ne répertorie pas cette image comme étant disponible, car TKR v1.22.9 n'est pas disponible et ne doit pas être utilisé. Cette image s'affiche dans la bibliothèque de contenu par erreur.

    Solution : Utilisez un autre TKR que TKR v1.22.9. Reportez-vous aux Notes de mise à jour de TKR pour obtenir la liste des TKR disponibles.

  • Impossible de provisionner une instance de TKC à l'aide de l'API v1alpha1 et d'un TKR v1.23.8 dans vSphere IaaS Control Plane 8.0.0a

    Lors de l'utilisation de l'API TKC v1alpha1 pour provisionner TKC avec la version 1.23.8. La demande échoue avec l'option « Impossible de trouver une version complète compatible correspondant à la version 1.23.8 conseillée » et aux étiquettes de système d'exploitation par défaut : « os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0 ».

    Solution : Basculer vers les API TKC v1alpha2 ou v1alpha3 lors du provisionnement des instances de TKC

  • Les clusters Tanzu Kubernetes Grid 2.0 provisionnés avec l'API v1beta1 doivent être basés sur la ClusterClass par défaut

    Si vous créez un cluster Tanzu Kubernetes Grid 2.0 sur le superviseur à l'aide de l'API v1beta1, le cluster doit être basé sur la ClusterClass tanzukubernetescluster par défaut. Le système n'effectue pas le rapprochement d'un cluster basé sur une ClusterClass différente.

    Solution : À partir de la version vSphere 8 U1, vous pouvez provisionner un cluster v1beta1 reposant sur une ClusterClass personnalisée. Reportez-vous à l'article de la base de connaissances https://kb.vmware.com/s/article/91826.

Problèmes connus de la mise en réseau

  • Dans une configuration NSX Advanced Load Balancer, il n'existe aucune section usage.ingressCIDRUsage dans la sortie clusternetworkinfo ou namespacenetworkinfo

    Dans une configuration NSX Advanced Load Balancer, l'adresse IP d'entrée est allouée par le contrôleur Avi. L'utilisation d'ingressCIDR ne s'affiche pas dans la sortie clusternetworkinfo ou namespacenetworkinfo.

    Solution : obtenez l'utilisation d'ingressCIDR à partir de l'interface utilisateur du contrôleur Avi dans Applications > VIP VS

  • Le CIDR d'espace sur la liste de préfixes de niveau 0 n'est pas supprimé après la suppression de l'espace de noms pour un superviseur routé

    Dans le superviseur routé, le CIDR d'espace dans une liste de préfixes de niveau 0 n'est pas supprimé après la suppression de l'espace de noms.

    Solution : supprimez l'objet prefix-lists :

    curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json

  • Les ressources Kubernetes clusternetworkinfo et namespacenetworkinfo ne contiennent pas usage.ingressCIDRUsage lors de l'utilisation de NSX Advanced Load Balancer.

    Lorsque vous utilisez NSX Advanced Load Balancer dans un superviseur basé sur NSX, les ressources Kubernetes clusternetworkinfo et namespacenetworkinfo ne contiennent plus les champs usage.ingressCIDRUsage. Cela signifie que l'exécution de kubectl get clusternetworkinfo <supervisor-cluster-name> -o json ou de kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json ne contiendra pas l'objet d'utilisation ingressCIDR dans la sortie.

    Solution : utilisez la page de l'interface utilisateur du contrôleur Avi pour accéder à l'objet ingressCIDR.

  • Il existe des segments de niveau 1 périmés pour certains espaces de noms après la sauvegarde et la restauration NSX

    Après une procédure de sauvegarde et de restauration NSX, les segments de niveau 1 périmés qui disposent de cartes réseau du moteur de service ne sont pas nettoyés.

    Lorsqu'un espace de noms est supprimé après une sauvegarde NSX, l'opération de restauration restaure les segments de niveau 1 périmés associés aux cartes réseau du moteur de service NSX Advanced Load Balancer Controller.

    Solution : supprimez manuellement les segments de niveau 1.

    1. Connectez-vous à NSX Manager.

    2. Sélectionnez Mise en réseau > Segments.

    3. Recherchez les segments périmés associés à l'espace de noms supprimé.

    4. Supprimez les cartes réseau du moteur de service périmées de la section Ports/Interfaces.

  • Le moniteur d'équilibrage de charge peut cesser de fonctionner et le superviseur peut se bloquer dans l'état « configuration » dans vSphere Client

    Si NSX Advanced Load Balancer est activé, en raison de la présence de plusieurs points d'application dans NSX, NCP peut ne pas parvenir à extraire l'état de l'équilibreur de charge. Cela affecte les superviseurs existants configurés avec NSX Advanced Load Balancer une fois qu'il est activé sur NSX. Ce problème affecte les nouveaux superviseurs tirant parti de NSX Advanced Load Balancer. Les superviseurs affectés par ce problème seront toujours fonctionnels, à l'exception de la capacité de surveillance de l'équilibreur de charge.

    Solution : Désactivez NSX Advanced Load Balancer dans NSX. Cela peut limiter la capacité de déploiement de superviseurs avec NSX Advanced Load Balancer dans des environnements WCP avec des superviseurs existants exécutant NSX Advanced Load Balancer.

  • 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 IaaS Control Plane, car seule l'option Cloud par défaut est 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.

Problèmes connus du stockage

  • Plusieurs erreurs de synchronisation de volume CNS sont observées dans un environnement dans lequel une banque de données est partagée entre les systèmes vCenter

    La migration entre instances de vCenter n'est pas prise en charge par CNS. Toutefois, la synchronisation périodique CNS est effectuée automatiquement et crée une contention de verrouillage pour les volumes sur la banque de données partagée.

    Solution : pour éviter ce problème, configurez un intervalle de temps important pour la synchronisation périodique CNS.

    1. Localisez le fichier de configuration de CNS dans vCenter :

      /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml

    2. Accédez à la ligne suivante :

      <newSyncInterval>60</newSyncInterval>

      Par défaut, la synchronisation périodique est définie sur 60 secondes.

    3. Remplacez cette valeur par une période plus longue. Par exemple, 31536000 pour 1 an.

  • Le type d'allocation de volume ne peut pas être modifié pour les disques d'une banque de données vSAN Direct

    Une fois que vous avez décidé du type d'allocation de volume pour les disques dans la banque de données vSAN Direct, vous ne pouvez pas le modifier. Cela est dû au fait que les couches sous-jacentes ne prennent pas en charge la conversion de type. Toutefois, la modification du type d'allocation de volume pour le nouveau disque est autorisée pour des opérations telles que le clonage et le déplacement.

    Solution : aucune

  • La VM supprimée bloque des tâches de stockage cloud natif dans l'état Mis en file d'attente

    Les opérations envoyées au stockage cloud natif renvoient un ID de tâche, mais l'état de la tâche reste Mis en file d'attente. Les tâches s'adressent aux volumes attachés à une machine virtuelle qui vient d'être supprimée.

    Solution : si la couche d'application peut corriger l'ordre d'appel, aucune mesure n'est à prendre côté stockage cloud natif. Si ce n'est pas le cas, désactivez la nouvelle sérialisation du stockage cloud natif en procédant comme suit :

    1. Ouvrez /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml sur vCenter.

    2. Modifiez la configuration suivante sur False : <newSerializationEnabled>true</newSerializationEnabled>

    3. Redémarrez vsan-health avec vmon-cli -r vsan-health

    Pour plus d'informations, reportez-vous à l'article 93903 de la base de connaissances.

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

    Solution :

    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>

    Note:

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

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