NSX Container Plugin 3.1.2 发行说明

VMware NSX Container Plugin 3.1.2 | 2021 年 4 月 15 日 | 内部版本 17855682

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

发行说明内容

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

新增功能
兼容性要求
已解决的问题
已知问题

新增功能

NSX Container Plugin (NCP) 3.1.2 具有以下新功能：

为实现第 7 层负载均衡器持久性，支持指定 Cookie 名称

弃用声明

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

兼容性要求

产品	版本
Tanzu Application Service (TAS) 的 NCP/NSX-T Tile 包	3.1.2
NSX-T	3.0.3、3.1.0、3.1.1、3.1.2、3.1.3
vSphere	6.7 和 7.0
Kubernetes	1.18、1.19、1.20
OpenShift 3	3.11 注意：OpenShift 3.x 支持将在未来版本中弃用。
OpenShift 4	RHCOS 4.6、4.7
Kubernetes 主机虚拟机操作系统	Ubuntu 18.04、Ubuntu 20.04 CentOS 7.8、CentOS 7.9、CentOS 8.3 RHEL 7.8、RHEL 7.9、RHEL 8.1、RHEL 8.3 请参见以下注释。
OpenShift 3 主机虚拟机操作系统	RHEL 7.7、RHEL 7.8（注意：对 Vanilla Kubernetes 的 RHEL 支持将在未来版本中弃用。）
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7 (LTS) Ops Manager 2.9 + TAS 2.9 Ops Manager 2.10 + TAS 2.10 Ops Manager 2.10 + TAS 2.11
Tanzu Kubernetes Grid Integrated (TKGI)	1.11

注意：

要在 CentOS/RHEL 上安装 nsx-ovs 内核模块，需要使用特定的内核版本。无论 RHEL 版本如何，支持的 RHEL 内核版本均为 1127 和 1160。请注意，RHEL 7.8 对应的默认内核版本为 1127，RHEL 7.9 对应的默认内核版本为 1160。如果运行的是其他内核版本，可以通过将 nsx-node-agent 配置映射中“nsx_node_agent”部分下的“use_nsx_ovs_kernel_module”设置为“False”来跳过 nsx-ovs 内核模块安装。

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

支持升级到此版本：

所有以前的 3.1.x 版本及所有 NCP 3.0.x 版本

已解决的问题

问题 2707883：如果在 nsx-ncp-operator 未运行时删除了与 NCP 相关的 Kubernetes 资源，则 nsx-ncp-operator 不会创建该资源
例如，如果在 nsx-ncp-operator 未运行时删除 nsx-node-agent 或 nsx-ncp-bootstrap DaemonSet 资源，则再次运行 nsx-ncp-operator 时不会重新创建该资源。

已知问题

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

解决办法：要删除 NGINX 创建的规则，请在类值为 nginx 时删除 Kubernetes Ingress。然后重新创建 Kubernetes Ingress。
对于 ClusterIP 类型的 Kubernetes 服务，不支持基于 Client-IP 的会话关联性
NCP 不支持 ClusterIP 类型的 Kubernetes 服务的基于 Client-IP 的会话关联性。

解决办法：无
对于 ClusterIP 类型的 Kubernetes 服务，不支持发卡模式标记
NCP 不支持 ClusterIP 类型的 Kubernetes 服务的发卡模式标记。

解决办法：无
问题 2192489：在 TAS Director 配置中禁用“BOSH DNS 服务器”后，Bosh DNS 服务器 (169.254.0.2) 仍显示在容器的 resolve.conf 文件中。
在运行 TAS 2.2 的 TAS 环境中，在 TAS Director 配置中禁用“BOSH DNS 服务器”后，Bosh DNS 服务器 (169.254.0.2) 仍显示在容器的 resolve.conf 文件中。这将导致需要较长时间来执行具有完全限定域名的 ping 命令。TAS 2.1 不存在此问题。

解决办法：无。这是 TAS 问题。
问题 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 创建的虚拟服务器，则可能会破坏其他应用程序的工作流。

