VMware Tanzu Kubernetes Grid v2.2 发行说明
除非另有说明，否则这些发行说明适用于 Tanzu Kubernetes Grid (TKG) 的所有 v2.2.x 修补程序版本。
TKG v2.2 作为可下载的 Tanzu CLI 软件包分发，用于部署版本化 TKG 独立管理集群。TKG v2.2 支持使用可在多个基础架构（包括 vSphere 6.7、7 和 8、AWS 和 Azure）上运行的独立管理集群创建和管理工作负载集群。
Tanzu Kubernetes Grid v2.0、v2.2 和 vSphere 8 中的 vSphere with Tanzu 主管
重要vSphere 8.0.1c 和更高版本中的 vSphere with Tanzu 主管运行 TKG v2.2。早期版本的 vSphere 8 运行 TKG v2.0，该版本并非独立于主管发布。从 TKG 2.1 开始，可以使用运行 TKG 2.x 的独立管理集群。更高的 TKG 版本将嵌入到未来 vSphere 更新版本的主管中。因此，给定时间最新vSphere with Tanzu版本中嵌入的 TKG 版本可能与您使用的独立 TKG 版本不同。但是，完全支持与所有 TKG v2.x 版本兼容的 Tanzu CLI 版本与 vSphere 8 中的主管一起使用。
Tanzu Kubernetes Grid v2.2 和 vSphere 7 中的 vSphere with Tanzu
注意与 vSphere 8 中的 TKG 2.x 和 vSphere with Tanzu 主管兼容的 Tanzu CLI 版本与 vSphere 7 中的主管集群不兼容。要在 vSphere 7 上对 vSphere with Tanzu 主管集群使用 Tanzu CLI，请使用 TKG v1.6 中的 Tanzu CLI 版本。要使用与具有主管的 TKG 2.x 兼容的 Tanzu CLI 版本，请升级到 vSphere 8。如果 vSphere with Tanzu 主管集群不存在，可以将独立 TKG 2.x 管理集群部署到 vSphere 7。有关 Tanzu CLI 与 VMware 产品之间兼容性的信息，请参见 Tanzu CLI 文档。
新增功能
Tanzu Kubernetes Grid v2.2.x 包含以下新增功能。
- 支持 Kubernetes v1.25.7、1.24.11 和 1.23.17。请参见下面的 Tanzu Kubernetes Grid v2.2 中支持的 Kubernetes 版本
- 对于独立管理集群和基于类的工作负载集群，可以使用集群配置文件中的
ADDITIONAL_IMAGE_REGISTRY*变量或Cluster对象规范中的additionalImageRegistries设置，为多个专用映像注册表配置信任。请参见基于类的集群的受信任注册表。 - 从 Harbor v2.7.1 中移除
jobservice.scandataExports持久卷声明。如果之前已将 Harbor Scandata Volume EmptyDir Overlay 应用于 Harbor 软件包，请参见更新运行的 Harbor 部署，然后再将 Harbor 软件包更新到 v2.7.1。 - 从 TKG 2.2.0 起，在 Tanzu Kubernetes Grid 上部署 VMware 支持的软件包（如 Harbor、Contour 和 Velero）时，VMware 会为它们提供运行时级别支持。
- vSphere CSI 软件包支持
vsphereCSI.netpermissions配置。
支持的 Kubernetes 和 TKG 版本
随着 TKG v2.2 的推出，VMware 对较旧的 TKG 和 TKr 修补程序版本的支持策略发生了变化，这些版本为 TKG 打包了 Kubernetes 版本。TKG v2.1 和较旧次要 TKG 版本的支持策略无变化。
以下几节总结了在适用于每个 TKG 和 TKr 的支持策略下，对所有当前支持的 TKG 和 TKr 版本的支持。
支持的 Kubernetes 版本
Tanzu Kubernetes Grid 的每个版本都增加了对其管理集群的 Kubernetes 版本以及其他 Kubernetes 版本的支持，这些版本以 Tanzu Kubernetes 版本 (TKr) 分发，除非注明为已知问题。
次要版本：VMware 在发布时支持 TKG v2.2 和 Kubernetes v1.25、v1.24 和 v1.23，并且只要 TKG v2.1 也受支持。一旦 TKG v2.1 达到其“常规支持结束”里程碑，VMware 将不再支持 Kubernetes v1.23 和 v1.24 和 TKG。
修补程序版本：在 VMware 为次要版本发布新的 TKr 修补程序版本后，针对较旧修补程序版本的支持会保留两个月。这为客户提供了 2 个月的时间升级到新的 TKr 修补程序版本。从 TKG v2.2 起，VMware 不支持以前的 Kubernetes 次要版本中的所有 TKr 修补程序版本。
支持的 TKG 和 TKr 版本
当前支持的 TKG 修补程序版本支持如下所示的 TKr 修补程序版本。
| Tanzu Kubernetes Grid 版本 | 管理集群 Kubernetes 版本 | 提供的 Kubernetes (TKr) 版本 |
|---|---|---|
| 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 |
| 1.6.1 | 1.23.10 | 1.23.10、1.22.13、1.21.14 |
| 1.6.0 | 1.23.8 | 1.23.8、1.22.11、1.21.14 |
TKG v2.2.0 支持的 TKr 版本
TKG v2.2.0 根据以下发布日期支持下表中列出的 TKr 修补程序版本：
- v2.2.0：2023 年 5 月 18 日
- v2.1.1：2023 年 3 月 21 日
| Kubernetes 次要版本 | Kubernetes 修补程序版本 | 与 TKG 一起发布 | 支持结束日期 （如果不是最新的） |
|---|---|---|---|
| v1.25 | v1.25.7 | v2.2.0 | 支持的最新版本 |
| v1.24 | v1.24.11 | v2.2.0 | 支持的最新版本 |
| v1.24.10 | v2.1.1 | 2023 年 7 月 11 日 | |
| v1.24.9 | v2.1.0 | 2023 年 5 月 21 日 | |
| v1.23 | v1.23.17 | v2.2.0 | 支持的最新版本 |
| v1.23.16 | v2.1.1 | 2023 年 7 月 11 日 | |
| v1.23.15 | v2.1.0 | 2023 年 5 月 21 日 |
支持的 Tanzu Kubernetes Grid 版本
VMware 支持如下所示的 TKG 版本：
次要版本：VMware 支持遵循 N-2 生命周期策略的 TKG，该策略适用于最新和之前的两个次要 TKG 版本。在 TKG v2.2.0 版本中，不再支持 TKG v1.5。有关详细信息，请参见 VMware 产品生命周期矩阵。
修补程序版本：VMware 不支持以前的所有 TKG 修补程序版本。VMware 发布 TKG 的新修补程序版本后，它将对较旧修补程序版本的支持保留两个月。这为客户提供了 2 个月的时间升级到新的 TKG 修补程序版本。
- 例如，对 TKG v2.2.0 的支持将在 TKG v2.2.1 正式发布两个月后终止。
Tanzu 标准存储库软件包支持说明
VMware 为 VMware Tanzu Standard 存储库中提供的可选软件包提供以下支持：
- VMware 为可选 VMware Tanzu Standard 存储库中部署在 Tanzu Kubernetes Grid 上的软件包提供安装和升级验证。此验证仅限于安装和升级软件包，但包括解决 CVE 所需的任何可用更新。任何错误修复、功能增强和安全修复将在新的软件包版本中提供，但前提是这些版本在上游软件包项目中可用。
- VMware 不会为 Tanzu Standard 存储库提供的组件提供运行时级别支持。VMware 不提供配置和性能相关问题的调试，或调试和修复软件包本身。
有关对 Tanzu Standard 软件包 VMware 支持的详细信息，请参见上面的新增功能和下面的功能行为更改通知。
Tanzu Kubernetes Grid v2.2 的产品快照
Tanzu Kubernetes Grid v2.2 支持以下基础架构平台和操作系统 (OS)，以及集群创建和管理、网络连接、存储、身份验证、备份和迁移以及可观察性组件。Tanzu Kubernetes Grid v2.2.0 中包含括号中列出的组件版本。有关详细信息，请参见组件版本。
| vSphere | AWS | Azure | |
| 基础架构平台 |
|
本机 AWS | 本机 Azure |
| CLI、API 和软件包基础架构 | Tanzu Framework v0.29.0 | ||
| 集群创建和管理 | 核心集群 API (v1.2.8)、集群 API 提供程序 vSphere (v1.5.3) | 核心集群 API (v1.2.8)、集群 API 提供程序 AWS (v2.0.2) | 核心集群 API (v1.2.8)、集群 API 提供程序 Azure (v1.6.3) |
| 使用 TKG 分发的 Kubernetes 节点操作系统 | Photon OS 3、Ubuntu 20.04 | Amazon Linux 2、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
| 构建您自己的映像 | Photon OS 3、Red Hat Enterprise Linux 7*** 和 8、Ubuntu 18.04、Ubuntu 20.04、Windows 2019 | Amazon Linux 2、Ubuntu 18.04、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
| 容器运行时 | Containerd (v1.6.18) | ||
| 容器网络连接 | Antrea (v1.9.0)、Calico (v3.24.1) | ||
| 容器注册表 | Harbor (v2.7.1) | ||
| 输入 | NSX Advanced Load Balancer Essentials 和 Avi 控制器 **** （v21.1.5-v21.1.6、v22.1.2-v22.1.3）、Contour (v1.23.5) | Contour (v1.23.5) | Contour (v1.23.5) |
| 存储 | vSphere 容器存储接口 (v2.7.1*) 和 vSphere 云原生存储 | Amazon EBS CSI 驱动程序 (v1.16.0) 和树内云提供程序 | Azure 磁盘 CSI 驱动程序 (v1.27.0)、Azure 文件 CSI 驱动程序 (v1.26.1) 和树内云提供程序 |
| 身份验证 | 通过 Pinniped (v0.12.1) 的 OIDC、通过 Pinniped (v0.12.1) 和 Dex 的 LDAP | ||
| 可观察性 | Fluent Bit （v1.9.5）、Prometheus （v2.37.0）*****、Grafana （v7.5.17） | ||
| 备份和迁移 | Velero (v1.9.7) | ||
* vsphere_csi_driver 版本。有关 Tanzu Kubernetes Grid v2.2 版本中包含的 vSphere Container Storage Interface 组件的完整列表，请参见组件版本。
** 有关与此版本兼容的 VMware Cloud on AWS SDDC 版本的列表，请参见 VMware 产品互操作性列表。
*** Tanzu Kubernetes Grid v1.6 是支持构建 Red Hat Enterprise Linux 7 映像的最新版本。
****在 vSphere 8 上，要将 NSX Advanced Load Balancer 与 TKG 独立管理集群及其工作负载集群结合使用，您需要 NSX ALB v22.1.2 或更高版本以及 TKG v2.1.1 或更高版本。
***** 如果将集群升级到 Kubernetes v1.25，则必须将 Prometheus 升级到版本 2.37.0+vmware.3-tkg.1。Prometheus 软件包的早期版本（例如版本 2.37.0+vmware.1-tkg.1）与 Kubernetes 1.25 不兼容。
有关 Tanzu Kubernetes Grid v2.2 随附的 Kubernetes 版本的完整列表，请参见上述 Tanzu Kubernetes Grid v2.2 中支持的 Kubernetes 版本。
组件版本
Tanzu Kubernetes Grid v2.2.x 版本包括以下软件组件版本：
| 组件 | TKG v2.2 |
|---|---|
| aad-pod-identity | v1.8.15+vmware.1* |
| addons-manager | v2.2+vmware.1* |
| ako-operator | v1.8.0_vmware.1* |
| alertmanager | v0.25.0_vmware.1* |
| antrea | v1.9.0_vmware.2-tkg.1-advanced* |
| aws-ebs-csi-driver | v1.16.0_vmware.1-tkg.1* |
| azuredisk-csi-driver | v1.27.0_vmware.2-tkg.1* |
| azurefile-csi-driver | v1.26.1_vmware.2-tkg.1* |
| calico | v3.24.1_vmware.1-tkg.2* |
| capabilities-package | v0.29.0-dev-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.25.1+vmware.2* |
| cluster-api-provider-azure | v1.6.3_vmware.2* |
| cluster_api | v1.2.8+vmware.2* |
| cluster_api_aws | v2.0.2+vmware.2* |
| cluster_api_vsphere | v1.5.3+vmware.2* |
| cni_plugins | v1.1.1+vmware.20* |
| configmap-reload | v0.7.1+vmware.2 |
| containerd | v1.6.18+vmware.1* |
| contour | v1.23.5+vmware.1-tkg.1* |
| coredns | v1.9.3_vmware.8* |
| crash-diagnostics | v0.3.7+vmware.6 |
| cri_tools | v1.24.2+vmware.8* |
| 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.3* |
| envoy | v1.24.5_vmware.1* |
| external-dns | v0.12.2+vmware.5* |
| external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.9* |
| fluent-bit | v1.9.5+vmware.1 |
| gangway | v3.2.0+vmware.2 |
| grafana | v7.5.17+vmware.2 |
| guest-cluster-auth-service | v1.3.0* |
| harbor | v2.7.1+vmware.1* |
| image-builder | v0.1.13+vmware.3* |
| image-builder-resource-bundle | v1.25.7+vmware.2-tkg.1* |
| imgpkg | v0.31.1+vmware.1 |
| jetstack_cert-manager | v1.10.2+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.5*、 v1.12.1+vmware.6* |
| k14s_kapp | v0.53.2+vmware.1 |
| k14s_ytt | v0.43.1+vmware.1 |
| kapp-controller | v0.41.7_vmware.1-tkg.1* |
| kbld | v0.35.1+vmware.1 |
| kube-state-metrics | v2.7.0+vmware.2* |
| kube-vip | v0.5.7+vmware.2* |
| kube-vip-cloud-provider* | v0.0.4+vmware.4* |
| kube_rbac_proxy | v0.11.0+vmware.2 |
| kubernetes | v1.25.7+vmware.2* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
| kubernetes-sigs_kind | v1.25.7+vmware.2-tkg.2_v0.17.0* |
| kubernetes_autoscaler | v1.25.0+vmware.1* |
| load-balancer-and-ingress-service （AKO） | v1.9.3_vmware.1-tkg.1* |
| metrics-server | v0.6.2+vmware.1 |
| multus-cni | v3.8.0+vmware.3* |
| pinniped | v0.12.1_vmware.3-tkg.4* |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 |
| prometheus | v2.37.0+vmware.3* |
| prometheus_node_exporter | v1.4.0+vmware.3* |
| pushgateway | v1.4.3+vmware.3* |
| sonobuoy | v0.56.16+vmware.1* |
| standalone-plugins-package | v0.29.0-dev-standalone-plugins* |
| tanzu-framework | v0.29.0* |
| tanzu-framework-addons | v0.29.0* |
| tanzu-framework-management-packages | v0.29.0-tf* |
| tkg-bom | v2.2.0* |
| tkg-core-packages | v1.25.7+vmware.2-tkg.1* |
| tkg-standard-packages | v2.2.0* |
| tkg-storageclass-package | v0.29.0-tkg-storageclass* |
| tkg_telemetry | v2.2.0+vmware.1* |
| velero | v1.9.7+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.5+vmware.1* |
| velero-plugin-for-csi | v0.3.5+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.5+vmware.1* |
| velero-plugin-for-vsphere | v1.4.3+vmware.1* |
| vendir | v0.30.1+vmware.1 |
| vsphere_csi_driver | v2.7.1+vmware.2* |
| whereabouts | v0.5.4+vmware.2* |
* 表示自上一版本以来的新组件或版本更新。TKG v2.1.1 是 v2.2.0 之前的版本。
有关 TKG v2.2 随附的软件组件版本的完整列表，请使用 imgpkg 提取存储库包，然后列出其内容。对于 TKG v2.2.0，例如：
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree
诸如以下内容的本地 BOM 文件也会列出软件包版本，但可能不是最新的：
~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml
支持的升級路徑
在 TKG 升级途径中，v2.2 紧跟 v2.1.1。
只能从 v2.1.x 升级到 Tanzu Kubernetes Grid v2.2.x。如果要从低于 v2.1.x 的版本升级到 Tanzu Kubernetes Grid v2.2.x，必须先升级到 v2.1.x。
在工作负载集群上升级 Kubernetes 版本时，无法跳过次要版本。例如，无法将 Tanzu Kubernetes 集群直接从 v1.23.x 升级到 v1.25.x。必须先将 v1.23.x 集群升级到 v1.24.x，然后再将集群升级到 v1.25.x。
发布日期
Tanzu Kubernetes Grid v2.2 发布日期为：
- v2.2.0：2023 年 5 月 9 日
Tanzu Kubernetes Grid v2.2 中的行为变化
与以前最新版 v2.1.1 相比，Tanzu Kubernetes Grid v2.2 中引入了以下新行为。
未来行为更改通知
本节提供了将在未来版本（TKG v2.2 版本之后的版本）中生效的行为更改的预先通知。
VMware Tanzu Standard 存储库
重要Tanzu Kubernetes Grid v2.2.x 是 TKG 的最后一个次要版本，其中 VMware Tanzu Standard 存储库打包为该版本的一部分。TKG v2.2.x 和早期版本在 Tanzu Standard Repository 中包含一组可选软件包，您可以在集群上部署这些软件包以添加日志转发、输入控制、容器注册表等功能。在未来的 TKG v2.x 次要版本中，安装 Tanzu CLI 并部署管理集群时，不会自动下载 Tanzu Standard 存储库。要使用此可选软件包集，您需要使用 Tanzu CLI 下载并手动添加这些软件包。通过将可选软件包与 TKG 版本分开，VMware 可以在 TKG 版本之外提供增量软件包更新，并且能够更迅速地响应 CVE。
弃用通知
- 在未来版本的 TKG 中，将移除 Dex 组件，因为 Pinniped 不再需要该组件即可与 LDAP 提供程序配合使用。进行此更改后，LDAP 身份验证的以下集群配置变量将变为必需：
LDAP_BIND_DN和LDAP_BIND_PASSWORD。有关详细信息，请参见《配置文件变量参考》中的身份提供程序 LDAP。
用户文档
部署和管理 TKG 2.2 独立管理集群中包含与“将 TKG 与 vSphere with Tanzu 主管配合使用”无关的独立管理集群的特定主题。
有关详细信息，请参见“VMware Tanzu Kubernetes Grid 文档 (VMware Tanzu Kubernetes Grid Documentation)”页面上的找到适用于您的部署的正确 TKG 文档。
已解决的问题
较低的 Tanzu Kubernetes Grid 版本中记录为已知问题的以下问题已在 Tanzu Kubernetes Grid v2.2.0 中得到解决。
-
从旧版配置文件创建
ClusterClass配置文件，--dry-run包括空的 Antrea 配置使用
tanzu cluster create --dry-run -f以及包含ANTREA_NODEPORTLOCAL条目的旧版配置文件创建ClusterClass配置文件会导致自动生成的 Antrea 配置不包含任何标签，从而导致 Antrea 无法成功协调。 -
对于 TKG 上处于不受支持的技术预览版状态的 PSA 控制器，某些 TKG 软件包不符合默认的
baseline配置文件。 -
运行
tanzu cluster create时出现验证错误默认情况下，将平面键值配置文件传递到
tanzu cluster create的--file选项时，命令会将该配置文件转换为 Kubernetes 样式的对象规范文件，然后退出。此行为由auto-apply-generated-clusterclass-based-configuration功能控制，该功能默认设置为false。在某些情况下，当您将由--file选项生成的 Kubernetes 样式对象规范文件传递到tanzu cluster create时，命令将失败，并显示类似以下内容的错误：Error: workload cluster configuration validation failed...传递由
--dry-run选项生成的 Kubernetes 样式对象规范文件到tanzu cluster create时，也可能会出现此错误。 -
tanzu cluster create不会正确验证使用非默认 Kubernetes 版本生成的集群规范如果使用创建基于类的集群 中所述的两个步骤之一从配置文件创建基于类的工作负载集群，并在第一步中指定
--tkr值以将集群建立在非默认版本的 Kubernetes 上时，第二步可能会失败，并显示验证错误。
已知问题
以下是 Tanzu Kubernetes Grid v2.2.x 中的已知问题。v2.2.0 中存在的任何已知问题如果在后续的 v2.2.x 修补程序版本中已解决，都会列在修复这些问题的修补程序版本的已解决问题下。
您可以在管理集群问题故障排除和工作负载集群问题故障排除或VMware 知识库文章中找到常见问题的其他解决方案。
软件包
-
在具有 NSX ALB v21.1.4 或更早版本的 vSphere 6.7 上安装 Grafana 失败
您无法将 Grafana v7.5.17 软件包安装到 vSphere v6.7U3 上使用 NSX ALB v21.1.4 或更低版本作为负载均衡器服务的 TKG v2.2 工作负载集群。
解决办法：如果工作负载集群使用 Grafana 和 NSX ALB，请先将 vSphere 升级到 v7.0+ 并将 ALB NSX 升级到 v21.1.5+，然后再将 TKG 升级到 v2.2。
-
当执行 ID 超过 1000000+ 时，Harbor CVE 导出可能会失败
Harbor v2.7.1（TKG v2.2 打包的版本）存在已知问题，即在执行主键自动增量 ID 增加到 1000000+ 时，CVE 报告导出错误“404 页面未找到 (404 page not found)”。
此 Harbor 问题已在更高版本的 Harbor 中解决，并准备包含在更高版本的 TKG 中。
-
Harbor 的 Notary 组件中的 Golang 漏洞
CVE-2021-33194 存在于 Notary 中。如 Harbor v2.6.0 发行说明中注释，Notary 组件已在 Harbor v2.6+ 中已被弃用，并计划在将来的版本中删除。VMware 建议使用 Sigstore Cosign 而不是 Notary 进行容器签名和验证。
-
运行
tanzu package repository add将tanzu-standard存储库添加到 vSphere 上的单节点集群（技术预览版）中所述类型的单节点集群可能失败。发生这种情况的原因是，单节点集群使用
cert-manager作为核心加载项进行引导，这与tanzu-standard存储库中不同的cert-manager软件包相冲突。解决办法：在添加
tanzu-standard存储库之前，请按照安装证书管理器中所述修补cert-manager软件包注释。
集群操作
-
无法基于具有 Antrea CNI 的非当前 TKr 版本创建新的工作负载集群
您无法创建使用 Antrea CNI 并运行以前版本的 TKG 附带的 Kubernetes 版本（如 Kubernetes v1.23.10）的新工作负载集群，这是 TKG v1.6.1 中的默认 Kubernetes 版本，如 Tanzu Kubernetes Grid v2.2 中支持的 Kubernetes 版本中所列。
解决办法：创建运行 Kubernetes 1.25.7、1.24.11 或 1.23.17 的工作负载集群。Kubernetes 项目建议在当前任何次要版本的最新修补程序版本上运行组件。
-
由于集群 API 中的标签传播问题，集群的
MachineDeployment对象中未设置基于类的工作负载集群的集群配置文件中的AUTOSCALER_MIN_SIZE_*和AUTOSCALER_MAX_SIZE_*设置。解决办法：在启用集群 Autoscaler 的情况下创建基于类的工作负载集群后，为每个 AZ 手动添加计算机计数最小值和最大值设置，如手动添加最小和最大的大小注释中所述。
-
您无法添加或更改现有节点池的
labels、az、nodeMachineType或者 vSphere 属性（如配置属性中所述）。解决办法：使用所需属性在集群中创建一个新节点池，将工作负载迁移到该新节点池，然后删除原始节点池。
-
如果在管理集群上运行
tanzu cluster scale并将偶数传递到--controlplane-machine-count选项，TKG 不会扩展控制平面节点，并且 CLI 不会输出错误。要保持仲裁数，控制平面节点计数应始终为奇数。解决办法：不要将控制平面节点计数缩放为偶数。
-
基于类的集群名称具有 25 个字符的限制，NSX ALB 作为负载均衡器服务或输入控制器
将 NSX Advanced Load Balancer (ALB) 用作基于类的集群的负载均衡器服务或具有独立管理集群的输入控制器时，其应用程序名称包括集群名称和
load-balancer-and-ingress-service、AKO 软件包的内部名称。当组合名称超过 Avi 控制器应用的 64 个字符限制时，tanzu cluster create命令可能会失败，并显示错误：“找不到avi-system命名空间 （the avi-system namespace was not found）”。解决办法：使用 NSX ALB 作为负载均衡器或输入控制器时，将基于类的集群名称长度限制为 25 个字符或更少。
网络
注意对于 v4.0+，VMware NSX-T Data Center 被重命名为“VMware NSX”。
-
TKG v2.2 在 vSphere 8 上不支持 IPv6 网络连接，但如 IPv6 网络连接中所述，它在 vSphere 7 上支持使用 Kube-Vip 进行单堆栈 IPv6 网络连接。
解决办法：如果需要或当前在 vSphere 上的 IPv6 环境中使用 TKG，请不要安装或升级到 vSphere 8。
-
管理集群不支持 NSX ALB
NodePortLocal输入模式在 TKG v2.2 中，无法将 NSX Advanced Load Balancer (ALB) 作为服务类型以输入模式
NodePortLocal运行，以获取管理集群的流量。此问题不会影响对
NodePortLocal输入工作负载集群的支持，如 NodePortLocal 模式下的 L7 输入中所述。解决办法：在将
AVI_INGRESS_SERVICE_TYPE设置为NodePort或ClusterIP的情况下配置管理集群。默认值为NodePort。 -
对于较旧的 NSX-T 版本和 Photon 3 或具有 Linux 内核 5.8 虚拟机的 Ubuntu，管理集群创建失败或性能下降
部署具有以下基础架构和配置的管理集群可能会失败或导致 Pod 之间的流量受限：
- 具有以下任一版本 NSX-T 的 vSphere ：
- 启用了增强型数据路径的 NSX-T v3.1.3
- 低于 v3.1.3 的 NSX-T v3.1.x
- 低于 v3.0.2 热修补程序的 NSX-T v3.0.x
- NSX-T v2.x。这包括使用 NSX-T v2.5 的 Azure VMware 解决方案 (AVS) v2.0
- 基础映像：Photon 3 或具有 Linux 内核 5.8 的 Ubuntu
此组合在较旧版本的 NSX-T 和 Antrea CNI 之间暴露了校验和问题。
TMC：如果管理集群已在 Tanzu Mission Control (TMC) 中注册，则此问题没有解决办法。否则，请参见下面的解决办法。
解决办法：
- 部署配置了
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD设置为"true"的工作负载集群。此设置将停用 Antrea 的 UDP 校验和卸载，从而避免某些底层网络和物理网卡网络驱动程序的已知问题。 - 升级到 NSX-T v3.0.2 热修补程序、v3.1.3 或更高版本，而不启用增强型数据路径
- 将 Ubuntu 基础映像与 Linux 内核 5.9 或更高版本结合使用。
- 具有以下任一版本 NSX-T 的 vSphere ：
身份和访问管理
-
按照备份和还原管理集群和工作负载集群基础架构（技术预览版）中所述重新创建独立管理集群后，用户无法通过 Pinniped 身份验证登录到工作负载集群。
解决办法：重新创建管理集群后，按照在现有部署中启用和配置身份管理中所述重新配置身份管理。
-
CVE-2022-41723 存在于 Pinniped v0.12.1 中。利用此漏洞可能会导致 Pinniped 服务的 DDoS 攻击。要将被利用概率降到较低水平，可以使用输入筛选以仅允许来自已知 IP 地址（如企业 VPN CIDR）的流量。该漏铜将在 Tanzu Kubernetes Grid 的未来版本中解决。
-
为主管部署的工作负载集群生成并使用 kubeconfig 会导致出现“未知标记”错误
在 Tanzu CLI v0.25.0 及更早版本中，
cluster插件会生成可能包含参数--concierge-is-cluster-scoped的kubeconfig文件。Tanzu CLI v0.29.0pinniped-auth插件无法识别此参数。此临时回归问题已在后续版本中得到修复。由于 vSphere 8.0 嵌入了 v0.25.0
cluster插件，因此从 CLI v0.29.0（TKG v2.2 中的版本）连接到主管部署的集群时可能会生成以下错误：Error: unknown flag: --concierge-is-cluster-scoped Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1解决办法：在
kubeconfig文件中，移除args下设置--concierge-is-cluster-scoped的行。
存储
-
无法启用工作负载集群以在多个数据存储之间分配存储，如部署使用数据存储集群的集群中所述。如果将数据存储集群中的多个数据存储标记为工作负载集群存储策略的基础，则工作负载集群仅使用其中一个数据存储。
解决办法：无
Tanzu CLI
-
使用 CLI 部署管理集群时，密码中不能使用非字母数字字符
# ` ^ | / ? % ^ { [ ] } \ " < >。此外，使用 UI 部署管理集群时，无法在 HTTP/HTTPS 代理密码中使用任何非字母数字字符。解决办法：使用 CLI 部署管理群集时，您可以密码中使用
# ` ^ | / ? % ^ { [ ] } \ " < >以外的非字母数字字符。 -
Tanzu CLI 在具有 ARM 处理器的 macOS 计算机上不起作用
Tanzu CLI v0.11.6 在具有 ARM (Apple M1) 芯片的 macOS 计算机上不起作用，如访达 (Finder) > 关于本机 (About This Mac) > 概览 (Overview) 下所示。
解决办法：使用具有 Linux 或 Windows 操作系统的引导计算机，或使用具有 Intel 处理器的 macOS 计算机。
-
management-cluster命令组列出了tanzu management-cluster osimage。此功能目前正在开发中，并保留以供将来使用。解决办法：请勿使用
tanzu management-cluster osimage。 -
tanzu package available get的--default-values-file-output选项输出 Harbor 软件包的不完整配置模板文件运行
tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH创建 Harbor 软件包的不完整配置模板文件。要获取完整文件，请使用imgpkg pull命令，如为服务注册表安装 Harbor 中所述。
vSphere
-
使用
small节点创建的节点池可能会停滞在Provisioning状态。使用配置为
small的节点SIZE创建的节点池可能会停滞在Provisioning状态，并且永远不会进入Running状态。解决办法：为节点池配置至少
medium大小的节点。
AWS
-
在 AWS 管理集群部署和升级期间，CAPA 资源标记问题导致协调失败。
由于上游集群 API 提供程序 AWS (CAPA) 中的资源标记问题，脱机部署无法访问
ResourceTaggingAPI，从而导致在创建或升级管理集群期间出现协调失败。解决办法：在脱机 AWS 环境中，先在本地环境或管理集群配置文件中设置
EXP_EXTERNAL_RESOURCE_GC=false，然后再运行tanzu mc create或tanzu mc upgrade。 -
AWS 上的工作负载集群节点池必须与独立管理集群位于同一可用区中。
创建配置了与管理集群所在位置不同的
az的节点池时，新节点池可能会一直停滞在ScalingUp状态（如tanzu cluster node-pool list列出），并且永远不会达到Ready状态。解决办法：仅在与独立管理集群相同的 AZ 中创建节点池。
-
如果集群使用的网络资源不是通过 Tanzu Kubernetes Grid 部署，则删除 AWS 上的集群将失败。
tanzu cluster delete和tanzu management-cluster delete命令在使用 AWS Cloud Controller Manager 创建的网络连接资源的集群中可能会挂起，而与 Tanzu Kubernetes Grid 部署过程无关。此类资源可能包括负载均衡器和其他网络服务，如 Kubernetes AWS 云提供商文档中的服务控制器中所列。有关详细信息，请参见集群 API 问题引流服务类型的工作负载集群 = 拆卸时的 Loadbalancer。
解决办法：使用
kubectl delete从集群中删除类型为LoadBalancer的服务。或者，如果失败，请使用 AWS 控制台手动删除 Cloud Controller 管理器为此服务创建的任何LoadBalancer和SecurityGroup对象。注意
请勿删除由 Tanzu 管理的负载均衡器或安全组，这些负载均衡器或安全组具有标记
key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME，value: owned。
Azure
-
对于未受管资源组中的 Azure 工作负载集群，当 Azure CSI 驱动程序创建持久卷 (PV)（该持久卷使用具有专用端点的存储帐户）时，它会创建一个
privateEndpoint和vNet资源，但删除 PV 时不会删除这些资源。因此，删除集群将失败，并显示类似以下内容的错误：subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use。解决办法：在删除 Azure 集群之前，手动删除存储帐户专用端点的网络接口：
- 从浏览器登录到 Azure 资源浏览器。
- 单击左侧的订阅 (subscriptions)，然后展开您的订阅。
- 在订阅下，展开左侧 resourceGroups，然后展开 TKG 部署的资源组。
- 在资源组下，展开提供程序 (providers) > Microsoft.Network > networkinterfaces。
- 在
networkinterfaces下，选择无法删除的网卡资源。 - 单击顶部的读取/写入 (Read/Write) 按钮，然后单击下面的操作（张贴、删除）[Actions (POST， DELETE)] 选项卡。
- 单击删除 (Delete)。
- 删除网卡后，删除 Azure 集群。
Windows
-
在 Internet 受限的环境中不支持 Windows 工作线程
Vmware 不支持在代理或气隙环境中具有 Windows Worker 节点的 TKG 工作负载集群。
解决办法：请联系您的 VMware 代表。某些 TKG 用户构建了 Windows 自定义映像，并在脱机环境中 Windows 工作线程运行工作负载集群，例如，如此非官方存储库中所述。
Image-Builder
-
运行 Kubernetes Image Builder 以创建自定义 Linux 自定义计算机映像时，
goss测试python-netifaces、python-requestsebtables失败。命令输出会报告故障。可以忽略这些错误；它们不会阻止映像构建成功。
AVS
在 Azure vSphere 解决方案 (AVS) 上，删除 vSphere CSI 持久卷 (PV) 可能会失败。删除 PV 需要 cns.searchable 权限。未使用此权限创建 AVS 的默认管理员帐户 ([email protected])。有关详细信息，请参见 vSphere 角色额权限。
解决办法：要删除 AVS 上的 vSphere CSI PV，请联系 Azure 支持部门。
