Notes de mise à jour de VMware Tanzu Kubernetes Grid v2.3

Sauf indication contraire, ces notes de mise à jour s'appliquent à toutes les versions de correctifs v2.3.x de Tanzu Kubernetes Grid (TKG).

TKG v2.3 est distribué sous la forme d'un module de la CLI Tanzu téléchargeable qui déploie un cluster de gestion autonome TKG avec version. TKG v2.3 prend en charge la création et la gestion de clusters de charge de travail basés sur une classe, avec un cluster de gestion autonome pouvant s'exécuter sur plusieurs infrastructures, notamment vSphere, AWS et Azure.

Tanzu Kubernetes Grid v2.x et le superviseur vSphere with Tanzu dans vSphere 8

Important

Le superviseur vSphere with Tanzu dans vSphere 8.0.1c et versions ultérieures exécute TKG v2.2. Les versions antérieures de vSphere 8 exécutent TKG v2.0, qui n'a pas été publié indépendamment du superviseur. Les clusters de gestion autonomes qui exécutent TKG 2.x sont disponibles à partir de TKG 2.1 et versions ultérieures. En raison de la version antérieure de TKG intégrée au superviseur, certaines fonctionnalités qui sont disponibles si vous utilisez un cluster de gestion TKG 2.3 autonome ne le sont pas si vous utilisez un superviseur vSphere with Tanzu pour créer des clusters de charge de travail. Les versions ultérieures de TKG seront intégrées dans le superviseur dans les futures versions de mise à jour vSphere. Par conséquent, la version de TKG intégrée à la dernière version de vSphere with Tanzu à un moment donné peut ne pas être aussi récente que la dernière version autonome de TKG. Toutefois, les versions de la CLI Tanzu compatibles avec toutes les versions de TKG v2.x sont entièrement compatibles avec le superviseur dans toutes les versions de vSphere 8. Par exemple, la CLI Tanzu v1.0.0 est entièrement rétrocompatible avec les plug-ins TKG 2.2 que le superviseur fournit.

CLI Tanzu et vSphere with Tanzu dans vSphere 7

Les versions de la CLI Tanzu compatibles avec TKG 2.x et disposant du superviseur vSphere with Tanzu dans vSphere 8 ne sont pas compatibles avec le cluster superviseur dans vSphere 7. Pour utiliser la CLI Tanzu avec un cluster superviseur vSphere with Tanzu sur vSphere 7, utilisez la version de la CLI Tanzu de TKG v1.6. Pour utiliser les versions de la CLI Tanzu compatibles avec TKG 2.x et un superviseur, effectuez une mise à niveau vers vSphere 8. Vous pouvez déployer un cluster de gestion TKG 2.x autonome sur vSphere 7 si aucun cluster superviseur vSphere with Tanzu n'est présent. Pour plus d'informations sur la compatibilité entre la CLI Tanzu et les produits VMware, reportez-vous à la documentation de la CLI Tanzu.

Nouveautés

Tanzu Kubernetes Grid v2.3.x inclut les nouvelles fonctionnalités suivantes.

Tanzu Kubernetes Grid v2.3.1

Nouvelles fonctionnalités de Tanzu Kubernetes Grid v2.3.1 :

• Prend en charge Kubernetes 1.26.8, 1.25.13 et 1.24.17 ; reportez-vous à la section versions de Kubernetes prises en charge
• (vSphere) Lorsque vous mettez à niveau un cluster de gestion ou de charge de travail autonome, vous pouvez spécifier un modèle OVA cible à l'aide de l'option --vsphere-vm-template-name comme décrit dans la section Sélectionner un modèle OVA vers lequel effectuer la mise à niveau.
• Composants mis à jour ; reportez-vous à la section Versions des composants
  • La dernière version compatible du référentiel Tanzu Standard est v2023.10.16, qui dispose de ses propres notes de mise à jour distinctes dans la documentation des modules Tanzu ; reportez-vous aux Notes de mise à jour du référentiel Tanzu Standard v2023.10.16
• Résolutions des bugs

Tanzu Kubernetes Grid v2.3.0

Nouvelles fonctionnalités de Tanzu Kubernetes Grid v2.3.0 :

• Nouveau mécanisme de distribution pour les plug-ins autonomes de la CLI Tanzu, y compris les plug-ins autonomes de la CLI Tanzu pour Tanzu Kubernetes Grid. En outre, la CLI Tanzu principale est désormais distribuée séparément de Tanzu Kubernetes Grid. Pour obtenir des instructions sur l'installation de la CLI Tanzu à utiliser avec Tanzu Kubernetes Grid, reportez-vous à la section Installer la CLI Tanzu et la CLI Kubernetes à utiliser avec des clusters de gestion autonomes.
• Le référentiel de modules Tanzu Standard est utilisé avec version et est distribué séparément de TKG. Reportez-vous la section Référentiel Tanzu Standard v2023.7.13 ci-dessous.
  • La dernière version compatible du référentiel Tanzu Standard pour TKG v2.3.0 est le référentiel Tanzu Standard v2023.7.13.
• Vous pouvez exécuter des clusters de charge de travail et de gestion autonomes sur plusieurs zones de disponibilité (AZ) et modifier ces dernières dans lesquelles leurs nœuds s'exécutent.
  • Pour savoir comment déployer de nouveaux clusters de charge de travail sur plusieurs zones de disponibilité et modifier les clusters de gestion et de charge de travail existants pour qu'ils s'exécutent dans plusieurs zones de disponibilité ou dans différentes zones de disponibilité, reportez-vous à la section Exécution de clusters sur plusieurs zones de disponibilité.
  • Pour utiliser l'interface du programme d'installation afin de configurer un nouveau cluster de gestion autonome afin qu'il s'exécute sur plusieurs zones de disponibilité, reportez-vous à la section Configurer les ressources vSphere.
  • La prise en charge de plusieurs zones de disponibilité est dans l'état de la fonctionnalité Stable.
• Les clusters à nœud unique peuvent être mis à niveau et sont pris en charge pour Telco Cloud Automation (TCA). Reportez-vous à la section Clusters à nœud unique sur vSphere.
  • La procédure de déploiement simplifiée ne nécessite pas l'ajout de TKr tiny au cluster de gestion.
  • Vous ne pouvez pas utiliser Tanzu Mission Control (TMC) pour créer et gérer des clusters à nœud unique, mais cette capacité est prévue pour une future version de TMC.
• Vous pouvez configurer un contrôleur d'admission de sécurité des espaces (PSA) à l'échelle du cluster avec de nouvelles variables du fichier de configuration de cluster POD_SECURITY_STANDARD_*, et les paramètres Cluster et podSecurityStandard de spécification, comme décrit dans la section Contrôleur d'admission de la sécurité des espaces.
  • La prise en charge de PSA est dans l'état de la fonctionnalité Stable.
• (vSphere) Capacités de gestion des adresses IP (IPAM) dans le cluster, reportez-vous à la section IPAM de nœud.
  • IPAM pour les clusters de gestion autonomes, en plus des clusters de charge de travail basés sur une classe.
  • Prise en charge d'IPv6.
  • Les clusters de charge de travail dans différents espaces de noms de gestion peuvent allouer des adresses IP à partir du même pool d'adresses IP global.
  • Les pools d'adresses IP peuvent contenir des plages d'adresses IP non contiguës.
  • La requête de pool d'adresses IP kubectl get inclusterippool génère des nombres d'adresses FREE et USED.
  • Variables de configuration de cluster, décrites dans IPAM de nœud dans la Référence de variable de fichier de configuration.
  • La structure d'objets InClusterIPPool diffère des versions précédentes de TKG. La mise à niveau du cluster vers la version v2.3 convertit les pools d'adresses IP en nouvelle structure.
