编辑 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 网关或路由器。通过导航到 ,选择 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 日志以查看错误消息。