VMware NSX Container Plugin 3.2.1.1 发行说明

VMware NSX Container Plugin 3.2.1.1 | 2022 年 5 月 17 日 | 内部版本 19750154 请查看发行说明以了解新增内容及更新。

新增功能

• 支持部署具有多个 vNIC 的 OCP 工作节点

  支持部署具有多个 vNIC 的 OCP 工作节点，并假设将第一个 vNIC 用于容器网络连接。

• 支持“natfirewallmatch”选项

  “natfirewallmatch”选项通过为 Kubernetes 命名空间创建的 NAT 规则，来指定 NSX-T 网关防火墙的行为方式。此选项仅适用于新创建的 Kubernetes 命名空间，而不适用于现有命名空间。

弃用声明

在 NCP 4.0 中，将弃用注释 ncp/whitelist-source-range。从 NCP 3.1.1 开始，可以改用注释“ncp/allowed-source-range”。

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

兼容性要求

产品	版本
Tanzu Application Service (TAS) 的 NCP/NSX-T Tile 包	3.2.1
NSX-T	3.1.3、3.2、3.2.1（请参见以下注释）
vSphere	6.7 和 7.0
Kubernetes	1.21、1.22、1.23
OpenShift 4	4.7、4.8、4.9
OpenShift 主机虚拟机操作系统	RHCOS 4.7、4.8
Kubernetes 主机虚拟机操作系统	Ubuntu 18.04、20.04 CentOS 8.2 RHEL 8.4、8.5 请参见以下注释。
Tanzu Application Service	Ops Manager 2.10 + TAS 2.11 Ops Manager 2.10 + TAS 2.12（终止支持日期：2023 年 3 月 31 日）
Tanzu Kubernetes Grid Integrated (TKGI)	1.13.6、1.14

注意：

要在 CentOS/RHEL 上安装 nsx-ovs 内核模块，需要使用特定的内核版本。支持的 CentOS/RHEL 内核版本为 193、305 和 348，而与 CentOS/RHEL 版本无关。请注意，RHEL 8.2 对应的默认内核版本为 193、RHEL 8.4 对应的默认内核版本为 305、RHEL 8.5 对应的默认内核版本为 348。如果运行不同的内核版本，您可以 (1) 将内核版本修改为支持的版本。在修改内核版本并随后重新启动虚拟机时，请确保在上行链路接口（由 ovs_uplink_port 指定）上保留了 IP 路由和静态路由，以保证到 Kubernetes API 服务器的连接不会中断。或者 (2) 在 nsx-node-agent 配置映射中的“nsx_node_agent”部分下面，将“use_nsx_ovs_kernel_module”设置为“False”以跳过 nsx-ovs 内核模块安装。

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

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

NCP 3.2.1.0 随附的 TKGI 1.14.0，不支持 NSX-T 3.2.1。

TKGI 1.13.x 和 TKGI 1.14.x 与 NSX-T 3.2.0.x 不兼容。

支持升级到此版本：

• 所有 3.1.x 版本

• 所有以前的 3.2.x 版本

限制

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

已解决的问题

• 问题 3042916：nsx-kube-proxy 在启动后失败，并显示错误“in_port 的端口无效或未知”(invalid or unknown port for in_port)

  在极少数情况下，nsx-kube-proxy 会在启动后不久失败，因为此时 OVS 上行链路“ofport”为空。日志包含错误消息“RuntimeError: Fatal error executing xxx: (): invalid or unknown port for in_port.”

  解决办法：重新引导 nsx-kube-proxy。

• 问题 2863155：在大型环境中，无法从 Pod 访问某些集群 IP 服务

  在大型环境中，较大的日志大小可能会导致 nsx-kube-proxy 出现问题。因此，将无法从 Pod 访问某些集群 IP 服务，并且 nsx-kube-proxy 无法在 nsxcli 中报告其状态。

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

