NCP YAML 檔案包含用於設定、安裝和執行所有 NCP 元件的資訊。
- 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 部署規格
- 記錄層級和記錄目錄。
- Kubernetes API 伺服器 IP、憑證路徑和用戶端 Token 路徑。依預設，會使用來自環境變數的 API 伺服器 ClusterIP，並從 ServiceAccount 自動掛接憑證和 Token。通常不需要變更。
- Kubernetes 叢集名稱。
- NSX Manager IP 和認證。
- NSX 資源選項，例如 overlay_tz、top_tier_router、container_ip_blocks、external_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，請分別以使用者名稱和密碼指定 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 服務包檔案。若未設定，則系統將會使用系統 root 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 網繭規格，或取消註解範例密碼磁碟區。
- 將磁碟區掛接新增至 NCP 容器規格，或取消註解範例磁碟區掛接。
- 更新 ConfigMap 中的 ncp.ini，以設定指向已掛接磁碟區中檔案的憑證檔案路徑。
如果您沒有共用的第 1 層拓撲，則必須將 edge_cluster 選項設定為 Edge 叢集識別碼，以便 NCP 將為 Loadbalancer 服務建立第 1 層閘道或路由器。導覽至，選取 Edge 叢集索引標籤，然後按一下 Edge 叢集名稱，即可找到 Edge 叢集識別碼。
依預設，會啟用 HA (高可用性)。在生產環境中，建議您不要停用 HA。
附註：依預設，kube-scheduler 將不會排程主節點上的網繭。在 NCP YAML 檔案中，會新增容許，以允許 NCP 網繭在主節點上執行。
lb_segment_subnetNcp.ini 中的 參數用於服務 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 Worker 節點上，必須將 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 路由對應項目，以防止第 0 層路由器向 BGP 芳鄰通告叢集的內部子網路。這主要用於 vSphere with Kubernetes 叢集。如果您未針對重新分配規則建立路由對應，NCP 將使用其主體身分識別來建立路由對應，並在規則中加以套用。如果您想要修改此路由對應，必須將其取代為新的路由對應，並從 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、憑證路徑和用戶端 Token 路徑。依預設，會使用來自環境變數的 API 伺服器 ClusterIP，並從 ServiceAccount 自動掛接憑證和 Token。通常不需要變更。
- OpenvSwitch 上行連接埠。例如：ovs_uplink_port = eth1
- CNI 的 MTU 值。
若要設定 CNI 的 MTU 值，請修改 nsx-node-agent ConfigMap 中的 mtu 參數，然後重新啟動 nsx-ncp-bootstrap 網繭。這會更新每個節點上的網繭 MTU。您也必須相應地更新節點 MTU。節點與網繭 MTU 不符可能會導致節點與網繭的通訊出現問題，進而影響到 TCP 活躍度和整備情形探查 (舉例而言)。
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。請務必使用實際 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
如果您打算為網繭指定 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 轉譯為網繭 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 選項：
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 的所有執行個體。
啟用備份和還原
NCP 支援 NSX 中的備份和還原功能。支援的資源包括命名空間、網繭和服務。
附註：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 記錄中是否有錯誤訊息。
