編輯 NCP YAML 檔案

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_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-T
    ,請分別以使用者名稱和密碼指定
    nsx_api_user
    nsx_api_password
    選項。由於此方式較不安全,不建議使用此驗證方法。如果將 NCP 設定為使用用戶端憑證進行驗證,則會略過這些選項。這些選項不會顯示在 NCP YAML 檔案中。您必須手動新增。
  • 指定
    nsx_api_cert_file
    nsx_api_private_key_file
    選項以便用於
    NSX-T
    的驗證。
    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 服務包檔案。若未設定,則系統將會使用系統 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
如果您想要使用 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 網繭在主節點上執行。
lb_segment_subnet
Ncp.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 會為每個專案設定 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 重新啟動時,再次將先前建立的路由對應套用至重新分配規則。

為 NAT 規則設定防火牆比對

從 NCP 3.2.1 開始,您可以使用
natfirewallmatch
選項,透過為 Kubernetes 命名空間建立的 NAT 規則來指定
NSX-T
閘道防火牆的行為方式。此選項僅適用於新建立的 Kubernetes 命名空間,而不適用於現有命名空間。此選項僅適用於原則模式。
[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 規格

找到名稱為
nsx-node-agent-config
的 ConfigMap。如需 ConfigMap 選項的完整清單,請參閱 nsx-node-agent-config ConfigMap。部分選項已設定為建議的值。您可以針對您的環境自訂所有選項。例如,
  • 記錄層級和記錄目錄。
  • 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
SNAT 會使用
hostIP
作為
hostPort
流量的來源 IP。如果有網繭的網路原則,而您想要存取網繭的
hostPort
,則必須在網路原則的允許規則中新增 Worker 節點 IP 位址。例如,如果您有兩個工作節點 (172.10.0.2 和 172.10.0.3),則入口規則必須顯示如下:
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 節點代理程式是每個網繭用來執行 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
的所有執行個體。

啟用備份和還原

NCP 支援
NSX-T
中的備份和還原功能。支援的資源包括命名空間、網繭和服務。
附註:NCP 必須設定成原則模式。
若要啟用此功能,請在
ncp.ini
中將
enable_restore
設為
True
,並重新啟動 NCP。
[k8s] enable_restore = True
您可以使用 NSX CLI 命令來檢查還原的狀態。例如,
nsxcli > get ncp-restore status NCP restore status is INITIAL
狀態可能是 INITIAL、RUNNING 或 SUCCESS。INITIAL 表示備份/還原功能已就緒,但還原不在執行中。RUNNING 表示 NCP 中正在執行還原程序。SUCCESS 表示已成功完成還原。如果在還原期間出現錯誤,NCP 會自動重新啟動並重試。如果長時間處於 RUNNING 狀態,請檢查 NCP 記錄中是否有錯誤訊息。