VMware vSphere IaaS 控制平面 8.0 发行说明

发行说明内容

本发行说明包含以下主题：

新增功能
此版本的安装与升级
已知问题

新增功能

新增功能：2024 年 6 月 25 日
新增功能：2024 年 3 月 26 日
新增功能：2024 年 2 月 29 日
新增功能 - 2023 年 9 月 21 日
新增功能：2023 年 7 月 27 日
新增功能 - 2023 年 4 月 18 日
新增功能：2023 年 3 月 30 日
新增功能：2023 年 2 月 14 日
新增功能：2022 年 12 月 15 日
新增功能：2022 年 10 月 11 日

新增功能：2024 年 6 月 25 日

VMware vSphere 8.0 Update 3 \| 2024 年 6 月 25 日 vCenter Server 8.0 Update 3 \| 2024 年 6 月 25 日 \| ISO 内部版本 24022515 VMware ESXi 8.0 Update 3 \| 2024 年 6 月 25 日 \| ISO 内部版本 24022510 VMware NSX Advanced Load Balancer avi-22.1.5 \| 2023 年 10 月 11 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 3.0 \| 2024 年 6 月 25 日

VMware vSphere 8.0 Update 3 | 2024 年 6 月 25 日

vCenter Server 8.0 Update 3 | 2024 年 6 月 25 日 | ISO 内部版本 24022515

VMware ESXi 8.0 Update 3 | 2024 年 6 月 25 日 | ISO 内部版本 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 3.0 | 2024 年 6 月 25 日

vSphere IaaS 控制平面 8.0 Update 3 引入了以下新功能和增强功能：

主管和 TKG 证书自动轮换 - 此版本引入了新的证书轮换机制。主管和 TKG 集群证书在过期之前会自动轮换。如果自动轮换失败，vCenter 将通知您，您必须手动续订证书。
在延伸 vSAN 集群上支持主管和 vSphere Pod 以及 TKG 集群 - 从此版本开始，您可以将主管配置为在 vSAN 延伸集群上运行。仅绿地环境支持此配置。这意味着，vSAN 集群应延伸，并且尚未配置工作负载管理和内容库。这两个组件需要配置 vSAN 延伸集群存储策略。有关详细信息，请参见此文档。
虚拟机服务虚拟机的虚拟机类范围现在限定为命名空间 - 在此版本中，使用 kubectl 列出虚拟机类时，只能查看范围限定为特定 vSphere 命名空间的虚拟机类。以前，虚拟机类是集群范围的资源，很难确定哪些虚拟机类已分配给特定命名空间并可供使用。
主管备份和还原 - vSphere 现在支持备份和还原主管。现在，您可以将主管的备份配置为 vCenter 备份的一部分，并在灾难恢复、升级失败、中断等恢复情况下从备份还原主管。请参见备份和还原主管控制平面。
虚拟机服务虚拟机备份和还原 - vSphere 现在支持备份和还原虚拟机服务虚拟机。现在，可以使用任何基于 VADP 的备份供应商来保护虚拟机服务虚拟机。如果发生中断或其他涉及数据丢失的情况，您可以从备份还原 vSphere 命名空间中的虚拟机。
VM Operator API v1alpha2 现已推出 - VM Operator API 的下一个版本现已推出，即 VM Operator v1alpha2 版本。此版本增强了引导提供程序支持（包括内嵌 Cloud-Init 和 Windows 支持），增强了客户机网络配置，加强了状态功能，支持用户定义的就绪门控，新增了 VirtualMachineWebConsoleRequest API，改进了 API 文档，还解锁了其他功能。
利用 Fluent Bit 在主管上进行日志转发 - 现在，支持将主管控制平面日志和系统日志转发到外部日志监控平台。有关详细信息，请参见此文档。
对主管服务支持专用注册表 - 现在，可以定义专用注册表详细信息，以允许部署为主管服务的工作负载从专用注册表提取映像和软件包。这是支持气隙环境的常见要求。有关详细信息，请参见文档。
改进了主管升级工作流 - 现在，可以在启动主管 Kubernetes 版本升级时启动主管升级预检查。仅当所有预检查都成功时，才会执行实际更新。此版本提供了从之前失败的位置继续组件升级过程的功能。有关详细信息，请参见更新主管。
主管支持 Kubernetes 1.28 - 此版本增加了主管对 Kubernetes 1.28 的支持，且不再支持 Kubernetes 1.25。

主管支持的 Kubernetes 版本：

此版本中受支持的 Kubernetes 版本为 1.28、1.27 和 1.26。在 Kubernetes 版本 1.25 上运行的主管将自动升级到版本 1.26，以确保所有主管集群都在支持的 Kubernetes 版本上运行。

Tanzu Kubernetes Grid Service for vSphere

TKG Service 即主管服务 – 此版本将 TKG Service 组件与 vCenter 相分离，并将其打包为主管服务，您可以独立于 vCenter 和主管版本对其进行更新和管理。可以从此处获取 TKG Service 的发行说明。
支持在延伸 vSAN 集群上部署 TKG Service 集群 – 此版本支持在 vSAN 延伸集群拓扑上部署 TKG Service 集群。有关如何在 vSAN 延伸集群上为 TKG Service 集群配置 HA 的详细信息，请参见文档。
自动调整 TKG Service 集群 – 此版本支持在 TKG Service 集群上安装集群 Autoscaler 软件包，从而能够自动横向扩展和缩减工作节点。
备份和还原 TKG 集群 – 此版本支持备份和还原主管数据库，其中包括 vSphere 命名空间对象和 TKG 集群虚拟机。请注意，TKG 集群工作负载需要单独备份和还原。
支持 Antrea-NSX 集成和 NSX 管理代理服务 – 此版本支持将使用 Antrea CNI 的 TKG 集群与 NSX Manager 集成，以便了解和控制集群网络。
可以配置 MachineHealthCheck – 此版本支持为 v1beta1 集群配置 MachineHealthCheck。
在集群范围配置 PSA – 此版本支持创建或更新集群时在集群范围配置 PSA。
标准软件包安装更新 – 此版本包括在 TKG Service 集群上安装标准软件包的文档更新。
更新了用于置备 TKG 集群的 v1beta1 API – 此版本包括以下 v1beta1 API 更改：
- 增加了 podSecurityStandard，可实现集群范围的 PSA
- 更新了 controlPlaneCertificateRotation
对 TKG 集群支持扩展控制平面节点卷。

国际化更新

从下一个主要版本开始，我们将减少受支持本地化语言的数量。支持的三种语言为：

日语
西班牙语
法语

将不再支持以下语言：

意大利语、德语、巴西葡萄牙语、繁体中文、韩语、简体中文

影响:

使用已弃用语言的用户将不再收到这些语言的更新或支持。
所有用户界面、帮助文档和客户支持将仅提供英语版本或上述三种受支持语言的版本。

新增功能：2024 年 3 月 26 日

VMware vSphere 8.0 Update 2c \| 2024 年 3 月 26 日 ESXi 8.0 Update 2b \| 2024 年 2 月 29 日 \| ISO 内部版本 23305546 vCenter Server 8.0 Update 2c \| 2024 年 3 月 26 日 \| ISO 内部版本 23504390 VMware NSX Advanced Load Balancer avi-22.1.5 \| 2023 年 10 月 11 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0 Update 2c | 2024 年 3 月 26 日

ESXi 8.0 Update 2b | 2024 年 2 月 29 日 | ISO 内部版本 23305546

vCenter Server 8.0 Update 2c | 2024 年 3 月 26 日 | ISO 内部版本 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 控制平面 8.0 Update 2c 引入了以下新功能和增强功能：

新功能

对 TKr 1.27 的支持 - 此版本添加了在 vSphere 8.x 上支持 TKr 1.27 所需的变更（在未来发布时）。有关详细信息，请参见 VMware Tanzu Kubernetes 版本发行说明。
支持从 vCenter 7.x 升级到 vCenter 8.x - 对于在 vSphere 7.x 上运行 TKr 1.27.6 的用户，此版本提供了升级到 vCenter 8.x 的路径。以前，适用于 vSphere 7.x 的 TKr 1.27.6 与 vCenter 8.x 不兼容。请参见知识库文章 96501。

已解决的问题

升级到 vCenter 8.0 Update 2b 后，vmon 托管服务 wcp 可能处于 STOPPED 状态，并且 vCenter 修补可能会失败。
如果取消与库的链接或删除具有共享库的命名空间，将从内容库中删除关联的项。

新增功能：2024 年 2 月 29 日

VMware vSphere 8.0 Update 2b \| 2024 年 2 月 29 日 ESXi 8.0 Update 2b \| 2024 年 2 月 29 日 \| ISO 内部版本 23305546 vCenter Server 8.0 Update 2b \| 2024 年 2 月 29 日 \| ISO 内部版本 23319993 VMware NSX Advanced Load Balancer avi-22.1.5 \| 2023 年 10 月 11 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0 Update 2b | 2024 年 2 月 29 日

