NCP YAML 文件包含用于配置、安装和运行所有 NCP 组件的信息。

NCP YAML 文件包含以下信息:
  • RBAC 定义。
  • 各种 CRD (CustomResourceDefinitions)。
  • 包含专用于 NCP 的 ncp.ini 的 ConfigMap。某些建议的配置选项已设置。
  • NCP 部署。
  • 包含专用于 nsx-node-agent 的 ncp.ini 的 ConfigMap。某些建议的配置选项已设置。
  • nsx-node-agent DaemonSet,包括 nsx-node-agent、nsx-kube-proxy 和 nsx-ovs。
  • nsx-ncp-bootstrap DaemonSet

NSX CNI 和 OpenvSwitch 内核模块由 nsx-ncp-bootstrap initContainers 自动安装。OpenvSwitch 用户空间守护进程正在每个节点上的 nsx-ovs 容器中运行。

更新 NCP 部署规范

找到名为 nsx-ncp-config 的 ConfigMap。有关 ConfigMap 选项的完整列表,请参见 nsx-ncp-config ConfigMap。某些选项已配置为建议的值。您可以自定义环境的所有选项。例如,
  • 日志级别和日志目录。
  • Kubernetes API 服务器 IP、证书路径和客户端令牌路径。默认情况下,将使用来自环境变量的 API 服务器 ClusterIP,并从 ServiceAccount 中自动挂载证书和令牌。通常无需进行任何更改。
  • Kubernetes 集群名称。
  • NSX Manager IP 和凭据。
  • NSX 资源选项,如 overlay_tztop_tier_routercontainer_ip_blocksexternal_ip_blocks 等。

默认情况下,Kubernetes Service VIP/端口和 ServiceAccount 令牌以及 ca_file 会用于 Kubernetes API 访问。此处不需要更改,但您需要填写 ncp.ini 的某些 NSX API 选项。

  • 指定 nsx_api_managers 选项。它可以是以逗号分隔的 NSX Manager IP 地址或 URL 规范(符合 RFC3896)的列表。例如,
    nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
  • 如果将 NCP 配置为使用基本身份验证连接到 NSX-T,请分别使用用户名和密码指定 nsx_api_usernsx_api_password 选项。不建议使用此身份验证方法,因为它的安全性较差。如果将 NCP 配置为使用客户端证书进行身份验证,则系统会忽略这些选项。这些选项不会显示在 NCP YAML 文件中。您必须手动添加它们。
  • 指定 nsx_api_cert_filensx_api_private_key_file 选项以使用 NSX-T 进行身份验证。nsx_api_cert_file 选项是指向 PEM 格式的客户端证书文件的完整路径。该文件的内容应如下所示:
    -----BEGIN CERTIFICATE-----
    <certificate_data_base64_encoded>
    -----END CERTIFICATE-----
    nsx_api_private_key_file 选项是指向 PEM 格式的客户端私钥文件的完整路径。该文件的内容应如下所示:
    -----BEGIN PRIVATE KEY-----
    <private_key_data_base64_encoded>
    -----END PRIVATE KEY-----

    通过使用客户端证书身份验证,NCP 可以使用其主体身份来创建 NSX-T 对象。这意味着,只有具有相同标识名称的身份才能修改或删除这些对象。它可防止由 NCP 创建的 NSX-T 对象被错误修改或删除。请注意,管理员可以修改或删除任何对象。如果对象是使用主体身份创建的,警告将指出这一点。

  • (可选)指定 ca_file 选项。该值应该是在验证 NSX Manager 服务器证书时使用的 CA 包文件。如果未设置,将使用系统根 CA。如果为 nsx_api_managers 指定一个 IP 地址,则指定一个 CA 文件。如果为 nsx_api_managers 指定三个 IP 地址,则可以指定一个或三个 CA 文件。如果指定一个 CA 文件,则该文件将用于所有三个管理器。如果指定三个 CA 文件,则每个文件将用于 nsx_api_managers 中对应的 IP 地址。例如,
       nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183
       ca_file = ca_file_for_all_mgrs
    or
       nsx_api_managers = 192.168.1.181,192.168.1.182,192.168.1.183
       ca_file = ca_file_for_mgr1,ca_file_for_mgr2,ca_file_for_mgr3
  • (可选)指定 insecure 选项。如果设置为 True ,则不会验证 NSX Manager 服务器证书。默认值为 False
如果要使用 Kubernetes 密钥存储 NSX 客户端证书和负载均衡器默认证书,则必须先使用 kubectl 命令创建密钥,然后再更新部署规范:
  • 将密钥卷添加到 NCP pod 规范,或取消对示例密钥卷的注释。
  • 将卷挂载添加到 NCP 容器规范,或取消对示例卷挂载的注释。
  • 在 ConfigMap 中更新 ncp.ini,以便将证书文件路径设置为指向已挂载卷中的文件。