• Les clusters qui utilisent la CNI Calico effectuent la détection d'adresses IP. Reportez-vous à la section CNI Calico du document Mise en réseau des espaces et des conteneurs.
• Les clusters de charge de travail Edge avec un stockage isolé peuvent utiliser leurs propres modèles de VM stockés localement. Reportez-vous à la section Spécification d'un modèle de VM local.
• Une nouvelle variable de fichier de configuration de cluster VSPHERE_MTU définit la taille de l'unité de transmission maximale (MTU) pour les nœuds de cluster de gestion et de charge de travail sur un commutateur vSphere. Reportez-vous à la section Configurer la MTU du nœud de cluster.
• Vous pouvez configurer des clusters pour qu'ils utilisent d'autres images de machine en annotant leurs spécifications d'objet, et sans créer ou modifier des TKr. Reportez-vous à la section Utiliser une autre image de machine.
• (vSphere) CONTROL_PLANE_NODE_NAMESERVERS et WORKER_NODE_NAMESERVERS sont désormais dans l'état Stable. Vous pouvez définir ces variables pour les nœuds s'exécutant sur Ubuntu ou Photon. Windows n'est pas pris en charge. Pour obtenir un exemple de cas d'utilisation, reportez-vous à la section IPAM de nœud.
• Vous pouvez désormais mettre à niveau les clusters que vous avez créés à partir d'une définition ClusterClass personnalisée dans une version précédente. Pour plus d'informations, reportez-vous à la section Mettre à niveau les clusters personnalisés.
• Nouveaux indicateurs pour les contrôles de santé des machines, --max-unhealthy et --machine-deployment. Reportez-vous à la section Gérer les contrôles de santé des machines pour les clusters de charge de travail.
• La nouvelle option tanzu mc credentials update --vsphere-thumbprint permet d'utiliser la CLI Tanzu pour mettre à jour l'empreinte numérique TLS de vCenter Server dans les clusters de gestion et les clusters de charge de travail sur vSphere. Reportez-vous à la section Mettre à jour les informations d'identification du cluster.
• Le référentiel de modules Tanzu Standard n'est pas ajouté par défaut aux clusters récemment créés basés sur un plan.

• Le composant Pinniped n'utilise plus Dex pour les fournisseurs d'identité LDAP, ce qui entraîne les modifications de configuration suivantes :

  • Nouvelle variable de configuration : LDAP_GROUP_SEARCH_SKIP_ON_REFRESH
  • Variables de configuration mises à jour :
  • Les variables LDAP_BIND_DN et LDAP_BIND_PASSWORD sont désormais requises.
  • La variable LDAP_GROUP_SEARCH_NAME_ATTRIBUTE est définie par défaut sur dn.
  • Les variables LDAP_USER_SEARCH_FILTER et LDAP_GROUP_SEARCH_FILTER doivent être définies au format utilisé par Pinniped.
  • Variables de configuration supprimées : LDAP_USER_SEARCH_USERNAME, LDAP_USER_SEARCH_EMAIL_ATTRIBUTE et LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE.

  La suppression de Dex implique la modification des paramètres LDAP d'un cluster de gestion avant de le mettre à niveau vers TKG v2.3. Reportez-vous à la section (LDAP uniquement) Mettre à jour les paramètres LDAP.
  Pour plus d'informations sur les nouvelles variables de configuration et celles qui sont mises à jour, reportez-vous à la section Fournisseurs d'identité - LDAP du document Référence de variable de fichier de configuration.

• Étant donné que le référentiel de modules Tanzu Standard est distribué séparément de TKG, le fichier de nomenclature TKG ne répertorie plus une image de conteneur grafana. D'autres composants Tanzu Standard sont prévus pour la suppression de la nomenclature dans une version ultérieure.
  • Pour obtenir la liste des composants distribués via le référentiel de modules Tanzu Standard, consultez les Notes de mise à jour du référentiel Tanzu Standard v2023.10.16 dans la documentation des modules Tanzu ou dans la section référentiel Tanzu Standard v2023.7.13 ci-dessous.

Référentiel Tanzu Standard

Avec TKG v2.3, le référentiel de modules Tanzu Standard est utilisé avec version et distribué séparément de TKG, et son contrôle de version est basé sur un horodatage. Pour plus d'informations, reportez-vous à référentiel Tanzu Standard v2023.7.13 ci-dessous.

Pour chaque version de correctif TKG v2.3, les notes de mise à jour de sa dernière version de référentiel Tanzu Standard compatible sont les suivantes :

• TKG v2.3.1 : notes de mise à jour du référentiel Tanzu Standard v2023.10.16 dans la documentation des modules Tanzu
• TKG v2.3.0 : section référentiel Tanzu Standard v2023.7.13, ci-dessous

Versions de Kubernetes, de TKG et de modules prises en charge

À partir de TKG v2.2, la stratégie de prise en charge de VMware a changé pour les anciennes versions de correctifs de TKG et les TKr qui intègrent les versions de Kubernetes pour TKG. Les stratégies de prise en charge de TKG v2.1 et les versions mineures antérieures de TKG ne changent pas.

Les deux premières sections ci-dessous résument la prise en charge de toutes les versions actuellement compatibles de TKG et des TKr sous les stratégies de prise en charge qui s'appliquent à chacune d'elles.

La troisième section ci-dessous répertorie les versions des modules dans le référentiel Tanzu Standard qui sont prises en charge par les TKr Kubernetes v1.26, v1.25 et v1.24.

Versions de Kubernetes prises en charge

Chaque version de Tanzu Kubernetes Grid ajoute la prise en charge de la version Kubernetes de son cluster de gestion, ainsi que des versions supplémentaires de Kubernetes distribuées en tant que versions de Tanzu Kubernetes (TKr), sauf indication contraire comme Problème connu.

Versions mineures : VMware prend en charge TKG v2.3 avec Kubernetes v1.26, v1.25 et v1.24 au moment de la publication. Une fois que TKG v2.1 atteint sa date de fin de support général, VMware ne prend plus en charge Kubernetes v1.24 avec TKG. Une fois que TKG v2.2 atteint sa date de fin de support général, VMware ne prend plus en charge Kubernetes v1.25 avec TKG.

Versions de correctifs : Lorsque VMware publie une nouvelle version de correctif TKr pour une gamme mineure, il conserve la prise en charge des versions de correctifs plus anciennes pendant deux mois. Cela donne aux clients un délai de 2 mois pour effectuer une mise à niveau vers les nouvelles versions de correctifs de TKr. À partir de TKG v2.2 et versions ultérieures, VMware ne prend plus en charge toutes les versions de correctifs TKr des gammes mineures précédentes de Kubernetes.

Les versions de correctifs Tanzu Kubernetes Grid prennent en charge les versions de correctifs TKr ou les prenaient en charge, comme indiqué ci-dessous.

Version de Tanzu Kubernetes Grid	Version Kubernetes du cluster de gestion	Versions de Kubernetes (TKr) fournies
2.3.1	1.26.8	1.26.8, 1.25.13, 1.24.17
2.3.0	1.26.5	1.26.5, 1.25.10, 1.24.14
2.2.0	1.25.7	1.25.7, 1.24.11, 1.23.17
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17

Versions de Tanzu Kubernetes Grid prises en charge

VMware prend en charge les versions de TKG comme suit :

Versions mineures : VMware prend en charge TKG conformément à la Stratégie de cycle de vie N-2, qui s'applique aux deux versions mineures (la plus récente et la précédente) de TKG. Pour plus d'informations, reportez-vous à la Matrice de cycle de vie des produits VMware.

Versions de correctifs : VMware ne prend pas en charge toutes les versions de correctifs TKG précédentes. Lorsque VMware publie une nouvelle version de correctif de TKG, il conserve la prise en charge de la version de correctif antérieure pendant deux mois. Cela donne aux clients un délai de 2 mois pour effectuer une mise à niveau vers les nouvelles versions de correctifs de TKG.

• Par exemple, la prise en charge de TKG v2.3.0 se terminera deux mois après la disponibilité générale de TKG v2.3.1.

Versions de modules prises en charge

Pour TKG v2.3, les versions de modules dans le référentiel Tanzu Standard sont compatibles avec les TKr pour les versions mineures de Kubernetes v1.26, v1.25 et v1.24 comme suit :

Module	Version du module	TKr Kubernetes v1.26	TKr Kubernetes v1.25	TKr Kubernetes v1.24
Gestionnaire de certificats cert-manager.tanzu.vmware.com	1.11.1+vmware.1-tkg.1-20230629	✔	✔	✔
Contour contour.tanzu.vmware.com	1.24.4+vmware.1-tkg.1-20230629	✔	✔	✔
DNS externe external-dns.tanzu.vmware.com	0.13.4+vmware.2-tkg.1-20230629	✔	✔	✔
	0.12.2+vmware.5-tkg.2-20230629	✔	✔	✔
	0.11.1+vmware.5-tkg.2-20230629	✖	✖	✔
Fluent Bit fluent-bit.tanzu.vmware.com	2.1.2+vmware.1-tkg.1-20230629	✔	✔	✔
	1.9.5+vmware.1-tkg.3-zshippable	✔	✔	✔
	1.8.15+vmware.1-tkg.1	✖	✖	✔
Contrôleur d'aide FluxCD fluxcd-helm-controller.tanzu.vmware.com	0.32.0+vmware.1-tkg.2-20230629	✔	✔	✔
	0.21.0+vmware.1-tkg.1-zshippable	✖	✖	✔
Contrôleur source FluxCD fluxcd-source-controller.tanzu.vmware.com	0.33.0+vmware.2-tkg.1-20230629	✔	✔	✔
Grafana grafana.tanzu.vmware.com	9.5.1+vmware.2-tkg.1-20230629	✔	✔	✔
	7.5.17+vmware.1-tkg.3-zshippable	✖	✖	✔
