NCP YAML 檔案包含用於設定、安裝和執行所有 NCP 元件的資訊。

NCP YAML 檔案包含下列資訊:
  • RBAC 定義。
  • 各種 CRD (CustomResourceDefinitions)。
  • ConfigMap 包含 NCP 專用的 ncp.ini。已設定一些建議的組態選項。
  • NCP 部署。
  • ConfigMap 包含 nsx-node-agent 專用的 ncp.ini。已設定一些建議的組態選項。
  • 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、憑證路徑和用戶端 Token 路徑。依預設,會使用來自環境變數的 API 伺服器 ClusterIP,並從 ServiceAccount 自動掛接憑證和 Token。通常不需要變更。
  • Kubernetes 叢集名稱。
  • NSX Manager IP 和認證。
  • NSX 資源選項,例如 overlay_tztop_tier_routercontainer_ip_blocksexternal_ip_blocks 等等。

依預設,Kubernetes 服務 VIP/連接埠和 ServiceAccount Token 和 ca_file 會用於 Kubernetes API 存取。此處不需要變更,但您需要填寫 ncp.ini 的部分 NSX API 選項。

  • 指定 nsx_api_managers 選項。它可以是符合 RFC3896 的 NSX Manager IP 位址或 URL 規格以逗點分隔的清單。例如,
    nsx_api_managers = 192.168.1.181, 192.168.1.182, 192.168.1.183
  • 如果您將 NCP 設定為使用基本驗證連線至 NSX-T,請分別以使用者名稱和密碼指定 nsx_api_usernsx_api_password 選項。由於此方式較不安全,不建議使用此驗證方法。如果將 NCP 設定為使用用戶端憑證進行驗證,則會略過這些選項。這些選項不會顯示在 NCP YAML 檔案中。您必須手動新增。
  • 指定使用 NSX-T 進行驗證的 nsx_api_cert_filensx_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 網繭規格,或取消註解範例密碼磁碟區。
  • 將磁碟區掛接新增至 NCP 容器規格,或取消註解範例磁碟區掛接。
  • 更新 ConfigMap 中的 ncp.ini,以設定指向已掛接磁碟區中檔案的憑證檔案路徑。

如果您沒有共用的第 1 層拓撲,則必須將 edge_cluster 選項設定為 Edge 叢集識別碼,以便 NCP 將為 Loadbalancer 服務建立第 1 層閘道或路由器。導覽至系統 > 網狀架構 > 節點,選取 Edge 叢集索引標籤,然後按一下 Edge 叢集名稱,即可找到 Edge 叢集識別碼。

依預設,會啟用 HA (高可用性)。在生產環境中,建議您不要停用 HA。

附註:依預設,kube-scheduler 將不會排程主節點上的網繭。在 NCP YAML 檔案中,會新增容許,以允許 NCP 網繭在主節點上執行。

設定 SNAT

依預設,NCP 會為每個專案設定 SNAT。將不會為具有下列註解的命名空間設定 SNAT:
ncp/no_snat: True
如果您不想將 SNAT 用於叢集中的任何命名空間,請在 ncp.ini 中設定下列選項:
[coe]
enable_snat = False

附註:不支援更新現有的命名空間 SNAT 註解。如果執行此類動作,則命名空間的拓撲將處於不一致的狀態,因為可能仍會有失效的 SNAT 規則。若要從這種不一致的狀態復原,您必須重新建立命名空間。

(僅限原則模式) 如果針對叢集設定 SNAT,則會啟用第 0 層路由器上的 BGP,且當您設定第 0 層路由器的路由重新分配時,會在 Advertised tier-1 subnets 下選取 Connected Interfaces & Segments,您可以使用下列選項來控制路由重新分配:
[nsx_v3]
configure_t0_redistribution = True 

如果 configure_t0_redistribution 設定為 True,NCP 將在重新分配規則中新增 deny 路由對應項目,以防止第 0 層路由器向 BGP 芳鄰通告叢集的內部子網路。這主要用於 vSphere with Kubernetes 叢集。如果您未針對重新分配規則建立路由對應,NCP 將使用其主體身分識別來建立路由對應,並在規則中加以套用。如果您想要修改此路由對應,必須將其取代為新的路由對應,並從 NCP 建立的路由對應中複製項目,然後新增項目。您必須管理新項目與 NCP 所建立項目之間的任何潛在衝突。如果您只是取消設定 NCP 所建立的路由對應,而不建立重新分配規則的新路由對應,NCP 會在 NCP 重新啟動時,再次將先前建立的路由對應套用至重新分配規則。

更新 nsx-node-agent DaemonSet 規格

找到名稱為 nsx-node-agent-config 的 ConfigMap。如需 ConfigMap 選項的完整清單,請參閱 nsx-node-agent-config ConfigMap。部分選項已設定為建議的值。您可以針對您的環境自訂所有選項。例如,
  • 記錄層級和記錄目錄。
  • Kubernetes API 伺服器 IP、憑證路徑和用戶端 Token 路徑。依預設,會使用來自環境變數的 API 伺服器 ClusterIP,並從 ServiceAccount 自動掛接憑證和 Token。通常不需要變更。
  • OpenvSwitch 上行連接埠。例如:ovs_uplink_port=eth1

nsx-ncp-bootstrap DaemonSet 會在節點上安裝 CNI 和 OVS 核心模組。然後,它會關閉節點上的 OVS 精靈,以便稍後 nsx-ovs 容器可以在 Docker Container 內執行 OVS 精靈。未安裝 CNI 時,所有 Kubernetes 節點都會處於「未就緒」狀態。啟動程序 DaemonSet 上有容許可允許它在「未就緒」節點上執行。安裝 CNI 外掛程式後,節點應變更為「就緒」。

如果不是使用 NSX OVS 核心模組,則必須以編譯 OVS 核心模組期間設定 OpenvSwitch 資料庫所在的正確路徑更新磁碟區參數 host-original-ovs-db。例如,如果您指定 --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 節點代理程式是每個網繭用來執行 3 個容器的 DaemonSet:
  • nsx-node-agent 會管理容器網路介面。它會與 CNI 外掛程式和 Kubernetes API 伺服器互動。
  • nsx-kube-proxy 透過將叢集 IP 轉譯為網繭 IP,以實作 Kubernetes 服務擷取。它可實現與上游 kube-proxy 相同的功能,但不會與其互斥。
  • nsx-ovs 會執行 OpenvSwitch 使用者空間精靈。它也會自動建立 OVS 橋接器,並將 IP 位址和路由從 node-if 移回到 br-int。您必須在 ncp.ini 中新增 ovs_uplink_port=ethX,才能使用 ethX 做為 OVS 橋接器上行。

如果 Worker 節點使用 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

附註:如果 kubelet 在使用 hyperkube 映像的容器內執行,則 kubelet 一律會將 AppArmor 報告為已停用狀態,無論實際狀態為何。必須進行上述的相同變更,並將其套用至 YAML 檔案。

更新命名空間名稱

在 YAML 檔案中,會在 nsx-system 命名空間下建立所有命名空間物件 (例如 ServiceAccount、ConfigMap、Deployment)。如果您使用不同的命名空間,請取代 nsx-system 的所有執行個體。