如果您没有共享的 Tier-1 拓扑,则必须将 edge_cluster 选项设置为 Edge 集群 ID,以便 NCP 为 Loadbalancer 服务创建 Tier-1 网关或路由器。通过导航到系统 > Fabric > 节点,选择 Edge 集群选项卡,并单击 Edge 集群名称,可以找到 Edge 集群 ID。

默认情况下,将启用 HA(高可用性)。在生产环境中,建议不要禁用 HA。

注意:默认情况下,kube 调度程序不会在主节点上计划 pod。在 NCP YAML 文件中,添加了一个宽容度,允许在主节点上运行 NCP Pod。

配置 SNAT

默认情况下,NCP 会为每个项目配置 SNAT。不会为具有以下注释的命名空间配置 SNAT:
ncp/no_snat: True
如果您不希望集群中的任何命名空间具有 SNAT,请在 ncp.ini 中配置以下选项:
[coe]
enable_snat = False

注意:不支持更新现有的命名空间 SNAT 注释。如果执行此类操作,则命名空间的拓扑将处于不一致状态,因为仍可能保留失效的 SNAT 规则。要从这种不一致的状态中恢复,必须重新创建命名空间。

(仅限策略模式)如果为集群配置了 SNAT,在 Tier-0 路由器上启用了 BGP,并且在为 Tier-0 路由器配置路由重新分发时在 Advertised tier-1 subnets 下选定 Connected Interfaces & Segments,则您可以使用以下选项控制路由重新分发:
[nsx_v3]
configure_t0_redistribution = True 

如果 configure_t0_redistribution 设置为 True,NCP 将在重新分发规则中添加 deny 路由映射条目,以阻止 Tier-0 路由器将集群的内部子网通告到 BGP 邻居。这主要用于 vSphere with Kubernetes 集群。如果不为重新分发规则创建路由映射,NCP 将使用其主体身份创建路由映射,并在规则中应用该映射。如果要修改此路由映射,必须将其替换为新的路由映射,从 NCP 创建的路由映射中复制条目,然后添加新条目。您必须管理新条目和 NCP 创建的条目之间存在的任何潜在冲突。如果您仅取消设置 NCP 创建的路由映射而不为重新分发规则创建新路由映射,NCP 在重新启动时会再次将先前创建的路由映射应用到重新分发规则。

为 NAT 规则配置防火墙匹配

从 NCP 3.2.1 开始,您可以使用 natfirewallmatch 选项,通过为 Kubernetes 命名空间创建的 NAT 规则来指定 NSX-T 网关防火墙的行为方式。此选项仅适用于新创建的 Kubernetes 命名空间,而不适用于现有命名空间。此选项仅适用于策略模式。
[nsx_v3]
# This parameter indicate how firewall is applied to a traffic packet.
# Firewall can be bypassed, or be applied to external/internal address of
# NAT rule
# Choices: MATCH_EXTERNAL_ADDRESS MATCH_INTERNAL_ADDRESS BYPASS
#natfirewallmatch = MATCH_INTERNAL_ADDRESS

更新 nsx-node-agent DaemonSet 规范

找到名为 nsx-node-agent-config 的 ConfigMap。有关 ConfigMap 选项的完整列表,请参见 nsx-node-agent-config ConfigMap。某些选项已配置为建议的值。您可以自定义环境的所有选项。例如,
  • 日志级别和日志目录。
  • Kubernetes API 服务器 IP、证书路径和客户端令牌路径。默认情况下,将使用来自环境变量的 API 服务器 ClusterIP,并从 ServiceAccount 中自动挂载证书和令牌。通常无需进行任何更改。
  • OpenvSwitch 上行链路端口。例如:ovs_uplink_port=eth1
  • CNI 的 MTU 值。

要设置 CNI 的 MTU 值,请修改 nsx-node-agent ConfigMap 中的 mtu 参数,然后重新启动 nsx-ncp-bootstrap pod。这将更新每个节点上的 pod MTU。您还必须相应地更新节点 MTU。节点与 pod MTU 不匹配可能会导致节点与 pod 之间的通信出现问题,从而影响 TCP 活动和就绪状态探测。

nsx-ncp-bootstrap DaemonSet 在节点上安装 CNI 和 OVS 内核模块。然后,它会关闭节点上的 OVS 守护进程,以便稍后 nsx-ovs 容器可以在 Docker 容器中运行 OVS 守护进程。未安装 CNI 时,所有 Kubernetes 节点都处于“未就绪”状态。对引导 DaemonSet 有一定的宽容度,以允许它在“未就绪”节点上运行。它安装 CNI 插件后,节点应变为“就绪”。

如果未使用 NSX OVS 内核模块,则必须将卷参数 host-original-ovs-db 更新为正确路径,即在 OVS 内核模块编译期间将 OpenvSwitch 数据库配置到的路径。例如,如果您指定 --sysconfdir=/var/lib,则需将 host-original-ovs-db 设置为 /var/lib/openvswitch。请确保使用实际 OVS 数据库的路径,而不是指向该数据库的符号链接。

如果使用 NSX OVS 内核模块,则必须设置 use_nsx_ovs_kernel_module = True 并取消注释要挂载的卷所对应的行:

  # Uncomment these mounts if installing NSX-OVS kernel module