ESXi 8.0 Update 2b | 2024 年 2 月 29 日 | ISO 内部版本 23305546

vCenter Server 8.0 Update 2b | 2024 年 2 月 29 日 | ISO 内部版本 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 控制平面 8.0 Update 2b 引入了以下新功能和增强功能：

新功能

支持通过 vSphere Client 配置虚拟机服务虚拟机类 - 主管上的虚拟机服务支持使用 vSphere 虚拟机当前支持的任何配置部署虚拟机。要为虚拟机类配置 CPU、内存、硬件、安全设备和直通设备，现在可以在 vSphere Client 中使用虚拟机类向导。使用 vSphere Client，可以简化用于运行 AI/ML 工作负载的虚拟机服务虚拟机的定义和管理过程。
主管支持 Avi 云设置 - 如果您使用的是 NSX Advanced Load Balancer（也称为 Avi 负载均衡器），现在可以为每个主管配置 Avi 云。这样，多个 vCenter Server 实例和数据中心可以使用单个 Avi 实例，而无需为每个部署主管的 vCenter Server 或数据中心设置 Avi 实例。
支持 FQDN 登录 - 对于主管和 TKG 集群，现在可以将所生成 kubeconfigs 中的 IP 替换为有效的 FQDN。必须在 DNS 中添加 FQDN 和 IP 地址，以确保正确解析主机名。
主管支持 Kubernetes 1.27 - 主管现在支持 Kubernetes 1.27 并停止支持 Kubernetes 1.24。

受支持的 Kubernetes 版本

此版本中受支持的 Kubernetes 版本为 1.27、1.26 和 1.25。在 Kubernetes 1.24 上运行的主管将自动升级到版本 1.25，以确保兼容性。

升级到 8.0 Update 2b

从低于 8.0 Update 2 的任何 vSphere 8.x 版本升级到 8.0 Update 2b 版本时，将对所有已置备的 TKGS 集群启动滚动更新以传播以下更改：

8.0 Update 2 包含 TKGS 控制器中 vSphere 7 和 vSphere 8 TKR 的更改，作为 ClusterClass 一部分。
由于 1.23 及更高版本的 TKGS 集群与 8.0 Update 2b 兼容，因此所有 TKGS 集群都将进行滚动升级。

已解决的问题

主管升级过程进行到 20% 时停止。

新增功能 - 2023 年 9 月 21 日

VMware vSphere 8.0.2 \| 2023 年 9 月 21 日 ESXi 8.0.2 \| 2023 年 9 月 21 日 \| 内部版本 22380479 vCenter Server 8.0.2 \| 2023 年 9 月 21 日 \| 内部版本 22385739 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 社区版 2.2.2，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0.2 | 2023 年 9 月 21 日

ESXi 8.0.2 | 2023 年 9 月 21 日 | 内部版本 22380479

vCenter Server 8.0.2 | 2023 年 9 月 21 日 | 内部版本 22385739

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 社区版 2.2.2，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 控制平面 8.0 Update 2 引入了以下新功能和增强功能：

主管

虚拟机服务现在支持具有 Windows 操作系统、GPU 以及传统 vSphere 虚拟机的所有其他选项的虚拟机 - 虚拟机服务现在支持使用 vSphere 虚拟机当前所支持的任何配置来部署虚拟机，从而与 vSphere 上的传统虚拟机完全相同，但支持作为基础架构即服务的一部分部署到主管的虚拟机。这包括支持置备 Windows 虚拟机和 Linux 虚拟机，以及 vSphere 所支持的任何硬件、安全、设备、自定义或多网卡支持和直通设备。现在，可以使用 GPU 置备工作负载虚拟机以支持 AI/ML 工作负载。
虚拟机映像服务 - DevOps 团队、开发人员和其他虚拟机使用者可以使用虚拟机映像服务以自助方式发布和管理虚拟机映像。服务允许使用者在主管命名空间范围的映像注册表中使用 K8s API 发布、修改和删除映像。每个 CCS 区域和 CCS 项目中都将自动创建虚拟机映像服务，映像注册表的映像填充范围按用户配置和消耗级别（全局级别或项目级别）进行限定。映像可用于通过虚拟机服务部署虚拟机。

请注意，此功能引入了新格式的虚拟机映像名称。有关如何解决名称更改导致的潜在问题的信息，请参见 vSphere 8.0 U2 中虚拟机映像名称格式的变更
导入和导出主管配置 - 在以前的版本中，激活主管是一个手动分步过程，无法保存任何配置。在当前版本中，您现在可以以人工可读格式或在源控制系统内导出主管配置并与对等方共享，将配置导入到新的主管，并在多个主管之间复制标准配置。查看文档，了解有关如何导出和导入主管配置的详细信息。
通过减少碎片提高了 GPU 利用率 - 工作负载放置现在可识别 GPU，DRS 会尝试将具有相似配置文件要求的工作负载放置在同一主机上。这提高了资源利用率，降低了成本，因为必须获取更少的 GPU 硬件资源来达到所需的性能水平。
主管支持 Kubernetes 1.26 - 此版本增加了对 Kubernetes 1.26 的支持，且不再支持 Kubernetes 1.23。此版本中受支持的 Kubernetes 版本为 1.26、1.25 和 1.24。在 Kubernetes 版本 1.23 上运行的主管将自动升级到版本 1.24，以确保所有主管集群都在支持的 Kubernetes 版本上运行。
配置了 NSX 网络连接的主管支持 NSX Advanced Load Balancer - 现在，可以通过以下方式启用主管：使用 NSX Advanced Load Balancer (Avi Networks) 实现 L4 负载均衡，以及使用 NSX 网络对主管和 Tanzu Kubernetes Grid 集群的控制平面节点实现负载均衡。请查看文档页面，了解使用 NSX 配置 NSX Advanced Load Balancer 的指导。
Telegraf 支持衡量指标和事件流 - 现在，可以通过 Kubernetes API 配置 Telegraf 以将主管衡量指标推送到与嵌入式 Telegraf 版本兼容的任何衡量指标服务。请参见文档，了解如何配置 Telegraf。

主管上的 Tanzu Kubernetes Grid

vSphere 8.0 上 TKR 的 STIG 合规性 - 使用 vSphere U2 时，高于 1.23.x 的所有 Tanzu Kubernetes Grid 集群都符合 STIG（安全技术实施指南）的要求，并包含可从此处获取的有关例外的文档。这些改进是朝着简化合规流程迈出的重要一步，让您更轻松地满足合规要求，帮助您快速、自信地在美国联邦市场和其他受监管行业使用 Tanzu Kubernetes Grid。
为即将过期的证书启用控制平面部署 – 更新了用于基于 ClusterClass 置备 TKG 集群的 v1beta1 API，集群能够在证书过期之前自动续订其控制平面节点虚拟机证书。可以将此配置作为变量添加到集群规范中。请参阅

集群 v1beta1 API文档，了解更多信息。
对 TKR 的 CSI 快照支持 - 使用 Tanzu Kubernetes 版本 1.26.5 及更高版本置备的 TKG 集群支持 CSI 卷快照，帮助您实现数据保护要求。卷快照为您提供了在特定时间点复制卷内容的标准化方式，而无需创建全新的卷。
安装和管理 Tanzu 软件包 – 用于在 TKG 集群上安装和管理 Tanzu 软件包的新整合存储库和出版物。有关您的所有软件包需求，请参阅出版物“安装和使用 VMware Tanzu 软件包”。
自定义 ClusterClass 改进 – 针对 vSphere 8 U2 简化了实施自定义 ClusterClass 集群的工作流。
TKG 集群的滚动更新 – 升级到 vSphere 8 U2 时，可以在以下场景下对置备的 TKG 集群进行滚动更新：
- 从任何先前发布的 vSphere 8 版本升级到 vSphere 8 U2 时，因为：
  - vSphere 8 U2 包含 TKR 的 Kubernetes 级别 STIG 更改作为 clusterclass 一部分
  - 1.23 及更高版本的 TKG 集群将经历滚动更新，以便与 v8.0 U2 兼容
- 从任何 vSphere 7 版本升级到 vSphere 8 U2 时，因为：
  - 底层 CAPI 提供程序需要从 CAPW 移至 CAPV
  - 现有集群需要从无类 CAPI 集群迁移到基于类的 CAPI 集群

已解决的问题

主管控制平面虚拟机上 /var/log/audit/ 下的审核日志文件可能会增长到非常大并填满根磁盘。您应该会在反映此状态的 journald 日志中看到“no space left on device”错误。这可能会导致主管控制平面功能的各个方面（如 Kubernetes API）失败。

新增功能：2023 年 7 月 27 日

