VMware NSX Container Plugin 2.5 | 2019 年 9 月 24 日 | 内部版本 14628220

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

发行说明内容

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

新增功能

NSX Container Plugin (NCP) 2.5 具有以下新增功能:
  • 支持使用策略 API 配置 NSX-T 资源。
  • 支持更多拓扑。用户可以选择每个 Kubernetes 集群具有一个共享的 Tier-1 路由器 - 在集群中的所有命名空间之间共享。在此拓扑中,将在 Tier-1 路由器上检测诸如 SNAT NAT 规则(如果有)之类的有状态服务,从而使用户可以选择使用活动-活动 Tier-0 拓扑。其他拓扑中提供的所有功能也可在共享 Tier-1 拓扑中使用。
  • Nsx-ncp-bootstrap 是新的 DaemonSet,可自动初始化 Kubernetes 节点。
  • 在虚拟机中运行 OVS 的新容器 nsx-ovs(位于 nsx-node-agent DaemonSet 内)。
  • 用于简化 NCP 安装的单个 YAML 文件。YAML 文件中包含 NCP 和容器主机组件的所有必需 Kubernetes 资源定义。
  • 支持将 Kubernetes CustomResourceDefinitions 用于 NCP 主节点选举。
  • 在 NSX BOSH 版本中支持多个 CNI 插件。

兼容性要求

产品 版本
NCP/NSX-T Tile for PAS 2.5
NSX-T 2.4.1、2.4.2、2.5
Kubernetes 1.13、1.14
OpenShift 3.10、3.11
Kubernetes 主机虚拟机操作系统     Ubuntu 16.04、Ubuntu 18.04、CentOS 7.6
OpenShift 主机虚拟机操作系统 RHEL 7.5、RHEL 7.6
OpenShift BMC RHEL 7.5、RHEL 7.6
PAS (PCF) Ops Manager 2.8 + PAS 2.8
Ops Manager 2.7 + PAS 2.7
Ops Manager 2.6 + PAS 2.6
Ops Manager 2.5 + PAS 2.5
注意:不支持 PAS 2.7.0 + NCP 2.5.0。

注意:此版本的 NCP 不支持 Linux 版本 4.15.0-59-generic 或更高版本。

如果 RHEL 节点的内核版本低于 3.10.0-957.27.2,则不满足 OpenShift 安装必备条件。由于 OVS 将无法运行,因此建议不要在裸机容器节点上升级内核版本。要使用较低的内核版本来部署 OpenShift 3.11,openshift-ansible 存储库应使用 commit: e0499023ea91741ab4afd29391e420a26b8859b5 作为顶层 commit。

支持升级到此版本:

  • 所有 NCP 2.4.x 版本

 

已解决的问题

  • 问题 2389094:NCP 删除负载均衡器服务器时,不会删除相应的 Tier-1 路由器

    启用自动缩放后,如果创建多个类型为 LoadBalancer 的服务,NCP 会创建所需数量的负载均衡器虚拟服务器。如果您后来减少服务数量,导致 NCP 删除一个负载均衡器虚拟服务器,将不会删除相应的 Tier-1 路由器。

  • 问题 2118515:在大型设置中,NCP 需要很长时间才能在 NSX-T 上创建防火墙

    在大型设置(例如,250 个 Kubernetes 节点、5000 个 pod、2500 个网络策略)中,NCP 可能需要数分钟才能在 NSX-T 中创建防火墙区域和规则。

  • 问题 2125755:执行 canary 更新和分阶段滚动更新时,StatefullSet 可能会断开网络连接

    如果将 NCP 升级到当前版本之前已创建 StatefulSet,则执行 canary 更新和分阶段滚动更新时,StatefullSet 可能会断开网络连接。

  • 问题 2193901:单个 Kubernetes 网络策略规则不支持使用多个 PodSelector 或多个 NsSelector

    应用多个选择器仅允许来自特定 pod 的入站流量。

  • 问题 2194646:不支持在 NCP 关闭时更新网络策略

    如果在 NCP 关闭时更新网络策略,则在 NCP 恢复运行后,网络策略的目标 IPset 将不正确。

  • 问题 2199504:NCP 创建的 NSX-T 资源的显示名称限定为 80 个字符

    当 NCP 为容器环境中的资源创建 NSX-T 资源时,会通过组合集群名称、命名空间或项目名称和容器环境中的资源的名称来生成 NSX-T 资源的显示名称。如果显示名称长度超过 80 个字符,则会截断为 80 个字符。

  • 问题 2199778:对于 NSX-T 2.2,不支持名称超过 65 个字符的 Ingress、Service 和 Secret

    对于 NSX-T 2.2,当 use_native_loadbalancer 设置为 True 时,Ingress 及其引用的 Secret/Service 的名称,以及 LoadBalancer 类型 Service 的名称不得超过 65 个字符。否则,Ingress 或 Service 将无法正常工作。

  • 问题 2065750:安装 NSX-T CNI 软件包失败并发生文件冲突

    在安装有 kubernetes 的 RHEL 环境中,如果使用 yum localinstallrpm-i 安装 NSX-T CNI 软件包,则会显示错误,指示 kubernetes-cni 软件包中的文件产生冲突。

  • 问题 2317608:不支持安装多个 CNI 插件

    Kubernetes 需要一个包含插件配置列表的 .conflist 类型的 CNI 配置文件。Kubelet 将按定义的顺序逐个调用在此 conflist 文件中定义的插件。目前,nsx-cf-cni bosh 版本仅支持单个 CNI 插件配置。任何其他 CNI 插件都将覆盖指定 cni_config_dir 中的现有 CNI 配置文件 10-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 关闭时执行删除和创建操作。

  • 问题 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 容器不会运行。

    解决办法:将 OVS 数据库文件移至 /etc/openvswitch,并移除符号链接。

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

  • 问题 2398430:重新启动后,与节点的连接中断

    如果将 OVS 配置为启动时在节点上运行,并在 NSX 节点代理 DaemonSet 正在运行,并且 IP 仍继续存留在 ovs_uplink_port 上时重新启动该节点,则与该节点的连接将会丢失。

    解决办法:在节点启动时,通过移除其服务来禁用在该主机上启动的 OVS。例如,在 Ubuntu 上,可以运行 update-rc.d -f openvswitch-switch remove

  • 问题 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、命名空间和网络策略等资源的处理可能需要额外的时间。

    解决办法:无

  • 问题 2423240:如果任意 IP 路由处于链路断开状态,则 nsx-ncp-bootstrap 容器将失败

    Nsx-ncp-bootstrap 容器假定所有 IP 路由的链路状态均为“已连接”,如果不符合此种情况,则会失败。

    解决办法:移除链路状态不是“已连接”的路由,并在引导完成后再次添加。

  • 问题 2425050:Nsx-ncp-bootstrap 容器无法在 Linux 版本 4.15.0-59-generic 或更高版本上编译 OVS 软件包

    因为在编译 OVS 内核模块的过程中缺少标头文件,所以编译失败。

    解决办法:无。请注意,NCP 2.5.0 不支持 Linux 版本 4.15.0-59-generic 或更高版本。

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