解决办法：无
问题 2397621：OpenShift 3 安装失败
OpenShift 3 安装要求节点的状态为准备就绪，安装 CNI 插件后可能会出现此种状态。在此版本中，没有单独的 CNI 插件文件，导致 OpenShift 安装失败。

解决办法：在开始安装之前，在每个节点上创建 /etc/cni/net.d 目录。
问题 2413383：由于并非所有节点都已准备就绪，因此 OpenShift 3 升级失败
默认情况下，不会在主节点上调度 NCP 引导 pod。因此，主节点状态始终为“未就绪”。

解决办法：分配具有“compute”角色的主节点，以允许 nnsx-ncp-bootstrap 和 nsx-node-agent DaemonSet 创建 pod。在 nsx-ncp-bootstrap 安装 NSX-CNI 后，节点状态将变为“就绪”。
问题 2451442：重复重新启动 NCP 并重新创建命名空间后，NCP 可能无法向容器分配 IP 地址
如果在重新启动 NCP 时重复删除并重新创建相同的命名空间，则 NCP 可能无法向该命名空间中的容器分配 IP 地址。

解决办法：删除与该命名空间关联的所有失效的 NSX 资源（逻辑路由器、逻辑交换机和逻辑端口），然后重新创建这些资源。
问题 2460219：如果没有默认服务器池，则 HTTP 重定向无法正常工作
如果 HTTP 虚拟服务器未绑定到服务器池，则 HTTP 重定向将失败。NSX-T 2.5.0 和更低版本中存在此问题。

解决办法：创建默认服务器池或升级到 NSX-T 2.5.1。
问题 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 资源。
问题 2524778：删除 NCP 主节点后，NSX Manager 会将 NCP 显示为关闭或不正常
例如，删除 NCP 主节点后，在成功切换到备份节点后，NCP 的运行状况仍会显示为关闭（应为开启）。

解决办法：使用 Manager API DELETE/api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status 手动清除失效状态。
问题 2517201：无法在 ESXi 主机上创建 Pod
从 vSphere 集群移除 ESXi 主机并将其重新添加到集群后，在主机上创建 Pod 会失败。

解决办法：重新引导 NCP。
问题 2416376：NCP 无法处理绑定到超过 128 个空间的 TAS ASG（应用程序安全组）
由于 NSX-T 分布式防火墙中的限制，NCP 无法处理绑定到超过 128 个空间的 TAS ASG。

解决办法：创建多个 ASG 并将每个 ASG 绑定到不超过 128 个空间。
问题 2534726：如果通过 NSX-T Tile 包升级到 NCP 3.0.1 失败，则使用 BOSH 命令行重新升级会导致性能问题
在 OpsMgr 上通过 NSX-T Tile 包升级到 NCP 3.0.1 时，升级过程中会将 NSX Manager 中 NCP 使用的 HA 交换配置文件标记为非活动状态。在重新启动 NCP 时，将删除这些交换配置文件。如果升级失败，并且您使用 BOSH 命令（如“bosh deploy -d <deployment-id> -n <deployment>.yml”）重新升级，则不会删除 HA 交换配置文件。NCP 仍然会运行，但性能会降级。

解决办法：始终通过 OpsMgr 升级 NCP，而不要通过 BOSH 命令行升级。
问题 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 过载。
问题 2550474：在 OpenShift 环境中，将 HTTPS 路由更改为 HTTP 路由可能会导致 HTTP 路由无法按预期工作
如果您编辑 HTTPS 路由并删除与 TLS 相关的数据以将该路由转换为 HTTP 路由，则 HTTP 路由可能无法按预期工作。

解决办法：删除 HTTPS 路由并创建新的 HTTP 路由。
问题 2552573：在 OpenShift 4.3 环境中，如果 DHCP 是使用策略 UI 配置的，则集群安装可能会失败
在 OpenShift 4.3 环境中，安装集群时要求 DHCP 服务器能够提供 IP 地址和 DNS 信息。如果您使用在 NSX-T 中通过策略 UI 配置的 DHCP 服务器，则集群安装可能会失败。

