VMware Tanzu Kubernetes Grid v2.1 发行说明
除非另有说明，否则这些发行说明适用于 Tanzu Kubernetes Grid (TKG) 的所有 v2.1.x 修补程序版本。
TKG v2.1 作为可下载的 Tanzu CLI 软件包分发，用于部署版本化 TKG 独立管理集群。TKG v2.1 是 TKG 的第一个版本，它支持创建和管理基于类的工作负载集群以及可在多个基础架构上运行的独立管理集群，包括 vSphere、AWS 和 Azure。
Tanzu Kubernetes Grid v2.x 和 vSphere with Tanzu vSphere 8 中的主管
重要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 vSphere 7 中的 v2.1 和 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.1.x 包含以下新增功能。
Tanzu Kubernetes Grid v2.1.1
Tanzu Kubernetes Grid v2.1.1 版的新增功能：
- 支持将 vSphere 8 上的 NSX Advanced Load Balancer v22.1.2 或更高版本与 TKG 独立管理集群及其工作负载集群结合使用。
- 您可以安装 FIPS 版本的 TKG v2.1.1。有关详细信息，请参见支持 FIPS 的版本。
- 配置变量：
Tanzu Kubernetes Grid v2.1.0
Tanzu Kubernetes Grid v2.1.0 版的新增功能：
- TKG 2.x 支持：在具有独立管理集群的 vSphere、AWS 或 Azure 上，按照工作负载集群类型中所述配置并创建基于类的集群。
- 您可以安装 FIPS 版本的 TKG v2.1.0。有关详细信息，请参见支持 FIPS 的版本。
- Tanzu CLI：
- 默认情况下，
package插件使用kctrl样式命令。请参见《Tanzu CLI 命令参考》中的 tanzu 软件包。 isolated-cluster插件download-bundle和upload-bundle命令可以检索和传输 TKG 所需的所有容器映像，如准备 Internet 受限环境中所述。tanzu cluster list的-A和--all-namespaces选项包括由管理集群管理且用户具有查看权限或更多权限的所有命名空间中的集群，而不仅仅是默认命名空间。context命令组允许用户设置和管理 Tanzu CLI 的上下文，其中包括目标服务器和要应用的kubeconfig。请参见 《Tanzu CLI 命令参考》中的 tanzu 上下文。- 未来版本将弃用
tanzu login命令，以支持tanzu context命令。
- 未来版本将弃用
- 插件的
Target类别更改了 CLI 行为并添加了保留的功能以供将来使用，如下面的 Tanzu Kubernetes Grid v2.1 中的行为变化中所述。 auto-apply-generated-clusterclass-based-configuration功能会在将旧版集群配置文件传递到tanzu cluster create时自动应用 Tanzu CLI 生成的基于类的集群配置。默认情况下，该功能设置为false。请参见《Tanzu CLI 架构和配置》中的功能。allow-legacy-cluster功能允许您创建基于计划的集群。默认情况下，该功能设置为false。请参见《Tanzu CLI 架构和配置》中的功能。tanzu mc credentials update和tanzu cluster credentials update命令会添加 Azure 的选项。这包括--azure-client-id、--azure-client-secret和--azure-tenant-id。
- 默认情况下，
- 基于类的集群和独立管理集群支持以下集群配置变量，如配置文件变量参考中所述：
- 节点配置：
CONTROL_PLANE_NODE_LABELS、CONTROL_PLANE_NODE_NAMESERVERS、CONTROL_PLANE_NODE_SEARCH_DOMAINS、WORKER_NODE_NAMESERVERS、WORKER_NODE_SEARCH_DOMAINS ExtraArgs属性：APISERVER_EXTRA_ARGS、CONTROLPLANE_KUBELET_EXTRA_ARGS、ETCD_EXTRA_ARGS、KUBE_CONTROLLER_MANAGER_EXTRA_ARGS、KUBE_SCHEDULER_EXTRA_ARGS、WORKER_KUBELET_EXTRA_ARGS- 速率限制和同步：
NTP_SERVERS、APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
- 节点配置：
- 集群可以自动续订控制平面节点虚拟机证书；请参见控制平面节点证书自动续订。
- (vSphere) 可以部署同时运行 Windows 和 Linux 工作节点的多操作系统工作负载集群，如部署多操作系统工作负载集群中所述。在此版本中，Windows 工作负载集群将替换为多操作系统工作负载集群。有关详细信息，请参见 Tanzu Kubernetes Grid v2.1 中的行为变更。
- 您可以在多个可用区中部署具有工作线程的多操作系统工作负载集群，如 部署工作负载集群到多个可用区（vSphere 技术预览版）中所述。
- (vSphere) 可以在分配的 IP 池上为基于类的工作负载集群配置集群内 IP 地址管理 （IPAM），从而无需在节点计数或实例发生更改时配置 DHCP 预留。
- (vSphere) 集群节点
Machine对象标签标识其 ESXi 主机的地址，以支持使用 nodeSelector 在专用硬件上运行特定工作负载。 - (vSphere) Ubuntu OVA 映像使用统一可扩展固件接口（Unified Extensible Firmware Interface，UEFI）模式进行引导，以取代传统的 BIOS 固件模式。UEFI 模式启用图形处理单元（GRAPHIC Processing Unit，GPU）工作负载并增强节点安全性。有关 Ubuntu 上 UEFI 的详细信息，请参见 Ubuntu 文档中的 UEFI。
- 您可以将 Kube-VIP 用作工作负载的 L4
LoadBalancer服务；请参见 Kube-VIP 负载均衡器（技术预览版）。 - 您可以为边缘应用程序部署在单个 ESXi 主机上同时运行托管工作负载和控制平面基础架构的单节点工作负载集群，如 vSphere 上的单节点集群（技术预览版）中所述。
- 您可以基于
tinyTKr 部署最小的单节点集群，从而最大限度减少其占用空间。
- 您可以基于
- 您可以备份和部署集群基础架构，如备份和还原管理和工作负载集群基础架构中所述（技术预览版）。
- 支持 Pod 安全准入 (PSA) 控制器，以替换命名空间中所述的 Pod 安全策略，如 Pod 安全准入控制器中所述（技术预览版）。
Tanzu Kubernetes Grid v2.1 中支持的 Kubernetes 版本
Tanzu Kubernetes Grid 的每个版本都增加了对其管理集群的 Kubernetes 版本以及其他 Kubernetes 版本的支持，这些版本以 Tanzu Kubernetes 版本 (TKr) 分发。
任何版本的 Tanzu Kubernetes Grid 都支持 Kubernetes 前两行次要行中的所有 TKr 版本，除非注明为已知问题。例如，TKG v2.1.x 支持下面列出的 Kubernetes 版本 v1.23.x 和 v1.22.x，但不支持 v1.21.x 或更低版本。
| Tanzu Kubernetes Grid 版本 | 管理集群 Kubernetes 版本 | 提供的 Kubernetes (TKr) 版本 |
|---|---|---|
| 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 |
| 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 的产品快照
Tanzu Kubernetes Grid v2.1 支持以下基础架构平台和操作系统 (OS)，以及集群创建和管理、网络连接、存储、身份验证、备份和迁移以及可观察性组件。Tanzu Kubernetes Grid v2.1.1 中包含括号中列出的组件版本。有关详细信息，请参见组件版本。
| vSphere | AWS | Azure | |
| 基础架构平台 |
|
本机 AWS | 本机 Azure |
| CLI、API 和软件包基础架构 | Tanzu Framework v0.28.1 | ||
| 集群创建和管理 | 核心集群 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.6) | ||
| 容器网络连接 | Antrea (v1.7.2)、Calico (v3.24.1) | ||
| 容器注册表 | Harbor (v2.6.3) | ||
| 输入 | NSX Advanced Load Balancer Essentials 和 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) |
| 存储 | vSphere 容器存储接口 (v2.5.2*) 和 vSphere 云原生存储 | Amazon EBS CSI 驱动程序 (v1.8.0) 和树内云提供程序 | Azure 磁盘 CSI 驱动程序 (v1.19.0)、Azure 文件 CSI 驱动程序 (v1.21.0) 和树内云提供程序 |
| 身份验证 | 通过 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.5) | ||
* vsphere_csi_driver 版本。有关 Tanzu Kubernetes Grid v1.6 版本中包含的 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 或更高版本。
有关 Tanzu Kubernetes Grid v2.1 随附的 Kubernetes 版本的完整列表，请参见上述 Tanzu Kubernetes Grid v2.1 中支持的 Kubernetes 版本。
组件版本
Tanzu Kubernetes Grid v2.1.x 版本包括以下软件组件版本：
| 组件 | TKG v2.1.1 | TKG v2.1.0 |
|---|---|---|
| aad-pod-identity | v1.8.13+vmware.2* | v1.8.13+vmware.1* |
| addons-manager | v2.1+vmware.1-tkg.3 | v2.1+vmware.1-tkg.3 |
| ako-operator | v1.7.0+vmware.3 | v1.7.0+vmware.3* |
| alertmanager | v0.24.0+vmware.2* | v0.24.0+vmware.1 |
| antrea | v1.7.2+vmware.1-advanced | v1.7.2+vmware.1-advanced* |
| aws-ebs-csi-driver | v1.8.0+vmware.2 | v1.8.0+vmware.2* |
| azuredisk-csi-driver | v1.19.0+vmware.1 | v1.19.0+vmware.1* |
| azurefile-csi-driver* | v1.21.0+vmware.1 | v1.21.0+vmware.1 |
| calico_all | v3.24.1+vmware.1 | v3.24.1+vmware.1* |
| capabilities-package | v0.28.1-dev-capabilities* | v0.28.0-dev-capabilities* |
| carvel-secretgen-controller | v0.11.2+vmware.1 | v0.11.2+vmware.1* |
| 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.9+vmware.1* |
| cloud_provider_vsphere | v1.24.3+vmware.1 | v1.24.3+vmware.1* |
| cluster-api-provider-azure | v1.6.3_vmware.1* | v1.6.1_vmware.1* |
| cluster_api | v1.2.8+vmware.1 | v1.2.8+vmware.1* |
| cluster_api_aws | v2.0.2+vmware.1 | v2.0.2+vmware.1* |
| cluster_api_vsphere | v1.5.3+vmware.1l* | v1.5.1+vmware.1l* |
| cni_plugins | v1.1.1+vmware.18* | v1.1.1+vmware.16* |
| configmap-reload | v0.7.1+vmware.2* | v0.7.1+vmware.1 |
| containerd | v1.6.6+vmware.3* | v1.6.6+vmware.1* |
| contour | v1.22.3+vmware.1 | v1.22.3+vmware.1* |
| coredns | v1.8.6+vmware.17* | v1.8.6+vmware.15* |
| crash-diagnostics | v0.3.7+vmware.6 | v0.3.7+vmware.6* |
| cri_tools | v1.23.0+vmware.8* | v1.23.0+vmware.7* |
| csi_attacher | v3.5.0+vmware.1、 v3.4.0+vmware.1、 v3.3.0+vmware.1 |
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 |
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 |
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 |
v3.2.1+vmware.1*、 v3.1.0+vmware.2、 v3.0.0+vmware.1 |
| dex | v2.35.3+vmware.2 | v2.35.3+vmware.2* |
| envoy | v1.23.3+vmware.2 | v1.23.3+vmware.2* |
| external-dns | v0.12.2+vmware.4 | v0.12.2+vmware.4* |
| external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
v6.0.1+vmware.1、 v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.6* | v3.5.6+vmware.3* |
| fluent-bit | v1.9.5+vmware.1 | v1.9.5+vmware.1* |
| gangway | v3.2.0+vmware.2 | v3.2.0+vmware.2 |
| grafana | v7.5.17+vmware.1* | v7.5.16+vmware.1 |
| guest-cluster-auth-service | v1.2.0* | v1.1.0* |
| harbor | v2.6.3+vmware.1 | v2.6.3+vmware.1* |
| image-builder | v0.1.13+vmware.2 | v0.1.13+vmware.2* |
| image-builder-resource-bundle | v1.24.10+vmware.1-tkg.1* | v1.24.9+vmware.1-tkg.1* |
| imgpkg | v0.31.1+vmware.1 | v0.31.1+vmware.1* |
| jetstack_cert-manager | v1.10.1+vmware.1 | v1.10.1+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.3*、 v1.12.1+vmware.5* |
v1.15.6+vmware.2、 v1.12.1+vmware.3* |
| k14s_kapp | v0.53.2+vmware.1 | v0.53.2+vmware.1* |
| k14s_ytt | v0.43.1+vmware.1 | v0.43.1+vmware.1* |
| kapp-controller | v0.41.5+vmware.1、 v0.38.5+vmware.2 |
v0.41.5+vmware.1*、 v0.38.5+vmware.2* |
| kbld | v0.35.1+vmware.1 | v0.35.1+vmware.1* |
| kube-state-metrics | v2.6.0+vmware.2* | v2.6.0+vmware.1* |
| kube-vip | v0.5.7+vmware.1 | v0.5.7+vmware.1* |
| kube-vip-cloud-provider* | v0.0.4+vmware.2 | v0.0.4+vmware.2 |
| kube_rbac_proxy | v0.11.0+vmware.2 | v0.11.0+vmware.2 |
| kubernetes | v1.24.10+vmware.1* | v1.24.9+vmware.1* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
v1.4.0+vmware.1*、 v1.3.0+vmware.1 |
| kubernetes-sigs_kind | v1.24.10+vmware.1-tkg.1_v0.17.0* | v1.24.9+vmware.1-tkg.1_v0.17.0* |
| kubernetes_autoscaler | v1.24.0+vmware.1 | v1.24.0+vmware.1* |
| load-balancer-and-ingress-service （AKO） | v1.8.2+vmware.1 | v1.8.2+vmware.1* |
| metrics-server | v0.6.2+vmware.1 | v0.6.2+vmware.1* |
| multus-cni | v3.8.0+vmware.2 | v3.8.0+vmware.2* |
| pinniped | v0.12.1+vmware.1-tkg.1 | v0.12.1+vmware.1-tkg.1 |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 | v0.12.1+vmware.2-tkg.3* |
| prometheus | v2.37.0+vmware.2* | v2.37.0+vmware.1* |
| prometheus_node_exporter | v1.4.0+vmware.2* | v1.4.0+vmware.1* |
| pushgateway | v1.4.3+vmware.2* | v1.4.3+vmware.1 |
| sonobuoy | v0.56.13+vmware.1 | v0.56.13+vmware.1* |
| standalone-plugins-package | v0.28.1-dev-standalone-plugins* | v0.28.1-dev-standalone-plugins* |
| tanzu-framework | v0.28.1* | v0.28.0* |
| tanzu-framework-addons | v0.28.1* | v0.28.0* |
| tanzu-framework-management-packages | v0.28.1-tf* | v0.28.0-tf* |
| tkg-bom | v2.1.1* | v2.1.0* |
| tkg-core-packages | v1.24.10+vmware.1-tkg.1* | v1.24.9+vmware.1-tkg.1* |
| tkg-standard-packages | v2.1.1* | v2.1.0* |
| tkg-storageclass-package | v0.28.1-tkg-storageclass* | v0.28.0-tkg-storageclass* |
| tkg_telemetry | v2.1.1+vmware.1* | v2.1.0+vmware.1* |
| velero | v1.9.5+vmware.1 | v1.9.5+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.3+vmware.1 | v1.5.3+vmware.1* |
| velero-plugin-for-csi | v0.3.3+vmware.1 | v0.3.3+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.3+vmware.1 | v1.5.3+vmware.1* |
| velero-plugin-for-vsphere | v1.4.2+vmware.1 | v1.4.2+vmware.1* |
| vendir | v0.30.1+vmware.1 | v0.30.1+vmware.1* |
| vsphere_csi_driver | v2.6.2+vmware.2 | v2.6.2+vmware.2* |
| whereabouts | v0.5.4+vmware.1 | v0.5.4+vmware.1* |
* 表示自上一版本以来的新组件或版本更新。TKG v2.1.0 之前为 v2.1.1，而 v1.6.1 之前为 v2.1.0。
有关 TKG v2.1 随附的软件组件版本的完整列表，请使用 imgpkg 提取存储库包，然后列出其内容。对于 TKG v2.1.1，例如：
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.1 -o standard-2.1.1
cd standard-2.1.1/packages
tree
诸如以下内容的本地 BOM 文件也会列出软件包版本，但可能不是最新的：
~/.config/tanzu/tkg/bom/tkg-bom-v2.1.yaml~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml
支持的升級路徑
在 TKG 升级途径中，v2.1 紧跟 v1.6。TKG v2.0 不是可下载的 TKG 版本：它是嵌入在 vSphere 8 vSphere with Tanzu 主管中的 TKG 版本。
只能从 v1.6.x 升级到 Tanzu Kubernetes Grid v2.1.x。如果要从低于 v1.6.x 的版本升级到 Tanzu Kubernetes Grid v2.1.x，必须先升级到 v1.6.x。
在工作负载集群上升级 Kubernetes 版本时，无法跳过次要版本。例如，无法将 Tanzu Kubernetes 集群直接从 v1.21.x 升级到 v1.23.x。必须先将 v1.21.x 集群升级到 v1.22.x，然后再将集群升级到 v1.23.x。
发布日期
Tanzu Kubernetes Grid v2.1 发布日期为：
- v2.1.0：2023 年 1 月 29 日
- v2.1.1：2023 年 3 月 21 日
Tanzu Kubernetes Grid v2.1 中的行为变化
与以前最新版 v1.6.1 相比，Tanzu Kubernetes Grid v2.1 中引入了以下新行为。
tanzu cluster list的--include-management-cluster选项需要使用-A选项列出独立管理集群。对于-A选项，该命令将列出所有命名空间中的集群。-
默认情况下，Tanzu CLI
package插件使用kctrl样式命令。请参见《Tanzu CLI 命令参考》中的包含 kctrl 的 Tanzu 软件包。- 在 TKG v1.6 中，
package插件默认在停用kctrl模式下运行，下面称为旧版模式。 -
kctrl模式和旧版模式命令不同，如下所示：- 要为软件包配置创建默认值文件，
kctrl-styletanzu package available get命令使用标记--generate-default-values-file而不是--default-values-file-output。 --create-namespace标记已移除。如果使用-n或--namespace指定目标命名空间，则命名空间必须已存在。--create标记已针对package repository update移除。--package-name标记已针package installed create和package install重命名为--package。--install标记已针对package installed update移除。--verbose全局标记已移除。--poll-interval和-poll-timeout标记已重命名为--wait-interval和--wait-timeout。- 在
package available get输出中，另一个表列出了软件包的可用版本。 - 在
package available list输出中，移除了LATEST-VERSION列，默认情况下不显示SHORT-DESCRIPTION；可使用--wide标记进行显示。 - 在
package repository list输出中，REPOSITORY和TAG列将替换为包含源类型（例如，imgpkg）、存储库 URL 和标记的SOURCE列。
- 要为软件包配置创建默认值文件，
-
请参见 TKG v1.6 文档中 CLI 管理的软件包下的主题，了解
tanzu package插件在停用kctrl式时的工作方式。
- 在 TKG v1.6 中，
tanzu-standard软件包存储库未预安装在基于类的集群上。要添加软件包存储库，请参见添加软件包存储库。- Tanzu CLI 管理集群创建过程不再支持创建新的 VPC。安装程序界面不包含用于创建新 VPC 的选项，并且集群配置文件不再支持
AWS_*选项，用于为指定的 CIDR 创建新 VPC。如果要使用新的 VPC，在 AWS 上部署独立管理集群之前，必须使用 AWS 控制台为 TKG 部署创建 VPC。 -
Tanzu CLI 使用新的目标 (Targets) 抽象化，以将不同的命令组与这些命令应用到的服务器类型相关联。
tanzu context list命令引用与具有--target标记的上下文类型相同的概念。由于命令组基于 CLI 插件：- 为 Kubernetes 集群定义命令的插件具有目标
k8s - 为 TMC 命令定义命令的插件已预留目标
tmc以供将来使用 - 定义与上下文无关的命令的插件没有目标
- 通过针对不同目标的同名插件，Tanzu CLI 在命令组（如
tanzu cluster）以适应上下文。
在 TKG v2.1 中，唯一支持的目标或上下文类型为
k8s，这还用以下内容表示：tanzu help命令输出中的Kubernetes cluster operationstanzu plugin list输出中的TARGET中的kubernetes
- 为 Kubernetes 集群定义命令的插件具有目标
- VMware 不建议部署只有 Windows 工作线程的 Windows 工作负载集群，如 TKG v1.6 文档中所述。相反，VMware 建议创建多操作系统集群，如部署多操作系统工作负载集群中所述。多操作系统集群可以同时运行 Windows 和 Linux 容器，从而同时支持基于 Linux 的 TKG 组件和 Linux 工作负载。
- 由于 Go v1.18 中的证书处理发生了变化，MacOS 引导计算机需要先将 vCenter 证书添加到其密钥链中，然后才能通过只玩验证运行
tanzu cluster create；请参见集群部署的必备条件。
用户文档
新出版物部署和管理 TKG 2.1 独立管理集群中包含与“将 TKG 与 vSphere with Tanzu 主管配合使用”无关的独立管理集群的特定主题。
有关详细信息，请参见“VMware Tanzu Kubernetes Grid 文档 (VMware Tanzu Kubernetes Grid Documentation)”页面上的找到适用于您的部署的正确 TKG 文档。
已解决的问题
已在 v2.1.1 中解决
Tanzu Kubernetes Grid v2.1.0 中记录为已知问题的以下问题已在 Tanzu Kubernetes Grid v2.1.1 中得到解决。
-
CNI:none选项不适用于从独立管理集群部署的工作负载集群。唯一可用的选项是antrea（默认）和calico。 -
TKG 的 vSphere 帐户会创建空闲 vCenter 会话，如 vSphere > 主机和集群 (Hosts and Clusters) 清单 > 您的 vCenter (your vCenter) > 监控 (Monitor) 选项卡> 会话 (Sessions) 中所列。
解决办法：通过启动和停止所有会话来移除空闲 vCenter 会话：
- 通过
ssh以root用户身份登录到 vCenter - 如有提示，键入
shell - 运行
service-control --stop --all - 等待服务显示为
Stopped - 运行
service-control --start --all
- 通过
-
Azure 上基于类的工作负载集群的
LoadBalancer服务需要手动配置网关或前端由于
AzureClusterName和ClusterName之间的名称不匹配，无法从 Internet 访问部署供基于类的 Azure 工作负载集群上的应用程序使用的类型为LoadBalancer的服务。解决办法：为负载均衡器服务提供您自己的路由（例如，通过 NAT 网关、代理或其他内部路由），以允许负载均衡器后面的节点访问 Internet。
VMware 建议使用 NAT 网关（如果可用）进行出站连接。如果 NAT 网关不可用：
- 从 Azure 门户中，导航到 CAPZ 创建的
LoadBalancer资源，该资源应与AzureCluster的名称相同。 - 选择 前端 IP 配置 (Frontend IP configuration)，然后单击添加 (Add)。
- 为负载均衡器服务创建新的公用 IP 地址。
-
使用以下规范配置并创建服务，将
loadBalancerIP值设置为由IP-ADDRESS指示的公共 IP 地址：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
- 从 Azure 门户中，导航到 CAPZ 创建的
-
将独立管理和工作负载集群升级到 v2.1 不会将其
kube-vip升级到当前版本。解决办法：对于使用 Kube-VIP 作为控制平面端点的已升级集群，如配置了
AVI_CONTROL_PLANE_HA_PROVIDER = false，请更新kube-vip组件：-
检索用于集群升级的当前 TKr BoM 文件。在
~/.config/tanzu/tkg/bom/中查找文件名以tkr-开头的此文件的本地副本。例如，tkr-bom-v1.24.10+vmware.1-tkg.1.yaml。 -
列出 BoM 文件中的当前
kube-vip版本，例如：$ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+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 -
为集群获取
kcp对象。此对象的名称的格式为CLUSTER-NAME-control-plane。- 管理集群对象是在 tkg-system 命名空间中创建的。
- 工作负载集群对象位于用于创建集群的命名空间中，或者
default，如果未设置NAMESPACE。
-
运行
kubectl edit以编辑kcp对象，并更新kube-vip的路径以匹配 BoM 映像中的当前版本。通过运行以下命令查找此设置的位置：kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
-
-
将管理集群从 v1.5.x 升级到 v2.1.0 会导致节点网络错误，因为 AKO 操作员密钥中的
avi_ingress_node_network_list为空对于最初在 TKG v1.5 或更低版本中创建的独立管理集群，升级到 v2.1.0 会将 AKO 操作员密钥中的
avi_ingress_node_network_list设置为空值。这会导致升级到 v2.1.0 时出现节点网络错误，并在日志中生成缺少 Avi 配置错误。解决办法：将 Tanzu CLI 升级到 v2.1.0 后，但在运行
tanzu mc upgrade之前：-
切换到管理集群环境：
kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER> -
检索 AKO 运算符密钥并解码其数据值：
kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml -
使用文本编辑器打开
values.yaml文件。avi_ingress_node_network_list设置如下所示：avi_ingress_node_network_list: '""' -
使用集群节点网络的范围将设置更改为类似以下内容：
avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]' -
base64 对新的数据值进行编码，并记录输出字符串：
base64 -w 0 values.yaml -
编辑 AKO 运算符密钥：
kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system -
将新的编码数据值字符串粘贴为密钥中的
values.yaml值。保存并退出。
-
-
TMC 无法使用
Default-GroupSEG 中不存在的服务引擎部署基于类的集群。与 TKG 集成的 Tanzu Mission Control 无法部署使用 NSX ALB 且配置的服务引擎不在 NSX ALB 的
Default-Group服务引擎组中的基于类的新集群。此限制不会影响升级配置了自定义服务引擎的现有工作负载集群。有关详细信息，请参见Tanzu Mission Control 发行说明。
-
您无法使用 Tanzu Mission Control (TMC) 的目录功能将软件包列出或安装到 TKG v2.1 工作负载集群，如 TMC 文档中的视图软件包所述。TMC UI 将显示软件包存储库停滞在协调状态。
已在 v2.1.0 中解决
Tanzu Kubernetes Grid v2.1.0 中记录为已知问题的以下问题已在 Tanzu Kubernetes Grid v1.6.1 中得到解决。
-
如果将 DaemonSet 配置为自动还原持久卷，则删除 Pod 的集群和 Pod 操作可能会失败
在 DaemonSet 使用持久卷 (PV) 的安装中，计算机删除可能会失败，因为默认情况下引流进程会忽略 DaemonSet，并且系统无限期地等待卷与节点分离。受影响的集群操作包括升级、横向缩减和删除。
-
在 vSphere with Tanzu 上，
tanzu cluster list为 DevOps 用户生成错误具有 DevOps 工程师角色的用户（如 vSphere with Tanzu 用户角色和工作流中所述）运行
tanzu cluster list时，他们可能会看到类似于Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope的错误。发生这种情况的原因是，不带
-n选项的tanzu cluster command尝试访问所有命名空间，DevOps 工程师用户可能无法访问其中的一些命名空间。解决办法：运行
tanzu cluster list时，请包含--namespace值以指定用户可以访问的命名空间。
已知问题
以下是 Tanzu Kubernetes Grid v2.1.x 中的已知问题。在后续 v2.1.x 修补程序版本中已解决的 v2.1.1 中存在的任何已知问题都列在修复这些问题的修补程序版本的已解决问题下。
升级
在 v2.1.1 中已知
以下是 v2.1.1 中的已知升级问题。
-
在 vSphere 上从 v2.1 升级到 v2.1.1 失败
在 vSphere 上，从 v2.1 升级到 v2.1.1 失败，并显示错误
Reconcile failed:Error。出现此错误的原因是，tkg-clusterclass-vsphere软件包无法协调且安装被阻止。解决办法：如果在本地环境中设置了以下 vSphere 资源变量，请取消设置：
unset VSPHERE_CLONE_MODE unset VSPHERE_DATACENTER unset VSPHERE_DATASTORE unset VSPHERE_FOLDER unset VSPHERE_NETWORK unset VSPHERE_RESOURCE_POOL unset VSPHERE_SERVER unset VSPHERE_STORAGE_POLICY_ID unset VSPHERE_TEMPLATE unset VSPHERE_WORKER_DISK_GIB unset VSPHERE_WORKER_MEM_MIB unset VSPHERE_WORKER_NUM_CPUS
在 v2.1.x 中已知
以下是 v2.1.x 中的已知升级问题。
-
在 Azure 上，升级管理集群和工作负载集群失败，并显示
context deadline exceeded或unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane等错误。发生这种情况的原因是，Azure 上的操作有时比其他平台上所需的时间长。解决办法：再次运行
tanzu management-cluster upgrade或tanzu cluster upgrade，在--timeout标记中指定更长的超时。默认超时为 30m0s。 -
对于最初在 TKG v1.3 或更低版本中创建的独立管理集群，升级失败
在 TKG v2.1 中，将通用集群转换为 TKG 独立管理集群的组件打包在 Carvel 软件包
tkg-pkg中。最初在 TKG v1.3 或更低版本中创建的独立管理集群缺少升级过程中安装tkg-pkg所需的配置密钥，从而导致升级失败。解决办法：对于在 TKG v1.3 或更低版本中创建的独立管理集群，请执行升级独立管理集群中列出的其他步骤。
-
在
TKG_NO_PROXY设置中使用通配符 (*) 创建的集群升级失败TKG v1.6 不允许在
TKG_NO_PROXY的集群配置文件设置中使用通配符 (*)。以前的 TKG 版本使用此设置创建的集群需要在升级之前进行特殊处理，以避免出现workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY错误。解决办法：根据要升级的集群类型：
-
管理集群：
- 切换到管理集群
kubectl上下文。 -
编辑 configMap kapp-controller-config：
kubectl edit cm kapp-controller-config -n tkg-system -
找到
data.noProxy字段，然后通过移除*更改其通配符主机名。例如，更改*.vmware.com to.vmware.com -
保存并退出。集群已准备好升级。
- 切换到管理集群
-
工作负载集群：
- 切换到工作负载集群
kubectl上下文 -
设置集群名称和命名空间的环境变量，例如：
CLUSTER_NAME=my-test-cluster NS=my-test-namespace -
获取工作负载集群的 kapp 控制器数据值并进行解码：
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" -
编辑
${CLUSTER_NAME}-${NS}-kapp-controller-data-values文件，方法是从其kappController.config.noProxy设置中移除*。例如，将*.vmware.com to更改为.vmware.com。 - 保存并退出。
-
对数据值文件
${CLUSTER_NAME}-${NS}-kapp-controller-data-values重新编码：cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0 -
编辑
${CLUSTER_NAME}-${NS}-kapp-controller-data-values密钥，并通过粘贴新编码的数据值字符串来更新其data.value.yaml设置。kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}" -
保存并退出。集群已准备好升级。
- 切换到工作负载集群
-
-
将独立管理集群从 TKG v1.6 升级到 v2.1 会将 TKr 源控制器替换为支持基于类的集群的较新版本，然后重新同步 TKr。因此，
tanzu mc upgrade命令完成后，tanzu cluster available-upgrades get和tanzu kubernetes-release get可能不会显示所有有效的 TKr 版本，并且 Tanzu CLI 可能无法立即升级工作负载集群。解决办法：等待几分钟以重新下载 TKr。
软件包
-
以下版本中的已知问题：v2.1.1
适用于 TKG v2.1.1 的 Tanzu Standard 软件包存储库缺少 v2.1.0 存储库中的以下软件包版本：
cert-manager：1.10.1+vmware.1-tkg.1.yml、1.5.3+vmware.7-tkg.1.yml和1.7.2+vmware.3-tkg.1.ymlexternal-dns：0.10.0+vmware.1-tkg.3.yml、0.11.0+vmware.1-tkg.3.yml和0.12.2+vmware.4-tkg.1.ymlgrafana：7.5.16+vmware.1-tkg.2.yml
因此，将工作负载集群从 TKG v2.1.0 升级到 v2.1.1 后，无法运行
tanzu package installed update来更新这些软件包的配置，也无法将软件包升级到最新版本：cert-manager：1.10.1+vmware.1-tkg.2.ymlexternal-dns：0.12.2+vmware.4-tkg.2.ymlgrafana：7.5.17+vmware.1-tkg.1.yml
仅当需要更改软件包配置时，才会出现此问题；安装的软件包继续运行而不升级。
解决办法：执行以下任一项：
-
如果需要更新
cert-manager、external-dns或grafana软件包配置：- 运行
tanzu package installed get以检索软件包的版本。 - 如上所述，如果 v2.1.1 存储库缺少已安装的软件包版本，请在运行
tanzu package installed update时将最新版本传递至-v-标记。
- 运行
-
将工作负载集群升级到 TKG v2.1.1 后，将三个软件包更新到上述版本。
有关
tanzu package命令，请参见安装和管理软件包中所述。 -
Multus CNI 在
medium和具有 NSX Advanced Load Balancer 的较小 Pod 上失败在 vSphere 上，运行带有 NSX ALB 的 Multus CNI 软件包的
medium或较小工作节点的工作负载群集可能会失败，并显示Insufficient CPU或其他错误。解决办法：要将 Multus CNI 与 NSX ALB 结合使用，请部署具有
large或extra-large的工作节点的工作负载集群。 -
TKG BoM 文件包含无关的 cert-manager 软件包版本
Tanzu CLI 安装到
~/.config/tanzu/tkg的 TKG 物料清单 (BoM) 文件列出了cert manager(jetstack_cert-manager) 软件包的 v1.5.3 和 v1.7.2 版本。要安装的正确版本是 v1.5.3，如安装 cert-manager 中所述。解决办法：安装 v1.5.3
cert-manager。 -
停用 Pinniped 需要在旧版集群上手动删除
Secret在管理集群上停用外部身份管理时，未使用的 Pinniped
Secret对象仍存在于旧版工作负载集群上。如果用户随后尝试使用旧的
kubeconfig访问集群，则会显示登录弹出窗口并失败。解决办法：手动删除旧版集群的 Pinniped
Secret，如停用身份管理中所述。 -
当执行 ID 超过 1000000+ 时，Harbor CVE 导出可能会失败
Harbor v2.6.3（TKG v2.1 打包的版本）存在已知问题，即在执行主键自动增量 ID 增加到 1000000+ 时，CVE 报告导出错误“404 页面未找到 (404 page not found)”。
此 Harbor 问题已在更高版本的 Harbor 中解决，并准备包含在更高版本的 TKG 中。
-
无法在 Internet 受限的环境中将 Harbor 的代理缓存功能用于运行 Tanzu Kubernetes Grid v2.1。您仍然可以使用 Harbor 代理缓存来代理以前版本的 Tanzu Kubernetes Grid 中的映像，以及应用程序映像等非 Tanzu 映像。
解决办法：无
-
对于 TKG 上处于不受支持的技术预览版状态的 PSA 控制器，某些 TKG 软件包不符合默认的
baseline配置文件。解决办法：在受影响的软件包命名空间中设置
audit=privileged和warn=privileged标签，如 Pod 安全准入控制器（技术预览版）中所述。 -
运行
tanzu package repository add将tanzu-standard存储库添加到 vSphere 上的单节点集群（技术预览版）中所述类型的单节点集群可能失败。发生这种情况的原因是，单节点集群使用
cert-manager作为核心加载项进行引导，这与tanzu-standard存储库中不同的cert-manager软件包相冲突。解决办法：在添加
tanzu-standard存储库之前，请按照安装证书管理器中所述修补cert-manager软件包注释。
集群操作
在 v2.1.1 中已知
以下是 v2.1.1 中的已知集群操作问题。
-
无法基于具有 Antrea CNI 的非当前 TKr 版本创建新的工作负载集群
您无法创建使用 Antrea CNI 并运行以前版本的 TKG 附带的 Kubernetes 版本（如 Kubernetes v1.23.10）的新工作负载集群，这是 TKG v1.6.1 中的默认 Kubernetes 版本，如 Tanzu Kubernetes Grid v2.1 中支持的 Kubernetes 版本中所列。
TKG v2.1.1 完全支持运行旧版 Kubernetes 的现有集群。
解决办法：创建运行 Kubernetes 1.24.10、1.23.16 或 1.22.17 的工作负载集群。Kubernetes 项目建议在当前任何次要版本的最新修补程序版本上运行组件。
在 v2.1 中已知
-
tanzu cluster create不会正确验证使用非默认 Kubernetes 版本生成的集群规范如果使用创建基于类的集群 中所述的两个步骤之一从配置文件创建基于类的工作负载集群，并在第一步中指定
--tkr值以将集群建立在非默认版本的 Kubernetes 上时，第二步可能会失败，并显示验证错误。解决办法：在第二步中，当您第二次运行
tanzu cluster create并传递生成的集群清单时，请指定您在第一步中所做的相同--tkr值和其他选项，如创建基于类的集群中所述。 -
由于集群 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”。
-
从旧版配置文件创建
ClusterClass配置文件，--dry-run包括空的 Antrea 配置使用
tanzu cluster create --dry-run -f以及包含ANTREA_NODEPORTLOCAL条目的旧版配置文件创建ClusterClass配置文件会导致自动生成的 Antrea 配置不包含任何标签，从而导致 Antrea 无法成功协调。发生这种情况的原因是，在 TKG 2.1.1 中，AntreaConfig资源需要tkg.tanzu.vmware.com/package-name label以便加载项管理器以便在指定的工作负载集群中安装 Antrea。此问题不适用于 2.1.0。解决办法：将缺少的标签添加到
ClusterClass配置文件中的AntreaConfig，然后再次尝试创建集群：labels: tkg.tanzu.vmware.com/cluster-name: rito tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced -
TKG v2.1 不支持 vSphere 8 上的 IPv6 网络连接，但如 IPv6 网络连接中所述，它支持使用 vSphere 7 上的 Kube-Vip 进行单堆栈 IPv6 网络连接。
解决办法：如果需要或当前在 vSphere 上的 IPv6 环境中使用 TKG，请不要安装或升级到 vSphere 8。
-
管理集群不支持 NSX ALB
NodePortLocal输入模式在 TKG v2.1 中，无法将 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 身份验证登录到工作负载集群。
解决办法：重新创建管理集群后，按照在现有部署中启用和配置身份管理中所述重新配置身份管理。
存储
-
更改默认
StorageClass对象会导致工作负载集群中协调失败修改 TKG 中包含的默认
StorageClass对象的属性会导致使用该存储类的工作负载集群中的软件包协调失败。解决办法：要自定义存储类，请使用不同的
name创建新的StorageClass定义，而不是修改默认对象定义，然后重新配置集群以使用新的存储类。 -
无法启用工作负载集群以在多个数据存储之间分配存储，如部署使用数据存储集群的集群中所述。如果将数据存储集群中的多个数据存储标记为工作负载集群存储策略的基础，则工作负载集群仅使用其中一个数据存储。
解决办法：无
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 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时，也可能会出现此错误。解决办法：将错误输出中列出的一个或多个配置参数设置为本地环境变量。或者，要避免此错误，可以在一个步骤中创建基于类的集群，而无需预览其配置，方法是将
auto-apply-generated-clusterclass-based-configuration功能设置为true，然后运行tanzu cluster create。要设置auto-apply-generated-clusterclass-based-configurationtrue，请运行：tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration true这会配置 Tanzu CLI，以便始终一步创建基于类的集群。有关详细信息，请参见创建基于类的集群。
-
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 中所述。 -
在 Windows 命令提示符 (CMD) 中，Tanzu 列格式化的 CLI 命令输出在列标题中包含无关字符。
Windows 终端或 PowerShell 中不会出现此问题。
解决办法：在 Windows 引导计算机上，从 Windows 终端运行 Tanzu CLI。
-
创建管理集群期间出现可忽略的
AKODeploymentConfig错误运行
tanzu management-cluster create以使用 NSX ALB 创建管理集群会输出以下错误：no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???。可以忽略该错误。有关详细信息，请参见知识库中的此文章。 -
在 vSphere 上创建工作负载集群期间，可忽略
machinehealthcheck和clusterresourceset错误通过 vSphere with Tanzu 使用
tanzu cluster create命令将工作负载集群部署到 vSphere 时，输出可能包含与运行machinehealthcheck以及访问clusterresourceset资源相关的错误，如下所示：Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" 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" ...已成功创建工作负载集群。您可以忽略这些错误。
-
在停用 MHC 时，CLI 暂时错误地报告最近删除的节点的状态
停用计算机运行状况检查 (MHC) 后，Tanzu CLI 命令（如
tanzu cluster status）在重新创建基础架构时可能不会报告最新的节点状态。解决办法：无
vSphere
-
使用
small节点创建的节点池可能会停滞在Provisioning状态。使用配置为
small的节点SIZE创建的节点池可能会停滞在Provisioning状态，并且永远不会进入Running状态。解决办法：为节点池配置至少
medium大小的节点。 -
如果对工作负载 (
AVI_ENABLE) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER) 使用 NSX Advanced Load Balancer，Avi 控制器可能无法区分名称相同的集群。解决办法：为每个集群设置唯一的
CLUSTER_NAME值：-
管理集群：即使从不同的引导计算机创建多个管理集群，也不要使用相同的
CLUSTER_NAME值。 -
工作负载集群：请勿创建多个具有相同
CLUSTER_NAME并且也位于同一管理集群命名空间的工作负载集群，如其NAMESPACE值所设置。
-
-
将外部身份管理添加到现有部署可能需要设置伪
VSPHERE_CONTROL_PLANE_ENDPOINT值要将外部身份提供程序与现有 TKG 部署集成在一起，可能需要在用于创建附加项密钥的管理集群配置文件中设置伪
VSPHERE_CONTROL_PLANE_ENDPOINT值，如 为管理集群生成 Pinniped 附加项密钥中所述
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 和多操作系统工作负载集群
-
无法在 MacOS 计算机上创建 Windows 计算机映像
由于 Kubernetes Image Builder 使用的开源
packer实用程序存在问题，您无法在 MacOS 计算机上构建 Windows 计算机映像，如 Windows 自定义计算机映象中所述。解决办法：使用 Linux 计算机构建自定义 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 支持部门。
