Sauf indication contraire, ces notes de mise à jour s'appliquent à toutes les versions de correctif v2.1.x de Tanzu Kubernetes Grid (TKG).
RemarqueLes analyses de sécurité de Tanzu Kubernetes Grid (TKG) peuvent produire des résultats positifs pour un ensemble de CVE. VMware les a évaluées et elles ne sont pas exploitables dans le contexte de TKG. Pour plus de détails, contactez votre représentant VMware.
Comme avec les versions 1.x, TKG v2.1 est distribué sous la forme d'un module de CLI Tanzu téléchargeable qui déploie un cluster de gestion autonome TKG versionné.
TKG v2 n'est pas un produit téléchargeable, mais fait plutôt référence à l'utilisation de la CLI Tanzu dans TKG v1.6 ou v2.1 pour créer et gérer des clusters de charge de travail basés sur une classe en le connectant à un superviseur vSphere with Tanzu intégré à vSphere 8.
ImportantVous ne pouvez pas utiliser la version de la CLI Tanzu fournie avec TKG 2.1 pour vous connecter à un cluster superviseur sur vSphere 7. Si vous utilisez la CLI Tanzu pour vous connecter à un cluster superviseur sur vSphere 7 et que vous ne pouvez pas effectuer la mise à niveau vers vSphere 8, ne procédez pas à la mise à niveau vers Tanzu Kubernetes Grid version 2.1 ou ne la déployez pas. Vous pouvez déployer un cluster de gestion sur vSphere 7 si aucun cluster superviseur vSphere with Tanzu n'est présent.
TKG v2.1 est la première version de TKG qui 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.
Tanzu Kubernetes Grid v2.1 inclut les nouvelles fonctionnalités suivantes :
package utilise des commandes de style kctrl par défaut. Reportez-vous à la section Module Tanzu dans Référence de commande de la CLI Tanzu.isolated-cluster, download-bundle et upload-bundle, récupèrent et transfèrent toutes les images de conteneur requises par TKG, comme décrit dans Préparer un environnement à accès restreint à Internet.-A et --all-namespaces pour tanzu cluster list incluent des clusters dans tous les espaces de noms gérés par le cluster de gestion et pour lesquels l'utilisateur dispose d'autorisations d'affichage ou supérieures, pas uniquement l'espace de noms par défaut.context permet aux utilisateurs de définir et de gérer les contextes de la CLI Tanzu, qui incluent le serveur à cibler et le fichier kubeconfig à appliquer. Reportez-vous à la section Contexte Tanzu dans la Référence de commande de la CLI Tanzu.
tanzu login en faveur des commandes tanzu context.Target des plug-ins modifie le comportement de la CLI et ajoute des fonctionnalités réservées pour une utilisation ultérieure, comme décrit dans la section Modifications de comportement dans Tanzu Kubernetes Grid v2.1, ci-dessous.auto-apply-generated-clusterclass-based-configuration applique automatiquement la configuration de cluster basée sur une classe générée par la CLI Tanzu lorsque vous transmettez un fichier de configuration de cluster hérité à tanzu cluster create. La fonctionnalité est définie sur false par défaut. Reportez-vous à la section Fonctionnalités dans Architecture et configuration de la CLI Tanzu.allow-legacy-cluster vous permet de créer des clusters basés sur un plan. La fonctionnalité est définie sur false par défaut. Reportez-vous à la section Fonctionnalités dans Architecture et configuration de la CLI Tanzu.tanzu mc credentials update et tanzu cluster credentials update ajoutent des options pour Azure. Cela inclut --azure-client-id, --azure-client-secret et --azure-tenant-id.CONTROL_PLANE_NODE_LABELS, CONTROL_PLANE_NODE_NAMESERVERS, CONTROL_PLANE_NODE_SEARCH_DOMAINS, WORKER_NODE_NAMESERVERS, WORKER_NODE_SEARCH_DOMAINSExtraArgs : APISERVER_EXTRA_ARGS, CONTROLPLANE_KUBELET_EXTRA_ARGS, ETCD_EXTRA_ARGS, KUBE_CONTROLLER_MANAGER_EXTRA_ARGS, KUBE_SCHEDULER_EXTRA_ARGS, WORKER_KUBELET_EXTRA_ARGSNTP_SERVERS, APISERVER_EVENT_RATE_LIMIT_CONF_BASE64Machine de nœuds de cluster identifient l'adresse de leur hôte ESXi à prendre en charge à l'aide de nodeSelector pour exécuter des charges de travail spécifiques sur du matériel spécialisé.LoadBalancer pour les charges de travail. Reportez-vous à la section Équilibreur de charge Kube-VIP (version d'évaluation technique).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 Tanzu Kubernetes (TKrs).
Toutes les versions de Tanzu Kubernetes Grid prennent en charge toutes les versions TKr des deux lignes mineures précédentes de Kubernetes. Par exemple, TKG v2.1.x prend en charge les versions v1.23.x et v1.22.x de Kubernetes répertoriées ci-dessous, mais pas les versions v1.21.x ou antérieures.
| Version de Tanzu Kubernetes Grid | Version Kubernetes du cluster de gestion | Versions de Kubernetes (TKr) fournies |
|---|---|---|
| 2.1.0 | 1.24.9 | 1.24.9, 1.23.15, 1.22.17 |
| 1.6.1 | v1.23.10 | v1.23.10, 1.22.13, 1.21.14 |
| 1.6.0 | 1.23.8 | 1.23.8, 1.22.11, 1.21.14 |
| 1.5.4 | 1.22.9 | 1.22.9, 1.21.11, 1.20.15 |
| 1.5.3 | 1.22.8 | 1.22.8, 1.21.11, 1.20.15 |
| 1.5.2, 1.5.1, 1.5.0 | 1.22.5 | 1.22.5, 1.21.8, 1.20.14 |
Tanzu Kubernetes Grid v2.1 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é. Les versions des composants répertoriées entre parenthèses sont incluses dans Tanzu Kubernetes Grid v2.1. Pour plus d'informations, reportez-vous à la section Versions des composants.
| vSphere | AWS | Azure | |
| Plate-forme d'infrastructure |
|
AWS natif | Azure natif |
| CLI, API et infrastructure de modules | Tanzu Framework v0.28.0 | ||
| Création et gestion du cluster | API de cluster principal (v1.2.8), fournisseur d'API de cluster vSphere (v1.5.1) | API de cluster principal (v1.2.8), fournisseur d'API de cluster AWS (v2.0.2) | API de cluster principal (v1.2.8), fournisseur d'API de cluster Azure (v1.6.1) |
| 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.6) | ||
| Mise en réseau de conteneur | Antrea (v1.7.2), Calico (v3.24.1) | ||
| Registre de conteneur | Harbor (v2.6.3) | ||
| Entrée | NSX Advanced Load Balancer Essentials et le contrôleur Avi **** (v21.1.3- v21.1.6, v22.1.1, v22.1.2), Contour (v1.22.3) | Contour (v1.22.3) | Contour (v1.22.3) |
| Stockage | Interface de stockage de conteneur vSphere (v2.5.2*) et stockage cloud natif vSphere | Pilote Amazon EBS CSI (v1.8.0) et fournisseurs de cloud dans l'arborescence | Pilote Azure Disk CSI (v1.19.0), pilote Azure File CSI (v1.21.0) et fournisseurs de cloud dans l'arborescence |
| Authentification | OIDC via Pinniped (v0.12.1), LDAP via Pinniped (v0.12.1) et Dex | ||
| Observabilité | Fluent Bit (v1.8.15), Prometheus (v2.37.0), Grafana (v7.5.16) | ||
| Sauvegarde et migration | Velero (v1.9.5) | ||
Remarque* Version de vsphere_csi_driver. Pour obtenir la liste complète des composants de vSphere Container Storage Interface inclus dans Tanzu Kubernetes Grid v1.6, reportez-vous à la section Versions des composants.
** 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.
*** Tanzu Kubernetes Grid v1.6 est la dernière version qui prend en charge la création d'images Red Hat Enterprise Linux 7.
**** VMware NSX Advanced Load Balancer ne prend pas en charge les clusters de gestion TKG autonomes sur vSphere 8. La prise en charge des clusters de gestion TKG sur vSphere 8 sera ajoutée dans une version ultérieure de NSX Advanced Load Balancer. Si vous utilisez NSX Advanced Load Balancer avec des clusters de gestion TKG autonomes sur vSphere, ne mettez pas à niveau vSphere vers vSphere 8.
Pour obtenir la liste complète des versions de Kubernetes fournies avec Tanzu Kubernetes Grid v2.1, reportez-vous à la section Versions de Kubernetes prises en charge dans Tanzu Kubernetes Grid v2.1 ci-dessus.
Les versions Tanzu Kubernetes Grid v2.1.x incluent les versions de composants logiciels suivantes :
| Composant | TKG v2.1 |
|---|---|
| aad-pod-identity | v1.8.13+vmware.2* |
| gestionnaire de modules complémentaires | v2.1+vmware.1-tkg.3 |
| ako-operator | v1.7.0+vmware.3* |
| alertmanager | v0.24.0+vmware.1 |
| antrea | v1.7.2+vmware.1-advanced* |
| aws-ebs-csi-driver | v1.8.0+vmware.2* |
| azuredisk-csi-driver | v1.19.0+vmware.1* |
| azurefile-csi-driver* | v1.21.0+vmware.1 |
| calico_all | v3.24.1+vmware.1* |
| capabilities-package | v0.28.0-tf-capabilities* |
| carvel-secretgen-controller | v0.11.2+vmware.1* |
| cloud-provider-azure | v1.1.26+vmware.1*, v1.23.23+vmware.1*, v1.24.10+vmware.1* |
| cloud_provider_vsphere | v1.24.3+vmware.1* |
| cluster-api-provider-azure | v1.6.1_vmware.1* |
| cluster_api | v1.2.8+vmware.1* |
| cluster_api_aws | v2.0.2+vmware.1* |
| cluster_api_vsphere | v1.5.1+vmware.1l* |
| cni_plugins | v1.1.1+vmware.16* |
| configmap-reload | v0.7.1+vmware.1 |
| containerd | v1.6.6+vmware.1* |
| contour | v1.22.3+vmware.1* |
| coredns | v1.8.6+vmware.15* |
| crash-diagnostics | v0.3.7+vmware.6* |
| cri_tools | v1.23.0+vmware.7* |
| csi_attacher | v3.5.0+vmware.1*, v3.4.0+vmware.1, v3.3.0+vmware.1 |
| csi_livenessprobe | 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.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1 |
| csi_provisioner | v3.2.1+vmware.1*, v3.1.0+vmware.2, v3.0.0+vmware.1 |
| dex | v2.35.3+vmware.2* |
| envoy | v1.23.3+vmware.2* |
| external-dns | v0.12.2+vmware.4* |
| external-snapshotter | v6.0.1+vmware.1, v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.3* |
| fluent-bit | v1.8.15+vmware.1 |
| gangway | v3.2.0+vmware.2 |
| grafana | v7.5.16+vmware.1 |
| guest-cluster-auth-service | v1.1.0* |
| harbor | v2.6.3+vmware.1* |
| image-builder | v0.1.13+vmware.2* |
| image-builder-resource-bundle | v1.24.9+vmware.1-tkg.1* |
| imgpkg | v0.31.1+vmware.1* |
| jetstack_cert-manager | v1.10.1+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.1 , v1.12.1+vmware.3* |
| k14s_kapp | v0.53.2+vmware.1* |
| k14s_ytt | v0.43.1+vmware.1* |
| contrôleur kapp | v0.41.5+vmware.1*, v0.38.5+vmware.2* |
| kbld | v0.35.1+vmware.1* |
| kube-state-metrics | v2.6.0+vmware.1* |
| kube-vip | v0.5.7+vmware.1* |
| kube-vip-cloud-provider* | v0.0.4+vmware.2 |
| kube_rbac_proxy | v0.11.0+vmware.2 |
| kubernetes | v1.24.9+vmware.1* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1*, v1.3.0+vmware.1 |
| sigs_kind kubernetes | v1.24.9+vmware.1-tkg.1_v0.17.0* |
| kubernetes_autoscaler | v1.24.0+vmware.1* |
| load-balancer-and-ingress-service (AKO) | v1.8.2+vmware.1* |
| metrics-server | v0.6.2+vmware.1* |
| multus-cni | v3.8.0+vmware.2* |
| pinniped | v0.12.1+vmware.1-tkg.1 |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3* |
| prometheus | v2.37.0+vmware.1* |
| prometheus_node_exporter | v1.4.0+vmware.1* |
| pushgateway | v1.4.3+vmware.1 |
| sonobuoy | v0.56.13+vmware.1* |
| standalone-plugins-package | v0.28.0-tf-standalone-plugins* |
| tanzu-framework | v0.28.0* |
| tanzu-framework-addons | v0.28.0* |
| tanzu-framework-management-packages | v0.28.0-tf* |
| tkg-bom | v2.1.0* |
| tkg-core-packages | v1.24.9+vmware.1-tkg.1* |
| tkg-standard-packages | v2.1.0* |
| tkg-storageclass-package | v0.28.0-tkg-storageclass* |
| tkg_telemetry | v2.1.0+vmware.1* |
| Velero | v1.9.5+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.3+vmware.1* |
| velero-plugin-for-csi | v0.3.3+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.3+vmware.1* |
| velero-plugin-for-vsphere | v1.4.2+vmware.1* |
| vendir | v0.30.1+vmware.1* |
| vsphere_csi_driver | v2.6.2+vmware.2* |
| whereabouts | v0.5.4+vmware.1* |
* Indique un nouveau composant ou un nouveau numéro de version depuis la version précédente. Pour TKG v2.1, la dernière version précédente était la version 1.6.1.
Pour obtenir la liste complète des versions de composants logiciels fournies avec Tanzu Kubernetes Grid v2.1, reportez-vous aux fichiers ~/.config/tanzu/tkg/bom/tkg-bom-v2.1.yaml et ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.9+vmware.1-tkg.1.yaml. Pour les versions de composants dans les versions précédentes, reportez-vous aux fichiers YAML tkg-bom- et tkr-bom- qui s'installent avec ces versions.
Dans le chemin de mise à niveau de TKG, la version 2.1 suit immédiatement la version 1.6. TKG 2.0 n'est pas une version téléchargeable, mais fait plutôt référence à l'utilisation de la CLI Tanzu dans TKG v1.6 avec un superviseur intégré dans vSphere 8.
Vous pouvez uniquement effectuer la mise à niveau vers Tanzu Kubernetes Grid v2.1.x à partir de la version 1.6.x. Si vous souhaitez effectuer une mise à niveau vers Tanzu Kubernetes Grid v2.1.x à partir d'une version antérieure à la version 1.6.x, vous devez d'abord effectuer la mise à niveau vers la version 1.6.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 1.21.x vers la version 1.23.x. Vous devez mettre à niveau un cluster v1.21.x vers la version 1.22.x avant de mettre à niveau le cluster vers la version 1.23.x.
Les dates de publication de Tanzu Kubernetes Grid v2.1 sont les suivantes :
Tanzu Kubernetes Grid v2.1 introduit les nouveaux comportements suivants par rapport à la version 1.6.1, qui est la dernière version précédente.
--include-management-cluster pour tanzu cluster list nécessite l'option -A pour répertorier un cluster de gestion autonome. Avec l'option -A, la commande répertorie les clusters dans tous les espaces de noms.Le plug-in package de la CLI Tanzu utilise des commandes de style kctrl par défaut. Reportez-vous à la section Module tanzu avec kctrl dans la Référence de commande de la CLI Tanzu.
package s'exécutait par défaut avec le mode kctrl désactivé, par exemple en utilisant l'indicateur--generate-default-values-file au lieu de --default-values-file-output avec tanzu package available get pour créer un fichier de valeurs par défaut pour la configuration du module. Reportez-vous aux rubriques sous Modules gérés via CLI dans la documentation de TKG v1.6 pour connaître le fonctionnement du plug-in tanzu package avec le mode kctrl désactivé.AWS_* pour créer un VPC pour un CIDR spécifié. Si vous souhaitez utiliser un nouveau VPC, avant de déployer un cluster de gestion autonome sur AWS, vous devez créer un VPC pour votre déploiement TKG à l'aide de la console AWS.La CLI Tanzu utilise une nouvelle abstraction Cibles (Targets) pour associer différents groupes de commandes au type de serveur auquel s'appliquent les commandes. La commande tanzu context list fait référence au même concept que type de contexte (context type), avec l'indicateur --type. Étant donné que les groupes de commandes sont basés sur des plug-ins de CLI :
k8stmc réservée pour une utilisation ultérieuretanzu cluster pour s'adapter au contexte.Dans TKG v2.1, le seul type de Cible (Target) ou de contexte pris en charge est k8s, qui est également indiqué par :
Kubernetes cluster operations dans la sortie des commandes tanzu helpkubernetes dans la colonne TARGET de la sortie de tanzu plugin listMachineDeploymentClasses Windows et Linux sont déjà définies dans la spécification de la ClusterClass installée via le module tkg-clusterclass-vsphere.Une nouvelle publication, Déploiement et gestion de clusters de gestion autonomes TKG 2.1, 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.
Les problèmes suivants documentés sous Problèmes connus dans Tanzu Kubernetes Grid v1.6.1 sont résolus dans Tanzu Kubernetes Grid v2.1.
Sur vSphere with Tanzu, tanzu cluster list génère une erreur pour les utilisateurs DevOps
Lorsqu'un utilisateur disposant du rôle d'ingénieur DevOps, comme décrit dans Rôles d'utilisateur et workflows vSphere with Tanzu, exécute tanzu cluster list, il peut voir une erreur semblable à Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope.
Cela se produit, car la commande tanzu cluster command sans option -n tente d'accéder à tous les espaces de noms, dont certains peuvent ne pas être accessibles à un utilisateur ingénieur DevOps.
Solution : lors de l'exécution de tanzu cluster list, incluez une valeur --namespace pour spécifier un espace de noms auquel l'utilisateur peut accéder.
Voici les problèmes connus dans Tanzu Kubernetes Grid v2.1.
Échec de la mise à niveau des clusters sur Azure
Sur Azure, la mise à niveau des clusters de gestion et des clusters de charge de travail échoue avec des erreurs telles que context deadline exceeded ou unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Cela se produit, car les opérations sur Azure prennent parfois plus de temps que sur d'autres plates-formes.
Solution : exécutez la commande tanzu management-cluster upgrade ou tanzu cluster upgrade de nouveau, en spécifiant un délai d'expiration plus long dans l'indicateur --timeout. Le délai d'expiration par défaut est 30 ms.
La mise à niveau des clusters ne met pas à jour la version de Kube-VIP
La mise à niveau de clusters de gestion et de charge de travail autonomes vers la version 2.1 ne met pas à niveau leurs kube-vip vers la version actuelle.
Solution : pour les clusters mis à niveau qui utilisent Kube-VIP pour leur point de terminaison de plan de contrôle, tel que configuré avec AVI_CONTROL_PLANE_HA_PROVIDER = false, mettez à jour le composant kube-vip :
Récupérez le fichier de nomenclature TKr actuel utilisé pour la mise à niveau du cluster. Recherchez une copie locale de ce fichier dans ~/.config/tanzu/tkg/bom/ avec un nom de fichier commençant par tkr-``. For example,tkr-bom-v1.24.9+vmware.1-tkg.1.yaml'.
Répertoriez la version actuelle de kube-vip du fichier de nomenclature, par exemple :
$ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.9+vmware.1-tkg.1.yaml | yq '.components.kube-vip'
- version: v0.5.7+vmware.1
images:
kubeVipImage:
imagePath: kube-vip
tag: v0.5.7_vmware.1
Obtenez l'objet kcp pour le cluster. Le nom de cet objet a le format CLUSTER-NAME-control-plane.
default si NAMESPACE n'a pas été défini.Exécutez kubectl edit pour modifier l'objet kcp et mettre à jour le chemin d'accès à kube-vip pour qu'il corresponde à la version actuelle de l'image de nomenclature. Recherchez l'emplacement de ce paramètre en exécutant :
kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
La mise à niveau échoue pour les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure
Dans TKG v2.1, les composants qui transforment un cluster générique en cluster de gestion autonome TKG sont regroupés dans un module Carvel tkg-pkg. Les clusters de gestion autonomes créés à l'origine dans TKG v1.3 ou version antérieure ne disposent pas d'un secret de configuration requis par le processus de mise à niveau pour installer tkg-pkg, ce qui entraîne l'échec de la mise à niveau.
Solution : suivez les étapes supplémentaires répertoriées dans la section Mettre à niveau des clusters de gestion autonomes pour les clusters de gestion autonomes créés dans TKG v1.3 ou version antérieure.
La mise à niveau échoue pour les clusters créés avec le caractère générique (*) dans le paramètre TKG_NO_PROXY
TKG v1.6 n'autorise pas le caractère générique (*) dans les paramètres du fichier de configuration du cluster pour TKG_NO_PROXY. Les clusters créés par les versions précédentes de TKG avec ce paramètre nécessitent un traitement spécial avant la mise à niveau, afin d'éviter l'erreur workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY.
Solution : selon le type de cluster que vous mettez à niveau :
Cluster de gestion :
kubectl du cluster de gestion.Modifiez la commande configMap kapp-controller-config :
kubectl edit cm kapp-controller-config -n tkg-system
Recherchez le champ data.noProxy et modifiez son nom d'hôte générique en supprimant *. Par exemple, remplacez *.vmware.com to .vmware.com
Enregistrer et quitter. Le cluster est prêt à être mis à niveau.
Cluster de charge de travail :
kubectlDéfinissez des variables d'environnement pour le nom et l'espace de noms de votre cluster, par exemple :
CLUSTER_NAME=my-test-cluster
NS=my-test-namespace
Obtenez et décodez les valeurs de données du contrôleur kapp pour le cluster de charge de travail :
kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values"
Modifiez le fichier ${CLUSTER_NAME}-${NS}-kapp-controller-data-values en supprimant * de son paramètre kappController.config.noProxy. Par exemple, modifiez *.vmware.com to .vmware.com.
Recodez le fichier de valeurs de données ${CLUSTER_NAME}-${NS}-kapp-controller-data-values :
cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0
Modifiez le secret ${CLUSTER_NAME}-${NS}-kapp-controller-data-values et mettez à jour son paramètre data.value.yaml en collant la chaîne de valeurs de données récemment codée.
kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"
Enregistrer et quitter. Le cluster est prêt à être mis à niveau.
Les anciennes versions TKr ne sont pas disponibles immédiatement après la mise à niveau du cluster de gestion autonome
La mise à niveau d'un cluster de gestion autonome de TKG v1.6 vers la version 2.1 remplace le contrôleur source TKr par une version plus récente qui prend en charge les clusters basés sur une classe, puis resynchronise les TKr. Par conséquent, une fois la commande tanzu mc upgrade terminée, tanzu cluster available-upgrades get et tanzu kubernetes-release get peuvent ne pas afficher toutes les versions TKr valides et la CLI Tanzu peut ne pas être en mesure de mettre à niveau immédiatement les clusters de charge de travail.
Solution : attendez quelques minutes que les TKr se téléchargent de nouveau.
Le référentiel de modules tanzu-standard n'est pas préinstallé sur les clusters basés sur une classe
Solution : ajoutez le référentiel de modules tanzu-standard en exécutant la commande suivante :
tanzu package repository add tanzu-standard --url projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.0 --namespace tkg-system
Pour plus d'informations, reportez-vous à la section Ajouter un référentiel de modules.
Multus CNI échoue sur medium et les espaces plus petits avec NSX Advanced Load Balancer
Sur vSphere, les clusters de charge de travail avec des nœuds worker medium ou plus petits exécutant le module Multus CNI avec NSX ALB peuvent échouer avec des erreurs Insufficient CPU ou d'autres erreurs.
Solution : pour utiliser Multus CNI avec NSX ALB, déployez des clusters de charge de travail avec des nœuds worker de taille large ou extra-large.
Le fichier de nomenclature TKG contient une version de module cert-manager superflue
Le fichier de nomenclature TKG que la CLI Tanzu installe dans ~/.config/tanzu/tkg répertorie les versions v1.5.3 et v1.7.2 du module cert manager (jetstack_cert-manager). La version correcte à installer est la version 1.5.3, comme décrit dans la section Installer cert-manager.
Solution : installez la version 1.5.3 de cert-manager.
Impossible de déployer un CNI personnalisé
L'option CNI:none ne fonctionne pas sur les clusters de charge de travail déployés à partir d'un cluster de gestion autonome. Les seuls choix disponibles sont antrea (par défaut) et calico.
La désactivation de Pinniped nécessite la suppression manuelle du Secret sur les clusters hérités
Lorsque vous désactivez la gestion des identités externes sur un cluster de gestion, l'objet Pinniped Secret inutilisé reste présent sur les clusters de charge de travail hérités.
Si un utilisateur tente ensuite d'accéder au cluster à l'aide d'un ancien kubeconfig, une fenêtre contextuelle de connexion s'affiche et échoue.
Solution : supprimez manuellement le code Pinniped Secret du cluster hérité, comme décrit dans la section Désactiver la gestion des identités.
Aucune prise en charge du cache de proxy Harbor
Vous ne pouvez pas utiliser Harbor en mode cache de proxy pour exécuter Tanzu Kubernetes Grid dans un environnement à accès restreint à Internet. Les versions antérieures de Tanzu Kubernetes Grid prenaient en charge la fonctionnalité de cache de proxy Harbor.
Solution : aucune.
Les modules ne sont pas conformes au profil PSA de ligne de base par défaut
Avec les contrôleurs PSA sur TKG, dans un état de version d'évaluation technique non pris en charge, certains modules TKG ne sont pas conformes au profil baseline par défaut.
Solution : définissez les étiquettes audit=privileged et warn=privileged dans les espaces de noms de module affectés, comme décrit dans la section Contrôleur d'admission de sécurité d'espace (version d'évaluation technique).
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.
Solution : après avoir créé un cluster de charge de travail basé sur une classe avec l'option de mise à l'échelle automatique de cluster activée, ajoutez manuellement le paramètre de nombre de machines minimal et maximal pour chaque zone de disponibilité, comme décrit dans la section Ajouter manuellement des annotations de taille minimale et maximale.
Les labels et d'autres propriétés de configuration de pool de nœuds ne peuvent pas être modifiés
Vous ne pouvez pas ajouter les propriétés labels, az, nodeMachineType ou les propriétés vSphere à un pool de nœuds existant ni les modifier, comme indiqué dans la section Propriétés de configuration.
Solution : créez un nouveau pool de nœuds dans le cluster avec les propriétés souhaitées, migrez les charges de travail vers le nouveau pool de nœuds et supprimez l'instance d'origine.
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.
Remarqueà partir de la version 4.0, VMware NSX-T Data Center est renommé « VMware NSX ».
La mise en réseau IPv6 n'est pas prise en charge sur vSphere 8
TKG v1.6 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.
Solution : si vous avez besoin ou que vous utilisez actuellement TKG dans un environnement IPv6 sur vSphere, n'installez pas vSphere 8 ni ne procédez à la mise à niveau vers cette version.
Le mode d'entrée NodePortLocal de NSX ALB n'est pas pris en charge pour le cluster de gestion
Dans TKG v1.6, vous ne pouvez pas exécuter NSX Advanced Load Balancer (ALB) en tant que 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 :
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 :
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. La définition de AVI_CONTROLLER_VERSION peut entraîner l'erreur ako operator webhook validation fail
Dans TKG v1.6, la variable de configuration du cluster AVI_CONTROLLER_VERSION n'est pas nécessaire, car l'opérateur AKO détecte automatiquement la version du contrôleur Avi en cours d'utilisation. Reportez-vous au Snapshot du produit pour connaître les versions du contrôleur Avi compatibles.
Si vous définissez cette variable ou si vous incluez un paramètre spec.controllerVersion lors de la personnalisation de votre déploiement AKO, la création du cluster de gestion ou la personnalisation AKO peut échouer avec une erreur webhook validation failed.
Solution : ne définissez pas AVI_CONTROLLER_VERSION dans un fichier de configuration de cluster de gestion et, si vous personnalisez votre déploiement AKO en exécutant kubectl apply -f avec une spécification d'objet AKODeploymentConfig, n'incluez pas de champ spec.controllerVersion dans la spécification.
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.
Solution : après avoir recréé le cluster de gestion, reconfigurez la gestion des identités comme décrit dans Activer et configurer la gestion des identités dans un déploiement existant.
TKG v2.1.0 peut déclencher des analyses de sécurité positives
Les analyses de sécurité de Tanzu Kubernetes Grid (TKG) peuvent produire des résultats positifs pour un ensemble de CVE. VMware les a évaluées et elles ne sont pas exploitables dans le contexte de TKG. Pour plus de détails, contactez votre représentant VMware.
Les opérations de cluster et d'espace qui suppriment des espaces peuvent échouer si DaemonSet est configuré pour restaurer automatiquement des volumes persistants
Dans les installations où un DaemonSet utilise des volumes persistants, la suppression d'une machine peut échouer, car le processus de drainage par défaut ignore les DaemonSets et le système attend indéfiniment que les volumes soient détachés du nœud. Les opérations de cluster affectées incluent la mise à niveau, la réduction de charge et la suppression.
Solution : pour résoudre ce problème, effectuez l'une des opérations suivantes sur chaque nœud worker du cluster avant la mise à niveau, la réduction de la charge ou la suppression du cluster :
Définissez une valeur spec.NodeDrainTimeout pour le nœud. Cela permet au contrôleur de machine de supprimer le nœud à l'expiration du délai d'expiration, même si des volumes lui sont attachés.
Supprimez manuellement chaque espace du nœud.
La modification de l'objet par défaut StorageClass entraîne l'échec du rapprochement dans les clusters de charge de travail
La modification des propriétés d'un objet StorageClass par défaut inclus dans TKG entraîne un échec du rapprochement des modules dans les clusters de charge de travail qui utilisent la classe de stockage.
Solution : pour personnaliser une classe de stockage, créez une définition StorageClass avec une valeur name au lieu de modifier la définition d'objet par défaut, puis reconfigurez le cluster pour utiliser la nouvelle classe de stockage.
La page de téléchargement répertorie les TKr minuscules expérimentales
Sur Customer Connect, la page de téléchargement de TKG répertorie les TKr avec tiny dans leurs noms de fichier, tels que V1.24.9+vmware.1-tiny.1-tkg.1. Elles sont utilisées pour une fonctionnalité expérimentale, actuellement en développement et non prise en charge, qui permet aux clusters de charge de travail TKG de s'exécuter sur des périphériques Edge à nœud unique, avec le plan de contrôle et les nœuds worker s'exécutant sur la même machine virtuelle.
Solution : ne téléchargez pas et n'utilisez pas de TKr tiny, sauf si votre contact VMware vous l'indique.
TMC ne peut pas déployer de clusters basés sur une classe avec des moteurs de service personnalisés.
Tanzu Mission Control, qui s'intègre à TKG, ne peut pas déployer de nouveaux clusters basés sur une classe qui utilisent NSX ALB et sont configurés avec des moteurs de service personnalisés. Cette limitation n'affecte pas la mise à niveau des clusters de charge de travail existants configurés avec des moteurs de service personnalisés.
Pour plus d'informations, reportez-vous aux Notes de mise à jour de Tanzu Mission Control.
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
Tanzu CLI 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.
Windows CMD : caractères superflus dans les en-têtes de colonne de sortie de CLI
Dans l'invite de commande Windows (CMD), la sortie de commande de CLI Tanzu formatée en colonnes inclut des caractères superflus dans les en-têtes de colonne.
Ce problème ne se produit pas avec le terminal Windows ou PowerShell.
Solution : sur les machines de démarrage Windows, exécutez la CLI Tanzu depuis votre terminal Windows.
Erreur AKODeploymentConfig ignorée lors de la création du cluster de gestion
L'exécution tanzu management-cluster create pour créer un cluster de gestion avec les sorties NSX ALB génère l'erreur suivante : no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???. Vous pouvez ignorer cette erreur. Pour plus d'informations, reportez-vous à cet article dans la base de connaissances.
Erreurs machinehealthcheck et clusterresourceset ignorées lors de la création du cluster de charge de travail sur vSphere
Lorsqu'un cluster de charge de travail est déployé sur vSphere à l'aide de la commande tanzu cluster create via vSphere with Tanzu, la sortie peut inclure des erreurs liées à l'exécution de machinehealthcheck et à l'accès aux ressources clusterresourceset, comme indiqué ci-dessous :
Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:Administrator@vsphere.local" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg"
...
Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet"
...
Le cluster de charge de travail a été créé. Vous pouvez ignorer les erreurs.
La CLI indique temporairement de manière incorrecte l'état des nœuds récemment supprimés lorsque les MHC sont désactivés
Lorsque les contrôles de santé de la machine (MHCs) sont désactivés, les commandes de la CLI Tanzu telles que tanzu cluster status peuvent ne pas signaler l'état à jour du nœud pendant la recréation de l'infrastructure.
Solution : aucune.
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.
Avec NSX ALB, impossible de créer des clusters avec des noms identiques
Si vous utilisez NSX Advanced Load Balancer pour les charges de travail (AVI_ENABLE) ou le plan de contrôle (AVI_CONTROL_PLANE_HA_PROVIDER), le contrôleur Avi peut ne pas parvenir à distinguer les clusters portant des noms identiques.
Solution : définissez une valeur de CLUSTER_NAME unique pour chaque cluster :
Clusters de gestion : ne créez pas plusieurs clusters de gestion avec la même valeur CLUSTER_NAME, même à partir de différentes machines de démarrage.
Clusters de charge de travail : ne créez pas plusieurs clusters de charge de travail qui ont la même valeur CLUSTER_NAME et se trouvent également dans le même espace de noms de cluster de gestion, tel que défini par leur valeur NAMESPACE.
L'ajout de la gestion des identités externes à un déploiement existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT factice
L'intégration d'un fournisseur d'identité externe à un déploiement TKG existant peut nécessiter la définition d'une valeur de VSPHERE_CONTROL_PLANE_ENDPOINT factice dans le fichier de configuration du cluster de gestion utilisé pour créer le secret de module complémentaire, comme décrit dans la section Générer le secret de module complémentaire Pinniped pour le cluster de gestion
Un problème de balisage des ressources CAPA entraîne un échec du rapprochement lors du déploiement et de la mise à niveau du cluster de gestion AWS.
En raison d'un problème de balisage des ressources dans le fournisseur d'API de cluster AWS (CAPA, Cluster API Provider AWS) en amont, les déploiements hors ligne ne peuvent pas accéder à l'API ResourceTagging, ce qui entraîne des échecs de rapprochement lors de la création ou de la mise à niveau du cluster de gestion.
Solution : dans un environnement AWS hors ligne, définissez EXP_EXTERNAL_RESOURCE_GC=false dans votre environnement local ou dans le fichier de configuration du cluster de gestion avant d'exécuter tanzu mc create ou tanzu mc upgrade.
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.
Solution : créez uniquement des pools de nœuds dans la même zone de disponibilité que le cluster de gestion autonome.
La suppression du cluster sur AWS échoue si le cluster utilise des ressources de mise en réseau non déployées avec Tanzu Kubernetes Grid.
Les commandes tanzu cluster delete et tanzu management-cluster delete peuvent se bloquer avec des clusters qui utilisent des ressources de mise en réseau créées par AWS Cloud Controller Manager indépendamment du processus de déploiement Tanzu Kubernetes Grid. Ces ressources peuvent inclure des équilibrages de charge et d'autres services de mise en réseau, comme indiqué dans la section The Service Controller de la documentation du fournisseur de cloud AWS Kubernetes.
Pour plus d'informations, reportez-vous à la section Problème de l'API de cluster Drain workload clusters of service Type=Loadbalancer on teardown.
Solution : utilisez kubectl delete pour supprimer des services de type LoadBalancer du cluster. Si cela échoue, utilisez la console AWS pour supprimer manuellement tous les objets LoadBalancer et SecurityGroup créés pour ce service par Cloud Controller Manager.
Attention :: ne supprimez pas les équilibrages de charge ou les groupes de sécurité gérés par Tanzu, qui ont les balises
key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME,value: owned.
Échec de la suppression du cluster lorsque le volume de stockage utilise un compte avec un point de terminaison privé
Avec un cluster de charge de travail Azure dans un groupe de ressources non géré, lorsque le pilote CSI Azure crée un volume persistant qui utilise un compte de stockage avec un point de terminaison privé, il crée une ressource privateEndpoint et une ressource vNet qui ne sont pas supprimées lorsque le volume persistant est supprimé. Par conséquent, la suppression du cluster échoue avec une erreur telle que subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.
Solution : avant de supprimer le cluster Azure, supprimez manuellement l'interface réseau du point de terminaison privé du compte de stockage :
networkinterfaces, sélectionnez la ressource de carte réseau dont la suppression échoue. Les services LoadBalancer pour les clusters de charge de travail basés sur une classe sur Azure nécessitent une configuration manuelle de passerelle ou de serveur frontal
En raison d'une non-correspondance de nom entre AzureClusterName et ClusterName, les services de type LoadBalancer qui sont déployés pour être utilisés par des applications sur des clusters de charge de travail Azure basés sur une classe ne sont pas accessibles depuis Internet.
Solution : fournissez votre propre route pour le service d'équilibrage de charge, par exemple via une passerelle NAT, un proxy ou un autre routage interne, afin de permettre aux nœuds derrière l'équilibrage de charge d'accéder à Internet.
VMware recommande d’utiliser une passerelle NAT, si disponible, pour la connectivité sortante. Si aucune passerelle NAT n’est disponible :
LoadBalancer créée par CAPZ, qui doit avoir le même nom que celle de AzureCluster.Configurez et créez le service à l'aide de la spécification ci-dessous, en définissant la valeur loadBalancerIP sur l'adresse IP publique lorsqu'elle est indiquée par IP-ADDRESS :
apiVersion: v1
kind: Service
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
namespace: sample-app
spec:
# Add the frontend public IP here
loadBalancerIP: IP-ADDRESS
type: LoadBalancer
ports:
- port: 80
selector:
app: guestbook
tier: frontend
Vous ne pouvez pas mettre à niveau les clusters de charge de travail Windows vers la version 1.6
Vous ne pouvez pas mettre à niveau les clusters de charge de travail Windows de TKG v1.5 vers la version 1.6
Solution : après la mise à niveau de votre cluster de gestion vers TKG v1.6, créez un cluster de charge de travail Windows avec une image ISO Windows Server 2019 et migrez toutes les charges de travail du cluster TKG v1.5 vers le cluster v1.6.
Vous ne pouvez pas créer une image de machine Windows sur une machine MacOS
En raison d'un problème avec l'utilitaire open source packer utilisé par Kubernetes Image Builder, vous ne pouvez pas créer une image de machine Windows sur une machine MacOS comme décrit dans la section Images de machine personnalisée Windows.
Solution : Utilisez une machine Linux pour créer vos images de machine Windows personnalisées.
La sauvegarde et la restauration ne sont pas prises en charge pour les clusters de charge de travail Windows
Vous ne pouvez pas sauvegarder et restaurer des clusters de charge de travail Windows.
Solution : Aucune
É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.
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, cloudadmin@vsphere.local, 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.
