NSX Container Plugin 3.0.0 版本說明

VMware NSX Container Plugin 3.0.0 | 2020 年 4 月 7 日 | 組建編號 15841604

請定期查看此文件的增補和更新。

版本說明的內容

此版本說明涵蓋下列主題：

新增功能
相容性需求
已解決的問題
已知問題

新增功能

NSX Container Plugin (NCP) 3.0.0 僅適用於 vSphere with Kubernetes 的客戶。請等待適用於所有其他 Kubernetes、Redhat 和 Pivotal 發行版的 NSX Container Plugin 3.0.1。

NSX Container Plugin 3.0.0 具有下列新功能：

支援放鬆負載平衡器服務的規模限制。針對原則 API，支援 Kubernetes 負載平衡器服務每個負載平衡器服務的集區成員限制。
支援 Kubernetes 負載平衡器服務和原則 API 入口的來源 IP 白名單。

相容性需求

產品	版本
NSX-T	3.0.0
vSphere with Kubernetes	7.0

支援升級至此版本：

所有 NCP 2.5.x 版本

已解決的問題

問題 2370137：由於 OVS 資料庫檔案不在 /etc/openvswitch 中，因此 nsx-ovs 和 nsx-node-agent 容器無法執行
當 nsx-ovs 和 nsx-node-agent 容器啟動時，它們會在 /etc/openvswitch 中尋找 OVS 資料庫檔案。如果連結至實際 OVS 檔 (例如 conf.db) 的目錄中存在符號連結，則 nsx-ovs 和 nsx-node-agent 容器不會執行。
問題 2451442：重複重新啟動 NCP 並重新建立命名空間後，NCP 可能無法將 IP 位址配置給網繭
如果您在重新啟動 NCP 時重複刪除並重新建立相同的命名空間，NCP 可能無法將 IP 位址配置給該命名空間中的網繭。

因應措施：刪除與命名空間相關聯的所有失效 NSX 資源 (邏輯路由器、邏輯交換器和邏輯連接埠)，然後重新建立這些資源。

已知問題

問題 2131494：將入口類別從 nginx 變更為 nsx 之後，NGINX Kubernetes 入口仍然正常運作
當您建立 NGINX Kubernetes 入口時，NGINX 會建立流量轉送規則。如果將入口類別變更為任何其他值，即使您在變更類別後刪除 Kubernetes 入口，NGINX 也不會刪除規則，並且會繼續套用這些規則。這是 NGINX 的限制。

因應措施：若要刪除 NGINX 所建立的規則，請在類別值為 nginx 時刪除 Kubernetes 入口。然後，重新建立 Kubernetes 入口。
對於類型為 ClusterIP 的 Kubernetes 服務，不支援以用戶端 IP 為基礎的工作階段相似性
對於類型為 ClusterIP 的 Kubernetes 服務，NCP 不支援以用戶端 IP 為基礎的工作階段相似性。

因應措施：無
對於類型為 ClusterIP 的 Kubernetes 服務，不支援 hairpin-mode 旗標
對於類型為 ClusterIP 的 Kubernetes 服務，NCP 不支援 hairpin-mode 旗標。

因應措施：無
問題 2192489：停用 PAS 導向器組態中的「BOSH DNS 伺服器」後，Bosh DNS 伺服器 (169.254.0.2) 仍會顯示在容器的 resolve.conf 檔案中。
在執行 PAS 2.2 的 PAS 環境中，停用 PAS 導向器組態中的「BOSH DNS 伺服器」後，Bosh DNS 伺服器 (169.254.0.2) 仍會顯示在容器的 resove.conf 檔案中。這會導致具有完整網域名稱的 Ping 命令花費很長時間。PAS 2.1 不存在此問題。

因應措施：無。此為 PAS 問題。
問題 2224218：刪除服務或應用程式後，需要 2 分鐘才能將 SNAT IP 釋放回 IP 集區
如果您刪除服務或應用程式，並在 2 分鐘內重新建立，它將從 IP 集區取得新的 SNAT IP。