VMware vSphere 8.0.1c \| 2023 年 7 月 27 日 ESXi 8.0.1c \| 2023 年 7 月 27 日 \| 内部版本 22088125 vCenter Server 8.0.1c \| 2023 年 7 月 27 日 \| 内部版本 22088981 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 社区版 2.2.2，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0.1c | 2023 年 7 月 27 日

ESXi 8.0.1c | 2023 年 7 月 27 日 | 内部版本 22088125

vCenter Server 8.0.1c | 2023 年 7 月 27 日 | 内部版本 22088981

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 社区版 2.2.2，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

新功能

主管支持 Kubernetes 1.25 - 此版本增加了对 Kubernetes 1.25 的支持，且不再支持 Kubernetes 1.22。
主管上的 Tanzu Kubernetes Grid 2.2.0 - 管理主管上的 Tanzu Kubernetes Grid 2.2.0 集群。

受支持的 Kubernetes 版本

此版本中受支持的 Kubernetes 版本为 1.25、1.24 和 1.23。在 Kubernetes 版本 1.22 上运行的主管将自动升级到版本 1.23，以确保所有主管集群都在支持的 Kubernetes 版本上运行。

支持

弃用 vRegistry 创建功能 - 嵌入式 Harbor 实例 vRegistry 的创建功能已弃用。现有 vRegistry 实例将继续运行，但新建 vRegistry 实例的功能已弃用。vRegistry 创建 API 已标记为已弃用，并且即将发布的版本中将移除部署新 vRegistry 实例的功能。因此，我们建议改用 Harbor 作为主管服务来管理容器映像和存储库，以提高性能和功能。要将现有 vRegistry 作为主管服务迁移到 Harbor，请参见“将映像从嵌入式注册表迁移到 Harbor”以了解迁移的详细信息。

已解决的问题

将在 vSphere Client 中显示一条新的警示消息，以警告主管或 TKG 集群上的证书即将过期。该警示将提供详细信息，包括主管的名称和证书过期日期。此外，还将包含指向 KB 90627 的链接，该链接分步说明了如何替换受影响的证书。
命令 kubectl get clustervirtualmachineimages 返回错误或No resources found。在以前的版本中，使用 kubectl get clustervirtualmachineimages 命令时遇到错误。但是，升级到 8.0 Update 1c 后，该命令现在可返回以下消息：No resources found。要检索有关虚拟机映像的信息，请改用以下命令： kubectl get virtualmachineimages
antrea-nsx-routed CNI 不适用于 vSphere IaaS 控制平面 8.x 版本上的 v1alpha3 Tanzu Kubernetes 集群。
v1beta1 集群的节点引流超时未正确传播。

新增功能 - 2023 年 4 月 18 日

VMware vSphere 8.0.1 \| 2023 年 4 月 18 日 ESXi 8.0.1 \| 2023 年 4 月 18 日 \| 内部版本 21495797 vCenter Server 8.0.1 \| 2023 年 4 月 18 日 \| 内部版本 21560480 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 社区版 2.2.2，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

VMware vSphere 8.0.1 | 2023 年 4 月 18 日

ESXi 8.0.1 | 2023 年 4 月 18 日 | 内部版本 21495797

vCenter Server 8.0.1 | 2023 年 4 月 18 日 | 内部版本 21560480

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 社区版 2.2.2，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新功能

主管

现在，主管服务可在基于 VDS 的主管上使用 - 以前，主管服务只能在基于 NSX 的主管上使用。在当前版本中，可以在基于 VDS 的主管上部署 Harbor、Contour、S3 对象存储和 Velero 主管服务。注意：基于 VDS 的主管上的主管服务功能要求 ESXi 更新到 8.0 U1。
对所有 Linux 映像提供虚拟机服务支持 - 现在，可以使用 CloudInit 以符合虚拟机服务映像规范的 OVF 格式自定义任何 Linux 映像，也可以通过 vAppConfig 利用 OVF 模板部署旧版 Linux 映像。
对虚拟机服务虚拟机提供 Web 控制台支持 - 部署虚拟机服务虚拟机后，作为 DevOps 工程师，您现在可以使用 kubectl CLI 为该虚拟机启动 Web 控制台会话，从而在客户机操作系统中进行故障排除和调试，而无需 vSphere 管理员访问客户机虚拟机。
主管合规性 - 适用于 vSphere IaaS 控制平面 8 主管版本的安全技术实施指南 (STIG)。有关详细信息，请参见 Tanzu STIG 强化。

主管上的 Tanzu Kubernetes Grid 2.0

自定义集群类 - 为主管上的 TKG 集群构建自己的集群类。有关信息，请参见 https://kb.vmware.com/s/article/91826。
TKG 节点的自定义映像 - 使用 vSphere TKG Image Builder 构建自己的自定义节点映像（Ubuntu 和 Photon）。

注意：要将特定 TKR 与 v1alpha1 API 结合使用，请使用 fullVersion。
新的 TKR 映像：有关详细信息，请参阅 Tanzu Kubernetes 版本发行说明。

vSpere IaaS 控制平面 8.0.0 GA 客户的关键要求

注意：此要求不适用于通过虚拟机服务置备的虚拟机所用的内容库，只适用于 TKR 内容库。

如果您已部署 vSphere IaaS 控制平面 8.0.0 GA，则在升级到 vSphere IaaS 控制平面 8 U1 之前，必须创建一个临时 TKR 内容库，以避免在将 TKG 2.0 TKR 推送到现有内容库时会导致 TKG 控制器 Pod 进入 CrashLoopBackoff 的已知问题。要避免此问题，请完成以下步骤。

使用指向 https://wp-content.vmware.com/v2/8.0.0/lib.json 的临时订阅 URL 创建新的订阅内容库。
同步临时内容库中的所有项目。
将临时内容库与部署了 TKG 2 集群的每个 vSphere 命名空间相关联。
运行命令 kubectl get tkr，并验证是否创建了所有 TKR。
此时，TKG 控制器应处于正在运行状态，您可以通过在主管命名空间中列出 Pod 进行验证。
如果 TKG 控制器处于 CrashLoopBackOff (CLBO) 状态，请使用以下命令重新启动 TKG 控制器部署：

kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager
升级到 vSphere IaaS 控制平面 8 Update 1。
更新每个 vSphere 命名空间，以使用 https://wp-content.vmware.com/v2/latest/lib.json 中原始的已订阅内容库。

已解决的问题

使用 v1beta1 API 置备的 Tanzu Kubernetes Grid 2.0 集群必须基于默认的 ClusterClass

如果要使用 v1beta1 API 在主管上创建 Tanzu Kubernetes Grid 2.0 集群，则该集群必须基于默认的 tanzukubernetescluster ClusterClass。系统不会协调基于不同 ClusterClass 的集群。

新增功能：2023 年 3 月 30 日

ESXi 8.0.0c \| 2023 年 3 月 30 日 \| 内部版本 21493926 vCenter Server 8.0.0c \| 2023 年 3 月 30 日 \| 内部版本 21457384 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0.0c | 2023 年 3 月 30 日 | 内部版本 21493926

vCenter Server 8.0.0c | 2023 年 3 月 30 日 | 内部版本 21457384

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

已解决的问题：

Harbor 默认配置不安全问题

此版本解决了在主管 7.0 或 8.0 上启用了嵌入式 Harbor 注册表时存在的 Harbor 默认配置不安全问题。

本版本 vCenter 8.0.0c 已解决该问题。请参阅 VMware 知识库文章 91452，了解此问题的详细信息以及如何通过安装本版本或应用临时解决办法来解决该问题。
升级到 vCenter Server 8.0b 后，尝试登录到主管和 TKG 集群失败

在 vCenter Server 8.0b 中运行的组件与使用早期版本的 vCenter Server 部署的主管不向后兼容。

解决办法：将 vCenter Server 升级到较新版本或升级所有部署的主管。

新增功能：2023 年 2 月 14 日

ESXi 8.0.0b \| 2023 年 2 月 14 日 \| 内部版本 21203435 vCenter Server 8.0.0b \| 2023 年 2 月 14 日 \| 内部版本 21216066 VMware NSX Advanced Load Balancer avi-22.1.1-9052 \| 2022 年 7 月 15 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0.0b | 2023 年 2 月 14 日 | 内部版本 21203435

vCenter Server 8.0.0b | 2023 年 2 月 14 日 | 内部版本 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022 年 7 月 15 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新功能：

增加了 Cert-Manager CA 集群颁发者支持 – 管理员能够在主管上定义集群范围的 CA 颁发者并部署为主管服务。通过部署集群范围的 CA 颁发者，主管命名空间的使用者可以请求和管理 CA 颁发者签名的证书。

除了此新功能外，本版本还提供了一些错误修复。

已解决的问题：

主管控制平面虚拟机根磁盘填满

