更新时间：2023 年 7 月 6 日
本发行说明包含以下主题：
发行说明内容
新增功能
VMware vSphere with Tanzu 每月发布修补程序以引入新特性和新功能，提供 Kubernetes 及其他服务更新，紧跟上游步伐，并解决报告的问题。下文介绍了每月修补程序引入的内容。
新增功能：2023 年 7 月 6 日
| 2023 年 7 月 6 日内部版本信息 ESXi 7.0 Update 3m | 2023 年 5 月 3 日 | 内部版本 21686933 vCenter Server 7.0 Update 3n | 2023 年 7 月 6 日 | ISO 内部版本 21958406 VMware NSX Advanced Load Balancer AVI-22.1.3 | 2023 年 1 月 31 日 |
新功能
-
主管集群支持 Kubernetes 1.24 - 此版本增加了对 Kubernetes 1.24 的支持，且不再支持 Kubernetes 1.21。
主管集群支持的 Kubernetes 版本：
此版本中受支持的 Kubernetes 版本为 1.24、1.23 和 1.22。在 Kubernetes 版本 1.21 上运行的主管将自动升级到版本 1.22，以确保所有主管集群都在支持的 Kubernetes 版本上运行。
新增功能：2023 年 3 月 30 日
| 2023 年 3 月 30 日内部版本信息 ESXi 7.0 Update 3l | 2023 年 3 月 30 日 | ISO 内部版本 21424296 vCenter Server 7.0 Update 3l | 2023 年 3 月 30 日 | ISO 内部版本 21477706 VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日 |
新功能：
-
无，这只是一个错误修复版本。
主管集群支持的 Kubernetes 版本
此版本中受支持的 Kubernetes 版本为 1.23、1.22 和 1.21。在 Kubernetes 版本 1.20 上运行的主管将自动升级到版本 1.21，以确保所有主管都在支持的 Kubernetes 版本上运行。
已解决的问题
此修补程序修复了以下问题。
-
激活大型接收卸载 (LRO) 后，使用 Antrea-ENCAP 的 Tanzu Kubernetes Grid 集群虚拟机可能会遇到网络性能问题。
-
在主管上启用嵌入式 Harbor 注册表可能会导致不安全的默认配置。
新增功能：2023 年 2 月 23 日
| 2023 年 2 月 23 日内部版本信息 ESXi 7.0 Update 3i | 2022 年 12 月 8 日 | ISO 内部版本 20842708 vCenter Server 7.0 Update 3k | 2023 年 2 月 23 日 | ISO 内部版本 21290409 VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日 |
新功能：
主管
-
主管集群支持 Kubernetes 1.23 - 此版本增加了对 Kubernetes 1.23 的支持，且不再支持 Kubernetes 1.20。此版本中受支持的 Kubernetes 版本为 1.23、1.22 和 1.21。在 Kubernetes 版本 1.20 上运行的主管将自动升级到版本 1.21，以确保所有主管都在支持的 Kubernetes 版本上运行。
新增功能：2022 年 12 月 8 日
| 2022 年 12 月 8 日内部版本信息 ESXi 7.0 Update 3i | 2022 年 12 月 8 日 | ISO 内部版本 20842708 vCenter Server 7.0 Update 3i | 2022 年 12 月 8 日 | ISO 内部版本 20845200 VMware NSX Advanced Load Balancer avi-21.1.4-9009 | 2022 年 4 月 7 日 |
新功能：
新的安全策略 CRD：vSphere 7.0 Update 3i 引入了安全策略 CRD，使用户可以将基于 NSX 的安全策略应用于主管集群中的虚拟机和 Pod。这使用户能够通过主管命名空间的 CRD 扩展 Kubernetes 网络策略，从而通过代码配置“Kubernetes 网络策略”。
支持: kube-apiserver-authproxy-svc 服务和系统 Pod 中使用的 TLS 版本已更新到 TLSv1.2。
新增功能 - 2022 年 9 月 13 日
| 2022 年 9 月 13 日内部版本信息 ESXi 7.0 Update 3g | 2022 年 9 月 13 日 | ISO 内部版本 20328353 vCenter Server 7.0 Update 3h | 2022 年 9 月 13 日 | ISO 内部版本 20395099 VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
无，这只是一个错误修复版本。
已解决的问题：
此修补程序修复了 vCenter Server 升级到版本 70u3f 时由于 WCP 服务在升级后未启动而失败的问题。尝试升级版本低于 70u3d 且激活了 vSphere with Tanzu 的 vCenter Server 时出现此错误。尝试将 vCenter Server 从低于 70u3d 的版本升级到 vCenter Server 70u3d，然后再升级到 vCenter Server 70u3f 时，该操作失败。
要了解有关已解决的这个问题的更多信息，请阅读知识库文章 89010。
新增内容：2022 年 7 月 12 日
| 2022 年 7 月 12 日内部版本信息 ESXi 7.0 Update 3f | 2022 年 7 月 12 日 | ISO 内部版本 20036589 vCenter Server 7.0 Update 3f | 2022 年 7 月 12 日 | ISO 内部版本 20051473 VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
主管集群
-
对虚拟机服务支持 LoadBalancer IP 字符串值 – 用户可以向 spec.LoadBalancerIP 值提供一个字符串值，该值表示/匹配在 NSX-T 中创建和标记的 IPPool。
-
备份和还原虚拟机服务虚拟机 – VMware 现在支持通过一个全面且记录完整的工作流备份和还原本地 vSphere 和 VMware Cloud on AWS 中的虚拟机服务虚拟机，该工作流支持 Veeam 和其他基于 vSphere Storage APIs for Data Protection (vADP) 的备份供应商，可确保更完整的数据保护解决方案和 VMware Cloud on AWS 上的虚拟机服务的常规可用性。
-
新增功能：2022 年 5 月 12 日
| 2022 年 5 月 12 日内部版本信息 ESXi 7.0 Update 3d | 2022 年 3 月 29 日 | ISO 内部版本 19482537 vCenter Server 7.0 Update 3e | 2022 年 5 月 12 日 | ISO 内部版本 19717403 VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
针对通过 VM Operator 服务部署的虚拟机增加了网络安全策略支持 – 可以根据标记通过安全组创建基于 NSX-T 的安全策略。现在可以创建基于 NSX-T 的安全策略，并根据 NSX-T 标记将其应用于通过 VM Operator 部署的虚拟机。
-
主管集群支持 Kubernetes 1.22 – 此版本增加了对 Kubernetes 1.22 的支持，且不再支持 Kubernetes 1.19。此版本中受支持的 Kubernetes 版本为 1.22、1.21 和 1.20。在 Kubernetes 版本 1.19 上运行的主管集群将自动升级到版本 1.20，以确保所有主管集群都在支持的 Kubernetes 版本上运行。
升级注意事项
如果升级低于 7.0 Update 3c 版本的 vCenter Server，并且主管集群在 Kubernetes 1.19.x 上运行，则 tkg-controller-manager Pod 将进入 CrashLoopBackOff 状态，从而致使客户机集群变得无法管理。您会看到类似以下内容的错误：
发现应急: 内存地址无效或零指针取消引用 (Observed a panic: Invalid memory address or nil pointer dereference)
解决办法：要了解并解决此问题，请阅读知识库文章 88443。
新增功能：2022 年 3 月 29 日
| 2022 年 3 月 29 日内部版本信息 ESXi 7.0 Update 3d | 2022 年 3 月 29 日 | ISO 内部版本 19482537 vCenter Server 7.0 Update 3d | 2022 年 3 月 29 日 | ISO 内部版本 19480866 VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
无，这只是一个错误修复版本。
已解决的问题
-
vTPM 主机上的 Spherelet VIB 安装失败
-
在 vTPM 主机上安装 spherelet VIB 失败，并显示错误“未找到可信签名者: 自签名证书 (Could not find a trusted signer: self-signed certificate)”。
-
-
vSphere 升级导致主管集群变得不稳定
-
将 vSphere 从 7.0 Update 1 升级到 7.0 Update 2 后，主管集群将进入配置状态。
-
-
使用 NSX-T Advanced Load Balancer 时，主管集群启用停止
-
启用具有 NSX-T Advanced Load Balancer 的主管集群可能会导致基于默认身份验证配置的配置过程停止。
-
新增功能：2021 年 10 月 21 日
| 2021 年 10 月 21 日 内部版本信息 ESXi 7.0 Update 3 | 2022 年 1 月 27 日 | ISO 内部版本 19193900 vCenter Server 7.0 Update 3a | 2021 年 10 月 21 日 | ISO 内部版本 18778458 VMware NSX Advanced Load Balancer 20.1.7 | 2021 年 10 月 21 日 | ISO 内部版本 18778458 |
重要信息：由于存在影响升级的问题，VMware 于 2021 年 11 月 19 日从所有站点中移除了 ESXi 7.0 Update 3、7.0 Update 3a 和 7.0 Update 3b。ESXi 7.0 Update 3c ISO 的内部版本 19193900 取代了内部版本 18644231。有关详细信息，请参见 VMware ESXi 7.0 Update 3c 发行说明。
新功能
-
Tanzu Kubernetes Grid Service for vSphere
-
使容器化工作负载能够在 Tanzu Kubernetes 集群上利用 GPU 加速 - vSphere 管理员现在可以将 GPU 加速虚拟机置备到 Tanzu Kubernetes 集群，开发人员现在可以使用本机 Kubernetes 命令将 GPU 加速虚拟机添加到其 Tanzu Kubernetes Grid 集群。
-
基于 Ubuntu 20.04 的 Tanzu Kubernetes 版本 (TKr) - 这是我们基于 Ubuntu 20.04 的首个 TKr 版本。此映像专门针对 GPU (AI/ML) 工作负载进行了优化和测试。有关详细信息，请参阅 TKr 发行说明。
-
新增功能：2021 年 10 月 5 日
| 2021 年 9 月 28 日内部版本信息 ESXi 7.0 Update 3 | 2022 年 1 月 27 日 | ISO 内部版本 19193900 vCenter Server 7.0 Update 3 | 2021 年 10 月 5 日 | ISO 内部版本 18700403 VMware NSX Advanced Load Balancer 20.1.6 | 2021 年 10 月 5 日 | ISO 内部版本 18700403 |
重要信息：由于存在影响升级的问题，VMware 于 2021 年 11 月 19 日从所有站点中移除了 ESXi 7.0 Update 3、7.0 Update 3a 和 7.0 Update 3b。ESXi 7.0 Update 3c ISO 的内部版本 19193900 取代了内部版本 18644231。有关详细信息，请参见 VMware ESXi 7.0 Update 3c 发行说明。
新功能
-
主管集群
-
vSphere 服务 - 通过使用 vSphere 服务框架，vSphere 管理员现在可以异步管理主管服务，包括 MinIO、Cloudian Hyperstore、Dell ObjectScale 和 Velero。管理员可以利用主管服务的分离性质，将新服务添加到 vCenter Server 版本之外的服务目录，从而进一步增强 DevOps 社区的能力。主管服务仅在配置了 NSX-T Data Center 网络连接的主管集群中可用。有关在 vSphere Client 中管理主管服务的信息，请查看文档。
-
在虚拟机服务中支持 vGPU - vSphere 管理员现在可以为开发人员提供自助服务访问权限，方便他们通过使用 Kubernetes 的虚拟机自助使用 GPU，但受通过虚拟机类所实施限制的约束。然后，DevOps 用户可以使用这些预定义的虚拟机类和映像快速创建具有 GPU 的虚拟机。
-
使用 DHCP 网络启用工作负载管理 - 此版本添加了 DHCP 网络作为备用网络设置路径，简化了启用过程，可以更快地实现 POC。vSphere 管理员只需选择网络和端口组，即可为管理网络和工作负载网络配置 DHCP，所有其他输入（包括 DNS、NTP 和浮动 IP）都使用 DHCP 自动获取。
-
在启用期间执行网络和负载均衡器运行状况检查 - 在启用期间，网络连接、DNS、NTP 和负载均衡器连接的运行状况检查将验证主管集群启用是否成功，并提供用户可读的错误消息以帮助诊断常见问题并采取相应措施。有关解决错误消息的详细说明，请查看文档。
-
主管集群支持 Kubernetes 1.21 - 此版本增加了对 Kubernetes 1.21 的支持，且不再支持 Kubernetes 1.18。此版本中受支持的 Kubernetes 版本为 1.21、1.20 和 1.19。在 Kubernetes 版本 1.18 上运行的主管集群将自动升级到版本 1.19，以确保所有主管集群都在支持的 Kubernetes 版本上运行。
-
主管命名空间具有标签和注释 - DevOps 用户通过命名空间自助服务模板创建的命名空间现在可以具有 Kubernetes 标签和注释。
-
启用后编辑主管集群配置 - 启用配置了 vSphere 网络连接堆栈的主管集群后，vSphere 管理员现在可以从 API 和 vSphere Client 编辑以下设置：负载均衡器用户名和密码、管理网络 DNS 搜索域以及工作负载网络 DNS 服务器、NTP 服务器，还可以扩展服务 IP 范围和添加新工作负载网络。对于使用 vSphere 或 NSX-T 网络连接的集群，可以在启用后纵向扩展控制平面大小。请注意，只能增加集群的规模，目前不支持缩小规模。有关如何通过 vSphere Client 更改主管集群设置的信息，请参见文档。
-
Tanzu 许可证密钥过期 - vSphere 管理员现在能够更加灵活地管理过期的 Tanzu 版本许可证密钥。Tanzu 许可证密钥过期时，将不会自动执行硬性实施，从而管理员能够更加灵活地购买和分配新的许可证密钥，而不会影响正常操作。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
对 vSAN 持久卷支持 RWX - 在 Tanzu Kubernetes 集群上运行的工作负载现在可以使用 RWX 挂载基于 vSAN 的持久卷。
-
Tanzu Kubernetes Grid Service v1alpha2 API 更新 - 对 Tanzu Kubernetes 集群 API 进行了更新，提供了一些新字段，可增强 Tanzu Kubernetes Grid Service 配置，包括支持多个工作节点池。弃用 v1alpha1 API，支持新的 v1alpha2 API。有关详细信息，请参见此文档。
-
衡量指标服务器 - 从 1.20.9+ 和 1.21 Tanzu Kubernetes 版本开始，Tanzu Kubernetes 集群中现在默认包含衡量指标服务器。
-
能够支持无 NAT（路由）拓扑 - 现在可以创建具有以下网络拓扑的 Tanzu Kubernetes 集群：允许将集群节点路由到集群网络之外。有关详细信息，请参见此文档。
-
新增功能：2021 年 8 月 24 日
| 2021 年 8 月 24 日内部版本信息 ESXi 7.0 Update 2c | 2021 年 8 月 24 日 | ISO 内部版本 18426014 vCenter Server 7.0 Update 2c | 2021 年 8 月 24 日 | ISO 内部版本 18356314 VMware NSX Advanced Load Balancer 20.1.5 | 2021 年 8 月 24 日 | ISO 内部版本 18379150 |
新功能
-
主管集群
-
主管集群支持 Kubernetes 1.20 - 此版本增加了对 Kubernetes 1.20 的支持，且不再支持 Kubernetes 1.17。此版本中受支持的 Kubernetes 版本为 1.20、1.19 和 1.18。在 Kubernetes 版本 1.17 上运行的主管集群将自动升级到版本 1.18，以确保所有主管集群都在支持的 Kubernetes 版本上运行。
-
对 vSphere Pod 支持 Velero Plugin for vSphere - 此版本支持 Velero 1.5.1 和 Velero Plugin for vSphere 1.1.0 及更高版本，可备份和还原 vSphere Pod。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
新增集群内扩展 Harbor 和 external-dns - 平台运维人员现在可以访问另外两个支持的集群内扩展：Harbor 和 external-dns。Harbor 是 CNCF 毕业级容器注册表，external-dns 是一种基于 Kubernetes 负载均衡服务动态配置 DNS 记录的常用工具。
-
改进了控制平面节点的修复 - Tanzu Kubernetes 集群现在将自动修复常见控制平面节点故障，从而提供了更可靠的 Kubernetes 运行时。
-
对 Tanzu Kubernetes 集群工作负载支持 Velero Plugin for vSphere - 此版本支持 Velero 1.5.1 及更高版本和 Velero Plugin for vSphere 1.1.0 及更高版本，可备份和还原 Tanzu Kubernetes 集群上运行的工作负载。
-
对 Tanzu Kubernetes 集群工作负载支持独立版 Velero - 此版本支持 Velero 1.6，可使用独立版 Velero with Restic 备份和还原 Tanzu Kubernetes 集群工作负载。
-
新增功能 - 2021 年 4 月 27 日
| 2021 年 4 月 27 日内部版本信息 ESXi 7.0 | 2021 年 3 月 9 日 | ISO 内部版本 17630552 vCenter Server 7.0 | 2021 年 4 月 27 日 | ISO 内部版本 17920168 |
新功能
-
主管集群
-
通过虚拟机服务使用 Kubernetes 管理虚拟机。本版本在 vSphere with Tanzu 包含的基础架构服务中增加了虚拟机服务，为开发人员提供了 Kubernetes 原生虚拟机管理。通过虚拟机服务，开发人员可以使用 Kubernetes 命令在命名空间中部署和管理虚拟机。同时，vSphere 管理员能够控制服务的资源消耗和可用性，而且仍为开发人员提供云原生体验。
-
开发人员能够以自助方式创建命名空间。vSphere 管理员现在可以创建主管命名空间并将其配置为自助式命名空间模板。此模板定义了资源限制和使用权限。随后，开发人员可以使用此模板置备命名空间并在其中运行工作负载，而无需请求命名空间并等待批准。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
重要信息：TKR 的 CVE 修复：发布了新的 Tanzu Kubernetes 版本，可解决 CVE-2021-30465。
-
重要信息：Contour Ingress 扩展的 CVE 修复：新增了 Envoy 映像版本，可解决 CVE-2021-28682、CVE-2021-28683 和 CVE-2021-29258。有关详细信息，请参见相关知识库文章。
-
新增使用默认虚拟机类的工作流。新增了使用默认虚拟机类置备 Tanzu Kubernetes 集群的工作流。在创建新集群之前，需要将默认虚拟机类添加到置备集群的 vSphere 命名空间中。有关指导，请参见文档。
-
系统变异 Webhook 现在支持试运行模式。现在，用户可以将常用工具（如 Terraform Kubernetes 提供程序）与 Tanzu Kubernetes Grid Service 集成。以前，系统 Webhook 不支持预运行模式，但这是 Terraform“plan”命令的一项要求。
-
自定义虚拟机类。Tanzu Kubernetes 集群可以通过虚拟机服务使用自定义虚拟机类。这将允许用户配置不同的 CPU 和内存量，分配给构成 Tanzu Kubernetes 集群的虚拟机。
-
新增功能：2021 年 3 月 9 日
| 2021 年 3 月 9 日内部版本信息 ESXi 7.0 | 2020 年 3 月 9 日 | ISO 内部版本 17630552 vCenter Server 7.0 | 2021 年 3 月 9 日 | ISO 内部版本 17694817 VMware NSX Advanced Load Balancer | 2020 年 10 月 12 日 | 20.1.X |
新功能
-
主管集群
-
配置了 VDS 网络连接的主管集群支持 NSX Advanced Load Balancer。现在，可以通过以下方式启用主管集群：使用 NSX Advanced Load Balancer (Avi Networks) 实现 L4 负载均衡，以及对主管集群和 Tanzu Kubernetes 集群的控制平面节点实现负载均衡。有关配置 NSX Advanced Load Balancer 的指导，请查看文档页面。
-
主管集群可升级到 Kubernetes 1.19 并自动升级运行 Kubernetes 1.16 的主管集群。可以将主管集群升级到 Kubernetes 1.19。在此更新中，支持以下主管集群版本：1.19、1.18 和 1.17。运行 Kubernetes 1.16 的主管集群会在更新 vCenter Server 后自动升级到 1.17。这将确保所有主管集群运行的都是受支持的 Kubernetes 版本。
-
PersistentVolumeClaim (PVC) 扩展。现在，可以通过修改 PersistentVolumeClaim 对象扩展现有卷，即使卷当前正在使用时也可扩展。这适用于主管集群和 Tanzu Kubernetes 集群中的卷。
-
使用 vSphere Lifecycle Manager 管理主管集群生命周期。对于配置了 NSX-T 网络连接的主管集群，可以使用 vSphere Lifecycle Manager 进行基础架构配置和生命周期管理。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
支持专用容器注册表。vSphere 管理员和 Kubernetes 平台运维人员现在可以定义在 Tanzu Kubernetes 集群中使用的其他证书颁发机构证书 (CA)，以信任专用容器注册表。借助此功能，Tanzu Kubernetes 集群能够从具有企业证书或自签名证书的容器注册表提取容器映像。可以在主管集群范围或针对每个 Tanzu Kubernetes 集群将专用 CA 配置为 Tanzu Kubernetes 集群的默认值。请访问文档页面，详细了解如何为 Tanzu Kubernetes 集群配置专用容器注册表支持。
-
为具有 NSX-T 和 NSX Advanced Load Balancer 的服务类型 LoadBalancer 提供用户定义的 IP。Kubernetes 应用程序运维人员现在可以在配置服务类型 LoadBalancer 时提供用户定义的 LoadBalancerIP，从而允许服务具有静态 IP 端点。此高级功能需要 NSX-T 负载均衡或 NSX Advanced Load Balancer 以及主管集群。要了解如何配置此功能，请访问文档页面。
-
为具有 NSX-T 的服务类型LoadBalancer 配置 ExternalTrafficPolicy 和 LoadBalancerSourceRanges。Kubernetes 应用程序运维人员现在可以为服务配置值为“local”的 ExternalTrafficPallicy，以将客户端 IP 地址传播到最终 pod。此外，还可以为服务定义 loadBalancerSourceRanges，以限制哪些客户端 IP 可以访问负载均衡服务。这两项高级功能需要 NSX-T 负载均衡和主管集群。
-
Kubernetes 版本管理和指示。现在可以使用 kubectl 检查 TanzuKubernetesRelease 与底层主管集群环境的兼容性。Tanzu Kubernetes 集群现在还指示是否推出了 Kubernetes 升级版，并推荐使用的下一个 TanzuKubernetesRelease。有关使用此新功能的详细信息，请参见文档页面。
-
改进的集群状态一目了然。在上一版本中，VMware 通过实施条件状态报告呈现常见问题和错误，扩展了 WCPCluster 和 WCPMachine CRD。在 vSphere 7.0 Update 2 版本中，TanzuKubernetesCluster CRD 进行了增强，将子系统组件的条件状态报告汇总在一起，可提供即时解答信息和精细指导，从而帮助您调查问题。要了解如何配置此功能，请访问文档页面。
-
针对每个 Tanzu Kubernetes 集群实现 HTTP 代理配置。现在可以针对每个 Tanzu Kubernetes 集群定义 HTTP/HTTPS 代理配置，或者，也可以通过默认配置在主管集群范围定义该配置。有关配置此功能的信息，请参见文档页面。
-
支持 Tanzu Kubernetes Grid 扩展。现在，Tanzu Kubernetes Grid Service 完全支持集群中扩展，包括 Fluent Bit、Contour、Prometheus、AlertManager 和 Grafana。
-
Tanzu Kubernetes 集群的更新注意事项
vSphere 7.0 Update 2 版本包括在 vCenter Server 更新时自动升级主管集群的功能。如果在环境中置备了 Tanzu Kubernetes 集群，请在升级到 vCenter Server 7.0 Update 2 之前先阅读知识库文章 82592。该文章提供了有关运行预检查的指导，以确定在主管集群自动升级后是否会有任何 Tanzu Kubernetes 集群变得不兼容。
已解决的问题
-
嵌入式容器注册表 SSL 证书未复制到 Tanzu Kubernetes 集群节点
-
为主管集群启用嵌入式容器注册表时，Harbor SSL 证书未包含在该 SC 上创建的任何 Tanzu Kubernetes 集群节点中，并且无法从这些节点连接到注册表。
-
-
从 Tanzu Kubernetes Grid 1.16.8 升级到 1.17.4 后，其中一个控制平面节点上的“guest-cluster-auth-svc”pod 一直停滞在“正在创建容器”状态
-
将 Tanzu Kuberentes 集群从 Tanzu Kubernetes Grid Service 1.16.8 升级到 1.17.4 后，其中一个集群控制平面节点上的“guest-cluster-auth-svc”pod 一直停滞在“正在创建容器”状态。
-
-
在执行集群更新期间或之后，用户无法管理 Tanzu Kubernetes 集群上的现有 pod
-
在执行集群更新期间或之后，用户无法管理 Tanzu Kubernetes 集群上的现有 pod。
-
-
Tanzu Kubernetes 集群升级作业失败并显示错误“等待 etcd 运行状况检查通过超时 (timed out waiting for etcd health check to pass)”。
-
与 Tanzu Kubernetes 集群升级相关联的 vmware-system-tkg 命名空间中的升级作业失败，并显示以下错误消息：“等待 etcd 运行状况检查通过超时 (timed out waiting for etcd health check to pass)”。此问题是由于etcd pod 缺少 PodIP 地址所致。
-
-
当前 TKC 版本不支持 Antrea CNI
-
置备 Tanzu Kubernetes 集群时，您会收到错误“当前 TKC 版本不支持 Antrea CNI (Antrea CNI not supported in current TKC version)”。
选项 1（推荐）：更新 Tanzu Kubernetes 集群以使用支持 Antrea（v1.17.8 或更高版本）的 OVA 版本。
选项 2：在 Tanzu Kubernetes 集群规范 YAML中，在“spec.settings.network.cni”部分中输入“calico”。
选项 3：将默认 CNI 更改为 Calico。请参阅文档中有关如何执行的主题。
-
新增功能：2021 年 2 月 2 日
| 2021 年 2 月 2 日内部版本信息 ESXi 7.0 | 2020 年 12 月 17 日 | ISO 内部版本 17325551 vCenter Server 7.0 | 2021 年 2 月 2 日 | ISO 内部版本 17491101 |
新功能
-
主管集群
-
更新使用 vSphere 网络连接的主管集群：现在，您可以将使用 vSphere 网络连接的主管集群从较旧版本的 Kubernetes 更新到最新版本。新的主管集群版本还将提供 Tanzu Kubernetes Grid 服务功能。
-
已解决的问题
-
新的 Tanzu Kubernetes Grid 服务功能在使用 vSphere 网络连接的现有主管集群中不可用
-
在先前版本中，使用 vSphere 网络连接时，Tanzu Kubernetes Grid 服务功能和错误修复仅在新创建的主管集群中可用。在此版本中，用户可以更新使用 vSphere 网络连接的主管集群，从而利用最新的 Tanzu Kubernetes Grid 服务功能和错误修复。
-
新增功能：2020 年 12 月 17 日
| 2020 年 12 月 17 日内部版本信息 ESXi 7.0 | 2020 年 12 月 17 日 | ISO 内部版本 17325551 vCenter Server 7.0 | 2020 年 12 月 17 日 | ISO 内部版本 17327517 |
注意：如果您使用 vSphere 网络连接，则需要创建新的主管集群才能利用此版本中新的 Tanzu Kubernetes Grid 服务功能和错误修复。
新功能
-
主管集群
-
使用专用 T1 路由器实现主管命名空间隔离。使用 NSX-T 网络的主管集群使用新的拓扑，其中每个命名空间都有自己的专用 T1 路由器。
-
新创建的主管集群会自动使用此新拓扑。
-
在升级过程中，现有的主管集群将迁移到此新拓扑。
-
-
主管集群支持 NSX-T 3.1.0。主管集群与 NSX-T 3.1.0 兼容。
-
不再支持主管集群版本 1.16.x。现已移除主管集群版本 1.16.x。运行 1.16.x 的主管集群应升级到新版本。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
HTTP/HTTPS 代理支持。新创建的 Tanzu Kubernetes 集群可以使用全局 HTTP/HTTPS 代理来输出流量以及从 Internet 注册表中提取容器映像。
-
与注册表服务集成。新创建的 Tanzu Kubernetes 集群与 vSphere 注册表服务集成，可一起使用。现有集群更新到新版本后，也可以与注册表服务一起使用。
-
可配置的节点存储。Tanzu Kubernetes 集群现在可以将额外的存储卷挂载到虚拟机，从而增加了可用的节点存储容量。这样，用户可以部署更大的容器映像，这些映像可能会超出默认的 16 GB 根卷大小。
-
改进了状态信息。WCPCluster 和 WCPMachine 自定义资源定义现在执行条件状态报告。成功的Tanzu Kubernetes 集群生命周期管理取决于多个子系统（例如，主管、存储、网络连接）以及了解故障可能具有挑战性。现在，WCPCluster 和 WCPMachine CRD 会显示常见状态和故障情况，从而简化故障排除。
-
已解决的问题
-
缺少 vCenter Server 7.0 Update 1 中引入的新默认虚拟机类
-
升级到 vSphere 7.0.1 后，执行主管集群的 vSphere 命名空间更新时，运行命令“kubectl get virtualmachineclasses”不会列出新的虚拟机类大小 2x-large、4x-large、8x-large。此问题已解决，所有主管集群将配置正确的默认虚拟机类集。
-
新增功能：2020 年 10 月 6 日
| 2020 年 10 月 6 日 内部版本信息 ESXi 7.0 | 2020 年 10 月 6 日 | ISO 内部版本 16850804 vCenter Server 7.0 | 2020 年 10 月 6 日 | ISO 内部版本 16860138 |
新功能
-
主管集群
-
为主管集群配置 vSphere 网络连接。我们为主管集群引入了 vSphere 网络连接，您可以使用现有网络基础架构提供开发人员就绪平台。
-
支持使用 HAproxy 负载均衡器设置具有 vSphere 网络连接的主管集群。如果为主管集群配置了 vSphere 网络连接，则需要添加负载均衡器以处理现代工作负载。您可以使用 HAproxy OVA 部署和设置负载均衡器。
-
使用 vSphere Lifecycle Manager 管理主管集群生命周期。对于配置了 vSphere 网络连接的主管集群，可以使用 vSphere Lifecycle Manager 进行基础架构配置和生命周期管理。
-
有机会在您的硬件上试用 vSphere with Tanzu。如果您要在硬件上启用主管集群并免费测试此现代应用程序平台，则可以使用我们提供的产品内试用版。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
向 DevOps 用户公开 Kubernetes 版本。我们在主管集群中引入了新的“TanzuKubernetesRelease”自定义资源定义。此自定义资源定义为 DevOps 用户提供了有关他们可在 Tanzu Kubernetes 集群中使用的 Kubernetes 版本的详细信息。
-
VMware Container Networking 与 Antrea for Kubernetes 集成。我们集成了商业支持的 Antrea 版本，作为新 Tanzu Kubernetes 集群的默认容器网络接口 (CNI)。Antrea 为 Tanzu Kubernetes Grid 服务带来了一整套企业网络策略功能。有关更多详细信息，请阅读发行公告。虽然 Antrea 是默认的 CNI，但 vSphere 管理员和 DevOps 用户仍可以选择 Calico 作为 CNI Tanzu 集群的 CNI。
-
支持使用 vSphere 网络连接的主管集群环境。现在支持使用 vSphere 网络连接的主管集群环境，方便您利用现有的网络基础架构。
-
已解决的问题
-
无内容列表。这是一个功能版本。
新增功能：2020 年 8 月 25 日
| 内部版本信息 - 2020 年 8 月 25 日 ESXi 7.0 | 2020 年 6 月 23 日 | ISO 内部版本 16324942 vCenter Server 7.0 | 2020 年 8 月 25 日 | ISO 内部版本 16749653 |
- 新功能
- 已解决的问题
- 新增功能：2020 年 7 月 30 日
- 新增功能：2020 年 6 月 23 日
- 新增功能：2020 年 5 月 19 日
- 初始 vSphere with Kubernetes 版本的内部版本信息
新功能
-
无，这只是一个错误修复版本。
已解决的问题
-
升级到 7 月 30 日修补程序后 CPU 利用率较高
-
vCenter Server 升级到 7 月 30 日修补程序后，CPU 利用率较高。此问题现已解决。
-
-
带有 Windows 行尾的证书导致主管集群启用失败
-
如果证书中存在 Windows 行尾，则启用主管集群可能会失败。此问题现已解决。
-
新增功能：2020 年 7 月 30 日
| 2020 年 7 月 30 日内部版本信息 ESXi 7.0 | 2020 年 6 月 23 日 | ISO 内部版本 16324942 vCenter Server 7.0 | 2020 年 7 月 30 日 | ISO 内部版本 16620007 |
新功能
-
主管集群：新版本 Kubernetes，支持自定义证书和 PNID 更改
-
主管集群现在支持 Kubernetes 1.18.2（以及 1.16.7 和 1.17.4）
-
现在支持将计算机 SSL 证书替换为自定义证书
-
当 vCenter Server 中存在主管集群时，现在支持 vCenter PNID 更新
-
-
Tanzu Kubernetes Grid Service for vSphere：针对集群扩展、网络和存储添加了新功能
-
Tanzu Kubernetes Grid Service 集群现在支持集群缩减操作
-
默认情况下，现在所有 Tanzu Kubernetes Grid Service 集群均实施 Ingress 防火墙规则
-
新版本 Kubernetes 会定期异步发送到 vSphere 修补程序，当前版本为 1.16.8、1.16.12、1.17.7、1.17.8
-
-
网络服务：新版本 NCP
-
ClusterIP 服务现在支持 SessionAffinity
-
Kubernetes 1.18 中的 Ingress 支持 IngressClass、PathType 和 Wildcard 域
-
Ingress Controller 现在支持客户端身份验证
-
-
注册表服务：新版本 Harbor
-
注册表服务现已升级到 1.10.3
-
有关如何升级的详细信息和说明，请参阅更新 vSphere with Tanzu 集群文档。
已解决的问题
-
Tanzu Kubernetes Grid 服务集群 NTP 同步问题
新增功能：2020 年 6 月 23 日
| 内部版本信息 - 2020 年 6 月 23 日 ESXi 7.0 | 2020 年 6 月 23 日 | ISO 内部版本 16324942 vCenter Server 7.0 | 2020 年 6 月 23 日 | ISO 内部版本 16386292 Tanzu Kubernetes 集群 OVA：v1.16.8+vmware.1-tkg.3.60d2ffd |
新功能
-
无，这只是一个错误修复版本。
已解决的问题
-
Tanzu Kubernetes Grid 服务集群升级失败
-
我们解决了以下问题：升级 Tanzu Kubernetes Grid Service 集群可能会因“错误: 前一个节点未知 (Error: unknown previous node)”而失败
-
-
主管集群升级失败
-
我们解决了以下问题：嵌入式 Harbor 处于失败状态时，主管集群更新可能会停滞不前
-
新增功能：2020 年 5 月 19 日
| 内部版本信息 - 2020 年 5 月 19 日 ESXi 7.0 | 2020 年 4 月 2 日 | ISO 内部版本 15843807 vCenter Server 7.0 | 2020 年 5 月 19 日 | ISO 内部版本 16189094 Tanzu Kubernetes 集群 OVA：v1.16.8+vmware.1-tkg.3.60d2ffd |
新功能
-
Tanzu Kubernetes Grid Service for vSphere：滚动升级和服务升级
-
客户现在可以对工作节点和控制平面节点执行 Tanzu Kubernetes Grid Service for vSphere 的滚动升级，以及升级 pvCSI、Calico 和 authsvc 服务。包括针对这些服务的预检查和升级兼容性。
-
滚动升级可用于垂直扩展工作节点，即，将工作节点的虚拟机类更改为更小或更大的大小。
-
-
主管集群：新版本的 Kubernetes，支持升级
-
主管集群现在支持 Kubernetes 1.17.4
-
主管集群现在支持从 Kubernetes 1.16.x 升级到 1.17.x
-
已解决的问题
-
有关已删除命名空间的命名冲突
-
我们解决了以下问题：如果用户删除了 vSphere 命名空间，然后又创建了一个新的同名 vSphere 命名空间，则会存在命名冲突，进而导致无法创建 Tanzu Kubernetes 集群。
-
-
改进发行名称
-
将 OVF 版本控制信息移至单独的一列，使所运行的 Kubernetes 版本更清晰明了。
-
初始 vSphere with Kubernetes 版本的内部版本信息
| 内部版本信息 - 2020 年 4 月 2 日 ESXi 7.0 | 2020 年 4 月 2 日 | ISO 内部版本 15843807 vCenter Server 7.0 | 2020 年 4 月 2 日 | ISO 内部版本 15952498 Tanzu Kubernetes 集群 OVA：v1.16.8+vmware.1-tkg.3.60d2ffd |
了解 vSphere with Tanzu
VMware 提供了多种资源，您可以通过这些资源来了解 vSphere with Tanzu。
-
阅读 vSphere with Tanzu 配置和管理，了解如何配置、管理和使用 vSphere with Tanzu。本指南旨在为 vSphere 系统管理员和 DevOps 团队提供有关 vSphere with Tanzu 架构、服务、许可、系统要求、设置和使用情况的详细信息。
-
使用《VMware 兼容性指南》可了解 vSphere with Tanzu 的 硬件兼容性和产品互操作性。vSphere with Tanzu 与 vSphere 7.0 具有相同的硬件要求。对于某些配置，vSphere with Tanzu 需要使用 NSX-T Edge 虚拟机，这些虚拟机具有自己较小的 CPU 兼容性子集。有关详细信息，请参见《NSX-T Data Center 安装指南》。
-
访问《vSphere 7.0 发行说明》的国际化部分，了解 vSphere with Tanzu 的可用语言版本。这些语言版本与 VMware 为 vSphere 提供的相同。
-
访问《vSphere 7.0 发行说明》的开源部分，查看 vSphere with Tanzu 开源组件的版权和许可证。《vSphere 7.0 发行说明》还介绍了何处下载 vSphere 开源组件。
已解决的问题
-
在 vCenter 升级到 vCenter Server 7.0 Update 2c 后，“命名空间摘要”页面上的“虚拟机服务”卡视图消失
在 vCenter 从 vCenter Server 7.0 Update 2a 升级到 vCenter Server 7.0 Update 2c 后，升级前创建的已有命名空间不在“命名空间摘要”视图下显示“虚拟机类”和“内容库”卡视图。此问题特定于 vCenter Server 7.0 Update 2a 源，不应影响从早期版本（如 vCenter Server 7.0 Update 2）进行升级
对于受影响的命名空间，升级主管集群应会还原“命名空间摘要”上的卡视图
-
由于虚拟机硬件版本不兼容，使用虚拟机服务创建的虚拟机上的某些操作可能会失败
如果 OVF 映像的虚拟机硬件版本不支持虚拟机上的操作，则该操作将失败。例如，对于虚拟硬件版本为 vmx-11 的映像，附加持久卷将失败，并显示以下错误：
Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed解决办法：无
-
在主管集群升级过程中，如果使用了 DaemonSet，则可能会创建额外的 vSphere Pod 并停滞在挂起状态
在主管集群升级过程中，DaemonSet 控制器会针对每个主管控制平面节点创建额外的 vSphere Pod。这是上游 Kubernetes 问题引起的。
解决办法：将 NodeSelector/NodeAffinity 添加到 vSphere Pod 规范，这样 DaemonSet 控制器在创建 Pod 时可以跳过控制平面节点。
-
Pod 创建间歇性失败：
某些环境报告 Pod 创建间歇性失败，并显示以下错误“无法获取映像。连接超时并显示‘无任何到主机的路由’错误 (“Failed to get image”. Connection timeout with a No Route to Host error”)”。这是由于映像提取程序请求期间超时值默认为 3 秒所致。
请联系 GSS，增加默认超时值。
-
如果 VC 具有大量断开连接的主机，则主管服务可能会崩溃：
在许多主机由于用户名和密码错误而断开连接的环境中，主管服务可能会崩溃，并且无法再次启动。
此问题已在最新版本中得到解决。
-
在 vCenter Server 7.0 Update 3 上配置具有 NSX-T Data Center 的主管集群可能会失败
配置具有 NSX-T Data Center 的主管集群可能无法在 ESXi 主机上安装 spherelet VIB，并显示以下错误：
Could not find a trusted signer: self signed certificate自签名 Spherelet VIB 与 vCenter Server 7.0 Update 3 捆绑在一起。但是，如果属于 vSphere 集群的 ESXi 主机上未启用安全引导，或者主机未在集群上启用 vSphere Lifecycle Manager (vLCM)，主管集群启用操作将成功。此问题现已在最新版本中得到解决。
-
vCenter 升级到 70u3f 时由于 WCP 服务未启动而失败
请参见知识库文章 89010
可以对处于失败状态的 vCenter Server 7.0u3f 本身应用此解决办法，也可以对开始升级到 7.0u3f 之前的 vCenter Server 7.0u3d 加以应用。
1.使用 root 凭据连接到 vCenter Server SSH 会话。
2.使用以下命令连接到 WCP 数据库：
PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost
3.运行以下命令，查看 instance_id 为 null 的条目：
SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;
4.将 cluster_db_configs 中值为 null 的 instance_id 更新为随机 UUID：
UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;
5.修复数据库条目后，需要重新启动 WCP 服务（以及升级后未启动的任何其他服务）。
service-control --status --all
service-control --restart --all（--stop 或 --start）
或
service-control --restart wcp（--stop 或 --start）
6.重新运行步骤 2 和 3，确认 instance_id 为非 NULL。现在，vCenter Server 肯定已启动且正在运行。
7.在此阶段，如果用户对 vCenter Server 70u3d 应用了此解决办法，则继续升级到 vCenter Server 70u3f；如果用户对 vCenter Server 70u3f 应用了此解决办法，请访问 VMware 设备管理界面 (VAMI) 或 CLI 安装程序并继续升级。
-
升级后，安全策略功能可能不可用
如果存在 NSX-T 3.1.x/3.0.x，并且升级了 vCenter，然后升级主管集群，最后将 NSX-T 升级到 3.2 或更高版本，则安全策略功能可能不可用，因为 NCP 无法识别 NSX-T 升级。
-
改进了使用 Antrea-ENCAP 并激活 LRO 的 Tanzu Kubernetes Grid 集群虚拟机的网络吞吐量性能
增加了数据路径优化，改进了使用 Antrea-ENCAP 并启用 LRO 的 Tanzu Kubernetes Grid 集群的网络吞吐量性能。
无
-
在主管上启用嵌入式 Harbor 注册表可能会导致不安全的默认配置
如果完成了在主管集群上启用嵌入式 Harbor 注册表中所述的步骤，则嵌入式 Harbor 注册表中可能存在不安全的默认配置。有关此问题的详细信息，请参见 VMware 知识库文章 91452。
解决办法：可以通过以下两种方法解决该问题：安装本版本或实施知识库文章 91452 中所述的临时解决办法。
已知问题
主管集群
-
<span style="color:#FF0000">新：</span>从共享数据存储（如 vSAN）中删除多个 FCD 和卷时，您可能会注意到性能变化
性能变化可能是由一个已修复的问题导致的。如果未能修复，该问题会导致失效的 FCD 和卷在 FCD 删除操作失败后仍保留在数据存储中。
解决办法：无。尽管性能发生变化，但删除操作仍照常运行。
-
将已断开连接的 ESXi 节点移出集群后，如果该节点仍位于同一数据中心下，则该节点上运行的 pod 和 PVC 会保持“正在终止”状态
如果 ESXi 主机由于 PSOD 而处于“未响应”状态，则将该主机移出集群，但仍位于同一数据中心下时，在该主机上运行的 pod 和 PVC 停滞在“正在终止”状态。即使集群中有备用节点，也会出现此问题。
当执行以下操作时，通常会出现此问题：
-
在主管集群上启用合作伙伴服务并创建该服务的实例。
-
运行服务实例的 ESXi 节点出现 PSOD。
-
断开无响应的主机的连接，并将其移出位于同一数据中心的集群。
主机移出集群后，可能会发现该节点上的 pod 和 PVC 保持“正在终止”状态。
解决办法：从清单中移除主机，而不是将其移出位于同一数据中心的集群。
-
-
当 DRS 设置为手动模式时，在主管集群上创建容器有时会失败
启用工作负载管理的集群还必须启用 HA 和自动 DRS。在未启用 HA 和 DRS 或者 DRS 为手动模式的集群上启用工作负载管理时，可能会导致行为不一致以及容器创建失败。
解决办法：在集群上启用 DRS 并将其设置为全自动或半自动。还要确保在集群上启用了 HA。
-
即使移除相应存储策略后运行 kubectl get sc，仍会显示存储类
将创建的存储策略添加到命名空间后，如果移除该策略，在运行
kubectl get sc时命令响应仍会列出相应的存储类。解决办法：运行
kubectl describe namespace，查看与该命名空间实际关联的存储类。 -
在主管集群上运行 kubectl describe storage-class 或 kubectl get storage-class 时返回所有存储类，而不仅仅是该主管命名空间的存储类
在主管集群上运行
kubectl describe storage-class或kubectl get storage-class命令时，该命令将返回所有存储类，而不仅仅是该主管命名空间的存储类。解决办法：根据配额的详细名称推断与命名空间关联的存储类名称。
-
共享 Kubernetes API 端点按钮忽略 FQDN，即使已配置 FQDN
即使为主管集群命名空间的 Kubernetes 控制平面 IP 配置了 FQDN，共享命名空间按钮也会提供 IP 地址而不是 FQDN。
解决办法：手动与 FQDN 共享主管集群命名空间。
-
无法通过 kubectl vSphere 登录访问负载均衡器
使用负载均衡端点时，无法通过 kubectl vSphere 登录访问 API 服务器。
解决办法：此问题可能表现为两种形式。
-
检查是否可通过控制平面 <curl -k https://vip:6443（或 443）> 访问 API 服务器
-
如果无法从 API 服务器访问负载均衡器，则 API 服务器尚未启动。
-
解决办法：等待几分钟以使 API 服务器变为可访问。
-
-
检查 Edge 虚拟机节点的状态是否为“启动”。
-
登录到 NSX Manager。
-
转到系统 > 架构 > 节点 > Edge 传输节点。节点状态应为“启动”。
-
转到网络 > 负载均衡器 > 虚拟服务器。查找以 kube-apiserver-lb-svc-6443 和 kube-apiserver-lb-svc-443 结尾的 VIP。如果它们的状态不是“启动”，请使用以下解决办法。
-
解决办法：重新引导 Edge 虚拟机。Edge 虚拟机应在重新引导后重新配置。
-
-
-
在集群配置期间配置 vSphere with Tanzu 时显示超时错误
在配置集群的过程中，您可能会看到以下错误消息：
Api request to param0 failed或
Config operation for param0 node VM timed out解决办法：无。启用 vSphere with Tanzu 可能需要 30 到 60 分钟的时间。如果您看到这些消息或类似的
param0超时消息，它们并非错误，可以放心地忽略。 -
在 vSphere with Tanzu 中禁用并立即重新启用 vSphere 服务会导致 vCenter Server 中的相应命名空间变得无响应。
禁用并立即重新启用 vSphere 服务时，将删除主管集群中的命名空间并重新创建。但是，vCenter Server 中的相应命名空间仍处于“正在终止”状态。因此，无法将资源配额分配给 vCenter Server 中的命名空间，并且 DevOps 工程师无法在命名空间上创建 pod 和 PVC 等资源。此外，UI 插件部署失败，因为服务运维人员 pod 无法运行。
可以在主管集群上运行以下命令，获取 App Platform 日志：kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0。
解决办法：
在重新启用服务之前，请等待从 vCenter Server 中完全删除命名空间。
如果命名空间停滞在“正在终止”状态，请执行以下步骤：
1.再次禁用服务。
2.在 vCenter Server 中重新启动 wcp 服务。
3.等待删除命名空间。此步骤可能需要一些时间。
4.重新启用服务。
-
启用容器注册表失败并显示错误
当用户从 UI 中启用容器注册表时，启用操作在 10 分钟后失败，并出现超时错误。
解决办法：禁用容器注册表，然后重试以启用。请注意，可能会再次出现超时错误。
-
禁用集群后再启用集群会失败并显示错误
在禁用集群后不久启用该集群可能会在服务帐户密码重置过程中产生冲突。启用操作失败并显示错误。
解决办法：使用命令
vmon-cli --restart wcp重新启动。 -
删除嵌入式容器注册表中的容器映像标记可能会删除共享同一物理容器映像的所有映像标记
可以将具有不同标记的多个映像从同一个容器映像推送到嵌入式容器注册表中的某个项目。如果删除该项目上的其中一个映像，将会删除从同一映像推送的具有不同标记的所有其他映像。
解决办法：该操作无法撤消。再次将映像推送到项目。
-
对注册表项目执行的清除操作失败导致项目处于“错误”状态
对注册表项目执行清除操作时，该项目将暂时显示为处于错误状态。您将无法推送或提取此类项目中的映像。将定期检查该项目，并删除和重新创建处于错误状态的所有项目。发生这种情况时，所有之前的项目成员都将重新添加到重新创建的项目中，并且项目中以前存在的所有存储库和映像都将被删除，从而有效完成清除操作。
解决办法：无。
-
当存储容量小于 2000 兆字节时，容器注册表启用失败
容器注册表存在最小总存储容量要求，表示为 VMODL 中的“限制”字段。这是因为某些 Kubernetes pod 需要足够的存储空间才能正常工作。要实现容器功能，至少需要 5 千兆字节的容量。请注意，此限制不能保证性能改进，也不能增大支持的映像数量或大小。
解决办法：部署具有更大总容量的容器注册表可避免此问题。建议的存储卷不小于 5 千兆字节。
-
如果替换 Kubernetes 集群的 NSX 负载均衡器的 TLS 证书，则可能无法从 Docker 客户端或 Harbor UI 登录到嵌入式 Harbor 注册表
要替换 Kubernetes 集群的 NSX 负载均衡器的 TLS 证书，请从 vSphere UI 导航到配置 > 命名空间 > 证书 > NSX 负载均衡器 > 操作，然后单击替换证书。替换 NSX 证书时，从 Docker 客户端或 Harbor UI 登录嵌入式 Harbor 注册表的操作可能会失败，并显示
unauthorized: authentication required或Invalid user name or password错误。解决办法：在
vmware-system-registry命名空间中重新启动注册表代理 Pod：-
运行
kubectl get pod -n vmware-system-registry命令。 -
运行
kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry命令，删除 Pod 输出。 -
等待 Pod 重新启动。
-
-
使用 DNSDefault 部署的 Pod 将使用 clusterDNS 设置
在主管集群中部署并使用 DNSDefault 的任何 vSphere pod 都将回退到使用为集群配置的 clusterDNS
解决办法：无。
-
升级主管集群时，集群中的所有主机可能会同时更新
在某些情况下，集群中的所有主机将在主管集群升级过程中并行更新。这将导致此集群上运行的所有 pod 停止运行。
解决办法：在升级主管集群期间，请勿重新启动 wcpsvc 或移除/添加主机。
-
如果将 VMCA 用作中间 CA，则主管集群升级可能会无限期停滞不前
如果将 VMCA 用作中间 CA，则主管集群升级可能会无限期停滞在“正在配置”状态。
解决办法：将 VMCA 切换到非中间 CA，并删除停滞在“正在配置”状态的所有控制平面虚拟机。
-
如果为 Pod 临时磁盘分配启用了加密的存储策略，则 vSphere Pod 部署将失败
如果对 Pod 临时磁盘使用启用了加密的存储策略，则 vSphere Pod 创建将失败，并显示“卷的 AttachVolume.Attach 失败 (AttachVolume.Attach failed for volume)”错误。
解决办法：对 Pod 临时磁盘使用不含加密的存储策略。
-
在“命名空间集群升级处于升级主机步骤”时，主管集群升级达到 50% 时挂起
在升级 Kubernetes 控制平面节点时，如果 vSphere Pod 挂起且处于“正在终止”状态，则会出现该问题。控制平面节点的控制器会尝试升级 Spherelet 进程，在此阶段，会在该控制平面节点上逐出或终止 vSphere Pod 以从 Kubernetes 控制平面取消注册节点。出于此原因，主管集群升级会在较旧版本上挂起，直到从清单中移除处于“正在终止”状态的 vSphere Pod。
解决办法：
1.登录到 vSphere Pod 挂起且处于“正在终止”状态的 ESXi 主机。
2.使用以下命令移除处于“正在终止”状态的 vSphere Pod：
# vim-cmd vmsvc/getallvms# vim-cmd vmsvc/destroy在此步骤之后，vSphere Pod 在 vSphere Client 中显示为孤立状态。
3.先将用户添加到 ServiceProviderUsers 组，再删除孤立的 vSphere Pod。
a.) 登录到 vSphere Client，选择系统管理 -> 用户和组 -> 创建用户，然后单击组。
b.) 搜索 ServiceProviderUsers 或管理员组，然后将用户添加到该组。
4.以刚创建的用户身份登录到 vSphere Client，然后删除孤立的 vSphere Pod。
5.在 kubectl 中，使用以下命令：
kubectl patch pod -p -n '{"metadata":{"finalizers":null}}' -
工作负载管理 UI 引发以下许可证错误：连接到此 vCenter 的所有主机均未获得工作负载管理许可 (None of the hosts connected to this vCenter are licensed for Workload Management)
在 vSphere 集群上成功启用工作负载管理后，重新引导 vCenter Server 或升级已启用工作负载管理的 ESXI 主机后，您可能会看到以下许可错误：连接到此 vCenter 的所有主机均未获得工作负载管理许可 (None of the hosts connected to this vCenter are licensed for Workload Management)。这是外观 UI 错误。您的许可证仍然有效，并且工作负载仍在运行。
解决办法：用户应清除 vSphere Client 的浏览器缓存。
-
大型 vSphere 环境可能需要很长时间才能在云上使用 VMware NSX Advanced Load Balancer Controller 进行同步
如果 vSphere 环境的清单中包含的 ESXi 主机超过 2,000 个，虚拟机超过 45,000 个，则可能需要长达 2 个小时才能在云上使用 NSX Advanced Load Balancer Controller 进行同步。
解决办法：无
-
在 vCenter Server 7.0 Update 2 上更改 VMware Certificate Authority (VMCA) 根证书后，主管集群的专用容器注册表可能会变得不正常
在 vCenter Server 系统 7.0 Update 2 上更改 VMware Certificate Authority (VMCA) 根证书后，主管集群的专用容器注册表可能变为不正常，并且注册表操作可能会停止正常工作。在集群配置 UI 上，容器注册表将显示以下运行状况消息：
Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority解决办法：
在 vSphere kubernetes 集群上的 vmware-system-registry 命名空间中手动重新启动注册表代理 Pod：
-
运行
kubectl get pod -n vmware-system-registry命令以获取注册表代理 Pod。 -
通过运行
kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry命令删除 Pod 输出。 -
等待 Pod 重新启动。
-
在集群配置 UI 上刷新映像注册表，运行状况不久后应显示为正在运行。
-
-
在专用容器注册表上，不会自动为主管集群中新创建的命名空间创建项目
在专用容器注册表上，可能不会自动为主管集群中新创建的命名空间创建项目。容器注册表的状态仍显示为正常，但在创建新命名空间时，集群的容器注册表上未显示任何项目。无法将映像推送或提取到容器注册表上新命名空间的项目。
解决办法：
-
运行 kubectl get pod -n vmware-system-registry 命令以获取注册表代理 Pod。
-
通过运行 kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry 命令删除 Pod 输出。
-
等待 Pod 重新启动。
-
登录到专用容器注册表，以验证是否为集群上的命名空间创建了项目。
-
-
创建具有 10 个副本的 pod 时，您可能会看到 ErrImgPull
尝试使用 YAML 中具有 10 个副本 pod 的部署时，可能会出现此问题。尝试使用专用容器注册表通过此 YAML 创建时，在 10 个副本中，至少 7 个可能会通过，3 个可能会失败，并出现“ErrImgPull”问题。
解决办法：使用较少的副本集，最多 5 个。
-
使用自定义端口部署 vCenter Server 时，不支持 NSX Advanced Load Balancer Controller
无法向 NSX Advanced Load Balancer Controller 注册 vCenter Server，因为注册时 NSX Advanced Load Balance Controller UI 中不存在用于提供自定义 vCenter Server 端口的选项。
NSX Advanced Load Balancer Controller 仅在使用默认端口 80 和 443 部署 vCenter Server 时起作用。
-
在已包含正在运行的主管集群的 vCenter Server 上执行域重新指向时，主管集群将进入“正在配置”状态
包含主管集群的 vCenter Server 不支持域重新指向。尝试执行域重新指向时，现有主管集群将进入“正在配置”状态，而且控制平面虚拟机和 Tanzu Kubernetes 集群虚拟机将不再显示在“主机和集群”视图下的清单中。
解决办法：无
-
对于主管集群中使用 Kubernetes 创建的虚拟机，分配标记和自定义属性不起作用
尝试通过 vSphere UI 客户端或 vAPI 为在主管集群中创建的虚拟机分配标记或自定义属性时，该操作将失败，并显示消息“附加标记时出错 (An error occurred while attaching tags)”。
解决办法：无
-
有权访问自助式命名空间的开发人员无法访问集群范围的资源，如存储类
当开发人员尝试使用
kubectl命令列出集群范围的存储类时kubectl get storageclass -n test-ns or kubectl get storageclass会遇到以下错误。
Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope解决办法：这是预期行为，因为开发人员只能访问分配给他们有权访问的命名空间模板的存储类。这是 vSphere 管理员预先确定的。
使用以下命令将列出与命名空间关联的存储类。
kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE> -
通过“kubectl apply -f”自助创建命名空间失败
尝试使用清单通过
kubectl apply -f创建命名空间失败并显示错误Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope解决办法：开发人员可以改用
kubectl create -f命令创建命名空间。 -
在自助式命名空间中创建 vSphere pod 间歇性失败
尝试在使用自助式命名空间模板创建的命名空间中创建 vSphere pod 时，可能会遇到“无法创建资源 pod (cannot create resource pods)”错误。
解决办法：命名空间创建后等待几秒钟，然后再在命名空间中创建 vSphere pod。
-
开发人员无法向使用自助式命名空间模板创建的命名空间添加标签和注释
尝试使用命令
kubectl apply -f在清单中指定用于创建或修改命名空间的标签和注释失败并显示错误Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""解决办法：将所需的标签和注释添加到命名空间清单中，然后改用
kubectl create -f添加标签和注释。 -
运行主管集群升级后，才能使用命名空间模板
启动主管集群升级时，与命名空间模板相关的任何任务（如激活、取消激活或更新）都会保留在队列中，直到升级完成。
解决办法：等待升级操作完成，然后再运行命令以操作命名空间模板
-
尝试将持久卷附加到 Tanzu Kubernetes 集群上的 pod 失败，并显示“CNS: 由于缺少 SCSI 控制器，无法附加磁盘 (CNS: Failed to attach disk because missing SCSI controller)”错误消息
在尝试将持久卷附加到 Tanzu Kubernetes 集群上的 pod 时，尝试失败，并且该 pod 一直处于挂起状态。错误消息指示缺少 SCSI 控制器，即使工作节点虚拟机配置了 PVSCSI 控制器。
工作节点虚拟机达到块卷限制（60 个卷）时，可能会出现此问题。但是，Kubernetes 会忽略 vSphere 卷限制，并调度在该节点上创建块卷。
解决办法：向集群中添加工作节点。删除 pod 以调度将其部署到新工作节点。
-
如果在非活动 vCenter Server 会话后删除有状态 pod 并稍后尝试在 Tanzu Kubernetes 集群中重用或删除其卷，此操作可能会导致失败并显示不可预知的行为
如果在有状态 pod 处于非活动状态大约一天后将其删除，其卷似乎已成功与 Tanzu Kubernetes 集群的节点虚拟机分离。但是，在尝试使用该卷创建新的有状态 pod 或删除该卷时，此尝试操作将失败，因为该卷仍附加到 vCenter Server 中的节点虚拟机。
解决办法：使用 CNS API 将该卷与节点虚拟机分离，以同步该卷在 Tanzu Kubernetes 集群和 vCenter Server 中的状态。此外，在主管集群中重新启动 CSI 控制器以恢复非活动会话。
-
主管集群升级由于主管集群的主工作负载网络（如果使用的是 vSphere 网络连接）/NCP 集群网络 pod CIDR（如果使用的是 NSX-T Container Plugin）上的 IP 范围耗尽而停滞不前/未完成。
主管集群升级停滞在挂起状态，并显示以下消息：“命名空间集群升级处于置备新主节点步骤 (Namespaces cluster upgrade is in provision a new master step)”。
在集群升级期间部署的新控制平面虚拟机仅收到一个网络接口。控制平面虚拟机应具有 2 个网络接口，一个接口连接到管理网络，另一个连接到工作负载网络。
应该部署到新控制平面虚拟机的某些系统 pod（如 coredns）可能会停滞在挂起状态。
解决办法：删除少量工作负载（虚拟机、Pod 虚拟机、TKG 集群）以释放足够的 IP 完成升级过程。应至少释放 3 个 IP。
-
更新主管服务配置的键值对或注册表凭据
如果输入了错误的登录凭据，或者注册表密码可能已过期，您可能希望更改主管服务的配置注册表键值对。
解决办法：
1.在主管集群上创建新的密钥资源。
kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=2.更新主管服务资源的服务引用。
# kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services3.更新 spec.config 会话：
spec:config:secretNamespace: vmware-system-supervisor-servicessecretRef: new-secret -
Tanzu Kubernetes Grid Service 和主管服务 UI 插件不正常运行
当 vCenter Server 由自定义 CA 证书签名并启用主管集群时，vSphere Client 中部署的 Tanzu Kubernetes Grid Service UI 插件和任何主管服务 UI 插件不会正常运行。这些 UI 插件在尝试与主管集群中的相应后端服务器通信时遇到 SSL 身份验证问题。Tanzu Kubernetes Grid Service 插件显示以下错误:
The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details解决办法：将信任根添加到 /etc/ssl/certs 下的单独文件（而不是
vmca.pem）中，并使用c_rehash重新生成哈希。必须在所有三个控制平面虚拟机上执行此操作。请注意，不建议编辑 /etc/ssl/certs/vmca.pem，因为在每次集群同步期间，更新控制器都会覆盖此文件的内容。
请注意，如果主管集群中的某个控制平面虚拟机重新部署（例如，调整控制平面虚拟机大小后或由于修复操作），则手动添加到
/etc/ssl/certs的证书将丢失，必须重新对该虚拟机应用此解决办法。 -
主管集群挂起且处于正在配置状态
将 vSphere 集群配置为主管集群后，集群挂起且处于正在配置状态。无法创建 vSphere Pod 和 Tanzu Kubernetes 集群。
解决办法：使用以下命令重新启动 wcp 服务：
vmon-cli restart wcp请查看文档，了解更详细的说明。
-
即使关联的内容库中填充了虚拟机映像，“kubectl get virtualmachineimages”也不返回任何结果
如果虚拟机服务使用的内容库启用了安全策略，则虚拟机服务将无法读取映像，并且无法使用此内容库中的映像部署虚拟机。
解决办法：解除具有安全策略的内容库与主管命名空间的关联。从相关内容库中移除“默认 OVF 安全策略”设置，然后将内容库与命名空间重新关联。
-
对于具有 vGPU 的虚拟机和由虚拟机服务管理的直通设备，当其主机进入维护模式时，开发人员将看到错误的 POWERSTATE。
当主机进入维护模式时，DRS 将自动关闭具有 vGPU 的虚拟机和由虚拟机服务管理的直通设备的电源。但是，kubectl get vm 的输出仍将显示之前的电源状况和虚拟机。即使已在 vCenter 上关闭虚拟机电源，结果也会显示 POWERSTATE=poweredOn。
无。
-
在设置了 NSX-T 的主管集群上，ESXi 主机可能会继续使用自签名 Spherelet VIB
如果使用 vCenter Server 7.0 Update 3 中提供的 Kubernetes 版本配置或升级了主管集群，并且进一步将主管集群的 Kubernetes 版本升级到了 vCenter Server 7.0 Update 3a 中提供的版本，则 ESXi 主机可能会继续使用自签名 Spherelet VIB。出现此问题的原因是，vCenter Server 7.0 Update 3 和 vCenter Server 7.0 Update 3a 上安装的自签名 Spherelet VIB 版本相同。此问题不适用于配置了 vSphere 网络堆栈的主管集群。
解决办法 1：
如果 vSphere 集群不基于 vSphere Lifecycle Manager，请执行以下步骤以安装 VMware 认证的 Spherelet VIB：
-
将 ESXi 主机置于维护模式，并等待主管集群将其标记为“未就绪”。
-
将该主机作为独立主机移出集群，并等待卸载 spherelet 和 NSX-T VIB。
-
将同一主机移回集群，退出维护模式并等待重新配置新的 spherelet 和 NSX-T VIB。
-
为集群内的每个 ESXi 主机重复上述步骤。
如果主管集群启用了 vSphere Lifecycle Manager，请停用主管集群，然后重新进行配置。
解决办法 2：
将 vCenter Server 升级到 vCenter Server 7.0 Update 3a 后，停用主管集群并重新进行配置。这同时适用于启用了 vSphere Lifecycle Manager 的集群以及基于非 vLCM/VUM 的集群。
-
-
某些 vSphere Pod 在重新引导主机或升级主管集群后显示 NodeAffinity 状态
重新引导主机或升级主管集群后，您可能会看到某些 vSphere Pod 显示 NodeAffinity 状态。此行为是由上游 Kubernetes 中的问题引起的，因为 Kubernetes 调度程序在重新启动 kubelet 后在集群中创建了状态为 NodeAffinity 的冗余 Pod。此问题不影响集群功能。有关上游 Kubernetes 问题的信息，请阅读 https://github.com/kubernetes/kubernetes/issues/92067。
解决办法：删除状态为 NodeAffinity 的冗余 Pod。
-
将环境升级到 7.0 Update 3e 或更高版本后，vSphere with Tanzu 上启用的 vDPp 服务操作者和实例 Pod 将进入“挂起”状态
如果主管集群上安装的合作伙伴服务版本不支持 Kubernetes 版本 1.22，则会出现此问题。将 vSphere with Tanzu 环境升级到与 1.22 兼容的版本 7.0 Update 3e 或更高版本后，该服务变得不兼容。因此，操作者和实例 Pod 将进入“挂起”状态。
尝试将服务升级到更新版本失败。
解决办法：将 vDPp 服务升级到与 Kubernetes 1.22 兼容的版本，然后再将 vSphere with Tanzu 升级到 7.0 Update 3e。
-
将集群从 Kubernetes 1.19.1 自动升级到 1.20.8 失败，无法继续
在极少数情况下，将集群从 Kubernetes 1.19.1 自动升级到 1.20.8 可能会失败，并显示以下错误：
找不到升级任务。请再次触发升级 (Task for upgrade not found. Please trigger upgrade again)。
解决办法：手动启动集群升级。
-
如果主管命名空间在短时间内重用，则对该主管命名空间的操作可能会失败：
如果删除主管命名空间，然后在短时间内重新创建具有相同名称的主管命名空间，则操作可能会由于缓存中的条目无效而失败。
该问题已在最新版本中得到解决。
-
主管支持包包括 VC 支持包：
通过生成主管支持包，不会自动包含 VC 支持包。
已在最新版本中得到解决。
-
网络支持检查表的内容未本地化。
在工作负载管理启用期间，可以下载网络检查表。该检查表未实施本地化。
已在最新版本中得到解决。
-
在扩展的 Tanzu Kubernetes 集群设置上，发现 WCP 系统 pod capi-kubeadm-control-plane-controller-manager 出现 OOM 问题
-
安全策略没有移除已更新的规则。
如果所创建的安全策略 CR 包含规则 A 和 B，然后您更新该 CR，则策略会将规则更改为 B 和 C。规则 A 仍会生效。
解决办法：删除安全策略，然后使用已更新的规则重新创建
-
NSX Advanced Load Balancer 上存在两个 SE 组时，不会创建 LoadBalancer 和 Tanzu Kubernetes 集群。
如果将第二个 SE 组添加到 NSX Advanced Load Balancer，无论是否为其分配 SE 或虚拟服务，创建新的主管集群或 Tanzu Kubernetes 集群都将失败，并且无法升级现有的主管集群。在 NSX Advanced Load Balancer 控制器上创建虚拟服务将失败，并显示以下错误消息：
“get() 返回了多个服务引擎组 - 它返回了 2 (get() returned more than one ServiceEngineGroup – it returned 2)”
因此，新的负载均衡器不可用，您无法成功创建新的工作负载集群。
有关详细信息，请参见 VMware 知识库文章 90386。
解决办法：应仅使用 SE 组“Default-Group”创建虚拟服务，并从 NSX Advanced Load Balancer 中删除 default-group 以外的所有其他 SE 组，然后重试该操作。
-
已更新的安全策略未生效。
如果所创建的安全策略 CR 包含规则 A 和 B，然后您更新该 CR，则策略会将规则更改为 B 和 C。规则 A 仍会生效，并且未移除。
解决办法：创建并应用包含规则 B 和 C 的新策略，并删除包含规则 A 和 B 的旧策略。
-
命名空间管理 API 有时可能会返回 HTTP 500 错误，无法授权请求
对工作负载管理的请求可能会间歇性失败。API 将返回 500 状态代码，并且不会处理任何请求。您将看到一条日志消息，指出“An unexpected error occurred during the authorization”。此问题间歇性出现，但在工作负载管理负载过重时（例如，主动配置一个或多个主管时）更可能出现此问题。
解决办法：重试发生该错误时正在尝试的操作。
-
主管集群可能会间歇性地处于“正在配置”或“错误”状态。
在启用、升级主管集群或重新部署其中的其他节点期间，该集群可能仍处于“正在配置”或“错误”状态，并显示以下错误消息：
“向 VMware vCenter Server (vpxd) 发出的 API 请求失败。详细信息 'ServerFaultCode: 出现常规系统错误: vix 错误代码 = (1, 0)' 可能停滞不前 (API request to VMware vCenter Server (vpxd) failed. Details 'ServerFaultCode: A general system error occurred: vix error codes = (1, 0)" may become stuck)。”
可在以下位置找到相关日志：/var/log/vmware/wcp/wcpsvc.log
删除与遇到该问题的控制平面虚拟机对应的 vSphere Agent Manager (EAM)，以强制重新部署节点。
-
成功删除 PVC 后，PV 仍处于已终止状态
删除 PersistentVolumeClaim (PVC) 后，相应的 PersistentVolume (PV) 可能仍在主管中处于已终止状态。此外，vSphere Client 也可能会显示多个失败的“deleteVolume”任务。
1.向主管进行身份验证：
kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME
2.获取处于正在终止状态的持久卷的名称：
kubectl get pv
3.记下持久卷中的卷句柄：
kubectl describe pv <pv-name>
4.使用上一步中的卷句柄，删除主管中的 CnsVolumeOperationRequest 自定义资源：
kubectl delete cnsvolumeoperationrequest delete-<volume-handle>
注意：在删除 PV 之前，请确保该 PV 未由集群中的任何其他资源使用。
网络
-
在速度较慢的网络上 NSX Edge 虚拟机部署失败
NSX Edge OVF 部署和 NSX Edge 虚拟机注册时共有 60 分钟的超时。在较慢的网络或具有较慢存储的环境中，如果 Edge 部署和注册所用的时间超过此 60 分钟超时时间，则操作将失败。
解决办法：清理 Edge 并重新启动部署。
-
如果在集群配置后 vCenter Server DNS、NTP 或 Syslog 设置发生更改，NSX Edge 不会更新
在集群配置期间，DNS、NTP 和 Syslog 设置从 vCenter Server 复制到 NSX Edge 虚拟机。如果在配置后更改其中的任何 vCenter Server 设置，则 NSX Edge 不会更新。
解决办法：使用 NSX Manager API 更新 NSX Edge 的 DNS、NTP 和 Syslog 设置。
-
NSX Edge 管理网络配置仅提供部分端口组上的子网和网关配置
仅当在所选 VDS 上的 DVPG 支持的主机上配置了 ESXi VMKnics 时，NSX Edge 管理网络兼容性下拉列表才会显示子网和网关信息。如果选择的分布式端口组未附加 VMKnic，则必须为网络配置提供子网和网关。
解决办法：使用以下配置之一：
-
Discreet 端口组：这是当前未驻留 VMK 的位置。您必须为此端口组提供相应的子网和网关信息。
-
共享管理端口组：这是 ESXi 主机的管理 VMK 所在的位置。将自动提取子网和网关信息。
-
-
无法在集群配置期间使用 VLAN 0
尝试将 VLAN 0 用于覆盖网络隧道端点或上行链路配置时，操作失败并显示以下消息：
Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network. Please use a VLAN ID between 1-4094解决办法：使用以下任一流程手动启用 VLAN 0 支持：
1.使用 SSH 登录到部署的 VC (root/vmware)。
2.打开 /etc/vmware/wcp/nsxdsvc.yaml。它将显示如下内容：
logging: level: debug maxsizemb: 10a. 要为 NSX 集群覆盖网络启用 VLAN0 支持，请将以下行附加到 /etc/vmware/wcp/nsxdsvc.yaml 并保存该文件。
experimental: supportedvlan: hostoverlay: min: 0 max: 4094 edgeoverlay: min: 1 max: 4094 edgeuplink: min: 1 max: 4094b. 要为 NSX Edge 覆盖网络启用 VLAN0 支持，请将以下行附加到 /etc/vmware/wcp/nsxdsvc.yaml 并保存该文件。
experimental: supportedvlan: hostoverlay: min: 1 max: 4094 edgeoverlay: min: 0 max: 4094 edgeuplink: min: 1 max: 4094c. 要为 NSX Edge 上行链路网络启用 VLAN0 支持，请将以下行附加到 /etc/vmware/wcp/nsxdsvc.yaml 并保存该文件。
experimental: supportedvlan: hostoverlay: min: 1 max: 4094 edgeoverlay: min: 1 max: 4094 edgeuplink: min: 0 max: 40943.使用
vmon-cli --restart wcp重新启动工作负载管理服务。 -
无法在启用了 vSphere Lifecycle Manager 映像的集群上启用 vSphere with Tanzu 和 NSX-T
vSphere with Tanzu 和 NSX-T 与 vSphere Lifecycle Manager 映像不兼容。它们仅与 vSphere Lifecycle Manager 基准兼容。在集群上启用 vSphere Lifecycle Manager 映像时，无法在该集群上启用 vSphere with Tanzu 或 NSX-T。
解决办法：将主机移至已禁用 vSphere Lifecycle Manager 映像的集群。必须将集群与 vSphere Lifecycle Manager 基准结合使用。移动主机后，可以在该新集群上启用 NSX-T，然后启用 vSphere with Tanzu。
-
为 vSphere with Tanzu 网络连接配置 NSX-T 时，不支持“ExternalTrafficPolicy: local”
对于类型为 LoadBalancer 的 Kubernetes 服务，不支持“ExternalTrafficPolicy: local”配置。
解决办法：无。
-
为 vSphere with Tanzu 网络连接配置 NSX-T 时，Tanzu Kuberetes 集群可支持的 LoadBalancer 类型的服务数量受主管集群的 NodePort 范围限制
类型为 LoadBalancer 的每个 VirtualMachineService 都会转换为一个类型为 LoadBalancer 的 Kubernetes 服务和一个 Kubernetes 端点。可在主管集群中创建的 LoadBalancer 类型 Kubernetes 服务的最大数量为 2767，这包括在主管集群自身上创建的该服务数量，以及在 Tanzu Kubernetes 集群中创建的该服务数量。
解决办法：无。
-
NSX Advanced Load Balancer Controller 不支持更改 vCenter Server PNID
为主管集群配置 NSX Advanced Load Balancer 后，无法更改 vCenter Server PNID。
解决办法：如果必须更改 vCenter Server 的 PNID，请移除 NSX Advanced Load Balancer Controller 并更改 vCenter Server PNID，然后重新部署并配置具有新 vCenter Server PNID 的 NSX Advanced Load Balancer Controller。
-
在 vSphere Distributed Switch (vDS) 环境中，配置 Tanzu Kubernetes 集群时所用的网络 CIDR 范围可能与主管集群的网络 CIDR 范围重叠或冲突，反之亦然，从而导致组件无法通信。
在 vDS 环境中，为主管集群配置 CIDR 范围或为 Tanzu Kubernetes 集群配置 CIDR 范围时，不会进行设计时网络验证。因此，可能会出现两个问题：
1) 创建主管集群时所用的 CIDR 范围与为 Tanzu Kubernetes 集群预留的默认 CIDR 范围冲突。
2) 创建 Tanzu Kubernetes 集群时所用的自定义 CIDR 范围与用于主管集群的 CIDR 范围重叠。
解决办法：对于 vDS 环境，配置主管集群时，不要使用用于 Tanzu Kubernetes 集群的默认 CIDR 范围之一，包括 192.168.0.0/16（预留用于服务）和 10.96.0.0/12（预留用于 pod）。另请参见 vSphere with Tanzu 文档中的“Tanzu Kubernetes 集群的配置参数”。
对于 vDS 环境，创建 Tanzu Kubernetes 集群时，不要使用用于主管集群的相同 CIDR 范围。
-
如果附加的自定义标签超过 18 个，则客户机集群虚拟网络创建将失败
如果用户希望在一个命名空间下成功创建客户机集群和虚拟机，用户最多可以为命名空间添加 18 个自定义标签，否则无法在命名空间下成功创建客户机集群的虚拟网络。
从命名空间中移除标签，使其总数小于或等于 18。NCP 重试机制将重试并创建命名空间，但可能需要长达 6 小时，具体取决于时间间隔。
-
对 WCP 支持通过 Policy API 创建的传输区域：
以前，如果通过 Policy API 创建 NSX 传输区域，则主管启用可能会失败。现在支持通过 Policy API 创建 NSX 传输区域，同时保持与通过 MP API 创建的 NSX 传输区域的向后兼容性。
已在最新版本中得到解决。
-
无法将 NSX Advanced Load Balancer 与使用嵌入式链接模式拓扑的 vCenter Server 结合使用。
配置 NSX Advanced Load Balancer 控制器时，可以在多个云上进行配置。但是，启用 vSphere with Tanzu 时，没有选择多个云的选项，因为它仅支持 Default-Cloud选项。因此，无法将 NSX Advanced Load Balancer 与使用嵌入式链接模式拓扑的 vCenter Server 版本结合使用。
为每个 vCenter Server 配置 NSX 负载均衡器。
存储
-
<span style="color:#FF0000">新：</span>尝试在 vSAN Direct 数据存储上运行移除磁盘操作失败，并显示“VimFault - 无法完成操作 (VimFault - Cannot complete the operation)”错误
通常，当出现以下情况之一时，您可能会看到此错误：
-
作为移除磁盘操作的一部分，放置在 vSAN Direct Datastore 上的所有持久卷将重定位到同一 ESXi 主机上的另一个 vSAN Direct 数据存储。如果目标 vSAN Direct 数据存储上没有可用空间，则重新放置操作可能会失败。为避免出现此故障，请确保目标 vSAN Direct 数据存储具有足够的存储空间来运行应用程序。
-
在 ESXi 主机上的目标 vSAN Direct 数据存储具有足够的存储时，移除磁盘操作也会失败。当底层持久卷重新放置操作（由移除磁盘父操作生成）由于卷的大小而超过 30 分钟时，可能会出现这种情况。在这种情况下，您在任务视图中会看到基础 vSphere Pod 的重新配置仍在进行中。
正在进行中的状态表示，即使移除磁盘操作超时并失败，通过重新配置vSphere Pod 完成的底层持久卷重新放置也不会中断。
解决办法：
vSphere Pod 的重新配置任务完成后，再次运行移除磁盘操作。移除磁盘操作成功继续。
-
-
在脱机或联机模式下扩展主管集群 PVC 不会扩展相应的 Tanzu Kubernetes 集群 PVC
由于文件系统尚未调整大小，因此，使用 Tanzu Kubernetes 集群 PVC 的 pod 无法使用主管集群 PVC 的扩展容量。
解决办法：将 Tanzu Kubernetes 集群 PVC 调整为等于或大于主管集群 PVC 的大小。
-
与底层卷相比，静态置备的 TKG PVC 中的大小不匹配
Kubernetes 中的静态置备不会验证 PV 与支持卷的大小是否相等。如果在 Tanzu Kubernetes 集群中静态创建一个 PVC，并且该 PVC 的大小小于相应底层主管集群 PVC 的大小，则可能会在 PV 中使用比请求的空间更多的空间。如果在 Tanzu Kubernetes 集群中静态创建的 PVC 大小大于底层主管集群 PVC 的大小，则即使在 Tanzu Kubernetes 集群 PV 中用尽请求的大小之前也可能会显示
No space left on device错误。解决办法：
-
在 Tanzu Kubernetes 集群 PV 中，将
persistentVolumeReclaimPolicy更改为Retain。 -
记下 Tanzu Kubernetes 集群 PV 的
volumeHandle，然后删除 Tanzu Kubernetes 集群中的 PVC 和 PV。 -
使用 volumeHandle 重新静态创建 Tanzu Kubernetes 集群 PVC 和 PV，并将存储设置为与相应主管集群 PVC 相同的大小。
-
-
如果外部 csi.vsphere.vmware.com 置备程序失去了主节点选举的租约，则尝试从主管命名空间或 TKG 集群创建 PVC 将失败
尝试使用
kubectl命令从主管命名空间或 TKG 集群创建 PVC 时，操作可能会失败。PVC 仍处于“挂起”状态。如果描述该 PVC，“事件”字段会以表布局显示以下信息：-
类型 –
Normal -
原因 –
ExternalProvisioning -
使用期限 –
56s (x121 over 30m) -
来自 –
persistentvolume-controller -
消息 –
waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator
解决办法：
-
确认
vmware-system-csi命名空间中的vsphere-csi-controllerpod 内的所有容器均在运行中。kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi -
使用以下命令检查外部置备程序日志。
kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c csi-provisioner以下条目指示外部置备程序 sidecar 容器失去了其主节点选举：
I0817 14:02:59.582663 1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading -
删除此 vsphere-csi-controller 实例。
kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi
Kubernetes 将创建新的 CSI 控制器实例，所有 sidecar 都将重新初始化。
-
-
所有 PVC 操作（如创建、附加、分离或删除卷）失败，同时 CSI 无法连接到 vCenter Server
除了操作失败外，也无法在主管集群中更新卷运行状况信息和存储池 CR。CSI 和 Syncer 日志显示有关无法连接到 vCenter Server 的错误。
CSI 以特定解决方案用户身份连接到 vCenter Server。此 SSO 用户的密码每 24 小时由 wcpsvc 轮换一次，且新密码将传输到 CSI 驱动程序读取的“密钥”中以连接到 vCenter Server。如果新密码无法传送到“密钥”，则失效密码将保留在主管集群中，并且 CSI 驱动程序的操作将失败。
此问题会影响 vSAN 数据持久性平台和所有 CSI 卷操作。
解决办法：
通常，WCP 服务会将更新的密码传送到在 Kubernetes 集群中运行的 CSI。有时，由于出现问题（例如，连接问题或同步过程的前期部分出现错误）而不会传送密码。CSI 继续使用旧密码，并最终由于身份验证失败次数过多而锁定帐户。
确保 WCP 集群处于正常的“正在运行”状态。在“工作负载管理”页面上不应报告该集群的任何错误。解决导致同步失败的问题后，强制刷新密码以解锁锁定的帐户。
要强制重置密码，请执行以下操作：
-
停止 wcpsvc：
vmon-cli -k wcp -
将上次密码轮换的时间编辑为较小的值（例如 1），方法为：将
/etc/vmware/wcp/.storageUser中的第三行更改为 1。 -
启动 wcpsvc：
vmon-cli -i wcp
wcpsvc 将重置密码，从而解锁帐户并将新密码传送到集群。
-
VMware Tanzu Kubernetes Grid Service for vSphere
-
在主管集群升级后，Tanzu Kubernetes 集群挂起且处于“正在更新”状态
在升级主管集群时，会触发所有 Tanzu Kubernetes 集群的滚动更新以传播任何新的配置设置。在此过程中，之前“正在运行”的 TKC 集群可能会在“正在更新”阶段挂起。Tanzu Kubernetes 集群的“正在运行”状态仅指示控制平面的可用性，有可能所需的控制平面和工作节点尚未成功创建。此类 Tanzu Kubernetes 集群可能会导致完成主管集群升级时启动的滚动更新期间执行的运行状况检查失败。这会导致 Tanzu Kubernetes 集群在“正在更新”阶段挂起，可以通过查看与 Tanzu Kubernetes 集群关联的
KubeadmControlPlane资源确认这一点。该资源发出的事件类似以下内容：Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked解决办法：无。
-
Tanzu Kubernetes 集群继续访问已移除的存储策略
当 VI 管理员从 vCenter Server 命名空间中删除存储类时，不会为已在使用该存储类的任何 Tanzu Kubernetes 集群移除对该存储类的访问权限。
解决办法：
-
以 VI 管理员的身份从 vCenter Server 命名空间中删除存储类后，应创建一个具有相同名称的新存储策略。
-
重新添加现有存储策略或刚刚重新创建到主管命名空间的存储策略。使用此存储类的 TanzuKubernetesCluster 实例现在应该能够完全正常运行。
-
对于使用您想要删除的存储类的每个 TanzuKubernetesCluster 资源，请创建使用不同存储类的新 TanzuKubernetesCluster 实例，并使用 Velero 将工作负载迁移到新集群中。
-
只要没有 TanzuKubernetesCluster 或 PersistentVolume 使用该存储类，就可以安全地将其移除。
-
-
嵌入式容器注册表 SSL 证书未复制到 Tanzu Kubernetes 集群节点
为主管集群启用嵌入式容器注册表时，Harbor SSL 证书未包含在该 SC 上创建的任何 Tanzu Kubernetes 集群节点中，并且无法从这些节点连接到注册表。
解决办法：将 SSL 证书从主管集群控制平面复制并粘贴到 Tanzu Kubernetes 集群工作节点。
-
无法从内容库获取虚拟机映像
在嵌入式链接模式设置下配置多个 vCenter Server 实例时，用户可以通过用户界面选择在不同 vCenter Server 实例上创建的内容库。选择此类库将导致 DevOps 用户无法使用虚拟机映像置备 Tanzu Kubernetes 集群。在这种情况下，“kubectl get virtualmachineimages”不会返回任何结果。
解决办法：将内容库与主管集群相关联以获取 Tanzu Kubernetes 集群虚拟机映像时，请选择在主管集群所在的同一 vCenter Server 实例中创建的库。或者，创建本地内容库，同时该库也支持对 Tanzu Kubernetes 集群进行气隙置备。
-
无法置备新的 Tanzu Kubernetes 集群或横向扩展现有集群，因为内容库订阅者无法与发布者同步。
为 Tanzu Kubernetes 集群 OVA 设置已订阅内容库时，会生成一个 SSL 证书，且系统会提示您通过确认证书指纹手动信任该证书。如果在初始库设置后更改该 SSL 证书，则必须通过更新指纹再次信任新证书。
编辑已订阅内容库的设置。这将启动订阅 URL 探查，即使未在库上请求任何更改也会如此。该探查将发现 SSL 证书不受信任，并提示您信任该证书。
-
Tanzu Kubernetes 版本 1.16.8 与 vCenter Server 7.0 Update 1 不兼容。
Tanzu Kubernetes 版本 1.16.8 与 vCenter Server 7.0 Update 1 不兼容。必须先将 Tanzu Kubernetes 集群更新到更高版本，然后才能对 U1 执行 vSphere 命名空间更新。
对 vCenter Server 7.0 Update 1 版本执行 vSphere 命名空间更新之前，请将运行版本 1.16.8 的每个 Tanzu Kubernetes 集群更新到更高版本。有关详细信息，请参阅文档中的 Tanzu Kubernetes 版本列表。
-
将工作负载控制平面升级到 vCenter Server 7.0 Update 1 后，新的虚拟机类大小不可用。
描述：升级到 vSphere 7.0.1 后，对 Tanzu Kubernetes 集群执行主管集群的 vSphere 命名空间更新时，运行命令“kubectl get virtualmachineclasses”不会列出新的虚拟机类大小 2x-large、4x-large、8x-large。
解决办法：无。新的虚拟机类大小只能在新安装的工作负载控制平面中使用。
-
使用 Calico CNI 时，Tanzu Kubernetes 发行版 1.17.11 vmware.1-tkg.1 在连接到集群 DNS 服务器时超时。
Tanzu Kubernetes 发行版 v1.17.11+vmware.1-tkg.1 存在 Photon OS 内核问题，导致映像无法按预期与 Calico CNI 一起使用。
解决办法：对于 Tanzu Kubernetes 发行版 1.17.11，标识为“v1.17.11+vmware.1-tkg.2.ad3d374.516”的映像解决了 Calico 问题。要运行 Kubernetes 1.17.11，请使用此版本，而不是“v1.17.11+vmware.1-tkg.1.15f1e18.489”。或者，使用其他 Tanzu Kubernetes 发行版，例如版本 1.18.5 或 1.17.8 或 1.16.14。
-
为 vSphere with Tanzu 网络连接配置 NSX-T Data Center 时，将“ExternalTrafficPolicy: Local”服务更新为“ExternalTrafficPolicy: Cluster”将导致无法在 SV 主节点上访问此服务的 LB IP
如果最初在工作负载集群中使用
ExternalTrafficPolicy: Local创建 LoadBalancer 类型的 Kubernetes 服务，后来更新为ExternalTrafficPolicy: Cluster，则将阻止在主管集群虚拟机上访问此服务的 LoadBalancer IP。解决办法：删除该服务，然后使用
ExternalTrafficPolicy: Cluster重新创建。 -
Tanzu Kubernetes 集群控制平面节点上的 CPU 使用率较高
Kubernetes 上游项目中存在一个已知问题，即，kube-controller-manager 有时会进入循环，从而导致 CPU 使用率较高，可能会影响 Tanzu Kubernetes 集群的功能。您可能会注意到，kube-controller-manager 进程消耗的 CPU 量大于预期，并输出重复日志，指示
failed for updating Node.Spec.PodCIDRs。解决办法：删除控制平面节点中具有此类问题的 kube-controller-manager pod。该 pod 将重新创建，此问题不应再次出现。
-
无法将使用 K8s 1.16 创建的 Tanzu Kubernetes 集群更新到 1.19
Kubelet 的配置文件在运行
kubeadm init时生成，然后在集群升级期间进行复制。在 1.16 时，kubeadm init会生成配置文件，其中resolvConf设置为/etc/resolv.conf，但随后被指向/run/systemd/resolve/resolv.conf.的命令行标记--resolv-conf覆盖。在 1.17 和 1.18 期间，kubeadm继续使用正确的--resolv-conf配置 Kubelet。自 1.19 起，kubeadm不再配置命令行标记，而是依赖 Kubelet 配置文件。由于集群升级期间执行复制过程，从 1.16 升级的 1.19 集群将包含一个配置文件，其中resolvConf指向/etc/resolv.conf，而不是/run/systemd/resolve/resolv.conf。解决办法：将 Tanzu Kubernetes 集群升级到 1.19 之前，重新配置 Kubelet 配置文件以指向正确的
resolv.conf。手动在kube-system命名空间中将ConfigMap kubelet-config-1.18复制到kubelet-config-1.19，然后将这个新的ConfigMap's数据修改为将resolvConf指向/run/systemd/resolve/resolv.conf。 -
为主管集群网络连接配置 NSX-T 时，将服务从“ExternalTrafficPolicy: Local”更新为“ExternalTrafficPolicy: Cluster”后，在主管集群控制平面节点上向此服务的负载均衡器 IP 发送的请求将失败
如果在 Tanzu Kubernetes 集群上使用
ExternalTrafficPolicy: Local创建服务，后来将该服务更新为ExternalTrafficPolicy: Cluster，则 kube-proxy 会在主管集群控制平面节点上错误地创建 IP 表规则，以阻止传至服务 LoadBalancer IP 的流量。例如，如果此服务具有 LoadBalancer IP 192.182.40.4，则会在任何一个控制平面节点上创建以下 IP 表规则：-A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable因此，将阻止访问该 IP。
解决办法：删除该服务，然后使用
ExternalTrafficPolicy: Cluster创建一个新服务。 -
在 TkgServiceConfiguration 规范中启用 HTTP 代理和/或信任设置后，所有没有代理/信任设置的现有集群将在更新时继承全局代理/信任设置。
您可以编辑 TkgServiceConfiguration 规范以配置 TKG 服务，包括指定默认 CNI、HTTP 代理和信任证书。对 TkgServiceConfiguration 规范执行的任何配置更改都会全局应用于该服务置备或更新的任何 Tanzu Kuberentes 集群。您无法使用按集群设置退出全局配置。
例如，如果您编辑 TkgServiceConfiguration 规范并启用 HTTP 代理，则由该集群置备的所有新集群将继承这些代理设置。此外，在修改或更新集群时，没有代理服务器的所有现有集群将继承全局代理配置。对于支持按集群配置的 HTTP/S 代理，您可以使用其他代理服务器更新集群规范，但无法移除全局代理设置。如果全局设置了 HTTP 代理，则必须使用该 HTTP 代理或使用其他代理服务器覆盖它。
解决办法：了解 TkgServiceConfiguration 规范在全局应用。如果不希望所有集群都使用 HTTP 代理，请不要在全局级别启用它。在集群级别执行此操作。
-
在具有许多 Tanzu Kubernetes 集群和虚拟机的超大型主管集群部署中，vmop-controller-manager pod 可能会由于 OutOfMemory 而失败，从而导致无法对 Tanzu Kubernetes 集群进行生命周期管理
在主管集群中，vmop-controller-manager pod 负责管理构成 Tanzu Kubernetes 集群的虚拟机的生命周期。在此类虚拟机数量非常大（每个主管集群超过 850 个虚拟机）时，vmop-controller-manager pod 可能会进入 OutOfMemory CrashLoopBackoff。发生这种情况时，Tanzu Kubernetes 集群的生命周期管理会中断，直到 vmop-controller-manager pod 恢复操作。
通过删除集群或纵向缩减集群，减少主管集群中管理的 Tanzu Kubernetes 集群工作节点的总数。
-
从 6.5 之前的 vSphere 版本升级到 vSphere 7 with Tanzu 可能会引发错误，指示 PhotonOS 类型不受支持。
将 vSphere 6 环境成功升级到 vSphere 7 with Tanzu 后，尝试部署 Tanzu Kubernetes 集群会导致显示错误消息，指示 PhotonOS“不受支持”。具体如下：
无法创建或更新 VirtualMachine: 准入 Webhook“default.validating.virtualmachine.vmoperator.vmware.com”已拒绝请求: 映像 v1.19.7---vmware.1-tkg.1.fc82c41 上的 osType vmwarePhoton64Guest 不支持 GuestOS (failed to create or update VirtualMachine: admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType vmwarePhoton64Guest on image v1.19.7---vmware.1-tkg.1.fc82c41')
如果从 vSphere 6.5 之前的 vSphere 版本（如 vSphere 6）升级到 vSphere 7 with Tanzu，则需要确保将默认虚拟机兼容性级别至少设置为“ESXi 6.5 及更高版本”，PhotonOS 才会显示为受支持的客户机操作系统。为此，请选择启用了工作负载管理的 vSphere 集群，右键单击，然后选择“编辑默认虚拟机兼容性”。选择“ESXi 6.5 及更高版本”。
-
使用小型虚拟机置备 Tanzu Kubernetes 集群，然后将工作负载部署到该集群后，工作节点将进入未就绪状态，并不断循环尝试重新生成该节点。
描述：在集群的小型或超小型工作节点上，/bin/opm 进程可能会消耗过多的虚拟机内存，从而导致工作节点出现内存不足错误。
解决办法：即使是临时的开发或测试集群，也应避免对工作节点使用小型或超小型虚拟机类。最佳做法是，在任何环境中，工作节点的最小虚拟机类都采用中型。有关详细信息，请参见文档中的默认虚拟机类。
-
从已订阅内容库同步 Tanzu Kubernetes 版本失败，并显示以下 HTTP 请求错误消息：“无法对主机 wp-content.vmware.com 的 SSL 证书进行身份验证 (cannot authenticate SSL certificate for host wp-content.vmware.com)”。
描述：为 Tanzu Kubernetes 集群 OVA 配置已订阅内容库时，会为 wp-content.vmware.com 生成 SSL 证书。系统会提示您通过确认证书指纹来手动信任证书。如果在初始库设置后更改该 SSL 证书，则必须通过更新指纹再次信任新证书。内容库的当前 SSL 证书将于 2021 年 6 月末过期。订阅 wp-content.vmware.com 的客户将看到其内容库同步失败，需要通过执行解决办法中的步骤来更新指纹。有关其他指导，请参见相关 VMware 知识库文章，网址为：https://kb.vmware.com/s/article/85268。
解决办法：通过 vSphere Client 登录 vCenter Server。选择“已订阅内容库”，然后单击编辑设置。此操作将启动订阅 URL 探查，即使未在库上请求任何更改也会如此。该探查将发现 SSL 证书不受信任，并提示您信任该证书。在显示的操作下拉菜单中，选择继续，指纹将更新。现在，您可以继续同步库的内容。
-
TKGS 不支持同时修改虚拟机类和节点纵向扩展。
对集群应用更新（涉及 VMClass 修改和节点纵向扩展）后，客户可能会看到失败。
请修改 TKC 配置，仅修改这两个字段中的一个，然后重新应用更改。
-
症状：更新集群规范中的标签或污点后，发生意外的集群滚动更新。
描述：使用 TKGS v1alpha2 API 时，修改一个节点池的 spec.topology.nodePools[*].labels 或 spec.topology.nodePools[*].taints 将触发该节点池的滚动更新。
解决办法：无
-
症状：集群更新后，手动添加到节点池的污点和标签不再存在。
描述：使用 TKGS v1alpha2 API 时，在集群更新期间，系统不会保留在更新之前手动添加并呈现的 spec.topology.nodePools[*].taints 和 spec.topology.nodePools[*].labels。
解决办法：更新完成后，手动重新添加标签和污点字段。
-
症状：Tanzu Kubernetes 集群停滞在“正在创建”阶段，因为其中一个控制平面虚拟机未获取 IP 地址。
描述：Tanzu Kubernetes 集群停滞在“正在创建”阶段，因为其中一个控制平面虚拟机未获取 IP 地址。
解决办法：使用 Tanzu Kubernetes 版本 1.20.7 或更高版本以避免出现此问题。
-
症状：在创建 Tanzu Kubernetes 集群期间，该过程停滞在“正在更新”状态，原因为“WaitingForNetworkAddress”。
描述：控制平面虚拟机和工作节点已打开电源，但没有分配 IP。这可能是由于 vmware-tools 内存不足且未重新启动所致。
解决办法：此特定问题已在 Tanzu Kubernetes 版本 v1.20.7 及更高版本中修复。此外，还可以通过增加虚拟机内存修复此问题。best-effort-xsmall 虚拟机类仅提供 2G 内存。使用具有更多内存的虚拟机类部署 Tanzu Kubernetes 集群。
-
症状：自助式 vSphere 命名空间停滞在“正在移除”状态。
描述：删除 vSphere 命名空间后，该过程停滞在“正在移除”状态数小时，没有任何进展。
解决办法：使用 kubectl 检查尚未从命名空间中删除的剩余 Kubernetes 对象。如果存在与 kubeadm-control-plane 相关的剩余对象，请重新启动 capi-kubeadm-control-plane-controller-manager pod。此操作应会将要删除的对象重新加入队列。
注意：这是一个高级操作。在执行此解决办法之前，请联系 VMware 技术支持。
-
TKC v1alpha2 API 不阻止使用不兼容的 TKr 创建 TKC
从 7.0.3 MP2 版本开始，低于 1.18.x 的 TKr 将不兼容，但 TKC API 仍允许创建版本低于 v1.18.x 的 TKC，不会阻止使用不兼容的 TKr 创建 TKC 对象。将永远不会创建这些 TKC。
删除未处于正在运行状态且使用不兼容的 TKr 创建的 TKC。使用兼容的版本重新创建。
vSAN 数据持久性平台
-
vDPP UI 插件未在 vSphere Client 中部署，并显示一条错误消息，指示尝试从不再存在的主管集群下载插件
如果在集群上部署 vDPP UI 插件，然后移除此集群，可能会出现此问题。但是，与此 vDPP UI 插件相关的失效条目仍保留在 vCenter Extension Manager 中。如果稍后创建新集群，则尝试在此集群上安装相同版本的 vDPP UI 插件将失败，因为 vSphere Client 使用失效条目从不存在的旧集群下载插件。
解决办法：
-
使用
https://vc-ip/mob and导航到 vCenter Extension Manager，然后找到插件扩展。 -
移除包含旧集群名称的所有
ClientInfo和ServerInfo条目。 -
从
ClientInfo阵列中，选择具有最大版本号的ClientInfo，然后将其类型从vsphere-client-remote-backup更改为vsphere-client-remote。
-
-
主管集群中的 vSphere pod 保持挂起状态且没有 vm-uuid 注释
有时，pod 可能会长时间保持挂起状态。当使用 vSAN 数据持久性平台 (vDPP) 时，通常会发生这种情况，可能由内部错误或用户操作所致。
使用
kubectl命令查询 pod 实例时，元数据注释中缺少vmware-system-vm-uuid/vmware-system-vm-moid注释。解决办法：使用
kubectl delete pod pending_pod_name命令删除该 pod。如果该 pod 属于有状态集，则将自动重新创建该 pod。 -
当 vDPP 服务实例的两个副本 pod 的主机本地 PVC 绑定到同一个集群节点时，该实例的部署将失败
有时，当 vSAN 数据持久性平台服务（例如 MinIO 或 Cloudian）实例的两个副本 pod 的主机本地 PVC 分配到同一个集群节点上时，该实例可能会进入某种状态。通常，同一实例的两个副本不得在同一个集群节点上具有主机本地存储。如果发生这种情况，其中一个副本 pod 可能会无限期保持挂起状态，从而导致实例部署失败。
在失败期间观察到的症状包括以下所有症状：
-
实例运行状况为黄色。
-
实例的至少一个 pod 处于挂起状态超过 10 分钟。
-
挂起 pod 和同一实例的一个正在运行的副本 pod 的主机本地 PVC 分配到集群的同一个节点上。
可能会导致出现此问题的失败场景如下：
-
集群中的某些节点没有足够的存储资源用于实例。
-
副本数大于集群中的节点数。这可能是因为一个或多个节点暂时不可用。
解决办法：
-
确保集群具有足够的存储资源，并且集群节点数大于实例副本计数。
-
删除挂起的 pod 及其所有主机本地 PVC。
服务运维人员应在已调度 pod 的新节点上重新构建卷数据。这可能需要一些时间才能完成，具体取决于卷大小以及卷上的有效数据量。
-
-
ESXi 节点在“确保可访问性”模式下退出维护模式后，在维护期间应用于该节点的污点可能仍保留在节点上
使用 vSAN 数据持久性平台 (vDPP) 创建合作伙伴服务实例时，可能会出现此问题。ESXi 节点在“确保可访问性”模式下退出维护模式后，仍然可以在该节点上找到残留的污点
node.vmware.com/drain=planned-downtime:NoSchedule。通常，执行以下操作时会出现该问题：
1.在主管集群上启用合作伙伴服务，并创建该服务的实例。
2.ESXi 节点在“确保可访问性”模式下置于维护模式。
3.该节点在“确保可访问性”模式下成功进入维护模式。
4.在该节点上应用污点
node.vmware.com/drain=planned-downtime:NoSchedule。5.该节点退出维护模式。
在该节点退出维护模式后，请使用以下命令确保节点上没有残留任何污点：
kubectl describe node | grep Taints解决办法：
如果主机上存在污点
node.vmware.com/drain=planned-downtime:NoSchedule，请手动移除该污点：kubectl taint nodes nodeNamekey=value:Effect-注意：确保在命令末尾使用连字符。
请按以下示例执行操作：
kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule- -
APD 恢复后，在 vSAN 数据持久性平台上运行的持久服务 pod 可能仍处于挂起状态，并显示 AttachVolume 错误
在 ADP 和恢复 ESXi 主机后，vDPP 服务实例 pod 可能仍处于挂起状态。如果运行
kubectl -n instance_namespace describe pod name_of_pod_in_pending命令，可能会显示AttachVolume错误。如果 pod 处于挂起状态的时间超过 15 分钟，则不太可能退出此状态。
解决办法：使用以下命令删除挂起的 pod：
kubectl -n instance_namespace delete pod name_of_pod_in_pending。pod 将重新创建，并变为正在运行状态。
VM 服务
-
<span style="color:#FF0000">新：</span>尝试部署具有相同名称的 vSphere Pod 和虚拟机服务虚拟机会导致错误和不可预知的行为
您可能会看到故障和错误或其他有问题的行为。在命名空间中运行 vSphere Pod，然后尝试在同一命名空间中部署具有相同名称的虚拟机服务虚拟机时，可能会遇到这些问题，反之亦然。
解决办法：请勿对同一命名空间中的 vSphere Pod 和虚拟机使用相同的名称。
-
可供虚拟机服务使用的虚拟机映像集有限
如果尝试使用与虚拟机服务不兼容的虚拟机映像，则创建虚拟机时会显示以下消息
Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image解决办法：仅使用 VMware Marketplace 中经验证可用于虚拟机服务的虚拟机映像
-
无法使用名称不符合 DNS 要求的虚拟机映像
如果内容库中 OVF 映像的名称不符合 DNS 子域名称要求，则虚拟机服务不会从该 OVF 映像创建 VirtualMachineImage。因此，
kubectl get vmimage不会在命名空间中列出映像，开发人员也将无法使用该映像。解决办法：对 OVF 映像使用符合 DNS 子域名称要求的名称。
-
重复的 OVF 映像不显示为重复的 VirtualMachineImage
不同内容库中具有相同名称的 OVF 映像不显示为不同的 VirtualMachineImage
解决办法：对配置了虚拟机服务的各个内容库中的 OVF 映像使用唯一的名称。
-
虚拟机服务创建的虚拟机不允许访问 Web 或远程控制台
虚拟机服务创建的虚拟机不允许访问远程控制台。因此，管理员无法使用 vSphere Web Client 中的启动 Web 控制台和启动远程控制台选项登录到虚拟机。
解决办法：管理员可以通过登录到虚拟机所在的 ESXi 主机访问虚拟机控制台。
-
ESXi 主机进入维护模式后，由虚拟机服务管理且具有 vGPU 和直通设备的虚拟机将关闭电源
虚拟机服务允许 DevOps 工程师创建连接到 vGPU 或直通设备的虚拟机。通常，ESXi 主机进入维护模式后，DRS 会为该主机上运行的此类虚拟机生成建议。然后，vSphere 管理员可以接受建议以触发 vMotion。
但是，由虚拟机服务管理且具有 vGPU 和直通设备的虚拟机将自动关闭电源。这可能会暂时影响在这些虚拟机中运行的工作负载。主机处于维护模式后，虚拟机将自动打开电源。
解决办法：无。
