VMware NSX Container Plugin 3.0.0   |   2020 年 4 月 7 日  |   内部版本 15841604

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

发行说明内容

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

新增功能

NSX Container Plugin (NCP) 3.0.0 仅面向 vSphere with Kubernetes 客户。对于 Kubernetes、Redhat 和 Pivotal 的所有其他分发版,请等待 NSX Container Plugin 3.0.1 的发布。
 
NSX Container Plugin 3.0.0 具有以下新功能:
  • 支持放松对负载均衡器服务的规模限制。对于策略 API,支持对 Kubernetes LoadBalancer 服务的每个负载均衡器服务进行池成员限制。
  • 对 Kubernetes LoadBalancer 服务支持源 IP 白名单,对策略 API 支持 Ingress。

兼容性要求

产品 版本
NSX-T 3.0.0
vSphere with Kubernetes 7.0

支持升级到此版本:

  • 所有 NCP 2.5.x 版本

 

已解决的问题

  • 问题 2370137:由于 OVS 数据库文件不在 /etc/openvswitch 中,因此 nsx-ovs 和 nsx-node-agent 容器无法运行。

    当 nsx-ovs 和 nsx-node-agent 容器启动时,它们会在 /etc/openvswitch 中查找 OVS 数据库文件。如果在链接到实际 OVS 文件(例如,conf.db)的目录中存在符号链接,则 nsx-ovs 和 nsx-node-agent 容器不会运行。

  • 问题 2451442:重复重新启动 NCP 并重新创建命名空间后,NCP 可能无法向容器分配 IP 地址

    如果在重新启动 NCP 时重复删除并重新创建相同的命名空间,则 NCP 可能无法向该命名空间中的容器分配 IP 地址。

    解决办法:删除与该命名空间关联的所有失效的 NSX 资源(逻辑路由器、逻辑交换机和逻辑端口),然后重新创建这些资源。

已知问题

  • 问题 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 分钟然后再重新创建。

  • 问题 2330811:如果在 NCP 关闭时创建 LoadBalancer 类型的 Kubernetes 服务,可能在重新启动 NCP 后无法创建这些服务

    在 LoadBalancer 类型的 Kubernetes 服务耗尽 NSX-T 资源时,您可以在删除一些现有的服务后创建新的服务。不过,如果在 NCP 关闭时删除并创建服务,NCP 将无法创建新服务。

    解决办法:在 LoadBalancer 类型的 Kubernetes 服务耗尽 NSX-T 资源时,请勿在 NCP 关闭时执行删除和创建操作。

  • 问题 2397438:重新启动后,NCP 会报告 MultipleObjects 错误

    在重新启动之前,由于出现 ServerOverload 错误,NCP 无法创建分布式防火墙区域。NCP 会重试,直到达到最大尝试次数为止。但是,仍会创建防火墙区域。当 NCP 重新启动时,它会收到重复的防火墙区域,并报告 MultipleObjects 错误。

    解决办法:手动删除过时和重复的分布式防火墙区域,然后重新启动 NCP。

  • 问题 2397684:NCP 找到正确的传输区域,但随后失败,显示错误“未配置默认传输区域 (Default transport-zone is not configured)”

    使用基于策略 API 的 NCP 创建 Kubernetes 命名空间时,由于在 NSX-T 中存在多个覆盖网络传输区域,基础架构分段创建可能会失败。如果未将任何覆盖网络传输区域标记为默认,则会出现此问题。

    解决办法:更新在 NCP ConfigMap 中配置的覆盖网络传输区域,并将“is_default”字段设置为“True”。

  • 问题 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 安装失败

    OpenShift 安装要求节点的状态为准备就绪,安装 CNI 插件后可能会出现此种状态。在此版本中,没有单独的 CNI 插件文件,导致 OpenShift 安装失败。

    解决办法:在开始安装之前,在每个节点上创建 /etc/cni/net.d 目录。

  • 问题 2408100:在多个 NCP 实例处于“活动-备用”模式或已启用活动状态探测的大型 Kubernetes 集群中,NCP 会频繁重新启动

    在大型 Kubernetes 集群(大约 25,000 个 pod、2,500 个命名空间和 2,500 个网络策略)中,如果有多个 NCP 实例在“活动-备用”模式下运行,或者如果启用了活动状态探测,则可能会由于“获取锁时发生冲突 (Acquiring lock conflicted)”或活动状态探测失败而导致 NCP 进程终止并频繁重新启动。 

    解决办法:执行下列步骤:

    1. 将 NCP 部署的 replicas 设置为 1,或将 ncp.ini 中的配置选项 ha.master_timeout 从默认值 18 增加到 30。
    2. 按如下所示增加活动状态探测参数:
        containers: 
          - name: nsx-ncp
            livenessProbe: 
              exec: 
                command: 
                  - /bin/sh
                  - -c
                  - timeout 20 check_pod_liveness nsx-ncp
              initialDelaySeconds: 20
              timeoutSeconds: 20
              periodSeconds: 20
              failureThreshold: 5
      
  • 问题 2412421:Docker 无法重新启动容器

    如果 (1) ConfigMap 已更新,(2) 容器使用 subPath 安装 ConfigMap,并且 (3) 重新启动该容器,那么 Docker 无法启动容器。

    解决办法:删除该 Pod,以便 DaemonSet 重新创建 Pod。

  • 问题 2413383:由于并非所有节点都准备就绪,因此 OpenShift 升级失败

    默认情况下,不会在主节点上调度 NCP 引导 pod。因此,主节点状态始终为“未就绪”。

    解决办法:分配具有“compute”角色的主节点,以允许 nnsx-ncp-bootstrap 和 nsx-node-agent DaemonSet 创建 pod。在 nsx-ncp-bootstrap 安装 NSX-CNI 后,节点状态将变为“就绪”。

  • 问题 2410909:重新启动后,NCP 可能需要很长时间才能在大型环境中初始化其缓存(尤其是存在多个网络策略时),并且可能需要大约半个小时的时间来启动并处理新的 pod 和资源

    重新启动后,NCP 可能需要很长时间才能启动。根据涉及的资源数量,pod、命名空间和网络策略等资源的处理可能需要额外的时间。

    解决办法:无

  • 问题 2447127:将 NCP 从 2.4.1 升级到 2.5.0 或 2.5.1 后,NCP 可能需要更长的时间才能启动并运行

    在将 NCP 从 2.4.1 升级到 2.5.x 的过程中,当 NCP 调用交换配置文件 API 来选择最佳项时,NSX-T 2.4.1 可能会出现响应缓慢的问题。这会导致 NCP 多需要几分钟才能启动并运行。

    解决办法:无。

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

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

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

  • 问题 3033821:完成管理器到策略的迁移后,分布式防火墙规则无法正确实施

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

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

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