主管控制平面虚拟机上 /var/log/audit/ 下的审核日志文件可能会增长到非常大并填满根磁盘。您应该会在反映此状态的 journald 日志中看到“no space left on device”错误。这可能会导致主管控制平面功能的各个方面（如 Kubernetes API）失败。

本版本 vSphere 8.0.0b 已解决该问题

新增功能：2022 年 12 月 15 日

ESXi 8.0 \| 2022 年 10 月 11 日 \| 内部版本 20513097 vCenter Server 8.0.0a \| 2022 年 12 月 15 日 \| 内部版本 20920323 VMware NSX Advanced Load Balancer avi-22.1.1-9052 \| 2022 年 7 月 15 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0 | 2022 年 10 月 11 日 | 内部版本 20513097

vCenter Server 8.0.0a | 2022 年 12 月 15 日 | 内部版本 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022 年 7 月 15 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新功能

增加了 Harbor 作为主管服务 – 提供在主管上运行的功能完备的 Harbor（OCI 映像注册表）实例。通过 Harbor 实例，Harbor 管理员能够创建并管理项目和用户以及设置映像扫描。
弃用 vRegistry – 称为 vRegistry 的嵌入式 Harbor 实例将在未来的版本中移除。取而代之，可以使用 Harbor 作为主管服务。有关迁移详细信息，请参见“将映像从嵌入式注册表迁移到 Harbor”。
主管支持 Kubernetes 1.24 – 此版本增加了对 Kubernetes 1.24 的支持，且不再支持 Kubernetes 1.21。此版本中受支持的 Kubernetes 版本为 1.24、1.23 和 1.22。在 Kubernetes 版本 1.21 上运行的主管集群将自动升级到版本 1.22，以确保所有主管集群都在支持的版本上运行。
vSphere 区域 API – vSphere 区域是一种构造，可用于将可用区分配给 vSphere 集群，从而为主管集群和 Tanzu Kubernetes 集群提供高可用性。在 vSphere 8.0 中，可从 vSphere Client 创建和管理 vSphere 区域。在 vSphere 8.0.0a 版本中，用户可以使用 DCLI 或 vSphere Client API 资源管理器创建和管理 vSphere 区域。在未来的版本中，将提供完整的 SDK 绑定支持（例如 Java、Python 等）。

升级注意事项：

在以下主管升级方案中，将滚动更新 Tanzu Kubernetes 集群：
- 从 8.0 升级到 8.0.0a，然后将主管从任何 Kubernetes 版本升级到主管 Kubernetes 1.24，并且满足以下任一条件。
  - 在 Tanzu Kubernetes 集群上对非空 noProxy 列表使用代理设置
  - 在主管上启用了 vRegistry。此设置仅适用于基于 NSX 的主管。
- 从任何 vSphere 7.0 版本升级到 vSphere 8.0.0a。

已解决的问题：

vSphere 8 支持 Tanzu 7 许可证密钥，而不支持 Tanzu 8 许可证密钥

vCenter 8.0 支持 Tanzu 7 许可证密钥，而不支持 Tanzu 8 许可证密钥。此问题不影响您在 vCenter 8.0 上使用 Tanzu 的全部功能。有关更多详细信息，在 vCenter 8.0 部署中修改 Tanzu 许可证之前，请参见 VMware 知识库文章 89839。
当 NSX-ALB 上存在两个 SE 组时，不会创建 LoadBalancer 和客户机集群。

如果向已分配或未分配 SE 或者虚拟服务的 NSX-ALB 添加第二个 SE 组，则创建新的主管集群或客户机集群将失败，并且无法升级现有的主管集群。在 NSX-ALB 控制器上创建虚拟服务将失败，并显示以下错误消息：
```
get() returned more than one ServiceEngineGroup – it returned 2
```
因此，新的负载均衡器不可用，您无法成功创建新的工作负载集群。有关详细信息，请参见 VMware 知识库文章 90386。

新增功能：2022 年 10 月 11 日

VMware vSphere 8.0 \| 2022 年 10 月 11 日 ESXi 8.0 \| 2022 年 10 月 11 日 \| 内部版本 20513097 vCenter 8.0 \| 2022 年 10 月 11 日 \| 内部版本 20519528 VMware NSX Advanced Load Balancer 21.1.4 \| 2022 年 4 月 7 日 HAProxy 2.2.2 社区版，数据平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

VMware vSphere 8.0 | 2022 年 10 月 11 日

ESXi 8.0 | 2022 年 10 月 11 日 | 内部版本 20513097

vCenter 8.0 | 2022 年 10 月 11 日 | 内部版本 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 2022 年 4 月 7 日

HAProxy 2.2.2 社区版，数据平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

vSphere IaaS 控制平面 8.0 引入了以下新功能和增强功能：

工作负载管理配置监控 - 现在，您可以更详细地跟踪主管的激活、停用和升级状态。启动主管激活、停用或升级后，主管将尝试通过达到与主管的不同组件（如控制平面虚拟机）关联的各种条件以达到所需状态。您可以跟踪每个条件的状态、查看关联的警告、重试状态、查看已达到的条件及其时间戳。
vSphere 区域 - vSphere 区域是一个新构造，用于将可用区分配给 vSphere 集群。通过跨 vSphere 区域部署主管，可在特定的可用区和故障域中置备 Tanzu Kubernetes Grid 集群。这样，工作负载可以跨多个集群，从而提高硬件和软件的故障恢复能力。
多集群主管 - 通过使用 vSphere 区域，您可以跨多个 vSphere 集群部署主管，以便为 Tanzu Kubernetes Grid 集群提供高可用性和故障域。您可以将 vSphere 集群添加到单独的 vSphere 区域，并激活跨多个 vSphere 区域的主管。从而为本地化硬件和软件故障提供故障切换和弹性。当区域或 vSphere 集群脱机时，主管会检测到故障并重新启动另一个 vSphere 区域上的工作负载。您可以在环境中使用跨距离的 vSphere 区域，前提是不超过最长延迟时间。有关延迟要求的详细信息，请参见区域主管部署的要求。
主管支持 Kubernetes 1.23 - 此版本增加了对 Kubernetes 1.23 的支持，且不再支持 Kubernetes 1.20。此版本中受支持的 Kubernetes 版本为 1.23、1.22 和 1.21。在 Kubernetes 版本 1.20 上运行的主管将自动升级到版本 1.21，以确保所有主管集群都在支持的 Kubernetes 版本上运行。
为 SecurityPolicy CRD 提供一致的网络策略 - SecurityPolicy 自定义资源定义能够为主管命名空间中的虚拟机和 vSphere Pod 配置网络安全控制。
主管上的 Tanzu Kubernetes Grid 2.0 - Tanzu Kubernetes Grid 现已升级到版本 2.0。Tanzu Kubernetes Grid 2.0 是 Tanzu 和 Kubernetes 社区中巨大创新的结晶，为跨配置了 Tanzu Kubernetes Grid 的私有云和公有云的一组通用接口奠定了基础。本版本新增了以下两个主要功能：
- ClusterClass - Tanzu Kubernetes Grid 2.0 现在支持 ClusterClass。ClusterClass 提供与上游一致的接口，取代了 Tanzu Kubernetes 集群，为 Tanzu Kubernetes Grid 平台提供了自定义功能。通过 ClusterClass，管理员可以定义将满足其企业环境要求的模板，同时减少样板并支持委派自定义。
- Carvel - Carvel 提供一系列可靠、单一用途、可组合的工具，可帮助在 Kubernetes 中构建、配置和部署应用程序。特别是，kapp 和 kapp-controller 通过一系列与上游一致的声明性工具提供软件包管理、兼容性和生命周期。结合使用模板工具 ytt，实现了灵活而可管理的软件包管理功能。
vSphere 8 中新的文档结构和登录页面 - vSphere IaaS 控制平面文档现在提供改进的结构，可以更好地反映产品中的工作流，让您能够更专注地体验内容。您还可以从新的文档登录页面访问 vSphere IaaS 控制平面的所有可用技术文档。

此版本的安装与升级

有关安装和配置 vSphere IaaS 控制平面的指导，请阅读《安装和配置 vSphere IaaS 控制平面》文档。有关更新 vSphere IaaS 控制平面的信息，请参见《更新 vSphere IaaS 控制平面》文档。

执行升级时，请注意以下事项：

更新到 vCenter Server 8.0 之前，确保所有主管的 Kubernetes 版本至少为 1.21，最好是支持的最新版本。Tanzu Kubernetes Grid 集群的 Tanzu Kubernetes 发布版本必须为 1.21，最好是支持的最新版本。
从 vSphere IaaS 控制平面 8.0 MP1 版本开始，允许从旧版 TKGS TKr 升级到 TKG 2 TKr。有关支持的版本列表，请参阅 Tanzu Kuberentes 版本发行说明。有关升级信息，请参阅《将主管上的 TKG 与 vSphere IaaS 控制平面结合使用》文档。