#   # mount host lib modules to install OVS kernel module if needed
#   - name: host-modules
#     mountPath: /lib/modules
#   # mount openvswitch database
#   - name: host-config-openvswitch
#     mountPath: /etc/openvswitch
#   - name: dir-tmp-usr-ovs-kmod-backup
#   # we move the usr kmod files to this dir temporarily before
#   # installing new OVS kmod and/or backing up existing OVS kmod backup
#     mountPath: /tmp/nsx_usr_ovs_kmod_backup

#   # mount linux headers for compiling OVS kmod
#   - name: host-usr-src
#     mountPath: /usr/src

...

# Uncomment these volumes if installing NSX-OVS kernel module
# - name: host-modules
#   hostPath:
#     path: /lib/modules
# - name: host-config-openvswitch
#   hostPath:
#     path: /etc/openvswitch
# - name: dir-tmp-usr-ovs-kmod-backup
#   hostPath:
#     path: /tmp/nsx_usr_ovs_kmod_backup

# - name: host-usr-src
#   hostPath:
#     path: /usr/src

如果计划为 Pod 指定 hostPort,请在 nsx-node-agent-config ConfigMap 的 [k8s] 部分中将 enable_hostport_snat 设置为 True。如果安装了 CNI 插件,则必须在同一 ConfigMap 中,将 use_ncp_portmap 设置为 False(默认值)。如果您没有安装 CNI 插件,并且想要使用 NCP 映像中的 portmap,则将 use_ncp_portmap 设置为 True

SNAT 使用 hostIP 作为 hostPort 流量的源 IP。如果存在 Pod 的网络策略,并且想要访问 Pod 的 hostPort,则必须在网络策略的允许规则中添加工作节点 IP 地址。例如,如果您有两个工作节点(172.10.0.2 和 172.10.0.3),则 Ingress 规则必须如下所示:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: test
    - podSelector:
        matchLabels:
          app: tea
    - ipBlock:
        cidr: 172.10.0.3/32
    - ipBlock:
        cidr: 172.10.0.2/32
    ...
NSX 节点代理是一个 DaemonSet,每个 pod 将运行 3 个容器。
  • nsx-node-agent 管理容器网络接口。它与 CNI 插件和 Kubernetes API 服务器进行交互。
  • nsx-kube-proxy 通过将集群 IP 转换为 pod IP 来实现 Kubernetes 服务抽象。它实现与上游 kube-proxy 相同的功能,但与该功能并不互斥。
  • nsx-ovs 将运行 OpenvSwitch 用户空间守护进程。它还会自动创建 OVS 网桥,并将 IP 地址和路由从 node-if 移回 br-int。您必须在 ncp.ini 中添加 ovs_uplink_port=ethX,以便它可以使用 ethX 作为 OVS 网桥上行链路。

如果工作线程节点使用的是 Ubuntu,则 ncp-Ubuntu.yaml 假设已启用了 AppArmor 内核模块,否则 Kubelet 将拒绝运行 nsx-node-agent DaemonSet,因为它已配置了 AppArmor 选项。对于 Ubuntu 和 SUSE,它在默认情况下处于启用状态。要检查模块是否已启用,请检查 /sys/module/apparmor/parameters/enabled 文件。

如果有意禁用了 AppArmor,则需要将以下更改应用于 YAML 文件:
  • 移除 AppArmor 选项:
    annotations:
        # The following line needs to be removed
        container.apparmor.security.beta.kubernetes.io/nsx-node-agent: localhost/node-agent-apparmor
  • 为 nsx-node-agent 和 nsx-kube-proxy 容器启用特权模式
    securityContext:
        # The following line needs to be appended
        privileged: true

注意:如果在使用 hyperkube 映像的容器中运行 kubelet,kubelet 始终将 AppArmor 报告为已禁用,无论实际处于何种状态。必须对上述情况进行相同的更改,并将其应用于 YAML 文件。

更新命名空间名称

在 YAML 文件中,所有带命名空间的对象(如 ServiceAccount、ConfigMap、Deployment)都在 nsx-system 命名空间下创建。如果使用其他命名空间,请替换 nsx-system 的所有实例。

启用备份和还原

NCP 支持 NSX-T 中的备份和还原功能。支持的资源包括命名空间、Pod 和服务。

注意:NCP 必须配置为策略模式。

要启用该功能,请在 ncp.ini 中将 enable_restore 设置为 True 并重新启动 NCP。
[k8s]
enable_restore = True
您可以使用 NSX CLI 命令检查还原状态。例如,
nsxcli
> get ncp-restore status
NCP restore status is INITIAL

状态可能是 INITIAL、RUNNING 或 SUCCESS。INITIAL 表示备份/还原功能准备就绪,但没有运行还原。RUNNING 表示正在 NCP 中运行还原过程。SUCCESS 表示已成功完成还原。如果在还原期间出现错误,NCP 将自动重新启动并重试。如果长时间处于 RUNNING 状态,请检查 NCP 日志以查看错误消息。