编辑 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-T，请分别使用用户名和密码指定 nsx_api_user 和 nsx_api_password 选项。不建议使用此身份验证方法，因为它的安全性较差。如果将 NCP 配置为使用客户端证书进行身份验证，则系统会忽略这些选项。这些选项不会显示在 NCP YAML 文件中。您必须手动添加它们。
使用 NSX-T 指定要进行身份验证的 nsx_api_cert_file 和 nsx_api_private_key_file 选项。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。

默认情况下，NCP 会为每个项目配置 SNAT。不会为具有以下注释的命名空间配置 SNAT：

ncp/no_snat: True

如果您不希望集群中的任何命名空间具有 SNAT，请在 ncp.ini 中配置以下选项：

[coe]
enable_snat = False

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

更新 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

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

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 的所有实例。