主管已知问题

在 vSphere 8.0 Update 3 中，vSphere 命名空间创建页面中不再显示网络替代选项

在 8.0 Update 3 版本之前，vSphere 管理员可以提供自定义网络配置来替代创建 vSphere 命名空间时使用的默认网络配置。在 8.0 Update 3 版本中，用于替代网络配置的 UI 选项不可用。

解决办法：可以使用 DCLI 创建具有自定义网络配置的 vSphere 命名空间。
有时，ESXi 主机可能由于无法加载 vds-vsip 模块而无法加入主管集群

ESXi 主机无法加入主管集群时，ESXi 主机日志文件中会显示以下错误 /var/run/log/spherelet.log:

cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

在主管集群升级、证书升级或重新启动 spherelet 的任何其他主管配置更改期间，可能会出现此问题。

解决办法：重新引导无法加载 vds-vsip 模块的 ESXi 主机。
尝试将 vSphere IaaS 控制平面环境从 7.0 Update 3o 升级到 8.0 Update 3 时，如果主管使用微型控制平面虚拟机，则该操作将失败并显示错误

将 vCenter 从 7.0 Update 3o 升级到 8.0 Update 3 后，配置了微型控制平面虚拟机的主管无法从 Kubernetes v1.26.8 升级到 v1.27.5。

可能会出现以下错误： Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

解决办法：升级之前，将控制平面虚拟机的大小从微型纵向扩展到大型或更大。请参见更改主管的控制平面大小。
将 vCenter 和 vSphere IaaS 控制平面环境升级到 vSphere 8.0 U3 后，如果主管使用 Kubernetes 版本 1.26，则尝试创建 vSphere Pod 将失败

将环境升级到 vSphere 8.0 U3 并将主管升级到 Kubernetes 版本 1.26 后，vSphere Pod 创建操作会在系统尝试提取映像时失败。可能会出现 failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface 错误，即使集群启用了静态网络。

解决办法：将 vSphere IaaS 控制平面和主管升级到 Kubernetes 版本 1.27 或更高版本。
有时，同时尝试删除卷快照和执行 PVC 还原操作时，由于内部依赖关系，这些操作无法完成

在以下情况下可能会出现这些问题。启动卷快照还原操作，但由于各种内部原因，还原操作需要较长的时间才能完成或重试。与此同时，触发源快照删除操作。因此，这两个操作发生冲突，始终无法完成。快照删除操作由于该快照的还原操作正在进行中而不断失败，而还原操作由于触发了快照删除而开始失败。

解决办法：要解决此问题，必须删除已还原的 PVC 以停止还原操作，然后继续删除快照。在这种情况下，快照数据将丢失且无法还原，因为在删除已还原的 PVC 后会删除快照。
虚拟机服务虚拟机无法使用存储类中的 volumeBindingMode 参数设置为 WaitForFirstConsumer 的 PVC

将这种类型的 PVC 用于虚拟机服务虚拟机时，会出现不可预知的行为和错误。例如，可能会出现 Waiting for first consumer to be created before binding 错误。

解决办法：虚拟机服务虚拟机支持存储类中具有即时 volumeBidingMode 的 PVC，但不支持 WaitForFirstConsumer。
新的许可模式更改了 VMware vSphere IaaS 控制平面环境中 NSX Container Plugin (NCP) 的行为

在 8.0 Update 3 版本中，NSX Distributed Firewall (DFW) 许可证作为单独的附加模块许可证提供。如果没有此许可证，VMware vSphere IaaS 控制平面环境中的 NCP 将对 NSX 上的 DFW 规则进行调整，从而导致不可预知的行为。

例如，如果没有 DFW 许可证，则为 VMware vSphere IaaS 控制平面创建的新安全策略和网络策略将不起作用，因为 NCP 无法在 NSX Manager 上添加规则。此外，新创建的命名空间中的 Pod 等资源还可以从另一个命名空间进行访问。相反，如果具有 DFW 许可证，默认情况下，新创建的命名空间不应从另一个命名空间进行访问。

解决办法：NSX Distributed Firewall (DFW) 许可证在 NSX Manager 上作为单独的附加模块许可证提供。为避免出现问题，请将该许可证添加到 NSX Manager。
Velero vSphere Operator 安装成功，但尝试实例化 Velero 实例可能会失败

Velero vSphere Operator 将其 Operator Pod 部署在控制平面虚拟机上，而 Velero 实例则部署为 vSphere Pod。

当 vCenter 升级到 8.x 并且主管使用 VDS 网络连接时，可能会出现部署问题。但是，该主管的 ESXi 主机尚未升级，并且使用的是低于 8.x 的异步版本。在这种情况下，ESXi 主机无法部署 vSphere Pod。因此，虽然 Velero vSphere Operator 安装成功，但当管理员尝试使用 Velero 实例时，无法实例化该实例。

解决办法：要确保 Velero 主管服务正常工作，必须先将 ESXi 升级到版本 8.x，然后再将 vCenter 和主管升级到相同的 8.x 版本。
由于大规模运行时资源不足，VM Operator Pod 崩溃

在大规模运行虚拟机（例如，数千个虚拟机）时，如果需要很长时间才能实现 VirtualMachine 资源，这可能是因为 VM Operator Pod 由于内存不足而崩溃。

解决办法：有关解决办法和详细信息，请参见知识库文章 88442。
升级到 vCenter 8.0 Update 2b 后，vmon 托管服务 wcp 可能处于 STOPPED 状态，并且 vCenter 修补可能会失败

仅当您将 vCenter 8.0 Update 1 或更高版本升级到 vCenter 8.0 Update 2b，并且至少有一个主管使用的是 VDS 网络拓扑且位于 Kubernetes 1.24 上时，才会出现此问题。

解决办法：要避免出现此问题，请先将主管升级到 Kubernetes 1.25 或更高版本，然后再将 vCenter 升级到 8.0 Update 2b。有关详细信息，请联系客户支持部门。
当自定义 vCenter 证书的大小大于 8K 时，主管操作失败

在 vSphere 8.0 Update 2b 中，vCenter 系统中 CSR 的最大密钥大小从 16384 位减小到 8192 位。当证书的密钥大小大于 8192 位时，您可能会发现主管操作出现不可预知的行为。例如，主管启用或升级等操作可能会失败。
解决办法：

重新生成密钥大小大于 8192 位的任何 vCenter 证书。
1. 确定密钥大小大于 8192 位的任何证书。
```
for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done
```
2. 替换密钥大小大于 8192 位的任何证书。
3. 如果使用 NSX，请在 NSX 中重新注册 vCenter。
4. 重新启动 WCP 服务。
有关详细信息，请参见知识库文章 96562。
当库链接到多个 vSphere 命名空间时，可能会从 vCenter 的内容库中删除模板

当库链接到 vSphere IaaS 控制平面中的多个命名空间，然后将库与某个命名空间取消链接或删除某个命名空间时，可能会出现此问题。

解决办法：

如果要将库链接到多个命名空间，请避免使用本地库。相反，请在 vCenter 上创建一个已发布的库，并将所有模板上载到该已发布的库。然后，在同一 vCenter 上创建一个订阅的库同步已发布库中的模板，并将此订阅库链接到多个命名空间。在这种情况下，即使库与任何命名空间取消链接或删除某个命名空间，也不会从 vCenter 中删除库项目。
使用 VMware vSphere Automation REST API 创建或更新虚拟机类并在 configSpec 中包含整数字段时出错

当 configSpec 包含整数字段（如 numCPU 或 memoryMB）时，您可能会看到以下错误：

未知错误 - vcenter.wcp.vmclass.configspec.invalid: json: 不支持的鉴别符种类: struct (Unknown error - vcenter.wcp.vmclass.configspec.invalid: json: unsupported discriminator kind: struct)。

未知错误 - vcenter.wcp.vmclass.configspec.invalid: json: 无法将字符串反编组为类型为 int32 的 Go 结构字段 VirtualMachineConfigSpec.<fieldName> (Unknown error - vcenter.wcp.vmclass.configspec.invalid: json: cannot unmarshal string into Go struct field VirtualMachineConfigSpec.<fieldName> of type int32)。

出现此问题的原因是，VAPI 端点中存在一个已知问题，即使用整数解析 Raw REST configSpec JSON 并将整数作为字符串传递，从而导致失败。仅当通过 VMware 开发人员中心使用 REST API 时，才会出现此问题。

解决办法：使用 DCLI 或 vSphere Client 创建或更新虚拟机类，而不使用 REST API。

或者，也可以使用 vSphere Automation SDK for Python/vSphere Automation SDK for Java。以下示例说明了如何使用公共协议转码器服务转换使用 pyvmomi 从 vCenter 获取的 VirtualMachineConfigSpec (vim.vm.ConfigSpec) 对象。该示例的最后一条展示了如何解析手动编写的 JSON。然后，可以将该对象发送到 VirtualMachineClasses API。
将有效 vSphere VMware Foundation 许可证应用于主管后，“工作负载管理”页面继续显示旧评估许可证过期警告

