编辑 NCP YAML 文件

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_tz
    top_tier_router
    container_ip_blocks
    external_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
    ,请分别使用用户名和密码指定
    nsx_api_user
    nsx_api_password
    选项。不建议使用此身份验证方法,因为它的安全性较差。如果将 NCP 配置为使用客户端证书进行身份验证,则系统会忽略这些选项。这些选项不会显示在 NCP YAML 文件中。您必须手动添加它们。
  • 指定
    nsx_api_cert_file
    nsx_api_private_key_file
    选项以使用
    NSX
    进行身份验证。
    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
    对象。这意味着,只有具有相同标识名称的身份才能修改或删除这些对象。它可防止由 NCP 创建的
    NSX
    对象被错误修改或删除。请注意,管理员可以修改或删除任何对象。如果对象是使用主体身份创建的,警告将指出这一点。
  • (可选)指定
    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。
ncp.ini
中的
lb_segment_subnet
参数用于服务 ClusterIP 的自访问。默认值为 169.254.131.0/24。NCP 将使用此子网中的第二个最后一个 IP 地址作为 SNAT IP。例如,如果
lb_segment_subnet
设置为 169.254.100.0/24,NCP 将使用 169.254.100.254 作为 SNAT IP。在 Windows 工作节点上,必须将
lb_segment_subnet
设置为 169.254.131.0/24 以外的值。创建集群后,无法更改
lb_segment_subnet

配置 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
网关防火墙的行为方式。此选项仅适用于新创建的 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
中的备份和还原功能。支持的资源包括命名空间、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 日志以查看错误消息。