因應措施：刪除服務或應用程式後，如果您想要重複使用相同的 IP，則等待 2 分鐘之後再重新建立服務或應用程式。
問題 2330811：在 NCP 關閉的情況下建立類型 LoadBalancer 的 Kubernetes 服務時，NCP 重新啟動時可能不會建立服務
類型 LoadBalancer 的 Kubernetes 服務的 NSX-T 資源用盡時，您可以在刪除部分現有的服務後建立新服務。但是，如果您在 NCP 關閉時刪除並建立服務，NCP 將無法建立新服務。

因應措施：類型 LoadBalancer 的 Kubernetes 服務的 NSX-T 資源用盡時，在 NCP 關閉時請勿執行刪除和建立作業。
問題 2397438：重新啟動後，NCP 報告 MultipleObjects 錯誤
在重新啟動之前，NCP 無法建立分散式防火牆區段，因為發生 ServerOverload 錯誤。NCP 會重試，直到達到嘗試的次數上限為止。但是，防火牆區段仍會建立。當 NCP 重新啟動時，它會收到重複的防火牆區段，並報告 MultipleObjects 錯誤。

因應措施：手動刪除失效和重複的分散式防火牆區段，然後重新啟動 NCP。
問題 2397684：NCP 找到正確的傳輸區域，但隨後會失敗，並顯示錯誤「預設的傳輸區域未設定」
當您使用原則 API 型 NCP 建立 Kubernetes 命名空間時，基礎結構區段建立可能會因為 NSX-T 中存在多個覆疊傳輸區域而失敗。如果未將任何覆疊傳輸區域標記為預設值，就會發生此問題。

因應措施：更新 NCP ConfigMap 中設定的覆疊傳輸區域，並將「is_default」欄位設定為「True」。
問題 2404302：如果 NSX-T 上存在相同資源類型 (例如 HTTP) 的多個負載平衡器應用程式設定檔，NCP 將選擇其中任何一個來連結至虛擬伺服器。
如果 NSX-T 上存在多個 HTTP 負載平衡器應用程式設定檔，則 NCP 會選擇其中任何一個具有適當 x_forwarded_for 組態的設定檔，來連結至 HTTP 和 HTTPS 虛擬伺服器。如果 NSX-T 上存在多個 FastTCP 和 UDP 應用程式設定檔，則 NCP 會分別選擇其中一個以連結至 TCP 和 UDP 虛擬伺服器。負載平衡器應用程式設定檔可能已由具有不同設定的不同應用程式建立。如果 NCP 選擇將其中一個負載平衡器應用程式設定檔連結至 NCP 建立的虛擬伺服器，則可能會中斷其他應用程式的工作流程。

因應措施：無
問題 2397621：OpenShift 安裝失敗
OpenShift 安裝預期節點的狀態為就緒，而在安裝 CNI 外掛程式之後這是可能的。在此版本中，並沒有單獨的 CNI 外掛程式檔案，因而導致 OpenShift 安裝失敗。

因應措施：開始安裝前，先在每個節點上建立 /etc/cni/net.d 目錄。
問題 2408100：在多個 NCP 執行個體處於作用中/待命模式或是已啟用活躍性探查的大型 Kubernetes 叢集中，NCP 經常重新啟動
在大型 Kubernetes 叢集中 (大約 25,000 個網繭、2,500 個命名空間和 2,500 個網路原則)，如果多個 NCP 執行個體在作用中/待命模式下執行，或是啟用了活躍性探查，則 NCP 程序可能會因為「取得鎖定衝突」或活躍性探查失敗而經常遭刪除並重新啟動。

因應措施：執行下列步驟：
1. 將 NCP 部署的 replicas 設定為 1，或將 ncp.ini 的組態選項 ha.master_timeout 從預設值 18 提高到 30。
2. 提高活躍性探查引數，如下所示：
```
  containers: 
    - name: nsx-ncp
      livenessProbe: 
        exec: 
          命令：
            - /bin/sh
            - -c
            - timeout 20 check_pod_liveness nsx-ncp
        initialDelaySeconds: 20
        timeoutSeconds: 20
        periodSeconds: 20
        failureThreshold: 5
```
問題 2412421：Docker 無法重新啟動容器
如果 (1) ConfigMap 已更新，(2) 容器使用 subPath 掛接 ConfigMap，並且 (3) 容器重新啟動，則 Docker 無法啟動容器。

