VMware NSX Container Plugin 4.0.1 发行说明

VMware NSX Container Plugin 4.0.1 | 2022 年 11 月 8 日 | 内部版本 20665035 请查看发行说明以了解新增内容及更新。

新增功能

• TKGI 集群现在支持管理器到策略迁移。与 NCP 4.0.1 捆绑的第一个 TKGI 版本将提供此支持。此功能需要 NSX 4.0.1 或更高版本。

弃用声明

允许使用 ncp/ingress_controller 注释通过 NAT 访问 Ingress 控制器 Pod 的功能已弃用，并将在 2023 年移除。公开 Ingress 控制器 Pod 的建议方法是使用 LoadBalancer 类型的服务。

兼容性要求

产品	版本
Tanzu Application Service (TAS) 的 NCP/NSX-T Tile 包	4.0.1
NSX-T/NSX	NSX-T 3.2.1、3.2.2、3.2.3。NSX 4.0.0.1、4.0.1.1。（请参见以下注释。）
vSphere	6.7 和 7.0 8.0.0.1（仅限 NSX 4.0.1）
Kubernetes	1.23、1.24、1.25
OpenShift 4	4.8, 4.9, 4.10
Kubernetes 主机虚拟机操作系统	Ubuntu 18.04、20.04 RHEL：8.4、8.5、8.6 请参见以下注释。
Tanzu Application Service	Ops Manager 2.10 + TAS 2.11 (LTS) Ops Manager 2.10 + TAS 2.13 Ops Manager 2.10 + TAS 3.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.15

注意：

NSX-T 3.2.3 支持基本完整性测试。请参见产品互操作性列表。

要在 RHEL 上安装 nsx-ovs 内核模块，需要使用特定的内核版本。无论 RHEL 版本如何，支持的 RHEL 内核版本均为 193、305、348 和 372。请注意，RHEL 8.2 的默认内核版本为 193，RHEL 8.4 的默认内核版本为 305，RHEL 8.5 的默认内核版本为 348，RHEL 8.6 的默认内核版本为 372。如果运行不同的内核版本，您可以 (1) 将内核版本修改为支持的版本。在修改内核版本并随后重新启动虚拟机时，请确保在上行链路接口（由 ovs_uplink_port 指定）上保留了 IP 路由和静态路由，以保证到 Kubernetes API 服务器的连接不会中断。或者 (2) 在 nsx-node-agent 配置映射中的“nsx_node_agent”部分下面，将“use_nsx_ovs_kernel_module”设置为“False”以跳过 nsx-ovs 内核模块安装。有关在 NSX-OVS 和上游 OVS 内核模块之间切换的信息，请参见 https://docs.vmware.com/cn/VMware-NSX-Container-Plugin/4.0/ncp-kubernetes/GUID-7225DDCB-88CB-4A2D-83A3-74BB9ED7DCFF.html。

要在 RHEL 上运行 nsx-ovs 内核模块，您必须禁用 vCenter Server 的虚拟机设置中“引导选项”下的“UEFI 安全引导”选项。

对于所有支持的集成，请使用 Red Hat 通用基础映像 (UBI)。有关详细信息，请参见 https://www.redhat.com/zh/blog/introducing-red-hat-universal-base-image。

支持升级到此版本：

• 所有以前的 3.2.x 版本

限制

• NCP 的“基准策略”功能会创建一个动态组，该组会选择集群中的所有成员。NSX-T 将动态组的有效成员数限制为 8,000 个（有关详细信息，请参见配置上限）。因此，如果集群中的 Pod 数预计会超过 8,000 个，则不应启用此功能。超出此限制可能会导致为容器创建资源时出现延迟。

• 透明模式负载均衡器

  • 仅支持 Kubernetes 集群的南北向流量。不支持集群内部的流量。

  • 连接到 LoadBalancer CRD 的服务或在启用自动缩放时不支持。必须禁用自动缩放，此功能才能正常工作。

  • 建议仅在新部署的集群上使用此功能。