Harbor harbor.tanzu.vmware.com	2.8.2+vmware.2-tkg.1-20230629	✔	✔	✔
CNI Multus multus-cni.tanzu.vmware.com	3.8.0+vmware.3-tkg.1	✔	✔	✔
	4.0.1+vmware.1-tkg.1-20230629	✔	✔	✔
Prometheus prometheus.tanzu.vmware.com	2.43.0+vmware.2-tkg.1-20230629	✔	✔	✔
	2.37.0+vmware.3-tkg.1	✔	✔	✔
	2.36.2+vmware.1-tkg.1	✖	✖	✔
Whereabouts whereabouts.tanzu.vmware.com	0.6.1+vmware.2-tkg.1-20230629	✔	✔	✔
	0.5.4+vmware.2-tkg.1	✔	✔	✔

Snapshot de produit pour Tanzu Kubernetes Grid v2.3

Tanzu Kubernetes Grid v2.3 prend en charge les plates-formes d'infrastructure et les systèmes d'exploitation (SE) suivants, ainsi que la création et la gestion de clusters, la mise en réseau, le stockage, l'authentification, la sauvegarde et la migration, ainsi que les composants d'observabilité.

Reportez-vous aux notes de mise à jour du référentiel Tanzu Standard v2023.10.16 dans la documentation des modules Tanzu pour connaître les versions de modules supplémentaires compatibles avec TKG v2.3.

Pour obtenir la liste complète des versions de composants incluses dans TKG v2.3, reportez-vous à la section Versions des composants.

	vSphere	AWS	Azure
Plate-forme d'infrastructure	vSphere 7.0, 7.0U1-U3 vSphere 8.0, 8.0U1 VMware Cloud on AWS* v1.20 et v1.22 Azure VMware Solution v2.0	AWS natif	Azure natif
CLI Tanzu	Tanzu CLI Core v1.0.0**
API TKG et infrastructure de modules	Tanzu Framework v0.30.2
Création et gestion du cluster	API de cluster principal (v1.4.5), fournisseur d'API de cluster vSphere (v1.7.1)	API de cluster principal (v1.4.5), fournisseur d'API de cluster AWS (v2.1.3)	API de cluster principal (v1.4.5), fournisseur d'API de cluster Azure (v1.9.2)
Système d'exploitation du nœud Kubernetes distribué avec TKG	Photon OS 3, Ubuntu 20.04	Amazon Linux 2, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Créer votre propre image	Photon OS 3, Red Hat Enterprise Linux 7*** et 8, Ubuntu 18.04, Ubuntu 20.04, Windows 2019	Amazon Linux 2, Ubuntu 18.04, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
Exécution de conteneur	Containerd (v1.6.18)
Mise en réseau de conteneur	Antrea (v1.11.2), Calico (v3.25.1), Multus CNI (v4.0.1, v3.8.0)
Registre de conteneur	Harbor (v2.8.4)
Entrée	NSX Advanced Load Balancer Essentials et Contrôleur Avi **** (v21.1.4-v21.1.6, v22.1.2-v22.1.3), NSX v4.1.0 (vSphere 8.0.u1), v3.2.2 (vSphere 7) et Contour (v1.25.2)	Contour (v1.25.2)	Contour (v1.25.2)
Stockage	Interface de stockage de conteneur vSphere (v3.0.1****) et stockage cloud natif vSphere	Pilote Amazon EBS CSI (v1.18.0) et fournisseurs de cloud dans l'arborescence	Pilote Azure Disk CSI (v1.27.1), pilote Azure File CSI (v1.27.0) et fournisseurs de cloud dans l'arborescence
Authentification	OIDC et LDAP via Pinniped (v0.24.0)
Observabilité	Fluent Bit (v2.1.6), Prometheus (v2.45.0, v2.37.0)******, Grafana (v10.0.1)
Détection de services	DNS externe (v0.13.4)
Sauvegarde et migration	Velero (v1.10.3)

* Pour obtenir la liste des versions de SDDC VMware Cloud on AWS compatibles avec cette version, reportez-vous à la Matrice d'interopérabilité des produits VMware.

** Pour obtenir la liste complète des versions de la CLI Tanzu compatibles avec cette version, reportez-vous à la Matrice d'interopérabilité des produits.

*** Tanzu Kubernetes Grid v1.6 est la dernière version qui prend en charge la création d'images Red Hat Enterprise Linux 7.

**** Sur vSphere 8 pour utiliser NSX Advanced Load Balancer avec un cluster de gestion autonome TKG et ses clusters de charge de travail, vous devez NSX ALB 22.1.2 ou version ultérieure et TKG 2.1.1 ou version ultérieure.

***** Version de vsphere_csi_driver. Pour obtenir la liste complète des composants de l'interface de stockage de conteneur vSphere inclus dans cette version, reportez-vous à la section Versions des composants.

****** Si vous mettez à niveau un cluster vers Kubernetes v1.25, vous devez mettre à niveau Prometheus au moins vers la version 2.37.0+vmware.3-tkg.1. Les versions antérieures du module Prometheus, par exemple version 2.37.0+vmware.1-tkg.1, ne sont pas compatibles avec Kubernetes 1.25.

Pour obtenir la liste complète des versions de Kubernetes fournies avec Tanzu Kubernetes Grid v2.3, reportez-vous à la section Versions de Kubernetes prises en charge ci-dessus.

Versions des composants

La version TKG v2.3.x inclut les versions de composants logiciels suivantes :

Remarque

Les versions précédentes de TKG incluaient des composants qui sont désormais distribués via le référentiel Tanzu Standard. Pour obtenir la liste de ces composants, reportez-vous à la section Référentiel Tanzu Standard ci-dessous.

