VMware NSX Container Plugin 3.0

4.2 4.1 4.0 3.2 3.1 3.0
简体中文 Deutsch Español Français Italiano 日本語 한국어 繁體中文 English

编辑 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。
注意：默认情况下，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 在重新启动时会再次将先前创建的路由映射应用到重新分发规则。

更新 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 OVS 内核模块，则必须将卷参数
host-original-ovs-db
 更新为正确路径，即在 OVS 内核模块编译期间将 OpenvSwitch 数据库配置到的路径。例如，如果您指定
--sysconfdir=/var/lib
，则需将
host-original-ovs-db
 设置为
/var/lib/openvswitch
。
如果使用 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
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
 的所有实例。

Content feedback and comments