• 管理器到策略迁移

  • 如果之前的迁移失败并回滚集群，则无法迁移 Kubernetes 集群。这是仅针对 NSX 4.0.0.1 或更低版本的限制。

已知问题

• 问题 3239352：在 TAS 环境中，当无法分配任务时，重试可能不起作用

  在 NCP TAS 环境中，当无法分配任务时，Auctioneer 会拒绝该任务，并且 BBS 会重试放置该任务，最多达到 task.max_retries 设置所指定的次数。达到 task.max_retries 后，BBS 会将任务从“挂起”状态更新为“已完成”状态，同时将其标记为“失败”，并包含失败原因，说明集群没有用于执行该任务的容量。

  重试期间，可能会将该任务调度到新单元，该单元会向 NCP 通知 task_changed 事件。由于 NCP 不会处理 task_changed 事件，因此无法在新单元中为任务分配新端口。任务无法正常运行。

  解决办法：禁用重试，并将 task.max_retries 值设置为 0。

• 问题 3049209：完成管理器到策略迁移后，删除集群不会删除 mp_default_LR_xxx_user_rules 资源

  执行管理器到策略迁移后，删除集群时，可能不会删除某些名为 mp_default_LR_xxxx_user_rules 的“GatewayPolicy”资源。

  解决办法：手动删除资源。

• 问题 3043496：如果管理器到策略迁移失败，NCP 将停止运行

  NCP 提供了 migrate-mp2p 作业以迁移 NCP 和 TKGI 使用的 NSX 资源。如果迁移失败，将回滚所有迁移的资源，但不会在管理器模式下重新启动 NCP。

  解决办法：

  1. 确保所有资源均已回滚。这可以通过检查 migrate-mp2p 作业的日志来完成。该日志必须以“All imported MP resources to Policy completely rolled back”一行结尾。

  2. 如果所有资源均已回滚，请通过 ssh 登录到每个主节点，然后运行命令“sudo /var/vcap/bosh/bin/monit start ncp”。

• 问题 3055618：在一个节点上同时创建多个 Windows Pod 时，某些 Pod 没有网络适配器

  应用 yaml 文件在同一节点上创建多个 Windows Pod 时，某些 Pod 没有网络适配器。

  解决办法：重新启动 Pod。

• 问题 2131494：将 NGINX Kubernetes Ingress 类从 nginx 更改为 nsx 后，该 Ingress 仍起作用

  创建 NGINX Kubernetes Ingress 时，NGINX 会创建流量转发规则。将 Ingress 类更改为其他任何值后，NGINX 不会删除规则并继续应用这些规则，即使在更改类后删除 Kubernetes Ingress 也是如此。这是 NGINX 的一个缺陷。

  解决办法：要删除 NGINX 创建的规则，请在类值为 nginx 时删除 Kubernetes Ingress。然后重新创建 Kubernetes Ingress。

• 问题 2999131：无法从 Pod 访问 ClusterIP 服务

  在大规模 TKGi 环境中，无法从 Pod 访问 ClusterIP 服务。其他相关问题包括：(1) nsx-kube-proxy 停止输出 nsx-kube-proxy 的日志；以及 (2) 不会在节点上创建 OVS 流。

  解决办法：重新启动 nsx-kube-proxy。

• 问题 2984240：对于网络策略的规则，matchExpressions 中的“NotIn”运算符在 namespaceSelector 中无法正常工作

  在为网络策略指定规则时，如果指定 namespaceSelector、matchExpressions 和“NotIn”运算符，则该规则不起作用。NCP 日志包含错误消息“NotIn operator is not supported in NS selectors”。

  解决办法：重写 matchExpressions 以避免使用“NotIn”运算符。

• 问题 2997828：如果 Ingress 具有 255 个以上的规则，则将集群从管理器模式迁移到策略模式将失败

  在策略模式下，NSX 负载均衡器最多可以支持 255 个规则。如果集群的某个 Ingress 资源具有 255 个以上的规则，则将集群从管理器模式迁移到策略模式将失败。

  解决办法：创建 LoadBalancer CRD 以便跨多个 NSX 负载均衡器分发规则。