Composant	TKG v2.3.1	TKG v2.3.0
aad-pod-identity	v1.8.15+vmware.2	v1.8.15+vmware.2*
gestionnaire de modules complémentaires	v2.2+vmware.1	v2.2+vmware.1*
ako-operator	v1.9.0_vmware.1	v1.9.0_vmware.1*
alertmanager	v0.25.0_vmware.4*	v0.25.0_vmware.3*
antrea	v1.11.2_vmware.1*	v1.11.1_vmware.4*
antrea-interworking	v0.11.1*	v0.11.0*
aws-ebs-csi-driver	v1.18.0+vmware.2	v1.18.0+vmware.2*
azuredisk-csi-driver	v1.27.1+vmware.3*	v1.27.1+vmware.2*
azurefile-csi-driver	v1.27.0+vmware.3*	v1.27.0+vmware.2*
calico	v3.25.1+vmware.2	v3.25.1+vmware.2*
capabilities-package	v0.30.2-capabilities*	v0.30.2-capabilities*
carvel-secretgen-controller	v0.14.2+vmware.2	v0.14.2+vmware.2*
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1
cloud_provider_vsphere	v1.24.6+vmware.1, v1.26.2+vmware.1, v1.25.3+vmware.1	v1.24.6+vmware.1*, v1.26.2+vmware.1*, v1.25.3+vmware.1*
cluster-api-provider-azure	v1.9.2+vmware.1	v1.9.2+vmware.1*
cluster_api	v1.4.5+vmware.1*	v1.4.2+vmware.3*
cluster_api_aws	v2.1.3+vmware.0	v2.1.3+vmware.0*
cluster_api_vsphere	v1.7.1+vmware.0*	v1.7.0+vmware.0*
cni_plugins	v1.1.1+vmware.28*	v1.1.1+vmware.23*
configmap-reload	v0.8.0+vmware.3*	v0.8.0+vmware.2*
containerd	v1.6.18+vmware.1	v1.6.18+vmware.1
coredns	v1.9.3+vmware.16*	v1.9.3+vmware.11*
crash-diagnostics	v0.3.7+vmware.7	v0.3.7+vmware.7*
cri_tools	v1.25.0+vmware.10*	v1.25.0+vmware.6*
csi_attacher	v4.2.0+vmware.4*, v4.0.0+vmware.1, v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1	v4.2.0+vmware.2*, v4.0.0+vmware.1*, v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1
csi_livenessprobe	v2.9.0+vmware.4*, v2.8.0+vmware.1, v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1	v2.9.0+vmware.2*, v2.8.0+vmware.1*, v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1
csi_node_driver_registrar	v2.7.0+vmware.4*, v2.7.0+vmware.2, v2.6.3+vmware.1, v2.6.2+vmware.1, v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1	v2.7.0+vmware.1*, v2.7.0+vmware.2*, v2.6.3+vmware.1*, v2.6.2+vmware.1*, v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1
csi_provisioner	v3.4.1+vmware.3*, v3.4.0+vmware.4*, v3.3.0+vmware.1, v3.2.1+vmware.1, v3.1.0+vmware.2	v3.4.1+vmware.2*, v3.4.0+vmware.2*, v3.3.0+vmware.1*, v3.2.1+vmware.1, v3.1.0+vmware.2
dex	S.O.	Supprimé
envoy	v1.25.9+vmware.1*	v1.25.6+vmware.1*
external-snapshotter	v6.2.1+vmware.4*, v6.1.0+vmware.1, v6.0.1+vmware.1, v5.0.1+vmware.1	v6.2.1+vmware.2*, v6.1.0+vmware.1*, v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.20*	v3.5.6+vmware.14*
guest-cluster-auth-service	v1.3.0_tkg.2	v1.3.0_tkg.2
image-builder	v0.1.14+vmware.1	v0.1.14+vmware.1*
image-builder-resource-bundle	v1.26.8+vmware.1-tkg.2*	v1.26.5+vmware.2-tkg.1*
imgpkg	v0.36.0+vmware.2	v0.36.0+vmware.2*
jetstack_cert-manager (cert-manager)	v1.11.1+vmware.1	v1.11.1+vmware.1*
k8s-sidecar	v1.22.4+vmware.2*	v1.22.0+vmware.2*, v1.15.6+vmware.5, v1.12.1+vmware.6
k14s_kapp (kapp)	v0.55.0+vmware.2	v0.55.0+vmware.2*
k14s_ytt (ytt)	v0.45.0+vmware.2	v0.45.0+vmware.2*
contrôleur kapp	v0.45.2+vmware.1	v0.45.2+vmware.1*
kbld	v0.37.0+vmware.2	v0.37.0+vmware.2*
kube-state-metrics	v2.8.2+vmware.1	v2.8.2+vmware.1*
kube-vip	v0.5.12+vmware.1	v0.5.12+vmware.1
kube-vip-cloud-provider	v0.0.5+vmware.1, v0.0.4+vmware.4	v0.0.5+vmware.1*, v0.0.4+vmware.4
kubernetes	v1.26.8+vmware.1*, v1.25.13+vmware.1*, v1.24.17+vmware.1*	v1.26.5+vmware.2*, v1.25.10+vmware.2*, v1.24.14+vmware.2
kubernetes-csi_external-resizer	v1.7.0+vmware.4*, v1.6.0+vmware.1, v1.5.0+vmware.1, v1.4.0+vmware.1	v1.7.0+vmware.2*, v1.6.0+vmware.1*, v1.5.0+vmware.1*, v1.4.0+vmware.1
sigs_kind kubernetes	v1.26.8+vmware.1-tkg.2_v0.17.0*, v1.25.13+vmware.2-tkg.1_v0.17.0*, v1.24.17+vmware.2-tkg.1_v0.17.0*	v1.26.5+vmware.2-tkg.1_v0.17.0*, v1.25.10+vmware.2-tkg.1_v0.17.0*, v1.24.14+vmware.2-tkg.1_v0.17.0*
kubernetes_autoscaler	v1.26.2+vmware.1	v1.26.2+vmware.1*
load-balancer-and-ingress-service (AKO)	v1.9.3+vmware.2-tkg.1	v1.9.3+vmware.2-tkg.1*
metrics-server	v0.6.2+vmware.1	v0.6.2+vmware.1
pinniped	v0.24.0+vmware.1-tkg.1	v0.24.0+vmware.1-tkg.1*
pinniped-post-deploy	v0.24.0+vmware.1	v0.24.0+vmware.1*
prometheus_node_exporter	v1.5.0+vmware.3*	v1.5.0+vmware.2*
pushgateway	v1.5.1+vmware.3*	v1.5.1+vmware.2*
sonobuoy	v0.56.16+vmware.2	v0.56.16+vmware.2*
tanzu-framework	v0.30.2*	v0.30.2*
tanzu-framework-addons	v0.30.2*	v0.30.2*
tanzu-framework-management-packages	v0.30.2*	v0.30.2*
tkg-bom	v2.3.1*	v2.3.0*
tkg-core-packages	v1.26.8+vmware.1-tkg.2*	v1.26.8+vmware.2-tkg.1*
tkg-standard-packages	v2023.10.16*	v2023.7.13*
tkg-storageclass-package	v0.30.2*	v0.30.2*
tkg_telemetry	v2.3.1+vmware.3*	v2.3.0+vmware.2*
Velero	v1.10.3+vmware.1	v1.10.3+vmware.1*
velero-mgmt-cluster-plugin*	v0.2.0+vmware.1	v0.2.0+vmware.1*
velero-plugin-for-aws	v1.6.2+vmware.1	v1.6.2+vmware.1*
velero-plugin-for-csi	v0.4.3+vmware.1	v0.4.3+vmware.1*
velero-plugin-for-microsoft-azure	v1.6.2+vmware.1	v1.6.2+vmware.1*
velero-plugin-for-vsphere	v1.5.1+vmware.1	v1.5.1+vmware.1*
vendir	v0.33.1+vmware.2	v0.33.1+vmware.2*
vsphere_csi_driver	v3.0.1+vmware.4*	v3.0.1+vmware.2*

^* Indique un nouveau composant ou un nouveau numéro de version depuis la version précédente. TKG v2.3.0 est antérieur à la version v2.3.1 et TKG v2.2.0 est antérieur à la version v2.3.0.

Pour obtenir la liste des versions de composants logiciels fournies avec TKG v2.3, utilisez imgpkg pour extraire les bundles de référentiels, puis répertorier leur contenu. Par exemple, pour répertorier les versions de composants fournies avec le référentiel Tanzu Standard pour TKG v2.3.1 exécutez la commande suivante :

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2023.10.16 -o standard-2023.10.16

Les fichiers de nomenclature locaux tels que les fichiers suivants répertorient également les versions de module, mais peuvent ne pas être à jour :

• ~/.config/tanzu/tkg/bom/tkg-bom-v2.3.1.yaml
• ~/.config/tanzu/tkg/bom/tkr-bom-v1.26.8+vmware.2-tkg.1.yaml

Chemins de mise à niveau pris en charge

Dans le chemin de mise à niveau de TKG, la version v2.3 suit immédiatement la version v2.2.0.

Vous pouvez uniquement effectuer une mise à niveau vers Tanzu Kubernetes Grid v2.3.x à partir de la version v2.2.x. Si vous souhaitez effectuer une mise à niveau vers Tanzu Kubernetes Grid v2.3.x à partir d'une version antérieure à la version v2.2.x, vous devez d'abord effectuer une mise à niveau vers la version v2.2.x.

Lors de la mise à niveau des versions de Kubernetes sur des clusters de charge de travail, vous ne pouvez pas ignorer les versions mineures. Par exemple, vous ne pouvez pas mettre à niveau un cluster Tanzu Kubernetes directement de la version v1.24.x vers la version v1.26.x. Vous devez mettre à niveau un cluster v1.24.x vers la version v1.25.x avant de mettre à niveau le cluster vers la version v1.26.x.

Dates de publication

Les dates de publication de Tanzu Kubernetes Grid v2.3 sont les suivantes :

• v2.3.1 : 9 novembre 2023
• v2.3.0 : 1er août 2023

Changements de comportement dans Tanzu Kubernetes Grid v2.3

Tanzu Kubernetes Grid v2.3 ajoute les nouveaux comportements suivants par rapport à la version v2.2.0, qui est la dernière version précédente.

• Les outils Carvel sont fournis dans un bundle de téléchargement dédié. Pour plus d'informations, reportez-vous à la section Installer les outils Carvel.

• Lors de l'utilisation d'un fournisseur d'identité OIDC (IDP) pour la gestion des identités et des accès via Pinniped, le fournisseur d'identité OIDC doit être configuré pour émettre un jeton d'actualisation.

  • Cela peut nécessiter une configuration supplémentaire dans le fournisseur d'identité OIDC.
  • Pour obtenir un exemple Okta, reportez-vous à la section Configurer la gestion des identités.
  • Si votre fournisseur d'identité OIDC nécessite des étendues ou des paramètres supplémentaires pour renvoyer un jeton d'actualisation, configurez OIDC_IDENTITY_PROVIDER_SCOPES et OIDC_IDENTITY_PROVIDER_ADDITIONAL_AUTHORIZE_PARAMS avec les étendues ou les paramètres requis.
