发行说明内容

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

新增功能

新增功能 - 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 日

vSphere with Tanzu 8.0 Update 2 引入了以下新功能和增强功能:

主管

  • 虚拟机服务现在支持具有 Windows 操作系统、GPU 以及传统 vSphere 虚拟机的所有其他选项的虚拟机 - 虚拟机服务现在支持使用 vSphere 虚拟机当前所支持的任何配置来部署虚拟机,从而与 vSphere 上的传统虚拟机完全相同,但支持作为基础架构即服务的一部分部署到主管的虚拟机。这包括支持置备 Windows 虚拟机和 Linux 虚拟机,以及 vSphere 所支持的任何硬件、安全、设备、自定义或多网卡支持和直通设备。现在,可以使用 GPU 置备工作负载虚拟机以支持 AI/ML 工作负载。

  • 虚拟机映像服务 - DevOps 团队、开发人员和其他虚拟机使用者可以使用虚拟机映像服务以自助方式发布和管理虚拟机映像。服务允许使用者在主管命名空间范围的映像注册表中使用 K8s API 发布、修改和删除映像。每个 CCS 区域和 CCS 项目中都将自动创建虚拟机映像服务,映像注册表的映像填充范围按用户配置和消耗级别(全局级别或项目级别)进行限定。映像可用于通过虚拟机服务部署虚拟机。

  • 导入和导出主管配置 - 在以前的版本中,激活主管是一个手动分步过程,无法保存任何配置。在当前版本中,您现在可以以人工可读格式或在源控制系统内导出主管配置并与对等方共享,将配置导入到新的主管,并在多个主管之间复制标准配置。查看文档,了解有关如何导出和导入主管配置的详细信息。

  • 通过减少碎片提高了 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 年 4 月 18 日 | 内部版本 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 with Tanzu 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 日

新功能

主管

  • 现在,主管服务可在基于 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 with Tanzu 8 主管版本的安全技术实施指南 (STIG)。有关详细信息,请参见 Tanzu STIG 强化

主管上的 Tanzu Kubernetes Grid 2.0

vSphere with Tanzu 8.0.0 GA 客户的关键要求

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

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

  1. 使用指向 https://wp-content.vmware.com/v2/8.0.0/lib.json 的临时订阅 URL 创建新的订阅内容库

  2. 同步临时内容库中的所有项目。

  3. 将临时内容库与部署了 TKG 2 集群的每个 vSphere 命名空间相关联

  4. 运行命令 kubectl get tkr,并验证是否创建了所有 TKR。

  5. 此时,TKG 控制器应处于正在运行状态,您可以通过在主管命名空间中列出 Pod 进行验证。

  6. 如果 TKG 控制器处于 CrashLoopBackOff (CLBO) 状态,请使用以下命令重新启动 TKG 控制器部署:

    kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

  7. 升级到 vSphere with Tanzu 8 Update 1。

  8. 更新每个 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 日

已解决的问题:

  • 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 日

新功能:

  • 增加了 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 日

新功能

  • 增加了 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 日

vSphere with Tanzu 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 with Tanzu 文档现在提供改进的结构,可以更好地反映产品中的工作流,让您能够更专注地体验内容。您还可以从新的文档登录页面访问 vSphere with Tanzu 的所有可用技术文档。


此版本的安装与升级

有关安装和配置 vSphere with Tanzu 的指导,请阅读《安装和配置 vSphere with Tanzu》文档。有关更新 vSphere with Tanzu 的信息,请参见《维护 vSphere with Tanzu》文档。

执行升级时,请注意以下事项:

  • 更新到 vCenter Server 8.0 之前,确保所有主管的 Kubernetes 版本至少为 1.21,最好是支持的最新版本。Tanzu Kubernetes Grid 集群的 Tanzu Kubernetes 发布版本必须为 1.21,最好是支持的最新版本。

  • 从 vSphere with Tanzu 8.0 MP1 版本开始,允许从旧版 TKGS TKr 升级到 TKG 2 TKr。有关支持的版本列表,请参阅 Tanzu Kuberentes 版本发行说明。有关升级信息,请参阅将 Tanzu Kubernetes Grid 2 于 vSphere with Tanzu 结合使用文档。

已知问题

主管已知问题

  • 在主管自动升级期间,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 with Tanzu 后,Tanzu Kubernetes Grid 集群无法完成升级,因为卷显示已连接到集群的节点

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

    解决办法:

    1. 使用以下命令获取有关已禁用调度的 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 卷。如果包含任何卷,请继续执行下一步。

    2. 确认步骤 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。

    3. 获取有关所有节点对象的信息,确保同一个卷连接到另一个节点:

      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
        ...
    4. 根据卷名称中的卷句柄搜索 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

    5. 使用 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 不正确。

    6. 从节点对象中删除失效的 volumeAttached 条目:

      kubectl edit node tkc_node_name

      例如:

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

      status.volumeAttached 中移除失效的卷条目。

    7. status.volumeAttached 属性中的所有失效卷重复上述步骤。

    8. 如果 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 已知问题

  • 在 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 with Tanzu 8.0.0a 的 TKC 上,tanzu-capabilities-controller-manager pod 不断重新启动并将进入 CLBO 状态

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

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

    1. 暂停 TKC 上功能包的协调:

      kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge
    2. 创建新的文件 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
    3. 修补 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
    4. 删除 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 with Tanzu 8.0.0a 中使用 v1alpha1 API 置备 TKR 为 v1.23.8 的 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 设置中,clusternetworkinfonamespacenetworkinfo 输出中没有 usage.ingressCIDRUsage 部分

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

    解决办法:从 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 资源 clusternetworkinfonamespacenetworkinfo 不包含 usage.ingressCIDRUsage

    在基于 NSX 的主管中使用 NSX Advanced Load Balancer 时,clusternetworkinfonamespacenetworkinfo Kuberentes 资源不再包含 usage.ingressCIDRUsage 字段。这意味着运行 kubectl get clusternetworkinfo <supervisor-cluster-name> -o jsonkubectl 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 with Tanzu 时,没有选择多个云的选项,因为它仅支持 Default-Cloud 选项。因此,无法将 NSX Advanced Load Balancer 与使用嵌入式链接模式拓扑的 vCenter Server 版本结合使用。

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

存储

  • 无法更改 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 未由集群中的任何其他资源使用。

check-circle-line exclamation-circle-line close-line
Scroll to top icon