• 问题 3033821：完成管理器到策略的迁移后，分布式防火墙规则无法正确实施

  完成管理器到策略的迁移后，新创建的与网络策略相关的分布式防火墙 (DFW) 规则的优先级将高于迁移的 DFW 规则。

  解决办法：根据需要使用策略 API 更改 DFW 规则的顺序。

• 对于 ClusterIP 类型的 Kubernetes 服务，不支持发卡模式标记

  NCP 不支持 ClusterIP 类型的 Kubernetes 服务的发卡模式标记。

  解决办法：无

• 问题 2224218：删除服务或应用程序后，需要 2 分钟的时间才会将 SNAT IP 释放回 IP 池

  如果删除服务或应用程序并在 2 分钟内重新创建，将从 IP 池中获取新的 SNAT IP。

  解决办法：删除服务或应用程序后，如果要重用相同的 IP，请等待 2 分钟然后再重新创建。

• 问题 2404302：如果 NSX-T 上存在同一资源类型（例如 HTTP）的多个负载均衡器应用程序配置文件，NCP 将选择其中任意一个配置文件来附加到虚拟服务器。

  如果 NSX-T 上存在多个 HTTP 负载均衡器应用程序配置文件，NCP 将选择其中一个具有相应 x_forwarded_for 配置的配置文件，以附加到 HTTP 和 HTTPS 虚拟服务器。如果在 NSX-T 上存在多个 FastTCP 和 UDP 应用程序配置文件，NCP 将选择其中任意配置文件以分别附加到 TCP 和 UDP 虚拟服务器。负载均衡器应用程序配置文件可能由具有不同设置的不同应用程序所创建。如果 NCP 选择将其中一个负载均衡器应用程序配置文件附加到 NCP 创建的虚拟服务器，则可能会破坏其他应用程序的工作流。

  解决办法：无

• 问题 2518111：NCP 无法删除已从 NSX-T 更新的 NSX-T 资源

  NCP 根据您指定的配置创建 NSX-T 资源。如果通过 NSX Manager 或 NSX-T API 对这些 NSX-T 资源进行任何更新，NCP 可能无法删除这些资源，并在必要时重新创建这些资源。

  解决办法：请勿通过 NSX Manager 或 NSX-T API 更新由 NCP 创建的 NSX-T 资源。

• 问题 2416376：NCP 无法处理绑定到超过 128 个空间的 TAS ASG（应用程序安全组）

  由于 NSX-T 分布式防火墙中的限制，NCP 无法处理绑定到超过 128 个空间的 TAS ASG。

  解决办法：创建多个 ASG 并将每个 ASG 绑定到不超过 128 个空间。

• 问题 2537221：将 NSX-T 升级到 3.0 后，NSX Manager UI 中与容器相关的对象的网络连接状态显示为“未知”

  在 NSX Manager UI 中，“清单”>“容器”选项卡会显示与容器相关的对象及其状态。在 TKGI 环境中，将 NSX-T 升级到 3.0 后，与容器相关的对象的网络连接状态显示为“未知”。之所以会出现此问题，是因为 TKGI 未检测到 NSX-T 的版本更改。如果 NCP 作为 Pod 运行并且活动状态探测处于活动状态，则不会出现此问题。

  解决办法：NSX-T 升级后，逐步重新启动 NCP 实例（一次重新启动不超过 10 个实例），以免 NSX Manager 过载。

• 问题 2552564：在 OpenShift 4.3 环境中，如果发现重叠地址，DNS 转发器可能会停止工作

  在 OpenShift 4.3 环境中，安装集群时要求配置 DNS 服务器。使用 NSX-T 配置 DNS 转发器时，如果 DNS 服务存在 IP 地址重叠，则 DNS 转发器将停止工作，并且集群安装将失败。

  解决办法：配置外部 DNS 服务，删除无法安装的集群并重新创建集群。

