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)

要在 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 或更低版本的限制。

解决办法：

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

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

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

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

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

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

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

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

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

解决办法：无

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

解决办法：无。

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

如果同时设置 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。

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

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

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

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

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

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

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

sudo systemctl disable openvswitch-switch.service

sudo systemctl stop openvswitch-switch.service

rm -rf /var/run/openvswitch

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

执行上面的 3 个步骤。

使用“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。

解决办法：无

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

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

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

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

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

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

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