NCP YAML 文件包含用于配置、安装和运行所有 NCP 组件的信息。
- 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 部署规范
- 日志级别和日志目录。
- 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。
- 将密钥卷添加到 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/no_snat: True
[coe] enable_snat = False
注意：不支持更新现有的命名空间 SNAT 注释。如果执行此类操作，则命名空间的拓扑将处于不一致状态，因为仍可能保留失效的 SNAT 规则。要从这种不一致的状态中恢复，必须重新创建命名空间。
[nsx_v3] configure_t0_redistribution = True
如果 configure_t0_redistribution 设置为 True，NCP 将在重新分发规则中添加 deny 路由映射条目，以阻止 Tier-0 路由器将集群的内部子网通告到 BGP 邻居。这主要用于 vSphere with Kubernetes 集群。如果不为重新分发规则创建路由映射，NCP 将使用其主体身份创建路由映射，并在规则中应用该映射。如果要修改此路由映射，必须将其替换为新的路由映射，从 NCP 创建的路由映射中复制条目，然后添加新条目。您必须管理新条目和 NCP 创建的条目之间存在的任何潜在冲突。如果您仅取消设置 NCP 创建的路由映射而不为重新分发规则创建新路由映射，NCP 在重新启动时会再次将先前创建的路由映射应用到重新分发规则。
为 NAT 规则配置防火墙匹配
[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 规范
- 日志级别和日志目录。
- 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。
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-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 选项：
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 必须配置为策略模式。
[k8s] enable_restore = True
nsxcli > get ncp-restore status NCP restore status is INITIAL
状态可能是 INITIAL、RUNNING 或 SUCCESS。INITIAL 表示备份/还原功能准备就绪，但没有运行还原。RUNNING 表示正在 NCP 中运行还原过程。SUCCESS 表示已成功完成还原。如果在还原期间出现错误，NCP 将自动重新启动并重试。如果长时间处于 RUNNING 状态，请检查 NCP 日志以查看错误消息。