• 问题 2597423：将管理器对象导入策略时，回滚将导致某些资源的标记丢失

  将管理器对象导入策略时，如果需要回滚，将不会还原以下对象的标记：

  • Spoofguard 配置文件（共享资源和集群资源的一部分）

  • BgpneighbourConfig（共享资源的一部分）

  • BgpRoutingConfig（共享资源的一部分）

  • StaticRoute BfdPeer（共享资源的一部分）

  解决办法：对于共享资源中的资源，请手动还原这些标记。使用备份和还原功能还原集群资源中的资源。

• 问题 2579968：如果频繁地对 LoadBalancer 类型的 Kubernetes 服务进行更改，不会按预期删除某些虚拟服务器和服务器池

  如果频繁地对 LoadBalancer 类型的 Kubernetes 服务进行更改，则当应该删除某些虚拟服务器和服务器池时，这些虚拟服务器和服务器池可能仍保留在 NSX-T 环境中。

  解决办法：重新启动 NCP。或者，手动移除失效的虚拟服务器及其关联的资源。如果任何 LoadBalancer 类型的 Kubernetes 服务在 external_id 标记中都不具有虚拟服务器的标识符，则该虚拟服务器将失效。

• 在 Kubernetes 安装过程中启用“将日志记录到文件”时，NCP 无法启动

  如果容器主机上的 uid:gid=1000:1000 不具有对日志文件夹的相关权限，则会出现此问题。

  解决办法：执行以下操作之一：

  • 在容器主机上将日志文件夹的模式更改为 777。

  • 向容器主机上的 uid:gid=1000:1000 授予对日志文件夹的“rwx”权限。

  • 禁用“将日志记录到文件”功能。

• 问题 2653214：更改某个节点的 IP 地址后，搜索该节点的分段端口时出错

  更改某个节点的 IP 地址后，如果升级 NCP 或重新启动 NCP Operator pod，则在使用命令“oc describe co nsx-ncp”检查 NCP Operator 状态时，将显示错误消息“搜索节点的分段端口时出错...”(Error while searching the segment port for a node...)

  解决办法：无。不支持在还具有 DHCP 配置的节点接口上添加静态 IP 地址。

• 问题 2672677：在负载过高的 OpenShift 4 环境中，节点可能会变得无响应

  在 OpenShift 4 环境中，如果每个节点具有较高的 pod 密度且要频繁删除和创建 pod，则 RHCOS 节点可能会进入“未就绪”状态。在受影响的节点上运行的 pod（daemonset 成员除外）将被逐出并在环境中的其他节点上重新创建。

  解决办法：重新引导受影响的节点。

• 问题 2707174：删除后使用相同命名空间和名称重新创建的 Pod 没有网络连接

  如果在 NCP 未运行而 nsx-ncp-agents 正在运行时，删除一个 Pod，然后使用相同命名空间和名称重新创建该 Pod，则该 Pod 可能会获取错误的网络配置，从而无法访问网络。

  解决办法：在 NCP 运行时删除 Pod 并重新创建。

• 问题 2745904：“将 IPSet 用于默认运行的 ASG”功能不支持移除或替换现有容器 IP 块

  如果在 NCP Tile 包上启用“将 IPSet 用于默认运行的 ASG”功能，NCP 将为同一 NCP Tile 包上由“容器网络的 IP 块”配置的所有容器 IP 块创建专用 NS 组。此 NS 组将用于为全局运行的 ASG 创建的防火墙规则，以允许所有容器的流量。如果稍后移除或替换现有容器 IP 块，它将在 NS 组中被移除或替换。原始 IP 块中的所有现有容器都将不再与全局运行的 ASG 关联。其流量可能不再进行传输。

  解决办法：仅将新 IP 块附加到“容器网络的 IP 块”。

• 问题 2745907：“monit”命令返回的 nsx-node-agent 状态信息不正确

  在 diego_cell 虚拟机上，当 monit 重新启动 nsx-node-agent 时，如果 nsx-node-agent 完全启动需要 30 秒以上的时间，monit 会将 nsx-node-agent 的状态显示为“执行失败”，即使 nsx-node-agent 稍后完全正常运行，也不会将状态更新为“正在运行”。

  解决办法：无。

