VMware NSX Container Plugin 3.0.2 | 2020 年 9 月 10 日 | 内部版本 16863080

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

发行说明内容

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

新增功能

 
NSX Container Plugin 3.0.2 具有以下新功能:
  • 支持 OpenShift 4.4(使用 NSX-T Data Center 3.0.1.1 或更高版本)
  • 支持将 JWT 客户端身份验证用于输入(使用 NSX-T Data Center 3.0.0 或更高版本)
  • 支持不带选择器的 LoadBalancer 类型的 Kubernetes 服务
  • 能够通过注释指定每个命名空间和服务的特定 SNAT IP
  • 新增用于为分布式防火墙规则启用日志记录流量的注释
  • 支持 Photon OS
  • 支持容器安全策略
  • 支持输入的 pathType 属性

NSX Container Plugin 3.0.2.2 是一个修补程序版本。它解决了 Pivotal Stemcells 621.85 和更高版本以及 456.121 和更高版本上的 OVS 内核模块编译问题。

 

兼容性要求

产品 版本
Tanzu 应用程序服务 (PCF) 的 NCP/NSX-T Tile 包 3.0.2
NSX-T 2.5.2、2.5.2.1、2.5.2.2、2.5.3、3.0.0、3.0.1、3.0.2、3.0.3
vSphere 6.7 和 7.0
Kubernetes 1.17 和 1.18
OpenShift 3 3.11
OpenShift 4 RHCOS 4.3、4.4
Kubernetes 主机虚拟机操作系统 Ubuntu 16.04、Ubuntu 18.04、CentOS 7.7、CentOS 7.8、CentOS 8.1、RHEL 7.8、RHEL 8.1

注意:对于 RHEL/CentOS 7.8 和 8.1,不支持 nsx-ovs。仅与上游 OVS 兼容。
OpenShift 主机虚拟机操作系统 RHEL 7.7、RHEL 7.8
OpenShift BMC
(在此版本中已弃用)
 
Tanzu 应用程序服务 (Pivotal Cloud Foundry) Ops Manager 2.8 + PAS 2.8
Ops Manager 2.9 + PAS 2.9
Ops Manager 2.10 + PAS 2.10

支持升级到此版本:

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

 

已解决的问题

  • 问题 2518312:NCP 引导容器无法在 Ubuntu 18.04.4(内核 4.15.0-88)上安装 nsx-ovs 内核模块

    NCP 引导容器 (nsx-ncp-bootstrap) 无法在 Ubuntu 18.04.4(内核 4.15.0-88)上安装 nsx-ovs 内核模块。

    请勿通过在 NSX-node-agent-config 中设置 use_nsx_ovs_kernel_module = False 在此内核上安装 NSX OVS。取而代之的是,在主机上使用上游 OVS 内核模块(默认情况下,Ubuntu 附带了 OVS 内核模块)。如果主机上没有 OVS 内核模块,请手动安装 OVS 内核模块,并在 nsx-node-agent-config 中设置 use_nsx_ovs_kernel_module = False,或者将内核版本降级到 4.15.0-76,以便可以安装 NSX OVS。

  • 问题 2548815:在从管理器导入到策略的 NCP 集群中,NCP 无法删除自动缩放的 Tier-1 路由器

    从管理器导入到策略后,在策略模式下运行的 NCP 无法删除自动缩放的 Tier-1 路由器,因为其 LocaleService 仍在引用该路由器。

    解决办法:使用 NSX Manager UI 手动删除 Tier-1 路由器。

  • 问题 2549433:DHCP 租约到期时,使用单个接口并配置为 ovs_uplink_port 的 OpenShift 节点将失去名称服务器信息

    当 ovs_uplink_port 的 DHCP 租约到期时,具有单个接口且在 nsx-node-agent 配置中配置为 ovs_uplink_port 的 OpenShift 节点会丢失名称服务器信息。

    解决办法:使用静态 IP 地址。

  • 问题 2550625:将集群从管理器迁移到策略后,不会释放共享 IP 池中的 IP 地址

    将集群从管理器迁移到策略后,删除命名空间时不会释放分配给该命名空间的 IP 地址。

    解决办法:无。

  • 问题 2549765:如果存在具有多个目标端口的 NAT 规则,则无法将管理器对象导入策略

    如果顶层路由器上存在具有多个目标端口的 NAT 规则,则从管理器导入到策略的过程将失败。在以下场景中会出现此问题:在 NCP 配置中,Kubernetes 参数 ingress_mode 为“nat”,并且 Kubernetes 中存在带有注释“ncp/ingress-controller”的 Pod。

    解决办法:当 NCP 未运行且尚未启动导入过程时,编辑 NAT 规则并移除“80”和“443”目标端口。

  • 问题 2550474:在 OpenShift 环境中,将 HTTPS 路由更改为 HTTP 路由可能会导致 HTTP 路由无法按预期工作

    如果您编辑 HTTPS 路由并删除与 TLS 相关的数据以将该路由转换为 HTTP 路由,则 HTTP 路由可能无法按预期工作。

    解决办法:删除 HTTPS 路由并创建新的 HTTP 路由。

  • 如果未配置任何容器 IP 段,NCP 在启动时将失败

    对于完全路由的部署,如果仅配置了“无 SNAT IP 段”但未配置“容器 IP 段”,NCP 3.0.1 在启动时将失败,并显示“IndexError: 列表索引超出范围 (IndexError: list index out of range)”。

已知问题

  • 问题 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 DaemonSet 创建 pod。在 nsx-ncp-bootstrap 安装 NSX-CNI 后,节点状态将变为“就绪”。

  • 问题 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 手动清除失效状态。

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

  • 问题 2552918:对于分布式防火墙,无法对管理器到策略的导入过程进行回滚,并且会导致集群回滚失败

    在极少数情况下,必须对管理器到策略的导入过程进行回滚,但无法对分布式防火墙区域和规则执行此操作。这会导致集群回滚失败并会在 NSX Manager 中保留失效资源。

    解决办法:使用备份和还原功能将 NSX Manager 还原到正常状态。

  • 问题 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 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”权限。
    • 禁用“将日志记录到文件”功能。
  • 问题 3033821:完成管理器到策略的迁移后,分布式防火墙规则无法正确实施

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

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

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