解决办法：使用管理器 UI 配置 DHCP 服务器，删除无法安装的集群并重新创建集群。
问题 2552564：在 OpenShift 4.3 环境中，如果发现重叠地址，DNS 转发器可能会停止工作
在 OpenShift 4.3 环境中，安装集群时要求配置 DNS 服务器。使用 NSX-T 配置 DNS 转发器时，如果 DNS 服务存在 IP 地址重叠，则 DNS 转发器将停止工作，并且集群安装将失败。

解决办法：配置外部 DNS 服务，删除无法安装的集群并重新创建集群。
问题 2483242：来自容器的 IPv6 流量被 NSX-T SpoofGuard 阻止
启用 SpooGuard 后，IPv6 链路本地地址不会自动列入白名单。

解决办法：通过在 NCP 配置中设置 nsx_v3.enable_spoofguard = False 来禁用 SpoofGuard。
问题 2552609 - X-Forwarded-For (XFF) 和 X-Forwarded-Port 数据不正确
对于 HTTPS 输入规则 (Kubernetes) 或 HTTPS 路由 (OpenShift)，如果为 XFF 配置 INSERT 或 REPLACE，则可能会在 XFF 标头中看到错误的 X-Forwarded-For 值和 X-Forwarded-Port 值。

解决办法：无。
问题 2555336：由于在管理器模式下创建的逻辑端口发生重复，Pod 流量无法正常运行
如果多个集群中存在大量 Pod，则很可能会出现此问题。创建 Pod 时，流向 Pod 的流量无法正常运行。NSX-T 显示为同一个容器创建了多个逻辑端口。在 NCP 日志中，只能找到其中一个逻辑端口的 ID。

解决办法：删除 Pod 并重新创建。当重新启动 NCP 时，将移除 NSX-T 上的失效端口。
问题 2554357：负载均衡器自动缩放不适用于 IPv6
在 IPv6 环境中，当达到现有负载均衡器规模时，类型为 LoadBalancer 的 Kubernetes 服务将不会处于活动状态。

解决办法：在 /var/vcap/jobs/ncp/config/ncp.ini（对于 TKGI 部署）和 nsx-ncp-configmap（对于其他部署）中设置 nsx_v3.lb_segment_subnet = FE80::/10。然后重新启动 NCP。
问题 2597423：将管理器对象导入策略时，回滚将导致某些资源的标记丢失
将管理器对象导入策略时，如果需要回滚，将不会还原以下对象的标记：
- Spoofguard 配置文件（共享资源和集群资源的一部分）
- BgpneighbourConfig（共享资源的一部分）
- BgpRoutingConfig（共享资源的一部分）
- StaticRoute BfdPeer（共享资源的一部分）
解决办法：对于共享资源中的资源，请手动还原这些标记。使用备份和还原功能还原集群资源中的资源。
问题 2579968：如果频繁地对 LoadBalancer 类型的 Kubernetes 服务进行更改，不会按预期删除某些虚拟服务器和服务器池
如果频繁地对 LoadBalancer 类型的 Kubernetes 服务进行更改，则当应该删除某些虚拟服务器和服务器池时，这些虚拟服务器和服务器池可能仍保留在 NSX-T 环境中。

解决办法：重新启动 NCP。或者，手动移除失效的虚拟服务器及其关联的资源。如果任何 LoadBalancer 类型的 Kubernetes 服务在 external_id 标记中都不具有虚拟服务器的标识符，则该虚拟服务器将失效。
问题 2536383：将 NSX-T 升级到 3.0 或更高版本后，NSX-T UI 无法正确显示 NCP 相关信息
将 NSX-T 升级到 3.0 或更高版本后，NSX-T UI 中的清单 > 容器选项卡会将容器相关对象的网络连接状态显示为“未知”。此外，NCP 集群也不会显示在系统 > Fabric > 节点 > NCP 集群选项卡中。在 TKGI 环境中通常会出现此问题。

