VMware NSX Container Plugin 3.1.1 | 2021 年 2 月 4 日 | 内部版本 17559186

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

发行说明内容

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

新增功能

NSX Container Plugin (NCP) 3.1.1 具有以下新功能:
  • 通过 Operator 简化了 Kubernetes 集群中的 NCP 部署和管理
  • 当 nsx-node-agent 在节点上不可用时设置节点的 NetworkUnavaialble 条件(通过 Operator)
  • 启用 SNAT 规则的日志记录
  • OCP4 的路由器分片
  • Kubernetes 集群支持到 Tier-1 的多播
  • 在 Ingress 虚拟服务器上启用访问日志
  • 在负载均衡器上启用 TCP 多路复用
  • 支持通过 hostPort 访问 Pod

弃用声明

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

兼容性要求

产品 版本
Tanzu 应用程序服务 (PCF) 的 NCP/NSX-T Tile 包 3.1.1
NSX-T 3.0.2、3.1.0、3.1.1
vSphere 6.7 和 7.0
Kubernetes 1.18 (P1)、1.19、1.20
OpenShift 3 3.11
注意:OpenShift 3.x 支持将在未来版本中弃用。
OpenShift 4 RHCOS 4.5、4.6
Kubernetes 主机虚拟机操作系统 Ubuntu 18.04、Ubuntu 20.04
CentOS 7.8、CentOS 7.9、CentOS 8.2
RHEL 7.8、RHEL 7.9 和 RHEL 8.3(注意:对 Vanilla Kubernetes 的 RHEL 支持将在未来版本中弃用。)
请参见以下注释。
OpenShift 主机虚拟机操作系统 RHEL 7.7、RHEL 7.8(注意:对 Vanilla Kubernetes 的 RHEL 支持将在未来版本中弃用。)
Tanzu Application Service (Pivotal Cloud Foundry) Ops Manager 2.7 + PAS 2.7 (LTS)
Ops Manager 2.9 + PAS 2.9
Ops Manager 2.10 + PAS 2.10
Tanzu Kubernetes Grid Integrated (TKGI) 1.10

注意:

要在 CentOS/RHEL 上安装 nsx-ovs 内核模块,需要使用特定的内核版本。无论 RHEL 版本如何,支持的 RHEL 内核版本均为 1127、1160 和 193。请注意,RHEL 7.8 对应的默认内核版本为 1127、RHEL 7.9 对应的默认内核版本为 1160、RHEL 8.2 对应的默认内核版本为 193。如果运行的是其他内核版本,可以通过将 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 及所有 NCP 3.0.x 版本

 

已解决的问题

  • 问题 2671647:为 OVS 守护进程 ovsdb-server 和 ovs-vswitchd 重新启动 monit 作业时,OVS 流量丢失

    如果使用命令“monit restart <process-name>”为 openvswitch 守护进程重新启动 monit 作业,则由 nsx-node-agent 创建的 OVS 流将丢失

    解决办法:在 openvswitch 守护进程恢复为“正在运行”状态后,使用“monit restart nsx-node-agent”命令重新启动 nsx-node-agent

  • 问题 2674503:nsx-ncp-bootstrap 不支持在 CentOS 7.8、8.1、8.2 或 RHEL 7.8、8.1、8.2 上安装 NSX OVS 内核模块

    nsx-ncp-bootstrap 容器不支持在 CentOS 7.8、8.1、8.2 或 RHEL 7.8、8.1、8.2 上安装 NSX OVS 内核模块。

    解决办法:在 NSX 节点代理 ConfigMap 中将 use_nsx_ovs_kernel_module 设置为 False,并使用 Linux 上游 OVS 内核模块。

已知问题

  • 问题 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:在 PAS Director 配置中禁用“BOSH DNS 服务器”后,Bosh DNS 服务器 (169.254.0.2) 仍显示在容器的 resolve.conf 文件中。

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

    解决办法:无。这是 PAS 问题。

  • 问题 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 DaemonSets 创建 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 个空间的 PAS ASG(应用程序安全组)

    由于 NSX-T 分布式防火墙中的限制,NCP 无法处理绑定到超过 128 个空间的 PAS 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 中,“清单”>“容器”选项卡会显示与容器相关的对象及其状态。在 PKS 环境中,将 NSX-T 升级到 3.0 后,与容器相关的对象的网络连接状态显示为“未知”。之所以会出现此问题,是因为 PKS 未检测到 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(对于 PKS 部署)和 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 集群选项卡中。在 PKS 环境中通常会出现此问题。

    解决办法:升级 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 运算符不支持连接到使用 API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> 创建的 Tier-1 分段的 OpenShift 节点

    NCP 运算符不支持连接到使用 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(守护进程集成员除外)将被逐出并在环境中的其他节点上重新创建。

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

  • 问题 2653241:不支持在 Kubernetes 中更新密钥的证书

    如果更新密钥中的证书,将不会在 NSX-T 中更新这些新证书。管理器模式和策略模式均存在此问题。

    解决办法:删除密钥,然后创建一个包含更新后的证书的密钥。

  • 问题 2706551:OpenShift 的全堆栈自动安装(称为 IPI)失败,因为节点在安装过程中未就绪。

    在主节点上开始运行 Kubernetes API 服务器之前,保持活动状态的 Pod 会将 Kubernetes VIP 添加到主节点上的 ovs_bridge。因此,对 Kubernetes API 服务器的所有请求均将失败,从而导致安装无法完成。

    解决办法:无

  • 问题 2707883:如果在 nsx-ncp-operator 未运行时删除了与 NCP 相关的 Kubernetes 资源,则 nsx-ncp-operator 不会创建该资源

    例如,如果在 nsx-ncp-operator 未运行时删除 nsx-node-agent 或 nsx-ncp-bootstrap DaemonSet 资源,则再次运行 nsx-ncp-operator 时不会重新创建该资源。

    解决办法:当 nsx-ncp-operator 再次运行时,更新 nsx-ncp-operator ConfigMap 中的任意字段,例如,[Default] 部分中的 log_level。

  • 问题 2697547:RHEL/CentOS/RHCOS 节点不支持 HostPort

    您可以通过将 nsx-node-agent ConfigMap 中的“enable_hostport_snat”设置为 True,在 Ubuntu 节点上的本机 Kubernetes 和 PKS 上指定 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 可能会重新启动或无法初始化负载均衡器服务。此外,在 NCP 运行时,可能会在短时间内(少于 1 秒)报告 NSX 端点处于已关闭状态。如果负载均衡器无法初始化,NCP 日志将显示消息“Failed to initialize loadbalancer services”。

    解决办法:增大 nsx_v3.conn_idle_timeout 参数的值。请注意,在使用客户端负载均衡时,这样做可能会导致在端点暂时断开连接后,需要等待较长的时间才会被重新检测为可用之。

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