VMware NSX Container Plugin 4.1.2 发行说明

VMware NSX Container Plugin 4.1.2 | 2023 年 10 月 19 日 | 内部版本 22596735 请查看发行说明以了解新增内容及更新。

新增功能

• 支持在管理器模式下的 TAS 中创建新集群。请注意，下一版本将不支持此功能。

• 支持将 TAS Foundation 从管理器模式迁移到策略模式。

• 用于为 NCP 配置步骤生成调试报告的新操作手册。

弃用声明

• 对第三方 Ingress 控制器的 NAT 支持已弃用，并且将在未来版本中移除。

  此功能由 k8s.ingress_mode 参数控制，并使用 ncp/ingress_controller 注释在 Ingress 控制器 Pod 上启用。在此功能中，将使用 DNAT 规则公开 Ingress 控制器 Pod。公开这些 Pod 的首选方法是使用 LoadBalancer 类型的服务。

• NSX OVS 内核模块已弃用，并且将在下一版本中移除。

• Multus 不再受支持。将在下一版本中移除。

兼容性要求

产品	版本
Tanzu Application Service (TAS) 的 NCP/NSX Tile 包	4.1.2
NSX	3.2.3、4.0.1、4.1.1、4.1.2
Kubernetes	1.25、1.26、1.27
OpenShift 4	4.11、4.12
Kubernetes 主机虚拟机操作系统	Ubuntu 20.04 具有内核 5.15 的 Ubuntu 22.04（支持 nsx-ovs 内核模块和上游 OVS 内核模块） 内核版本高于 5.15 的 Ubuntu 22.04（仅支持上游 OVS 内核模块） RHEL 8.6、8.8、9.2 请参见以下注释。
Tanzu Application Service (TAS)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0 Ops Manager 2.10 + TAS 5.0 Ops Manager 3.0 + TAS 5.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.18.0

注意：

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

支持升级到此版本：

• 4.1.0、4.1.1 以及所有 4.0.x 版本。

限制

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

• 透明模式负载均衡器

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

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

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

• 管理器到策略迁移

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

• 实施在输入/输出规则中使用多选择器条件的网络策略时，在实际组成员计算中存在性能明显下降的风险，并会对网络流量产生影响。为了解决此限制，我们提供了一个新的配置选项 enable_mixed_expression_groups，此选项会影响在策略模式下使用多选择器的 Kubernetes 网络策略。管理器模式下的集群不受影响。此选项的默认值为“False”。我们建议在集群中使用以下值：

  • TKGi

    • 新集群，策略模式：False

    • 现有集群（基于策略）：True

    • 在管理器到策略的迁移后：True

  • OC：设置为 True 以确保 Kubernetes 网络策略遵从性

  • DIY Kubernetes

    • 新集群（基于策略）：False

    • 现有集群（基于策略）：True

    • 在管理器到策略的迁移后：True

  当 enable_mixed_expression_groups 设置为 True 时，此限制适用。这会影响使用 NCP 版本 3.2.0 及更高版本和 NSX-T 版本 3.2.0 及更高版本的安装。网络策略影响的命名空间数量不受限制。如果将此选项设置为 True 并重新启动 NCP，NCP 将再次同步所有网络策略以实现此行为。

  当 enable_mixed_expression_groups 设置为 False 时，将通过动态 NSX 组来实施在输入/输出规则中使用多选择器条件的网络策略，这些组在计算实际成员时不受任何性能降级的影响。但是，根据网络策略中定义的其他条件，最多只能对 5 个命名空间实施这些规则。如果网络策略在任何时间点影响 5 个以上命名空间，则将使用“ncp/error: NETWORK_POLICY_VALIDATION_FAILED”进行注释，并且不会在 NSX 中强制执行。请注意，在创建满足多选择器条件的新命名空间或更新现有命名空间时，可能会发生这种情况。如果将此选项设置为 False 并重新启动 NCP，NCP 将再次同步所有网络策略以实现此行为。

已解决的问题

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

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

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

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

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

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

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

  解决办法：无

已知问题