• 问题 2735244：由于活动状态探测失败，nsx-node-agent 和 nsx-kube-proxy 崩溃

  nsx-node-agent 和 nsx-kube-proxy 使用 sudo 运行某些命令。如果 /etc/resolv.conf 中具有许多有关 DNS 服务器和搜索域的条目，sudo 可能需要较长时间才能解析主机名。这将导致 sudo 命令长时间阻止 nsx-node-agent 和 nsx-kube-proxy，并且活动状态探测将失败。

  解决办法：执行以下两项操作之一：

  • 将主机名条目添加到 /etc/hosts。例如，如果主机名为“host1”，请添加条目“127.0.0.1 host1”。

  • 为 nsx-node-agent 活动状态探测超时设置更大的值。运行命令“kubectl edit ds nsx-node-agent -n nsx-system”以更新 nsx-node-agent 和 nsx-kube-proxy 容器的超时值。

• 问题 2736412：如果设置 max_allowed_virtual_servers，将忽略 members_per_small_lbs 参数

  如果同时设置 max_allowed_virtual_servers 和 members_per_small_lbs，虚拟服务器可能无法连接到可用的负载均衡器，因为只会考虑 max_allowed_virtual_servers。

  解决办法：放宽缩放限制，而不是启用自动缩放。

• 问题 2740552：使用 api-server 删除静态 Pod 时，nsx-node-agent 不会移除该 Pod 的 OVS 网桥端口，并且 Kubernetes 自动重新创建的静态 Pod 的网络不可用

  Kubernetes 不允许使用 api-server 移除静态 Pod。Kubernetes 会创建静态 Pod 的镜像 Pod，以便 api-server 可以搜索静态 Pod。使用 api-server 删除 Pod 时，只会删除镜像 Pod，并且 NCP 将接收和处理删除请求，以移除为该 Pod 分配的所有 NSX 资源。但是，静态 Pod 仍然存在，并且 nsx-node-agent 不会从 CNI 获取删除请求以移除静态 Pod 的 OVS 网桥端口。

  解决办法：通过删除清单文件来移除静态 Pod，而不是使用 api-server 移除静态 Pod。

• 问题 2795482：节点/Hypervisor 重新引导或执行任何其他操作后，正在运行的 Pod 停留在 ContainerCreating 状态

  如果 wait_for_security_policy_sync 标记为 true，则由于工作节点硬性重新引导、Hypervisor 重新引导或某些其他原因，Pod 在处于“正在运行”状态超过一小时后可能进入 ContainerCreating 状态。Pod 将永久处于“正在创建”状态。

  解决办法：删除并重新创建 Pod。

• 问题 2841030：对于 Kubernetes 1.22，nsx-node-agent 的状态始终为“AppArmor”

  对于 Kubernetes 1.22，在 nsx-node-agent Pod 处于“Ready”状态时，不会将它们的状态从“AppArmor”更新为“Running”。这不会影响 NCP 或 nsx-node-agent 的功能。

  解决办法：重新启动 nsx-node-agent Pod。

• 问题 2824129：在重新启动后，节点的状态 network-unavailable 等于 true 的时间超过 3 分钟

  如果使用 NCP Operator 管理 NCP 的生命周期，在 nsx-node-agent DaemonSet 从非运行状态恢复时，其节点的状态 network-unavailable 将等于 true，直到它已运行 3 分钟。这是预期的行为。

  解决办法：在 nsx-node-agent 重新启动后，至少等待 3 分钟。