解决办法：升级 NSX-T 后，逐步重新启动 NCP 实例（一次重新启动不超过 10 个实例）。
问题 2622099：LoadBalancer 类型的 Kubernetes 服务初始化失败，并显示错误代码 NCP00113 和错误消息“该对象已被他人修改 (The object was modified by somebody else)”
在使用策略 API 进行的单层部署中，如果您使用现有的 Tier-1 网关作为顶层网关，并且该网关的池分配大小为“路由”，则 LoadBalancer 类型的 Kubernetes 服务可能无法初始化，并显示错误代码 NCP00113 和错误消息“该对象已被他人修改。请重试 (The object was modified by somebody else. Please retry)”。

解决办法：出现问题时，请等待 5 分钟。然后重新启动 NCP。该问题将会得到解决。
问题 2633679：NCP Operator 不支持连接到使用 API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> 创建的 Tier-1 分段的 OpenShift 节点
NCP Operator 不支持连接到使用 API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> 创建的 Tier-1 分段的 OpenShift 节点。

解决办法：使用 API /policy/api/v1/infra/segments/<segment-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 成员除外）将被逐出并在环境中的其他节点上重新创建。

解决办法：重新引导受影响的节点。
问题 2706551：OpenShift 的全堆栈自动安装（称为 IPI）失败，因为节点在安装过程中未就绪。
在主节点上开始运行 Kubernetes API 服务器之前，保持活动状态的 Pod 会将 Kubernetes VIP 添加到主节点上的 ovs_bridge。因此，对 Kubernetes API 服务器的所有请求均将失败，从而导致安装无法完成。

解决办法：无
问题 2697547：RHEL/CentOS/RHCOS 节点不支持 HostPort
您可以通过将 nsx-node-agent ConfigMap 中的“enable_hostport_snat”设置为 True，在 Ubuntu 节点上的本机 Kubernetes 和 TKGI 上指定 hostPorts。但是，RHEL/CentOS/RHCOS 节点不支持 hostPort，因此“enable_hostport_snat”参数将被忽略。

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

解决办法：在 NCP 运行时删除 Pod 并重新创建。
问题 2713782：NSX API 调用失败，并出现错误“SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC”
有时，在 NCP 启动时，由于负载均衡器存在重复的负载均衡服务器或 Tier-1 逻辑路由器，NCP 可能会重新启动或无法初始化负载均衡器服务。此外，在 NCP 运行时，可能会在短时间内（少于 1 秒）报告 NSX 端点处于已关闭状态。如果负载均衡器无法初始化，NCP 日志将显示消息“Failed to initialize loadbalancer services”。

只有当 NCP 在多个 NSX Manager 实例之间执行客户端负载均衡时，才会出现此行为。如果在 ncp.ini 中配置了单个 API 端点，则不会出现此行为。

解决办法：增大 nsx_v3.conn_idle_timeout 参数的值。请注意，在使用客户端负载均衡时，这样做可能会导致在端点暂时断开连接后，需要等待较长的时间才会被重新检测为可用之。
问题 2745904：“将 IPSet 用于默认运行的 ASG”功能不支持移除或替换现有容器 IP 块
如果在 NCP Tile 包上启用“将 IPSet 用于默认运行的 ASG”功能，NCP 将为同一 NCP Tile 包上由“容器网络的 IP 块”配置的所有容器 IP 块创建专用 NS 组。此 NS 组将用于为全局运行的 ASG 创建的防火墙规则，以允许所有容器的流量。如果稍后移除或替换现有容器 IP 块，它将在 NS 组中被移除或替换。原始 IP 块中的所有现有容器都将不再与全局运行的 ASG 关联。其流量可能不再进行传输。

解决办法：仅将新 IP 块附加到“容器网络的 IP 块”。
问题 2744480：KVM 上不支持 Kubernetes 服务自我访问
如果 Kubernetes Pod 尝试通过该 Pod 作为其端点的 Kubernetes 服务访问自身，则 KVM 主机上将丢弃回复数据包。