如果使用评估许可证启用主管，并将 vSphere VMware Foundation 许可证应用于主管，则可能会遇到此问题。但是，新许可证不会显示在 vSphere Client“工作负载管理”页面上的 vCenter > 工作负载管理 > 主管 > 主管下。即使已成功应用新许可证密钥，vSphere Client 仍会继续显示警告和旧评估许可证过期日期。

解决办法：无。新许可证正确显示在 vSphere Client 中的系统管理 > 许可证 > 资产 > 主管下。
如果添加或删除的规则不是最后一个，则安全策略 CRD 中更新的安全策略规则不会生效

作为 DevOps，您可以将安全策略 CRD 配置为将基于 NSX 的安全策略应用于主管集群命名空间。更新 CRD 并添加或删除安全策略规则时，更新的规则不会生效，除非它是规则列表中的最后一个。

解决办法：将规则添加到规则列表的末尾，或使用另外的安全策略添加或删除规则。
使用旧虚拟机映像名称时，vSphere 8.0 U2 中的虚拟机映像名称格式更改可能会导致出现问题

在 vSphere 8.0 Update 2 之前，虚拟机映像资源的名称派生自内容库项目的名称。例如，如果内容库项目命名为 photonos-5-x64，则其相应的 VirtualMachineImage 资源也将命名 photonos-5-x64。当不同库中的库项目具有相同的名称时，这会导致出现问题。

在 vSphere 8.0 Update 2 版本中，引入了虚拟机映像服务，以便能够以自助方式管理虚拟机映像。请参见在 vSphere IaaS 控制平面中创建和管理独立虚拟机的内容库。

此新功能支持将内容库与命名空间或整个主管集群相关联，并且要求 Kubernetes 集群中虚拟机映像资源的名称唯一且确定。因此，为了避免与库项目名称发生潜在冲突，虚拟机映像现在采用新的命名格式 vmi-xxx。但是，如果使用的先前的虚拟机 YAML 引用旧映像名称（如 photonos-5-x64 或 centos-stream-8），此更改可能会导致在 vSphere 8.0 Update 2 版本中出现问题。
解决办法：
1. 使用以下命令检索有关虚拟机映像的信息：
  - 要显示与其命名空间关联的映像，请运行 kubectl get vmi -n <namespace>。
  - 要获取集群中可用的映像，请运行 kubectl get cvmi。
2. 在获取 NAME 列下列出的映像资源名称后，更新虚拟机部署规范中的名称。
在主管自动升级期间，vSphere 上的 WCP 服务进程可能会触发应急并意外停止

您可能会注意到为 WCP 服务进程生成的核心转储文件。

解决办法：无。VMON 进程会自动重新启动 WCP 服务，并且 WCP 服务继续升级，不会出现其他问题。
主管升级挂起，vSphere Pod 中的 ErrImagePull 和提供程序处于“故障”状态。出现 ErrImagePull 故障时，可能无法分离连接到 vSphere Pod（包括主管服务）的持久卷。

对于因 ErrImagePull 失败的 vSphere Pod，可能无法分离持久卷。这可能会导致 vSphere Pod 级联故障，因为所需持久卷连接到故障实例。在主管升级期间，主管内的 vSphere Pod 可能会转变为 provider failed 状态，变得无响应。

解决办法：删除持久卷连接到的故障 vSphere Pod 的实例。请务必注意，可以保留与 vSphere Pod 关联的持久卷声明 (PVC) 和持久卷。完成升级后，使用相同的 PodSpecPVC 重新创建 vSphere Pod 以保持数据完整性和功能。要缓解此问题，请使用 ReplicaSet（DaemonSet、Deployment）创建 vSphere Pod，以维护在任何给定时间运行的一组稳定的 vSphere Pod 副本。
由于主节点选举，主管升级停滞在 50% 且 Pinniped 升级失败

Pinniped Pod 在推出期间停滞在挂起状态，并且主管升级在 Pinniped 组件升级期间失败。
解决办法：
1. 运行 kubectl get pods -n vmware-system-pinniped 以检查 Pinniped Pod 的状态。
2. 运行 kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml 以验证 holderIdentity 不是任何处于挂起状态的 Pinniped Pod。
3. 运行 kubectl delete leases -n vmware-system-pinniped pinniped-supervisor 以移除将不活动 Pod 作为 holderIdentity 的 Pinniped 主管的租约对象。
4. 再次运行 kubectl get pods -n vmware-system-pinniped 以确保 vmware-system-pinniped 下的所有 Pod 均已启动且正在运行
主管控制平面虚拟机处于打开电源状态时，ESXi 主机节点无法进入维护模式

在具有 NSX Advanced Load Balancer 的主管设置中，如果 Avi 服务引擎虚拟机处于打开电源状态，则 ESXi 将主机无法进入维护模式，这会影响维护模式下的 ESXi 主机升级和 NSX 升级。

解决办法：关闭 Avi 服务引擎虚拟机的电源，以便 ESXi 进入维护模式。
无法在 VDIS 上使用 ClusterIP 和 vSphere Pod 接收环回流量

如果 vSphere Pod 中的应用程序尝试访问在同一 vSphere Pod（位于不同容器中）内提供的 ClusterIP，VSIP 中的 DLB 无法将流量路由回 vSphere Pod。

解决办法：无。
网络策略不在基于 VDS 的主管中实施

使用 NetworkPolicy 的现有服务 YAML 不需要进行任何更改。如果文件中存在 NetworkPolicy，则不会实施策略。

解决办法：必须在 VDS 的网络上设置基于策略的规则。要获得 NetworkPolicy 支持，需要支持 NSX 网络。
从主管卸载 Carvel 服务后，vSphere Client 中可能仍显示该服务的命名空间

如果从主管卸载 Carvel 服务的时间超过 20 分钟，则卸载该服务后，vSphere Client 中可能仍显示其命名空间。

尝试在同一主管上重新安装该服务失败，直到删除命名空间。重新安装期间将显示消息 ns_already_exist_error。

您会在日志文件中看到以下条目：

/var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"
解决办法：从 vSphere Client 手动删除命名空间。
1. 从 vSphere Client 主菜单中，选择工作负载管理。
2. 单击命名空间选项卡。
3. 从命名空间列表中，选择未清除的命名空间，然后单击移除按钮以删除命名空间。
如果将 ESXi 主机从 7.0 Update 3 升级到 8.0，但不升级主管，会导致 ESXi 主机显示为“未就绪”，并且工作负载脱机

将主管中的 ESXi 主机从 vSphere 7.0 Update 3 升级到 vSphere 8.0 时，如果不升级主管的 Kubernetes 版本，则 ESXi 主机将显示为“未就绪”，并且主机上运行的工作负载将脱机。

解决办法：将主管的 Kubernetes 版本升级到 1.21、1.22 或 1.23，至少升级到 1.21。
一键式升级 vCenter Server 后，不会自动升级主管

如果主管的 Kubernetes 版本低于 1.22，则将 vCenter Server 一键式升级到 8.0 后，主管无法自动升级到 8.0 支持的最低 Kubernetes 版本 1.23。

解决办法：将 vCenter Server 升级到 8.0 之前，先将主管的 Kubernetes 版本升级到 1.22。如果已将 vCenter Server 升级到 8.0，请手动将主管的 Kubernetes 版本升级到 1.23。
如果更改安全策略自定义资源中的规则，可能不会删除失效的规则

更新安全策略时，可能会出现此问题。例如，创建包含规则 A 和 B 的安全策略自定义资源，然后更新该策略，将规则更改为 B 和 C。结果，不会删除规则 A。NSX 管理平面除显示规则 B 和 C 外，还会显示规则 A。

解决办法：删除安全策略，然后创建相同的安全策略。

升级 vCenter Server 和 vSphere IaaS 控制平面后，Tanzu Kubernetes Grid 集群无法完成升级，因为卷显示已连接到集群的节点。

当 Tanzu Kubernetes Grid 集群升级失败时，您会注意到一个卷显示为已连接到集群的节点，并且不会被清除。此问题可能是由上游 Kubernetes 中的问题导致的。

解决办法：

使用以下命令获取有关已禁用调度的 TKG 集群节点的信息：

kubectl get node tkc_node_name -o yaml

例如：

# kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

检查此节点的 status.volumeAttached 属性中是否包含任何 vSphere CSI 卷。如果包含任何卷，请继续执行下一步。

确认步骤 1 中标识的节点上没有正在运行的 Pod。使用以下命令：

kubectl get pod -o wide | grep tkc_node_name

例如：
```
kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
```
此命令输出为空，则表示没有 Pod。继续执行下一步，因为步骤 1 中的输出显示卷连接的节点不包含任何 Pod。