• 问题 3293981：在短时间内使用 defaultBackend 创建两个 Ingress 会导致 DEFAULT_BACKEND_IN_USE 错误

  如果在短时间内使用指定的 defaultBackend 创建了两个 Ingress，则这两个 Ingress 都可能会收到 DEFAULT_BACKEND_IN_USE 错误。

  解决办法：一次创建一个 Ingress。要解决 DEFAULT_BACKEND_IN_USE 错误，请从两个 Ingress 中删除 defaultBackend，然后一次将其重新添加回到一个 Ingress。

• 问题 3292003：在 OCP 环境中，应用具有 NoExecute 效果的污点后，节点关闭

  在 OCP 环境中，如果移除节点代理 DaemonSet 的 {"effect":"NoExecute","operator":"Exists"} 宽容度，并在节点上添加 NoExecute 效果污点（例如 test=abc:NoExecute），节点可能会关闭。在此场景中，节点代理 Pod 将被从具有污点的节点中逐出。在节点代理 Pod 逐出期间，节点可能会断开连接，因为节点代理 Pod 未正常退出，并且未正确地将节点上行链路接口从 br-int 配置回到 ens192。

  解决办法：从 vCenter Server 重新引导节点虚拟机。

• 问题 3293969：在 OCP 环境中，在 NCP 升级期间，节点状态变为未就绪

  在 OCP 环境中，在 NCP 升级期间，将重新启动节点代理。节点可能会断开连接，因为节点代理 Pod 未正常退出，并且未正确地将节点上行链路接口从 br-int 配置回到 ens192。节点状态将变为 NotReady。

  解决办法：从 vCenter Server 重新引导节点虚拟机。

• 问题 3252571：如果 NSX Manager 变得不可用，则从管理器到策略的迁移永远无法完成

  如果在从管理器到策略的迁移期间 NSX Manager 变得不可用，则迁移可能永远无法完成。此问题的一个表现是日志中将没有关于迁移的更新。

  解决办法：重新建立与 NSX Manager 的连接，然后重新启动迁移。

• 问题 3248662：工作节点无法访问服务。未在该节点上创建服务的 OVS 流。

  nsx-kube-proxy 日志显示错误消息“greenlet.error: cannot switch to a different thread.”

  解决办法：在节点上重新启动 nsx-kube-proxy。

• 问题 3241693：当创建的路由数超出某些限制时，L7 路由需要 10 分钟以上才能开始使用

  在 OpenShift 环境中，您可以在 ConfigMap 中将标记“relax_scale_validation”设置为 True，并将“l4_lb_auto_scaling”设置为 False，以部署 1000 个以上路由。但是，当创建的路由数超出限制时，路由需要 10 分钟以上才能开始使用。限制为 500 个 HTTPS 路由和 2000 个 HTTP 路由。

  解决办法：不要超出路由数限制。如果创建 500 个 HTTPS 路由和 2000 个 HTTP 路由，则必须使用大型 Edge 虚拟机部署这些路由。

• 问题 3158230：在 Ubuntu 20.04 上加载 AppArmor 配置文件时，nsx-ncp-bootstrap 容器无法初始化

  由于主机操作系统和容器映像上的 AppArmor 软件包版本不同，nsx-ncp-bootstrap DaemonSet 中的 nsx-ncp-bootstrap 容器无法初始化。容器日志中显示如下消息：“Failed to load policy-features from '/etc/apparmor.d/abi/2.13': No such file or directory”。

  解决办法：将 AppArmor 更新到版本 2.13.3-7ubuntu5.2，或主机操作系统上 focal-updates 中的最新可用版本。

• 问题 3179549：不支持更改现有命名空间的 NAT 模式

  对于已具有 Pod 的命名空间，如果将 NAT 模式从 SNAT 更改为 NO_SNAT，Pod 仍将使用从在 container_ip_blocks 中指定的 IP 块分配的 IP 地址。如果命名空间中的分段子网仍有可用的 IP 地址，则新创建的 Pod 仍将使用现有分段子网的 IP 地址。对于新创建的分段，将从 no_snat_ip_block 分配子网。但在命名空间上，将删除 SNAT 规则。

  解决办法：无。