• Tanzu Kubernetes Grid n'utilise plus Dex pour les fournisseurs d'identité LDAP. Chaque variable de configuration répertoriée dans la section Fournisseurs d'identité - LDAP de la Référence de variable de fichier de configuration correspond désormais à un paramètre de configuration dans la ressource personnalisée LDAPIdentityProvider. Avant de mettre à niveau un cluster de gestion configuré pour utiliser un fournisseur d'identité LDAP pour Tanzu Kubernetes Grid v2.3, mettez à jour vos paramètres LDAP, comme décrit dans la section (LDAP uniquement) Mettre à jour les paramètres LDAP. Tous les paramètres LDAP existants seront automatiquement migrés vers le nouveau format Pinniped lors de la mise à niveau du cluster de gestion vers la version v2.3.
• Velero v1.10 ajoute des Modifications importantes par rapport aux versions de Velero qui étaient fournies avec les versions précédentes de TKG. Pour plus d'informations sur l'atténuation de ces modifications importantes lors de la mise à niveau de Velero v1.9.x vers la version v1.10, reportez-vous à la section Mettre à niveau Velero.
• Lors de la mise à niveau de Tanzu Kubernetes Grid vers la version v2.3 sur AWS, vous devez exécuter tanzu mc permissions aws set après la mise à niveau de la CLI Tanzu, mais avant la mise à niveau du cluster de gestion. Pour plus d'informations, reportez-vous à l'onglet AWS de la section Préparer la mise à niveau des clusters.
• Lors de la création de définitions d'objets ClusterClass personnalisées, ne téléchargez plus le manifeste par défaut à partir du référentiel Tanzu Framework. Le manifeste par défaut est mis à disposition lorsque vous créez un cluster de gestion ou installez la CLI Tanzu, ou lorsque vous pouvez l'extraire du référentiel d'images TKG. Pour plus d'informations, reportez-vous à la section Créer une ClusterClass personnalisée.
• Lors du déploiement d'un cluster de charge de travail avec une version de correctif Kubernetes antérieure à celle du dernier correctif pris en charge pour sa version mineure, vous devez créer un objet ConfigMap pour sa TKr avant de déployer le cluster. Reportez-vous à la section Déployer le cluster Kubernetes sur la page Plusieurs versions de Kubernetes.

Avis des futurs changements de comportement

Cette section fournit un avis préalable des changements de comportement qui prendront effet dans les versions ultérieures, après la version TKG v2.3.

Remarques concernant l'obsolescence

La commande tanzu login sera supprimée dans les versions futures de TKG. Elle sera remplacée par la commande tanzu context. Pour plus d'informations, reportez-vous à la section tanzu context de la Documentation de la CLI VMware Tanzu.

Documentation utilisateur

La section Déploiement et gestion de clusters de gestion autonomes TKG 2.3 inclut des rubriques spécifiques aux clusters de gestion autonomes qui ne sont pas pertinentes pour l'utilisation de TKG avec un superviseur vSphere with Tanzu.

Pour plus d'informations, reportez-vous à la section Rechercher les documents TKG appropriés pour votre déploiement sur la page Documentation de VMware Tanzu Kubernetes Grid.

Problèmes résolus

• Résolu dans la v2.3.1
• Résolu dans la version v2.3.0

Résolu dans la v2.3.1

Tanzu Kubernetes Grid v2.3.1 résout les problèmes et les bogues des clients non documentés.

Résolu dans la version v2.3.0

Les problèmes suivants documentés sous Problèmes connus dans les versions antérieures de Tanzu Kubernetes Grid sont résolus dans Tanzu Kubernetes Grid v2.3.

• La mise en réseau IPv6 n'est pas prise en charge sur vSphere 8

  TKG v2.3 ne prend pas en charge la mise en réseau IPv6 sur vSphere 8, bien qu'il prenne en charge la mise en réseau IPv6 à pile unique à l'aide de Kube-Vip sur vSphere 7, comme décrit dans la section Mise en réseau IPv6.

• La mise à l'échelle automatique du cluster n'ajoute pas les clés attendues au MachineDeployment

  Si vous créez un cluster avec la mise à l'échelle du cluster activée, les clés attendues cluster.x-k8s.io/cluster-api-autoscaler-node-group-max-size et cluster.x-k8s.io/cluster-api-autoscaler-node-group-min-size ne sont pas ajoutées à metadata.annotations dans le MachineDeployment.

• La variable de déploiement des nœuds worker est manquante dans les configurations ClusterClass

  La variable WORKER_ROLLOUT_STRATEGY que vous utilisez pour définir la stratégie de déploiement pour les clusters de charge de travail MachineDeployments était manquante dans les configurations ClusterClass pour tous les plateformes cibles. Vous pouvez désormais définir la variable WORKER_ROLLOUT_STRATEGY sur les clusters basés sur une classe, ainsi que sur les clusters hérités basés sur un plan. Pour plus d'informations, reportez-vous à la section Clusters compatibles GPU de la Référence de variable de fichier de configuration.

• Les pools de nœuds de cluster de charge de travail sur AWS doivent se trouver dans la même zone de disponibilité que le cluster de gestion autonome.

  Lors de la création d'un pool de nœuds configuré avec une variable az différente de l'emplacement du cluster de gestion, le nouveau pool de nœuds peut rester bloqué avec l'état ScalingUp, tel que répertorié par tanzu cluster node-pool list et ne jamais atteindre l'état Ready.