获取有关所有节点对象的信息，确保同一个卷连接到另一个节点：

kubectl get node -o yaml

例如：

相同的卷名称显示在两个 TKG 集群节点对象中。

On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...

根据卷名称中的卷句柄搜索 PV。

在上例中，卷名称为 kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd，卷句柄为 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd。

使用以下命令获取所有 PVS 并搜索上述卷句柄：

kubectl get pv -o yaml

在上例中，具有该卷句柄的 PV 为 pvc-59c73cea-4b75-407d-8207-21a9a25f72fd。

使用 volumeattachment 命令搜索上一步中找到的 PV：

kubectl get volumeattachment | grep pv_name

例如：

# kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

您会看到卷连接到节点 gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88，而不是节点 gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95。这表示 gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 中的 status.volumeAttached 不正确。

从节点对象中删除失效的 volumeAttached 条目：

kubectl edit node tkc_node_name

例如：

kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

从 status.volumeAttached 中移除失效的卷条目。
对 status.volumeAttached 属性中的所有失效卷重复上述步骤。

如果 WCPMachines 仍然存在，请手动将其删除并等待几分钟以协调集群。

# kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

如果 vSphere 管理员为自助命名空间模板配置的资源限制超出集群容量，不会触发警示。

vSphere 管理员配置的资源限制超出集群容量时，DevOps 工程师可以使用该模板为 vSphere Pod 部署高资源。这会导致工作负载出现故障。

解决办法：无
删除包含 Tanzu Kubernetes Grid 集群的主管命名空间时，主管中的持久卷声明可能始终处于正在终止状态

当系统删除命名空间并从 Tanzu Kubernetes Grid 集群中的 Pod 中分离卷时，可能会出现资源冲突，此时您会看到此问题。

主管命名空间删除未完成，vSphere Client 显示命名空间状态为“正在终止”。连接到 Tanzu Kubernetes Grid 集群中的 Pod 的持久卷声明也保持正在终止状态。

如果运行以下命令，则会看到“无法在 persistentvolumeclaims 上执行操作 (Operation cannot be fulfilled on persistentvolumeclaims)”错误:

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

无法更新命名空间: \\\"<supervisor-namespace>\\\" 上的PersistentVolumeClaim: \\\"<pvc-name>\\\"。错误: 无法在 persistentvolumeclaims \\\"<pvc-name>\\\\" 上执行操作: 对象已修改；请将更改应用到最新版本，然后重试 (failed to update PersistentVolumeClaim: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\". Error: Operation cannot be fulfilled on persistentvolumeclaims \\\"<pvc-name>\\\": the object has been modified; please apply your changes to the latest version and try again\)

解决办法：

使用以下命令修复此问题：

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge
从共享数据存储（如 vSAN）中删除多个 FCD 和卷时，您可能会注意到性能变化

性能变化可能是由一个已修复的问题导致的。如果未能修复，该问题会导致失效的 FCD 和卷在 FCD 删除操作失败后仍保留在数据存储中。

解决办法：无。尽管性能发生变化，但删除操作仍照常运行。
如果 DevOps 用户在 vCenter Server 重新引导时启动卷操作或有状态应用程序部署，则此操作可能会失败

出现此问题的原因是工作负载存储管理用户帐户被锁定，主管上运行的 vSphere CSI 插件无法进行身份验证。因此，卷操作失败并显示 InvalidLogin 错误。

日志文件 /var/log/vmware/vpxd/vpxd.log 显示以下消息：

Authentication failed: The account of the user trying to authenticate is locked.:: The account of the user trying to authenticate is locked.:: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})
解决办法：
1. 获取帐户解除锁定时间。
  1. 在 vSphere Client 中，导航到“系统管理”，然后单击 Single Sign On 下的“配置”。
  2. 单击“选择帐户”选项卡。
  3. 在“锁定策略”下，获取解除锁定时间（以秒为单位）。
2. 使用适用于 kubectl 的 vSphere 插件对主管进行身份验证。
  
  kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME
3. 记下 vmware-system-csi- namespace 中 vsphere-csi-controller 部署的原始副本计数。
  
  kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'
  
  original-replica-count
4. 将 vsphere-csi-controller 部署副本计数缩减为零。
  
  kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi
5. 等待“解除锁定时间”下指示的秒数。
6. 将 vsphere-csi-controller 部署副本计数增加到原始值。
  
  kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

主管上的 TKG 已知问题

将 vSphere IaaS 控制平面 7.0.x 环境升级到 vSphere 8.0.x 时，任何 v1.27.6 TKG 集群都会变得不兼容

vSphere 8.0.x 不支持 TKR 1.27.6。

因此，将 vSphere IaaS 控制平面 7.0.x 升级到 vSphere 8.0.x 后，v1.27.6 TKG 集群将变得不兼容。在主管升级期间，不会收到任何预检查警告。
解决办法：
- 如果在 vSphere 7.0.x 上有任何 v1.27.6 TKGS 集群正在运行，请不要升级到 vCenter 8.0.x，尤其是 vCenter 8.0 Update 2b。有关详细信息，请参见 VMware Tanzu Kubernetes 版本发行说明和知识库文章 96501。
- 如果您计划将 vSphere 7.x 环境升级到 vCenter 8.x，请不要升级到 TKR 1.27.6。
TKG 集群工作节点无法打开电源，并在 nsx-ncp pod 中显示错误日志 VIF restore activity already completed for attachment ID

TKG 集群工作节点无法打开电源，并显示以下错误：

nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

NCP 记录错误：

VIF restore activity already completed for attachment ID

当 NSX 备份后创建的 TKG 集群节点的虚拟机在 NSX 还原后立即使用 vMotion 进行迁移时，NCP 无法还原该虚拟机的端口，因为在 vMotion 中会重用连接 ID 并阻止 NCP 的还原请求。
解决办法：
1. 转到 NSX Manager 获取应予以删除的分段端口，这些端口的显示名称格式为 <vm name>.vmx@<attachment id>
2. 在删除新创建的端口之前，找到正在运行虚拟机的主机，并通过在主机上运行 /etc/init.d/nsx-opsagent stop 关闭 ops-agent。
3. 使用 NSX API 删除端口 https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true
4. 通过在主机上运行 /etc/init.d/nsx-opsagent start 打开 ops-agent。
5. 等待 NCP 还原端口。
在 TKG 集群清理期间或从 ESXi 主机停机恢复期间，TKG 集群中的 Pod、PV 和 PVC 可能会停滞在 Terminating 状态

在正常 TKG 集群删除和清理过程中，将删除所有部署、有状态集、PVC、PV 和类似对象。但是，对于基于 TKR v1.24 及更低版本的 TKG 集群，由于 DetachVolume 错误，某些 PV 可能会停滞在 Terminating 状态。当 VolumeAttachment 对象上的 DetachVolume 错误导致 VolumeAttachment 上的终结器无法移除，从而导致无法删除相关对象时，会出现此问题。如果 ESXi 主机停机，也可能会出现此情况。
解决办法：在 TKG 集群中运行以下命令，从具有 detachError 的 VolumeAttachment 中删除终结器：
```
kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments
```
备份和还原后无法访问 TGK 集群

如果在 NSX 备份后创建 vSphere 命名空间并配置了自定义的输入/输出 CIDR，则从备份还原 NSX 后，NCP 将无法完成还原过程且 vSphere 命名空间上的 TKG 集群不可用。NCP 在还原过程中失败，并显示如下错误：

NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

解决办法：如果执行主管备份的时间与 NSX 备份时间大致相同，但在创建受影响的 vSphere 命名空间之前，也可以从备份还原主管。或者，删除 vSphere 命名空间和关联的 TKG 集群，等待 NCP 重新同步，然后重新创建已删除的资源。
NSX 备份和还原后无法访问 TKG 集群

如果主管配置了自定义的输入 CIDR，则在 NSX 备份还原后，TKG 集群可能会变得不可用，因为 NCP 组件无法正确验证 TKG 集群的输入 VIP。

解决办法：通过使用 NSX API，为 NSX 中的 TKG 集群手动配置 VIP 以还原访问权限。
配置了代理服务器的现有 Tanzu Kubernetes Grid 集群无法升级到 vSphere 8 主管

已修复：此已知问题在 vSphere 8 with Tanzu MP1 版本中已修复。

如果为现有 Tanzu Kubernetes Grid 集群配置了代理服务器，则无法将该集群从 vSphere 7 主管升级到 vSphere 8 主管上的 Tanzu Kubernetes Grid 2.0。

解决办法：noProxy 字段的内容与升级检查冲突。如果将代理部分添加到集群规范，则此字段为必填字段，因此必须先完全移除代理配置，然后再升级到 vSphere 8。
antrea-resource-init pod 处于“挂起”状态

