This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware NSX Container Plugin 3.2.0.2 | 2021 年 12 月 16 日 | 内部版本 19024342

请定期查看以了解本文档的新增内容和更新。

发行说明内容

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

新增功能

NSX Container Plugin (NCP) 3.2.0.2 具有以下新功能：
  • 支持 NSX-T 3.2.0

弃用声明

在 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
NSX-T 3.1.3、3.2（请参见以下注释）
vSphere 6.7 和 7.0
Kubernetes 1.20、1.21 和 1.22
OpenShift 4 4.7 和 4.8
OpenShift 主机虚拟机操作系统 RHCOS 4.7、4.8
Kubernetes 主机虚拟机操作系统 Ubuntu 18.04、20.04
CentOS 7.8、7.9、8.2
RHEL 8.2、8.4
请参见以下注释。
Tanzu Application Service Ops Manager 2.7 + TAS 2.7 (LTS)（终止支持日期：2022 年 4 月 30 日）
Ops Manager 2.10 + TAS 2.10（终止支持日期：2022 年 3 月 31 日）
Ops Manager 2.10 + TAS 2.11
Ops Manager 2.10 + TAS 2.12（终止支持日期：2023 年 3 月 31 日）
Tanzu Kubernetes Grid Integrated (TKGI) 1.13

注意：

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

要在 RHEL 8.2（内核版本 193）上运行 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。

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

支持升级到此版本：

  • 所有以前的 3.1.x 版本

 

已解决的问题

  • 对于 ClusterIP 类型的 Kubernetes 服务，不支持基于 Client-IP 的会话关联性

    NCP 不支持 ClusterIP 类型的 Kubernetes 服务的基于 Client-IP 的会话关联性。

    解决办法：无

已知问题

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

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

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

  • 对于 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 服务，删除无法安装的集群并重新创建集群。

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

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

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

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

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

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

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

  • 问题 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 的状态显示为“执行失败 (Execution failed)”，即使 nsx-node-agent 稍后完全正常运行，也不会将状态更新为“正在运行 (running)”。

    解决办法：无。

  • 问题 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 容器的超时值。
  • 问题 2744557：Ingress 路径匹配不支持同时包含捕获组 () 和 {0} 的复杂正则表达式模式

    例如，如果正则表达式 (regex) 模式为：/foo/bar/(abc){0,1}，将不会匹配 /foo/bar/。

    解决办法：在创建 Ingress 正则表达式规则时，请勿使用捕获组 () 和 {0}。使用常规模式 EQUALS 以匹配 /foo/bar/。

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

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

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

    解决办法：添加规则网络策略以允许从其他 Pod 到 DNS 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 分钟。

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

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

    解决办法：无

  • 问题 2869247：在 Ubuntu 18.04 主机操作系统上，nsx-ovs 容器不断重新启动

    nsx-ovs 容器不断重新启动，因为其活动状态探测不断失败。/var/log/nsx-ujo/openvswitch/ovs-vswitchd.log 包含的日志指示它不断重新启动。例如：

    2021-10-28T17:38:49.364Z|00004|backtrace(monitor)|WARN|Backtrace using libunwind not supported. 
2021-10-28T17:38:49.364Z|00005|daemon_unix(monitor)|WARN|2 crashes: pid 282 died, killed (Aborted), core dumped, waiting until 10 seconds since last restart 
2021-10-28T17:38:57.364Z|00006|daemon_unix(monitor)|ERR|2 crashes: pid 282 died, killed (Aborted), core dumped, restarting

    该问题是由于 nsx-ovs 容器中安装的上游 OVS 用户空间包与主机上的 OVS 内核模块不兼容造成的。

    解决办法：将主机操作系统升级到 Ubuntu 20.0，或执行以下步骤以使用 NSX 提供的 OVS 内核模块：

    1. 在 nsx-node-agent 的配置映射中将 use_nsx_ovs_kernel_module 设置为 True。
    2. 在 ncp-ubuntu*.yaml 文件的 nsx-ncp-bootstrap DaemonSet 中取消注释卷挂载（搜索“Uncomment these mounts if installing NSX-OVS kernel module”和“Uncomment these volumes if installing NSX-OVS kernel module”）。
    3. 重新应用 ncp-ubuntu*.yaml 文件，然后重新启动 nsx-node-agent Pod。
  • 问题 2867871：如果 Pod 的 Kubernetes 节点名称与主机名不同，则从服务引用的 Pod 中访问 ClusterIP 服务将失败

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

    解决办法：无

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

    解决办法：无

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

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

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

  • 问题：2887484：将 NCP 资源从管理器迁移到策略导致失败

    此版本不支持将 NCP 资源从管理器迁移到策略。

    解决办法：无

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

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

    解决办法：无

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

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

    解决办法：无

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

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

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

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

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

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

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

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

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