• 问题 3218243：将 NCP 升级到版本 4.1.1 后或在用户创建/更新命名空间时，将移除在 NSX 中为使用多选择器条件的 Kubernetes 网络策略所创建的安全策略

  验证“enable_mixed_expression_groups”选项是否已在 NCP 中设置为 False（默认值为 False）。如果是，则网络策略会导致在 NSX 上创建 5 个以上组条件，但不支持这种情况。

  解决办法：在 NCP 配置映射中将 enable_mixed_expression_groups 设置为 True，然后重新启动 NCP。请注意，在这种情况下，实际组成员计算存在性能显著下降的风险，并会影响网络流量。

• 问题 3235394：具有命名空间设置的基准策略在 TKGI 设置中不起作用

  在 TGKI 环境中，如果将 baseline_policy_type 设置为 allow_namespace 或 allow_namespace_strict，NCP 将创建一个明确的基准策略，以仅允许同一命名空间中的 Pod 相互通信并拒绝来自其他命名空间的输入流量。此基准策略还将阻止系统命名空间（如 kube-system）访问其他命名空间中的 Pod。

  解决办法：无。在 TKGI 设置中，NCP 不支持此功能。

• 问题 3179960：应用程序实例在执行 vMotion 后无法访问，并且具有与另一个应用程序实例相同的 IP 地址

  批量执行 vMotion 时（例如，在 NSX 主机升级期间），主机逐个进入维护模式，且 Diego 单元在主机之间迁移。执行 vMotion 后，某些分段端口可能会缺失，某些应用程序实例可能无法访问，并且两个应用程序实例可能具有相同的 IP 地址。此问题更有可能在 TAS 2.13.18 中发生。

  解决办法：重新创建受此问题影响的应用程序实例。

• 问题 3108579：删除 LB CRD 并使用相同密钥立即重新创建将失败

  在管理器模式下，如果在 LB CRD 上删除 Ingress，再删除 LB CRD，然后立即使用相同证书重新创建 Ingress 和 LB CRD，您可能会看到“尝试导入的证书已导入”(Attempted to import a certificate which has been imported) 错误。这是由于计时问题所致，因为必须等到删除 Ingress 完成后才能删除 LB CRD。

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

  - 运行以下命令，等待删除 Ingress 完成，然后删除 LB CRD。

  • kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep ‘name: <Ingress name>’

  - 等待至少 2 分钟，然后再重新创建 Ingress 和 LB CRD。

• 问题 3221191：当集群具有超过 4000 个 Pod 时，域组创建将失败

  如果 NCP 选项“k8s.baseline_policy_type”设置为 allow_cluster、allow_namespace 或 allow_namespace_strict，并且集群具有超过 4000 个 Pod，则将无法创建包含所有 Pod IP 地址的域组（具有类似于 dg-k8sclustername 的名称）。这是由 NSX 存在的限制所致。

  解决办法：请不要设置“k8s.baseline_policy_type”选项，或者确保集群中的 Pod 少于 4000 个。

• 问题 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”运算符。

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

• 在 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 并重新创建。

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

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

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

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

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

  解决办法：无

• 问题 3066449：在 use_ip_blocks_in_order 设置为 True 时，并非始终从第一个可用的 IP 块中分配命名空间子网

  在创建多个命名空间并将 use_ip_blocks_in_order 设置为 True 时，有时不会从第一个可用的 IP 块中分配第一个命名空间的子网。例如，假设 container_ip_blocks = '172.52.0.0/28,172.53.0.0/28'，子网前缀长度为 29，并且已分配子网 172.52.0.0/29。如果您创建 2 个命名空间（ns-1 和 ns-2），则子网分配可能是 (1) ns-1：172.52.0.8/29，ns-2：172.53.0.0/29，或者 (2) ns-1：172.53.0.0/29，ns-2：172.52.0.8/29。

  use_ip_blocks_in_order 参数仅确保按照在 container_ip_blocks 参数中出现的顺序使用不同的 IP 块。在同时创建多个命名空间时，任何命名空间可以在另一个命名空间之前通过 API 调用请求子网。因此，无法保证从特定 IP 块中为特定命名空间分配子网。

  解决办法：单独创建命名空间，即，创建第一个命名空间，确保已分配其子网，然后创建下一个命名空间。