升级 Tanzu Kubernetes Grid 集群的 Tanzu Kubernetes 发布版本后，antrea-resource-init pod 可能处于“挂起”状态。

解决办法：重新启动主管上的 pod。
Tanzu Kubernetes Grid 集群 v1.21.6 可能进入 FALSE 状态，并且某些计算机可能无法迁移

升级到 vCenter Server 8 并更新主管后，v1.21.6 Tanzu Kubernetes Grid 集群可能会进入 FALSE 状态，并且某些 wcpmachine 可能不会迁移到 vspheremachine。

解决办法：无
默认情况下，对于运行 TKR 版本 v1.23.8---vmware.2-tkg.2-zshippable 的 TKG 集群，vmware-system-user 帐户的密码在 60 天后过期

作为 STIG 强化的一部分，对于运行 TKR 版本 v1.23.8---vmware.2-tkg.2-zshippable 的 TKG 集群，vmware-system-user 帐户配置为在 60 天后过期。这可能会影响使用 vmware-system-user 帐户通过 SSH 访问集群节点的用户。

请参阅以下知识库文章，更新 vmware-system-user 密码过期时间，如果需要，允许与 TKG 集群节点建立 SSH 会话：https://kb.vmware.com/s/article/90469

在 vSphere IaaS 控制平面 8.0.0a 的 TKC 上，tanzu-capabilities-controller-manager pod 不断重新启动并进入 CLBO 状态

由于服务帐户权限问题，使用 TKR 版本 v1.23.8+vmware.2-tkg.2-zshippable 时，TKG 集群上的 tanzu-capabilities-controller-manager pod 将停滞在 CLBO（崩溃循环后退）状态。

解决办法：将所需权限添加到 TKC 上的功能服务帐户 tanzu-capabilities-manager-sa。

暂停 TKC 上功能包的协调：

kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

创建新的文件 capabilities-rbac-patch.yaml：

apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

修补 TKC 上的功能集群角色：

//Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

删除 TKC 上的 tanzu-capabilities-controller-manager。

部署在三个 vSphere 区域中的主管上的 Tanzu Kubernetes Grid 2.0 集群不支持具有 vGPU 和实例存储的虚拟机。

在跨三个 vSphere 区域部署的主管实例上置备的 Tanzu Kubernetes Grid 2.0 集群不支持具有 vGPU 和实例存储的虚拟机。

解决办法：无
TKR 版本 v1.22.9 列在内容库映像中，但在 kubectl 命令中未列出

TKR 映像的内容库列出了 TKR v1.22.9。命令 kubectl get tkr 未将此映像列为可用，因为 TKR v1.22.9 不可用，不应使用。此映像错误地显示在内容库中。

解决办法：使用 TKR v1.22.9 以外的 TKR。有关可用 TKR 的列表，请参阅 TKR 发行说明。
无法在 vSphere IaaS 控制平面 8.0.0a 中使用 v1alpha1 API 和 v1.23.8 TKR 置备 TKC

利用 TKC v1alpha1 API 置备版本为 v1.23.8 的 TKC 时，该请求将失败，并显示错误消息“找不到与版本提示‘1.23.8’和默认操作系统标签‘os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0’匹配的兼容完整版本 (unable to find a compatible full version matching version hint "1.23.8" and default OS labels: "os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0”)”。

解决办法：置备 TKC 时切换到 TKC v1alpha2 API 或 v1alpha3 API
使用 v1beta1 API 置备的 Tanzu Kubernetes Grid 2.0 集群必须基于默认的 ClusterClass

如果要使用 v1beta1 API 在主管上创建 Tanzu Kubernetes Grid 2.0 集群，则该集群必须基于默认的 tanzukubernetescluster ClusterClass。系统不会协调基于不同 ClusterClass 的集群。

解决办法：从 vSphere 8 U1 版本开始，可以根据自定义 ClusterClass 置备 v1beta1 集群。请参阅知识库文章 https://kb.vmware.com/s/article/91826。

网络连接已知问题

在 NSX Advanced Load Balancer 设置中，clusternetworkinfo 或 namespacenetworkinfo 输出中没有 usage.ingressCIDRUsage 部分

在 NSX Advanced Load Balancer 设置中，输入 IP 由 Avi 控制器分配，ingressCIDR 的使用情况不会显示在 clusternetworkinfo 或 namespacenetworkinfo 输出中。

解决办法：从 Avi 控制器 UI 应用程序 > VS VIP 获取 ingressCIDR 使用情况。
删除路由主管的命名空间后，未移除 Tier-0 前缀列表上的 Pod CIDR

在路由主管中，删除命名空间后，不会删除 Tier-0 前缀列表中的 Pod CIDR。

解决办法：删除前缀列表对象：

curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json
使用 NSX Advanced Load Blanacer 时，Kubernetes 资源 clusternetworkinfo 和 namespacenetworkinfo 不包含 usage.ingressCIDRUsage。

在基于 NSX 的主管中使用 NSX Advanced Load Balancer 时，clusternetworkinfo 和 namespacenetworkinfo Kuberentes 资源不再包含 usage.ingressCIDRUsage 字段。这意味着运行 kubectl get clusternetworkinfo <supervisor-cluster-name> -o json 或 kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json 不会在输出中包含 ingressCIDR 使用情况对象。

解决办法：使用 Avi 控制器 UI 页面访问 ingressCIDR 使用情况。
NSX 备份和还原后，某些命名空间存在失效的 Tier-1 分段

NSX 备份和还原过程完成后，不会清理具有服务引擎网卡的失效 Tier-1 分段。

NSX 备份后删除命名空间时，还原操作会还原与 NSX Advanced Load Balancer 控制器服务引擎网卡关联的失效 Tier-1 分段。
解决办法：手动删除 Tier-1 分段。
1. 登录到 NSX Manager。
2. 选择网络 > 分段。
3. 查找与已删除命名空间关联的失效分段。
4. 从端口/接口部分中删除失效的服务引擎网卡。
负载均衡器监控器可能会停止工作，主管可能会在 vSphere Client 中停滞在“正在配置”状态

如果启用了 NSX Advanced Load Balancer，由于 NSX 中存在多个实施点，NCP 可能无法提取负载均衡器状态。在 NSX 上启用 NSX Advanced Load Balancer 后，这会影响配置了 NSX Advanced Load Balancer 的现有主管。此问题会影响利用 NSX Advanced Load Balancer 的新主管。受此问题影响的主管仍将正常工作 - LB 监控功能除外。

解决办法：在 NSX 中禁用 NSX Advanced Load Balancer在现有主管运行 NSX Advanced Load Balancer 的 WCP 环境中，这可能会限制部署具有 NSX Advanced Load Balancer 的主管的能力。
无法将 NSX Advanced Load Balancer 与使用嵌入式链接模式拓扑的 vCenter Server 结合使用。

配置 NSX Advanced Load Balancer 控制器时，可以在多个云上进行配置。但是，启用 vSphere IaaS 控制平面时，没有选择多个云的选项，因为它仅支持 Default-Cloud 选项。因此，无法将 NSX Advanced Load Balancer 与使用嵌入式链接模式拓扑的 vCenter Server 版本结合使用。

为每个 vCenter Server 配置 NSX 负载均衡器。

存储已知问题

在各 vCenter 系统之间共享数据存储的环境中，观察到多个 CNS 卷同步错误

CNS 不支持跨 vCenter 迁移。但是，会定期自动执行 CNS 同步，并且会为共享数据存储上的卷创建锁定争用。
解决办法：要避免出现此问题，请为 CNS 定期同步设置较大的时间间隔。
1. 在 vCenter 中找到 CNS 配置文件：
  
  /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml
2. 导航到以下文件：
  
  <newSyncInterval>60</newSyncInterval>
  
  默认情况下，定期同步设置为 60 秒。
3. 将此时间更改为更长的时间段，例如，1 年时间 31536000 秒。
无法更改 vSAN Direct 数据存储中磁盘的卷分配类型

确定 vSAN Direct 数据存储中磁盘的卷分配类型后，将无法进行更改。这是因为底层不支持类型转换。但是，克隆和重新放置等操作允许更改新磁盘的卷分配类型。

解决办法：无
已删除的虚拟机导致 CNS 任务停滞在已排队状态。

发送到 CNS 的操作返回任务 ID，但任务状态仍是“已排队”。这些任务适用于附加到刚删除的虚拟机的卷。
解决办法：如果应用程序层可以修复调用顺序，则无需在 CNS 端执行任何操作。如果不能，请按照以下步骤禁用 CNS 新序列化：
1. 在 vCenter 上打开 /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml。
2. 将以下配置更改为 false： <newSerializationEnabled>true</newSerializationEnabled>
3. 使用以下命令重新启动 vsan-health： vmon-cli -r vsan-health
有关更多详细信息，请参见知识库文章 93903。
成功删除 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 未由集群中的任何其他资源使用。