• 问题 2868572：在运行 NCP 之前，必须在主机虚拟机上禁用 Open vSwitch (OVS)

  要在主机虚拟机上部署 NCP，您必须先使用以下命令在主机上停止 OVS 相关进程并删除一些文件：

  1. sudo systemctl disable openvswitch-switch.service

  2. sudo systemctl stop openvswitch-switch.service

  3. rm -rf /var/run/openvswitch

  如果您已在主机虚拟机上部署了 NCP，并且 OVS 未正常运行，请执行以下步骤以进行恢复：

  1. 执行上面的 3 个步骤。

  2. 使用“kubectl delete pod $agent-pod -n nsx-system”命令删除有问题的节点上的 nsx-node-agent Pod，以重新启动节点代理 Pod。

  解决办法：请参见上文。

• 问题 2832480：对于 ClusterIP 类型的 Kubernetes 服务，sessionAffinityConfig.clientIP.timeoutSeconds 不能超过 65535

  对于 ClusterIP 类型的 Kubernetes 服务，如果将 sessionAffinityConfig.clientIP.timeoutSeconds 设置为大于 65535 的值，实际值将为 65535。

  解决办法：无

• 问题：2940772：将 NCP 资源从管理器模式迁移到策略模式会导致 NSX-T 3.2.0 出现故障

  NSX-T 3.1.3 和 NSX-T 3.2.1 支持将 NCP 资源从管理器模式迁移到策略模式，但 NSX-T 3.2.0 不支持。

  解决办法：无

• 问题 2934195：分布式防火墙规则不支持某些类型的 NSX 组

  分布式防火墙 (DFW) 规则不支持“仅限 IP 地址”类型的 NSX 组。此外，也不支持包含手动添加的 IP 地址作为成员的“通用”类型 NSX 组。

  解决办法：无

• 问题 2936436：NSX Manager UI 在容器集群页面上不显示 NCP 版本

  NSX Manager UI 可在“清单”选项卡中显示容器集群，但不会显示 NCP 版本。

  解决办法：可通过调用 API /policy/api/v1/fabric/container-clusters 获取 NCP 版本。

• 问题 2939886：无法将对象从管理器模式迁移到策略模式

  在网络策略规范中，如果输出和输入具有相同的选择器，则将对象从管理器模式迁移到策略模式会失败。

  解决办法：无

• 问题：2961789：将管理器对象迁移到策略后，无法删除部分与运行状况检查 Pod 相关的资源

  将管理器对象迁移到策略后，删除运行状况检查 Pod 时，无法删除与该 Pod 相关的分段端口和分布式防火墙规则的目标组。

  解决办法：手动删除这些资源。

• 问题：2966586：将管理器对象迁移到策略后，命名空间创建失败

  如果 IP 块是在管理器模式下创建的，则在将管理器对象迁移到策略后，命名空间创建将失败，因为 NCP 无法从该 IP 块分配子网。

  解决办法：在策略模式下创建新的 IP 块，并将 NCP 配置为使用这些新的 IP 块。

• 问题 2972811：在大型环境中，部分工作节点的 Hyperbus 连接会断开

  在大型环境中，由于 RPC 通道超时，Pod 创建进程可能会停滞 10-15 分钟。可能会出现以下问题：

  • 在 Kubernetes 集群中，部分 Pod 会进入 ContainerCreating 状态并保持 10-15 分钟。

  • 在 cfgAgent 中，隧道会进入 COMMUNICATION_ERROR 状态并保持 10-15 分钟。

  • 在 NSX UI 中，可能会生成警报，指示 Hyperbus 连接已断开。

  解决办法：不需要采取任何措施。此问题会在 10-15 分钟后自动恢复。

• 问题 2960121：对于 LoadBalancer 类型的服务，如果配置不正确，则无法与 Windows 工作节点上的 Pod 连接

  对于 LoadBalancer 类型的服务，如果将 NCP 配置为使用默认 LB 分段子网，则将无法与 Windows 工作节点上的 Pod 连接。默认子网 169.254.128.0/22 属于 IPv4 链路本地空间，不会在 Windows 节点上进行转发。

  解决办法：将 NCP 配置为使用非默认 LB 分段子网。为此，需在 nsx_v3 部分中设置 lb_segment_subnet 参数。请注意，这仅对新创建的 NSX 负载均衡器有效。