• 问题 2944368：指定了“主机名”的 Ingress 规则同时匹配不带后缀和带后缀的主机

  例如，将主机指定为“test.co”的规则将同时匹配“test.co”和“test.co.uk”。

  解决办法：无

• 问题 2882699：在 IPv6 环境中，将 baseline_policy_type 设置为 allow_namespace_strict 导致通信失败

  在 IPv6 环境中，在将 baseline_policy_type 设置为 allow_namespace_strict 时，Pod 无法访问 Kubernetes 节点。

  解决办法：添加一个优先级高于基准规则的分布式防火墙规则，以允许从 Pod 到 Kubernetes 节点的流量。

• 问题 2867871：如果 Pod 的 Kubernetes 节点名称与主机名不同，则从服务引用的 Pod 中访问 ClusterIP 服务将失败

  目前，只有在 Kubernetes 节点名称与主机名相同时，NCP 才支持 Pod 对 ClusterIP 服务的自访问。这是因为，只有在主机名与节点名称相同时，nsx-kube-proxy 才会添加自访问流。

  解决办法：无

• 问题 2555336：由于在管理器模式下创建的逻辑端口发生重复，Pod 流量无法正常运行

  如果多个集群中存在大量 Pod，则很可能会出现此问题。创建 Pod 时，流向 Pod 的流量无法正常运行。NSX-T 显示为同一个容器创建了多个逻辑端口。在 NCP 日志中，只能找到其中一个逻辑端口的 ID。

  解决办法：删除 Pod 并重新创建。当重新启动 NCP 时，将移除 NSX-T 上的失效端口。

• 问题 2664457：在 OpenShift 中使用 DHCP 时，nsx-node-agent 启动或重新启动后，可能会暂时断开连接

  nsx-ovs 会创建并激活 5 个临时的连接配置文件以配置 ovs_bridge，但 NetworkManager 可能暂时无法激活这些配置文件。因此，ovs_uplink_port 和/或 ovs_bridge 上的虚拟机没有任何 IP（连接）。

  解决办法：重新启动虚拟机或等待 NetworkManager 成功激活所有这些配置文件。

已知问题

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 问题 2923436：过长的 Kubernetes 资源名称会导致失败

  如果 Kubernetes 资源名称过长，则无法创建相应的 NSX 资源，因为 NSX 资源名称会超出 NSX 中显示名称的限制。日志将显示一条错误消息，例如“Field level validation errors: {display_name ipp-k8scl-two-aaaaaa... has exceeded its maximum valid length 255 characters}”。NSX 具有以下限制：

  • 分段显示名称：80 个字符

  • 组名称 + 域名：245 个字符

  • 其他 NSX 资源显示名称：255 个字符

  解决办法：缩短 Kubernetes 资源名称。

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

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

  解决办法：无

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

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

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

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

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

  解决办法：无

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

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

  解决办法：无

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

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

  解决办法：无

• 问题 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。

  解决办法：请参见上文。

• 问题 2867361：在 NCP 清理后，未移除 nsx-node-agent 和 hyperbus 警报

  如果由于某种原因（例如，停止所有 NSX 节点代理）出现 nsx-node-agent 和 hyperbus 警报，并且您停止 NCP 并运行清理脚本，将在清理后保留这些警报。

  解决办法：无

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

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

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

• 问题 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。

• 问题 2860091：如果 baseline_policy_type 设置为 allow_namespace，DNS 流量将失败

  在 OpenShift 或 Kubernetes 环境中，如果将 baseline_policy_type 设置为 allow_namespace，它将阻止其他命名空间中的 Pod（hostNetwork：False）访问 DNS 服务。

  解决办法：添加规则网络策略以允许从其他 Pod 到 DNS Pod 的流量。

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

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

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

• 问题 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。

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

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

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

• 问题 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 容器的超时值。

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

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

  解决办法：无。

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

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

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

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

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

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

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

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

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

• 问题 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 地址。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 问题 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 过载。

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

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

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

• 问题 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 资源。

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

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

  解决办法：无

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

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

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

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

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

  解决办法：无

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

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

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