解决办法：无
问题 2744361：当 nsx-node-agent Pod 终止时，配置了静态 IP 地址的 OpenShift 中的工作负载虚拟机可能会断开连接
有时，当 nsx-node-agent Pod 终止时，配置了静态 IP 地址的 OpenShift 中的工作负载虚拟机会断开连接。

解决办法：重新引导虚拟机。
问题 2746362：nsx-kube-proxy 无法从 Kubernetes API 服务器接收 Kubernetes 服务事件
有时，在 OpenShift 集群中，nsx-kube-proxy 无法从 Kubernetes API 服务器接收任何 Kubernetes 服务事件。命令“nsxcli -c get kube-proxy-watchers”输出“监视程序线程状态: 启动 (Watcher thread status: Up)”，但“已处理的事件数 (Number of events processed)”为 0，这意味着 nsx-kube-proxy 未从 API 服务器接收任何事件。

解决办法：重新启动 nsx-kube-proxy Pod。
问题 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/。
问题 2751080：升级 KVM 主机后，容器主机无法运行 Kubernetes Pod
升级 KVM 主机后，在升级的主机上部署的容器主机将无法运行 Kubernetes Pod。Pod 将保持处于“容器正在创建”状态。如果部署了 NCP Operator，节点的状态可能会变为 NotReady，并且 networkUnavailable 节点条件将为 True。此问题仅在 RHEL 中出现，而未在 Ubuntu 中出现。

解决办法：重新启动 KVM Hypervisor 上的 nsx-opsagent。
问题 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。
问题 2795268：nsx-node-agent 和 hyperbus 之间的连接发生转换，并且 Kubernetes Pod 停留在“正在创建”状态
在大型环境中，nsx-node-agent 可能无法连接到 Kubernetes API 服务器以获取 Pod 信息。由于正在传输的信息量庞大，无法将 KeepAlive 消息发送到 hyperbus，并且 hyperbus 将关闭连接。

解决办法：重新启动 nsx-node-agent。确保 Kubernetes API 服务器可用，并且用于连接到 API 服务器的证书正确无误。
问题 2795482：节点/Hypervisor 重新引导或执行任何其他操作后，正在运行的 Pod 停留在 ContainerCreating 状态
如果 wait_for_security_policy_sync 标记为 true，则由于工作节点硬性重新引导、Hypervisor 重新引导或某些其他原因，Pod 在处于“正在运行”状态超过一小时后可能进入 ContainerCreating 状态。Pod 将永久处于“正在创建”状态。

解决办法：删除并重新创建 Pod。
问题 2871314：在将 TKGI 从 1.10.x 升级到 1.11.x（1.11.6 之前）后，将删除 NSX 负载均衡器的 Ingress 证书。
从 NCP 3.1.1 开始，证书是使用修订号跟踪的。这会在将 TKGI 1.10.x 升级到 TKGI 1.11.x（1.11.6 之前）时出现问题，从而导致删除而不是重新导入 NSX 负载均衡器的 Ingress 证书。

解决办法：执行以下操作之一：
1. 重新启动 NCP。或者，
2. 删除 Kubernetes 环境中的密钥并重新创建相同的密钥。或者，
3. 升级到 TKGI 1.11.6 或更高版本。
问题 2871321：在将 TKGI 从 1.10.x 升级到 1.11.x（1.11.6 之前）后，如果 CRD LoadBalancer 使用 L7 Cookie 持久性，它将丢失 IP 地址。
该问题是由 NCP 3.1.1 中的一个新功能引起的，该功能支持在 NSX 负载均衡器中更新 Cookie 名称。

解决办法：执行以下操作之一：
1. 使用源 IP 持久性而不是 Cookie 持久性。
2. 升级到 TKGI 1.11.6 或更高版本。
问题 3033821：完成管理器到策略的迁移后，分布式防火墙规则无法正确实施
完成管理器到策略的迁移后，新创建的与网络策略相关的分布式防火墙 (DFW) 规则的优先级将高于迁移的 DFW 规则。

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