• La recréation d'un cluster de gestion autonome ne restaure pas l'authentification Pinniped

  Après la recréation d'un cluster de gestion autonome comme décrit dans la section Sauvegarder et restaurer l'infrastructure du cluster de charge de travail et de gestion (version d'évaluation technique), les utilisateurs ne peuvent pas se connecter aux clusters de charge de travail via l'authentification Pinniped.

• L'exportation des CVE Harbor peut échouer lorsque l'ID d'exécution dépasse plus de 1 000 000

  Harbor v2.7.1, qui était la version en module pour TKG v2.2, présente un problème connu que les rapports CVE exportent avec l'erreur « Page 404 introuvable » (404 page not found) lorsque l'ID d'incrémentation automatique de la clé principale d'exécution atteint plus de 1 000 000.

• L'option --default-values-file-output de tanzu package available get génère un fichier de modèle de configuration incomplet pour le module Harbor

  L'exécution de tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH crée un fichier de modèle de configuration incomplet pour le module Harbor.

• La mise à l'échelle automatique pour les clusters basés sur une classe nécessite des annotations manuelles

  En raison d'un problème de propagation d'étiquette dans l'API de cluster, les paramètres AUTOSCALER_MIN_SIZE_* et AUTOSCALER_MAX_SIZE_* dans le fichier de configuration du cluster pour les clusters de charge de travail basés sur une classe ne sont pas définis dans les objets MachineDeployment du cluster et doivent être ajoutés manuellement.

• Les noms des clusters basés sur une classe sont limités à 25 caractères avec NSX ALB comme équilibreur de charge ou contrôleur d'entrée.

  Lorsque NSX Advanced Load Balancer (ALB) est utilisé comme service d'équilibrage de charge ou contrôleur d'entrée d'un cluster basé sur une classe avec un cluster de gestion autonome, ses noms d'application incluent à la fois le nom du cluster et load-balancer-and-ingress-service, le nom interne du module AKO. Lorsque le nom combiné dépasse la limite de 64 caractères pour les applications du contrôleur Avi, la commande tanzu cluster create peut échouer avec une erreur indiquant que l'espace de noms avi-system est introuvable.

  Solution : Limitez la longueur du nom de cluster basé sur une classe à 25 caractères ou moins lorsque vous utilisez NSX ALB comme équilibreur de charge ou contrôleur d'entrée.

Problèmes connus

Voici les problèmes connus dans Tanzu Kubernetes Grid v2.3.x. Tous les problèmes connus présents dans la version v2.3.0 qui ont été résolus dans une version de correctif v2.3.x ultérieure sont répertoriés sous la section Problèmes résolus pour cette version de correctif.

Vous trouverez des solutions supplémentaires aux problèmes fréquemment rencontrés dans les sections Dépannage des problèmes de cluster de gestion et Dépannage des problèmes de cluster de charge de travail ou dans les articles de la base de connaissances VMware.

Modules

• L'ajout d'un référentiel standard échoue pour les clusters à nœud unique

  L'exécution de tanzu package repository add pour ajouter le référentiel tanzu-standard à un cluster à nœud unique du type décrit dans la section Clusters à nœud unique sur vSphere peut échouer.

  Cela se produit, car les clusters à nœud unique démarrent avec cert-manager en tant que module complémentaire principal, qui entre en conflit avec le module cert-manager différent dans le référentiel tanzu-standard.

  Solution : Avant d'ajouter le référentiel tanzu-standard, corrigez les annotations du module cert-manager, comme décrit dans la section Installer le gestionnaire de certificats.

Opérations de cluster

• Sur AWS et Azure, la création d'un cluster de charge de travail avec une spécification d'objet échoue avec une erreur de zone/région

  Par défaut, sur AWS ou Azure, l'exécution de tanzu cluster create avec une spécification d'objet de cluster basée sur une classe transmise à --file entraîne l'exécution par la CLI Tanzu d'une vérification de la région et de la zone uniquement pertinente pour les zones de disponibilité vSphere.

  Solution Lors de la création d'un cluster basé sur une classe sur AWS ou Azure, procédez comme suit, selon que vous utilisez le processus en une ou deux étapes décrit dans la section Créer un cluster basé sur une classe :

  • Une étape : Suivez le processus en une étape, comme décrit, en définissant features.cluster.auto-apply-generated-clusterclass-based-configuration sur true et en ne transmettant pas --dry-run à la commande tanzu cluster create.

  • Deux étapes : Avant d'exécuter tanzu cluster create avec la spécification d'objet comme deuxième étape, définissez SKIP_MULTI_AZ_VERIFY sur true dans votre environnement local :

    export SKIP_MULTI_AZ_VERIFY=true
    

• La planification des composants échoue lors de l'utilisation de clusters avec une capacité limitée

  Si vous déployez des clusters avec un seul nœud de plan de contrôle, un seul nœud worker ou des clusters de petite ou moyenne taille pour les clusters de gestion et les clusters de charge de travail, vous pouvez rencontrer une contention de planification des ressources.

  Solution : Utilisez des clusters à nœud unique ou des clusters comportant au moins trois nœuds au total.

• Impossible de créer des clusters de charge de travail basés sur des versions TKr non actuelles avec la CNI Antrea

  Vous ne pouvez pas créer un cluster de charge de travail qui utilise la CNI Antrea et exécute des versions de Kubernetes livrées avec des versions antérieures de TKG, telles que Kubernetes v1.23.10, qui était la version de Kubernetes par défaut dans TKG v1.6.1, comme indiqué dans la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.2.

  Solution : Créez un cluster de charge de travail qui exécute Kubernetes 1.26.8, 1.25.13 ou 1.24.17. Le projet Kubernetes recommande d'exécuter des composants sur la version de correctif la plus récente de toute version mineure actuelle.

• Vous ne pouvez pas mettre à l'échelle les nœuds du plan de contrôle du cluster de gestion vers un nombre pair

  Si vous exécutez tanzu cluster scale sur un cluster de gestion et transmettez un nombre pair à l'option --controlplane-machine-count, TKG ne met pas à l'échelle les nœuds de plan de contrôle et la CLI ne génère pas d'erreur. Pour maintenir le quorum, le nombre de nœuds du plan de contrôle doit toujours être impair.

  Solution : ne pas mettre à l'échelle le nombre de nœuds du plan de contrôle sur un nombre pair.

Mise en réseau

Remarque

à partir de la version 4.0, VMware NSX-T Data Center est renommé « VMware NSX ».

• Certaines variables de configuration ALB NSX ne fonctionnent pas

  Dans TKG v2.3, les variables de configuration du cluster de gestion AVI_DISABLE_INGRESS_CLASS, AVI_DISABLE_STATIC_ROUTE_SYNC et AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER ne fonctionnent pas.

  Pour définir l'une de leurs propriétés sous-jacentes sur la valeur non définie par défaut true, vous devez modifier manuellement les deux objets de configuration AKODeploymentConfig du cluster de gestion, comme décrit ci-dessous après la création du cluster de gestion.

  Solution : modifiez les objets install-ako-for-all et install-ako-for-management-cluster dans le cluster de gestion :

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

     kubectl config use-context MGMT-CLUSTER-CONTEXT
     

  2. Modifiez les configurations install-ako-for-all et install-ako-for-management-cluster :

     kubectl edit adc install-ako-for-all
     

     kubectl edit adc install-ako-for-management-cluster
     

  3. Dans les configurations, définissez les propriétés suivantes comme vous le souhaitez :

     • extraConfigs.ingress.disableIngressClass - pour la variable de configuration AVI_DISABLE_INGRESS_CLASS
     • extraConfigs.disableStaticRouteSync - pour la variable de configuration AVI_DISABLE_STATIC_ROUTE_SYNC
     • extraConfigs.ingress.defaultIngressController - pour la variable de configuration AVI_INGRESS_DEFAULT_INGRESS_CONTROLLER

  4. Enregistrer et quitter.

  Ces paramètres s’appliqueront aux clusters de charge de travail créés par la suite par le cluster de gestion.

• Le mode d'entrée NodePortLocal de NSX ALB n'est pas pris en charge pour le cluster de gestion

  Dans TKG v2.3, vous ne pouvez pas exécuter NSX Advanced Load Balancer (ALB) comme type de service avec le mode d'entrée NodePortLocal pour le trafic vers le cluster de gestion.

  Ce problème n'affecte pas la prise en charge de l'entrée NodePortLocal aux clusters de charge de travail, comme décrit dans la section Entrée L7 en mode NodePortLocal.

  Solution : configurez les clusters de gestion avec AVI_INGRESS_SERVICE_TYPE défini sur NodePort ou ClusterIP. La valeur par défaut est NodePort.

• La création d'un cluster de gestion échoue ou les performances sont lentes avec les anciennes versions de NSX-T et les machines virtuelles Photon 3 ou Ubuntu avec le noyau Linux 5.8

  Le déploiement d'un cluster de gestion avec l'infrastructure et la configuration suivantes peut échouer ou entraîner une restriction du trafic entre les espaces :

  • vSphere avec l'une des versions suivantes de NSX-T :
    • NSX-T v3.1.3 avec chemin de données optimisé activé
    • NSX-T version 3.1.x antérieure à la version 3.1.3
    • NSX-T version 3.0.x antérieure au correctif à chaud v3.0.2
    • NSX-T v2.x. Cela inclut Azure VMware Solution (AVS) v2.0, qui utilise NSX-T v2.5
  • Image de base : Photon 3 ou Ubuntu avec noyau Linux 5.8

  Cette combinaison expose un problème de total de contrôle entre les anciennes versions de NSX-T et de la CNI Antrea.

  TMC : si le cluster de gestion est enregistré dans Tanzu Mission Control (TMC), il n'existe aucune solution à ce problème. Sinon, reportez-vous aux solutions ci-dessous.

  Solutions :

  • Déployez des clusters de charge de travail configurés avec ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD défini sur "true". Ce paramètre désactive le déchargement du total de contrôle UDP d'Antrea, ce qui évite les problèmes connus avec certains pilotes réseau de sous-couche et de carte réseau physique.
  • Mise à niveau vers le correctif à chaud NSX-T v3.0.2, v3.1.3 ou version ultérieure, sans l'option Chemin de données optimisé activée
  • Utilisez une image de base Ubuntu avec le noyau Linux 5.9 ou version ultérieure.

Stockage

• Le cluster de charge de travail ne peut pas distribuer le stockage sur plusieurs banques de données

  Vous ne pouvez pas activer un cluster de charge de travail pour distribuer le stockage entre plusieurs banques de données, comme décrit dans la section Déployer un cluster qui utilise un cluster de banques de données. Si vous balisez plusieurs banques de données dans un cluster de banques de données comme base de la stratégie de stockage d'un cluster de charge de travail, ce cluster n'utilise qu'une seule des banques de données.

  Solution : Aucune

CLI Tanzu

• Les caractères non alphanumériques ne peuvent pas être utilisés dans les mots de passe de proxy HTTP/HTTPS

  Lors du déploiement de clusters de gestion avec la CLI, les caractères non alphanumériques # ` ^ | / ? % ^ { [ ] } \ " < > ne peuvent pas être utilisés dans les mots de passe. En outre, vous ne pouvez pas utiliser des caractères non alphanumériques dans les mots de passe de proxy HTTP/HTTPS lors du déploiement d'un cluster de gestion avec l'interface utilisateur.

  Solution : vous pouvez utiliser des caractères non alphanumériques autres que # ` ^ | / ? % ^ { [ ] } \ " < > dans les mots de passe lors du déploiement du cluster de gestion avec la CLI.

• La CLI Tanzu ne fonctionne pas sur les machines macOS avec des processeurs ARM

  La CLI Tanzu v0.11.6 ne fonctionne pas sur les machines macOS dotées de puces ARM (Apple M1), comme identifié sous Outil de recherche > À propos de ce Mac > Présentation.

  Solution : utilisez une machine de démarrage avec un système d'exploitation Linux ou Windows, ou une machine macOS avec un processeur Intel.

• La CLI Tanzu répertorie tanzu management-cluster osimage

  Le groupe de commandes management-cluster répertorie tanzu management-cluster osimage. Cette fonctionnalité est actuellement en développement, et réservée pour une utilisation ultérieure.

  Solution : n'utilisez pas tanzu management-cluster osimage.

vSphere

• Le déploiement du cluster de gestion sur vSphere 7 échoue lors de l'attente de la disponibilité du plan de contrôle du cluster

  Si vous spécifiez un réseau de VM lors du déploiement d'un cluster de gestion vers vSphere 7, le déploiement du cluster échoue avec l'erreur unable to set up management cluster: unable to wait for cluster control plane available: control plane is not available yet.

  Solution : Ensuite, le réseau « Réseau de VM » dispose de plusieurs sous-réseaux configurés avec des adresses IP statiques pour VsVip et ServiceEngine. Définissez exclude_discovered_subnets sur True sur le réseau de VM, pour ignorer les sous-réseaux détectés et autoriser le placement des services virtuels sur les moteurs de service.

• Les zones de disponibilité peuvent être supprimées lorsque des VM leur sont attribuées

  Si vous supprimez une zone de disponibilité qui contient des VM, celles-ci ne peuvent pas être supprimées par la suite.

  Solution : Supprimez toutes les VM d'une zone de disponibilité avant de la supprimer.

• La création de clusters de charge de travail échoue en raison de l'épuisement des sessions VPXD

  Lors de la création de clusters de charge de travail sur vSphere, la création échoue avec l'erreur suivante :

  vSphere config validation failed: failed to get VC client: failed to create vc client: Post "https://address/sdk": EOF ". VCenter vpxd.log report error: Out of HTTP sessions: Limited to 2000
  

  Cela se produit en raison de l'épuisement des sessions vCenter Server.

  Solution : Reportez-vous à l'article 50114010 de la base de connaissances VMware.

• Les pools de nœuds créés avec des nœuds small peuvent se bloquer à l'état Provisioning

  Les pools de nœuds créés avec le nœud SIZE configurés comme small peuvent se bloquer à l'état Provisioning et ne jamais passer à l'état Running.

  Solution : configurez le pool de nœuds avec des nœuds de taille au moins medium.

Windows

• Travailleurs Windows non pris en charge dans les environnements à accès restreint à Internet

  VMware ne prend pas en charge les clusters de charge de travail TKG avec des nœuds worker Windows dans des environnements en proxy ou isolés.

  Solution : Contactez votre représentant VMware. Certains utilisateurs TKG ont créé des images personnalisées Windows et exécutent des clusters de charge de travail avec des travailleurs Windows dans des environnements hors ligne, par exemple, comme décrit dans ce référentiel non officiel.

Image-Builder

• Échecs de test goss ignorés lors du processus de création d'image

  Lorsque vous exécutez Kubernetes Image Builder pour créer une image de machine personnalisée Linux personnalisée, les tests goss python-netifaces, python-requests et ebtables échouent. La sortie de la commande signale les échecs. Les erreurs peuvent être ignorées ; elles n'empêchent pas la création d'une image réussie.

AVS

• La suppression du volume vSphere CSI peut échouer sur AVS

  Sur la Azure vSphere Solution (AVS), la suppression des volumes persistants vSphere CSI peut échouer. La suppression d'un volume persistant nécessite l'autorisation cns.searchable. Le compte d'administrateur par défaut pour AVS, [email protected], n'est pas créé avec cette autorisation. Pour plus d'informations, reportez-vous à la section Rôles et privilèges dans vSphere.

  Solution : pour supprimer un volume persistant vSphere CSI sur AVS, contactez le support Azure.

Référentiel Tanzu Standard v2023.7.13

Avec TKG v2.3, le référentiel de modules Tanzu Standard est utilisé avec version et distribué séparément de TKG, et son contrôle de version est basé sur un horodatage.

Pour TKG v2.3.0 et v2.3.1, la version du correctif TKG et sa dernière version compatible du référentiel Tanzu Standard sont publiées à la même date.

Les futures versions du référentiel Tanzu Standard peuvent être publiées plus fréquemment que les versions de TKG, mais toutes les versions de correctifs conserveront les compatibilités existantes entre les versions mineures de TKG et de Tanzu Standard.

Pour chaque version du correctif TKG v2.3, sa version compatible du référentiel Tanzu Standard la plus récente est la suivante :

• TKG v2.3.1 : Tanzu Standard v2023.10.16
  • Notes de mise à jour : Reportez-vous aux Notes de mise à jour du référentiel Tanzu Standard v2023.10.16 dans la documentation des modules Tanzu
• TKG v2.3.0 : Tanzu Standard v2023.7.13
  • Notes de mise à jour : Voir ci-dessous

Prise en charge des modules du référentiel Tanzu Standard

VMware fournit la prise en charge suivante des modules facultatifs fournis dans le référentiel VMware Tanzu Standard :

• VMware fournit la validation de l'installation et de la mise à niveau des modules inclus dans le référentiel VMware Tanzu Standard facultatif lorsqu'ils sont déployés sur Tanzu Kubernetes Grid. Cette validation est limitée à l'installation et à la mise à niveau du module, mais inclut toutes les mises à jour disponibles requises pour traiter les CVE. L'ensemble des correctifs de bogues, des améliorations des fonctionnalités et des correctifs de sécurité sont fournis dans les nouvelles versions du module lorsqu'ils sont disponibles dans le projet de module en amont.
• VMware ne fournit pas de support au niveau de l'environnement d'exécution pour les composants fournis par le référentiel Tanzu Standard. Le débogage de la configuration, les problèmes liés aux performances ou le débogage et la correction du module lui-même ne sont pas fournis par VMware.
• VMware fournit un support au niveau de l'environnement d'exécution pour les modules compatibles VMware : Harbor, Contour et Velero, lorsqu'ils sont déployés sur Tanzu Kubernetes Grid.

Cert-manager v1.11.1

Nouveautés

• Reportez-vous aux notes de mise à jour de cert-manager v1.11.1
• Le module vmware_cert-manager inclut le composant acmesolver de l'instance de jetstack_cert-manager en amont.

Versions prises en charge

Version de TKG	Version de jetstack_cert-manager	Version du module VMware cert-manager	Compatibilité des versions de Kubernetes
2.3	v1.11.1	v1.11.1+vmware.1	1.21-1.27

Versions des composants

Le gestionnaire de certificats v1.11.1 contient les versions d'image de composant suivants :

• quay.io/jetstack/cert-manager-cainjector:v1.11.1
• quay.io/jetstack/cert-manager-controller:v1.11.1
• quay.io/jetstack/cert-manager-webhook:v1.11.1
• quay.io/jetstack/cert-manager-acmesolver:v1.11.1

Obsolescences

Les versions suivantes du gestionnaire de certificats sont obsolètes dans TKG v2.3 :

• v1.5.3
• v1.7.2
• v1.10.2

Contour v1.24.4

Nouveautés

• Reportez-vous aux notes de mise à jour de Contour v1.24.0-4 :
  • CHANGELOG-v1.24.0.md
  • CHANGELOG-v1.24.1.md
  • CHANGELOG-v1.24.2.md
  • CHANGELOG-v1.24.3.md
  • CHANGELOG-v1.24.4.md
• Vous pouvez configurer Envoy pour l'installer comme déploiement avec un nombre spécifié de réplicas, plutôt que comme DaemonSet (par défaut), à l'aide de valeurs de données suivantes :

  envoy: 
    workload: 
      type: Deployment 
      replicas: 3
  

• Vous pouvez spécifier des demandes ou des limites de ressources pour chaque conteneur dans les charges de travail Contour et Envoy, à l'aide de valeurs suivantes :

  contour: 
    resources: 
      contour: 
        requests: 
          cpu: 250m 
          memory: 128Mi 
        limits: 
          cpu: 1 
  
          memory: 512Mi
  envoy:
    resources:
      envoy:
  # include requests and limits as desired
      shutdown-manager:
  # include requests and limits as desired 
  

• Les valeurs du fichier de configuration data-values sont vérifiées. La spécification d'une valeur non prise en charge dans les valeurs de données génère une erreur.

Versions de Kubernetes prises en charge

Contour v1.24.4 est pris en charge sur Kubernetes v1.24-v1.26. Reportez-vous à la Matrice de compatibilité de Contour.

Obsolescences

• Toutes les versions de Contour antérieures à la version v1.24.4 ont été supprimées du référentiel Tanzu Standard v2023.7.13.
• Les fichiers data-values du module Contour n'acceptent plus les valeurs null. Pour tout champ de configuration dont la valeur est définie sur null, vous devez omettre complètement la valeur.

External-csi-snapshot-webhook v6.1.0

Nouveautés

• external-csi-snapshot-webhook est un nouveau module pour TKG v2.3
• TKG v2.3 avec un superviseur vSphere 8.0U2 prend en charge les snapshots CSI pour le superviseur et les clusters de charge de travail qu'il déploie, mais vous devez d'abord installer explicitement external-csi-snapshot-webhook v6.1.0 à l'aide de la CLI Tanzu.

Versions prises en charge

Version de TKG	Version d'external-csi-snapshot-webhook	Compatibilité de la version de Kubernetes attendue	Testée sur la version de Kubernetes
2.3.0	6.1.0	1.18 - dernière version	1.24

Dépendances

• external-csi-snapshot-webhook nécessite cert-manager pour sécuriser la communication X509 avec le serveur d'API Kubernetes.

Versions des composants

external-csi-snapshot-webhook contient la version de l'image de composant suivante :

• registry.k8s.io/sig-storage/snapshot-validation-webhook:v6.1.0

DNS externe v0.13.4

Nouveautés

• Reportez-vous aux notes de mise à jour de DNS v0.13.4 externe
• Nouveau champ de configuration createNamespace. Définissez cette variable sur true pour créer l'espace de noms dans lequel les composants external-dns sont installés. Si cette variable est définie sur false, les composants de module s'installent dans un espace de noms existant.

Fluent-bit v2.1.2

Nouveautés

• Reportez-vous aux notes de mise à jour de Fluent Bit v2.1.2.

Limitations/Problèmes connus

• Ne prend pas en charge les variables d'environnement d'informations d'identification AWS dans la ConfigMap du module fluent-bit pour accéder à AWS S3.
  • La prise en charge des informations d'identification AWS est prévue pour une version ultérieure.

Contrôleurs Fluxcd

Nouveautés

Reportez-vous aux notes de mise à jour du module de contrôleur Fluxcd suivantes :

• Fluxcd-helm-controller
  • Notes de mise à jour de fluxcd-helm-controller v0.21.0
  • Notes de mise à jour de fluxcd-helm-controller v0.28.1
• Fluxcd-kustomize-controller
  • Notes de mise à jour de fluxcd-kustomize-controller v0.24.4
  • Notes de mise à jour de fluxcd-kustomize-controller v0.32.0
• Fluxcd-source-controller
  • Notes de mise à jour de fluxcd-source-controller v0.24.4
  • Notes de mise à jour de fluxcd-source-controller v0.33.0

Grafana v9.5.1

Nouveautés

• Reportez-vous aux notes de mise à jour de Grafana v9.5.1

Versions des composants

Grafana v9.5.1 contient les versions d'image de composant suivantes :

• grafana/grafana:9.5.1
• kiwigrid/k8s-sidecar:1.22.0

Harbor v2.8.2

Nouveautés

• Reportez-vous aux notes de mise à jour de Harbor v2.8.2
• En raison des CVE, la compatibilité de TKG v2.3 avec les versions suivantes de Harbor a été supprimée :
  • v2.2.3_vmware.1-tkg.1
  • v2.2.3_vmware.1-tkg.2
  • v2.3.3_vmware.1-tkg.1
  • v2.5.3_vmware.1-tkg.1
  • v2.7.1_vmware.1-tkg.1

Versions des composants

Harbor v2.8.2 contient les versions d'image de composant suivantes :

• harbor-core:v2.8.2
• harbor-db:v2.8.2
• harbor-exporter:v2.8.2
• harbor-jobservice:v2.8.2
• harbor-portal:v2.8.2
• harbor-registryctl:v2.8.2
• registry-photon:v2.8.2
• notary-server-photon:v2.8.2
• notary-signer-photon:v2.8.2
• redis-photon:v2.8.2
• trivy-adapter-photon:v2.8.2

CNI Multus v4.0.1

Nouveautés

• Ajoute un déploiement et une architecture de plug-in statique. Reportez-vous à la nouvelle fonctionnalité CNI Multus v4.0.1

• Modifie les valeurs par défaut comme suit :

  namespace: kube-system 
  #! DaemonSet related configuration 
  daemonset: 
    resources: 
      limits: 
        cpu: 100m 
        memory: 50Mi 
      requests: 
        cpu: 100m 
        memory: 50Mi 
  configmap: 
    cniVersion: 0.3.1 
    multusConfigFile: auto 
  

Prometheus v2.43.0

Nouveautés

• Reportez-vous aux notes de mise à jour de Prometheus v2.43.0

Versions des composants

Prometheus v2.43.0 contient les versions d'image de composant suivantes :

• prom/prometheus:v2.43.0
• prom/alertmanager:v0.25.0
• prom/pushgateway:v1.5.1
• jimmidyson/configmap-reload:v0.8.0
• bitnami/kube-state-metrics:2.8.2
• quay.io/prometheus/node-exporter:v1.5.0

Velero v1.10.0

Nouveautés

• Reportez-vous aux notes de mise à jour de Velero v1.10.0
• Kopia remplace Restic en tant que chargeur. Cela entraîne les modifications importantes suivantes. Pour plus d'informations, reportez-vous à la section Modifications importantes dans le journal des modifications de Velero v1.10 :
  • restic daemonset renommé node-agent
  • CR ResticRepository renommé BackupRepository
  • Commande velero restic repo renommée velero repo
  • Secret velero-restic-credentials renommé velero-repo-credentials
  • Paramètre default-volumes-to-restic renommé default-volumes-to-fs-backup
  • Paramètre restic-timeout renommé fs-backup-timeout
  • Paramètre default-restic-prune-frequency renommé default-repo-maintain-frequency
• Unifie le référentiel de sauvegarde et le dissocie des systèmes de déplacement des données, comme décrit dans la section Référentiel unifié et conception de l'intégration Kopia.
• Refactorise la sauvegarde du système de fichiers en ajoutant un chemin d'accès Kopia au chemin d'accès Restic existant, prenant ainsi en charge les deux via un paramètre de configuration uploader-type.
  • Reportez-vous aux sections Sauvegarde du système de fichiers et Mise à niveau vers Velero 1.10.
  • Pour choisir entre Kopia et Restic, reportez-vous au Guide des performances de sauvegarde du système de fichiers Velero.
• Déplace les plug-ins BackupItemAction, RestoreItemAction et VolumeSnapshotterAction vers la version v1 afin d'autoriser de futures modifications de plug-in qui peuvent ne pas prendre en charge la rétrocompatibilité, telles que des tâches de déplacement de données complexes, par exemple, des tâches de déplacement de données. Reportez-vous à la section Contrôle de version des plug-ins.
• Ajoute des options d'enregistrement des informations d'identification pour des emplacements de snapshots de volumes spécifiques ; reportez-vous à la section Emplacements de stockage des sauvegardes et emplacements de snapshots de volumes.
• Améliore la robustesse des snapshots CSI avec des codes de protection pour la gestion des erreurs et la possibilité d'ignorer les vérifications d'exclusion afin que le snapshot CSI soit compatible avec différents filtres de ressources de sauvegarde.
• Prend en charge la suspension de la planification de sauvegarde ou l'annulation de la suspension de celle-ci :
  • Transmettez l'indicateur -paused à velero schedule create pour créer une planification suspendue.
  • Les variables velero schedule pause et velero schedule unpause suspendent une planification existante et annulent la suspension de celle-ci.

Versions prises en charge

Version de TKG	Version de Velero	Compatibilité de la version de Kubernetes attendue	Testée sur la version de Kubernetes
2.3 (Halifax)	1.10	1.18 - dernière version	1.22.5, 1.23.8, 1.24.6 et 1.25.1

Versions des composants

Velero v1.10.3 contient les versions d'image de composant suivantes :

• velero/velero:v1.10.3
• velero/velero-plugin-for-aws:v1.6.2
• velero/velero-plugin-for-csi:v0.4.3
• velero/velero-plugin-for-microsoft-azure:v1.6.2
• vsphereveleroplugin/velero-plugin-for-vsphere:v1.5.1

Pour corriger les CVE, les versions d'environnement d'exécution et de dépendance de Velero sont mises à jour comme suit :

• Version d'exécution Go v1.18.8
• Compilation de Restic v0.13.1 avec Go 1.18.8 au lieu d'intégrer le fichier binaire Restic
• Versions mises à jour des principales bibliothèques dépendantes

Mises à niveau

Les procédures de mise à niveau précédentes ne fonctionnent pas en raison de modifications de la sauvegarde du système de fichiers. Pour connaître les nouvelles étapes de mise à niveau, reportez-vous à la section Mise à niveau vers Velero 1.10.

Limitations/Problèmes connus

• La sauvegarde Kopia ne prend pas en charge le certificat auto-signé pour le stockage compatible S3. Pour suivre ce problème, reportez-vous à la section Velero problème n° 5123 et Kopia problème n° 1443.
• Ne fonctionne pas avec le dernier plug-in vSphere pour la version de Velero, comme décrit dans la section Plug-in vSphere pour Velero problème n° 485. Tant que ce problème n'est pas résolu, ne mettez pas à niveau le plug-in vSphere pour qu'il soit compatible avec Velero v1.1.0.

Whereabouts v0.6.1

Nouveautés

• Prend en charge ipRanges pour la configuration de l'attribution d'adresses IP à double pile. Reportez-vous à la section Exemple de configuration d'IPv6 dans le fichier LISEZ-MOI du référentiel Whereabouts.