因應措施：刪除網繭，讓 DaemonSet 重新建立網繭。
問題 2413383：OpenShift 升級失敗，因為並非所有節點都已就緒
依預設，不會在主節點上排程 NCP 啟動程序網繭。因此，主節點狀態永遠是「未就緒」。

因應措施：指派具有「運算」角色的主節點，以允許 nsx-ncp-bootstrap 和 nsx-node-agent DaemonSet 建立網繭。nsx-ncp-bootstrap 安裝 NSX CNI 後，節點狀態會變更為「就緒」。
問題 2410909：重新啟動後，在大型環境中 NCP 可能需要很長的時間來初始化快取 (尤其是有多個網路原則時)，並且可能需要大約半小時的時間來啟動並處理新的網繭和資源
重新啟動後，NCP 可能需要很長時間才能啟動。處理資源 (如網繭、命名空間和網路原則) 可能需要額外的時間，具體取決於所涉及的資源數量。

因應措施：無
問題 2447127：將 NCP 從 2.4.1 升級至 2.5.0 或 2.5.1 時，NCP 可能需要額外的時間才能啟動並執行
在 NCP 從 2.4.1 升級至 2.5.x 的過程中，當 NCP 呼叫交換設定檔 API 以進行領導選舉時，NSX-T 2.4.1 可能會發生回應速度緩慢的問題。這會導致 NCP 須額外花費數分鐘才能啟動並執行。

因應措施：無。
問題 2460219：在沒有預設伺服器集區的情況下，HTTP 重新導向無法正常運作
如果 HTTP 虛擬伺服器未繫結至伺服器集區，HTTP 重新導向就會失敗。此問題出現在 NSX-T 2.5.0 及更早版本中。

因應措施：建立預設伺服器集區或升級至 NSX-T 2.5.1。
問題 2518111：NCP 無法刪除已從 NSX-T 更新的 NSX 資源
NCP 會根據您指定的組態建立 NSX-T 資源。如果您透過 NSX Manager 或 NSX API 對這些 NSX-T 資源進行任何更新，則 NCP 可能無法刪除這些資源，且會在必要時重新建立這些資源。

因應措施：請勿透過 NSX Manager 或 NSX-T API 更新由 NCP 建立的 NSX-T 資源。
問題 2518312：NCP 啟動程序容器無法在 Ubuntu 18.04.4 核心 4.15.0-88 上安裝 nsx-ovs 核心模組。
NCP 啟動程序容器 (nsx-ncp-bootstrap) 無法在 Ubuntu 18.04.4 核心 4.15.0-88 上安裝 nsx-ovs 核心模組。

請勿透過在 nsx-node-agent-config 中設定 use_nsx_ovs_kernel_module = False 以在此核心上安裝 NSX-OVS。請改用主機上的上游 OVS 核心模組 (Ubuntu 依預設會隨附於 OVS 核心模組)。如果主機上沒有任何 OVS 核心模組，請手動安裝 OVS 核心模組，並在 nsx-node-agent-config 中設定 use_nsx_ovs_kernel_module = False，或將核心版本降級至 4.15.0-76，以便可以安裝 NSX-OVS。
問題 2524778：刪除 NCP 主節點後，NSX Manager 會將 NCP 顯示為關閉或狀況不良
刪除 NCP 主節點後，例如，在成功切換至備份節點後，當 NCP 的健全狀況狀態應為開啟時，仍會顯示為關閉。

因應措施：使用 Manager API DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status 手動清除過時狀態。
問題 2517201：無法在 ESXi 主機上建立網繭
從 vSphere 叢集中移除 ESXi 主機並將其新增回叢集後，在主機上建立網繭會失敗。

因應措施：將 NCP 重新開機。
問題 3033821：在完成管理程式至原則移轉後，分散式防火牆規則無法正確強制執行
在完成管理程式至原則移轉後，新建立的網路原則相關分散式防火牆 (DFW) 規則的優先順序將高於已移轉的 DFW 規則。

因應措施：視需要使用原則 API 變更 DFW 規則的順序。