|
VMware NSX Container Plugin 3.1.1 | 2021 年 2 月 4 日 | 組建編號 17559186 請定期查看此文件的增補和更新。 |
版本說明的內容
此版本說明涵蓋下列主題：
新增功能
- 透過 Operator 簡化 Kubernetes 叢集的 NCP 部署和管理
- 當節點上無法使用 nsx-node-agent 時設定節點的 NetworkUnavaialble 條件 (透過 Operator)
- 啟用 SNAT 規則的記錄
- OCP4 的路由器分區
- 針對 Kubernetes 叢集多點傳播至第 1 層
- 在入口虛擬伺服器上啟用存取記錄
- 在負載平衡器上啟用 TCP 多工處理
- 支援透過 hostPort 存取網繭
棄用通知
註解「ncp/whitelist-source-range」將在 NCP 3.3 中棄用。從 NCP 3.1.1 開始，您可以改用註解「ncp/allowed-source-range」。
相容性需求
| 產品 | 版本 |
|---|---|
| Tanzu 應用程式服務 (PCF) 的 NCP/NSX-T 圖標 | 3.1.1 |
| NSX-T | 3.0.2、3.1.0、3.1.1 |
| vSphere | 6.7、7.0 |
| Kubernetes | 1.18 (P1)、1.19、1.20 |
| OpenShift 3 | 3.11 附註：在未來版本中，OpenShift 3.x 支援將變為棄用。 |
| OpenShift 4 | RHCOS 4.5、4.6 |
| Kubernetes 主機虛擬機器作業系統 | Ubuntu 18.04、Ubuntu 20.04 CentOS 7.8、CentOS 7.9、CentOS 8.2 RHEL 7.8、RHEL 7.9、RHEL 8.3 (附註：在未來版本中，對原始版本 Kubernetes 的 RHEL 支援將變為棄用。） 請參閱以下附註。 |
| OpenShift 主機虛擬機器作業系統 | RHEL 7.7、RHEL 7.8 (附註：在未來版本中，對原始版本 Kubernetes 的 RHEL 支援將變為棄用。） |
| Tanzu 應用程式服務 (Pivotal Cloud Foundry) | Ops Manager 2.7 + PAS 2.7 (LTS) Ops Manager 2.9 + PAS 2.9 Ops Manager 2.10 + PAS 2.10 |
| Tanzu Kubernetes Grid Integrated (TKGI) | 1.10 |
附註：
在 CentOS/RHEL 上安裝 nsx-ovs 核心模組需要特定的核心版本。無論 RHEL 版本為何，支援的 RHEL 核心版本都是 1127、1160 和 193。請注意，RHEL 7.8 的預設核心版本為 1127、RHEL 7.9 是 1160，而 RHEL 8.2 是 193。如果您執行其他的核心版本，則可以略過 nsx-ovs 核心模組的安裝，方法是在 nsx-node-agent ConfigMap 的「nsx_node_agent」區段下方，將「use_nsx_ovs_kernel_module」設定為「False」。
若要在 RHEL 8.2 (核心版本 193) 上執行 nsx-ovs 核心模組，您必須在 vCenter Server 的虛擬機器設定中，停用「開機選項」下方的「UEFI 安全開機」選項。
支援升級至此版本：
- NCP 3.1 及所有 NCP 3.0.x 版本
已解決的問題
- 問題 2671647：重新啟動 OVS 精靈 ovsdb-server 和 ovs-vswitchd 的 monit 工作時，OVS 流量會遺失
如果使用「monit restart <process-name>」命令重新啟動 openvswitch 精靈的 monit 工作，由 nsx-node-agent 建立的 OVS 流量將會遺失
因應措施：在 openvswitch 精靈恢復「執行中」狀態後，使用「monit restart nsx-node-agent」命令執行 nsx-node-agent 的重新啟動
- 問題 2674503：nsx-ncp-bootstrap 不支援在 CentOS 7.8、8.1、8.2 或 RHEL 7.8、8.1、8.2 上安裝 NSX OVS 核心模組
nsx-ncp-bootstrap 容器不支援在 CentOS 7.8、8.1、8.2 或 RHEL 7.8、8.1、8.2 上安裝 NSX OVS 核心模組。
因應措施：在 NSX 節點代理程式 ConfigMap 中，將
use_nsx_ovs_kernel_module設定為False，並使用 Linux 上游 OVS 核心模組。
已知問題
- 問題 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 分鐘之後再重新建立服務或應用程式。
- 問題 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 3 安裝失敗
OpenShift 3 安裝預期節點的狀態為就緒，而在安裝 CNI 外掛程式之後這是可能的。在此版本中，並沒有單獨的 CNI 外掛程式檔案，因而導致 OpenShift 安裝失敗。
因應措施：開始安裝前，先在每個節點上建立 /etc/cni/net.d 目錄。
- 問題 2413383：OpenShift 3 升級失敗，因為並非所有節點都已就緒
依預設，不會在主節點上排程 NCP 啟動程序網繭。因此，主節點狀態永遠是「未就緒」。
因應措施：指派具有「運算」角色的主節點，以允許 nsx-ncp-bootstrap 和 nsx-node-agent DaemonSet 建立網繭。nsx-ncp-bootstrap 安裝 NSX CNI 後，節點狀態會變更為「就緒」。
- 問題 2451442：重複重新啟動 NCP 並重新建立命名空間後，NCP 可能無法將 IP 位址配置給網繭
如果您在重新啟動 NCP 時重複刪除並重新建立相同的命名空間，NCP 可能無法將 IP 位址配置給該命名空間中的網繭。
因應措施：刪除與命名空間相關聯的所有失效 NSX 資源 (邏輯路由器、邏輯交換器和邏輯連接埠)，然後重新建立這些資源。
- 問題 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 資源。
- 問題 2524778：刪除 NCP 主節點後，NSX Manager 會將 NCP 顯示為關閉或狀況不良
刪除 NCP 主節點後，例如，在成功切換至備份節點後，當 NCP 的健全狀況狀態應為開啟時，仍會顯示為關閉。
因應措施：使用 Manager API DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status 手動清除過時狀態。
- 問題 2517201：無法在 ESXi 主機上建立網繭
從 vSphere 叢集中移除 ESXi 主機並將其新增回叢集後，在主機上建立網繭會失敗。
因應措施：將 NCP 重新開機。
- 問題 2416376：NCP 無法處理繫結到超過 128 個空間的 PAS ASG (應用程式安全群組)
由於 NSX-T 分散式防火牆中的限制，NCP 無法處理繫結到超過 128 個空間的 PAS ASG。
因應措施：建立多個 ASG，並將每個 ASG 繫結到不超過 128 個空間。
- 問題 2534726：如果透過 NSX-T 動態磚升級至 NCP 3.0.1 失敗，則使用 BOSH 命令列重做升級會導致效能問題
透過 OpsMgr 上的 NSX-T 動態磚升級至 NCP 3.0.1 時，升級程序會在 NCP 所使用的 NSX Manager 中將 HA 交換設定檔標記為非作用中狀態。當 NCP 重新開機時，將會刪除交換設定檔。如果升級失敗，且您使用 BOSH 命令 (例如「bosh deploy -d <deployment-id> -n <deployment>.yml」) 來重做升級，則不會刪除 HA 交換設定檔。NCP 仍會執行，但效能將會降級。
因應措施：一律透過 OpsMgr 而非 BOSH 命令列來升級 NCP。
- 問題 2537221：將 NSX-T 升級至 3.0 之後，NSX Manager UI 中容器相關物件的網路狀態會顯示為「未知」
在 NSX Manager UI 中，[詳細目錄] > [容器] 索引標籤會顯示容器相關物件及其狀態。在 PKS 環境中，將 NSX-T 升級至 3.0 後，容器相關物件的網路狀態會顯示為「未知」。此問題是由於 PKS 未偵測到 NSX-T 的版本變更所致。如果 NCP 以網繭的形式執行，且活躍性探查處於作用中狀態，則不會發生此問題。
因應措施：在 NSX-T 升級後，逐漸重新啟動 NCP 執行個體 (同時間不超過 10 個)，以免 NSX Manager 超載。
- 問題 2550474：在 OpenShift 環境中，將 HTTPS 路由變更為 HTTP 可能會導致 HTTP 路由無法如預期運作
如果您編輯 HTTPS 路由並刪除 TLS 相關資料，以將其轉換為 HTTP 路由，則 HTTP 路由可能無法如預期運作。
因應措施：刪除 HTTPS 路由，然後建立新的 HTTP 路由。
- 問題 2552573：在 OpenShift 4.3 環境中，如果使用原則 UI 設定 DHCP，則叢集安裝可能會失敗
在 OpenShift 4.3 環境中，叢集安裝需要 DHCP 伺服器可供使用，才能提供 IP 位址和 DNS 資訊。如果您使用透過原則 UI 在 NSX-T 中設定的 DHCP 伺服器，則叢集安裝可能會失敗。
因應措施：使用管理程式 UI 來設定 DHCP 伺服器，刪除安裝失敗的叢集，然後重新建立叢集。
- 問題 2552564：在 OpenShift 4.3 環境中，如果找到重疊位址，則 DNS 轉寄站可能會停止運作
在 OpenShift 4.3 環境中，叢集安裝需要設定 DNS 伺服器。如果您使用 NSX-T 來設定 DNS 轉寄站，且 IP 位址與 DNS 服務重疊，則 DNS 轉寄站將停止運作，且叢集安裝將失敗。
因應措施：設定外部 DNS 服務，刪除安裝失敗的叢集，然後重新建立叢集。
- 問題 2483242：NSX-T SpoofGuard 已封鎖來自容器的 IPv6 流量
IPv6 連結本機位址未在啟用 SpoofGuard 的情況下自動列入白名單。
因應措施：透過在 NCP 組態中設定 nsx_v3.enable_spoofguard = False 來停用 SpoofGuard。
- 問題 2552609 - X 轉送 (XFF) 和 X 轉送連接埠資料錯誤
如果您針對 HTTPS 入口規則 (Kubernetes) 或 HTTPS 路由 (OpenShift) 使用「插入」或「取代」來設定 XFF，則可能會在 XFF 標頭中看到錯誤的 X 轉送值和 X 轉送連接埠值。
因應措施：無。
- 問題 2555336：由於在管理程式模式中建立的邏輯連接埠重複，因此網繭流量無法運作
當多個叢集中有許多網繭時，可能會發生此問題。當您建立網繭時，網繭的流量無法運作。NSX-T 會顯示針對相同容器所建立的多個邏輯連接埠。在 NCP 記錄中，僅能找到其中一個邏輯連接埠的識別碼。
因應措施：刪除網繭並加以重新建立。當 NCP 重新啟動時，將會移除 NSX-T 上的失效連接埠。
- 問題 2554357：負載平衡器自動調整功能不適用於 IPv6
在 IPv6 環境中，當達到現有的負載平衡器規模時，類型為 LoadBalancer 的 Kubernetes 服務將不會處於作用中狀態。
因應措施：針對 PKS 部署設定 nsx_v3.lb_segment_subnet = FE80::/10 in /var/vcap/jobs/ncp/config/ncp.ini，並針對其他部分設定 nsx-ncp-configmap。然後重新啟動 NCP。
- 問題 2597423：將管理程式物件匯入原則時，復原會導致部分資源的標籤遺失
將管理程式物件匯入原則時，如果有必要復原，將不會還原下列物件的標籤：
- Spoofguard 設定檔 (共用和叢集資源的一部分)
- BgpneighbourConfig (共用資源的一部分)
- BgpRoutingConfig (共用資源的一部分)
- StaticRoute BfdPeer (共用資源的一部分)
因應措施：對於屬於共用資源一部分的資源，請手動還原標籤。使用備份和還原功能來還原屬於叢集資源一部分的資源。
- 問題 2579968：對類型為 LoadBalancer 的 Kubernetes 服務進行高頻率的變更時，某些虛擬伺服器和伺服器集區不會如預期般刪除
對類型為 LoadBalancer 的 Kubernetes 服務進行高頻率的變更時，某些虛擬伺服器和伺服器集區可能會在應已刪除時仍保留在 NSX-T 環境中。
因應措施：重新啟動 NCP。或者，手動移除失效的虛擬伺服器及其相關聯的資源。如果類型為 LoadBalancer 的 Kubernetes 服務在 external_id 標籤中有虛擬伺服器的識別碼，則虛擬伺服器會失效。
- 問題 2536383：將 NSX-T 升級至 3.0 或更新版本後，NSX-T UI 不會正確顯示 NCP 相關的資訊
將 NSX-T 升級至 3.0 或更新版本後，NSX-T UI 中的詳細目錄 > 容器索引標籤會將容器相關物件的網路狀態顯示為「未知」。此外，NCP 叢集不會顯示在系統 > 網狀架構 > 節點 > NCP 叢集索引標籤中。此問題通常出現在 PKS 環境中。
因應措施：在 NSX-T 升級後，逐步重新啟動 NCP 執行個體 (同時間不超過 10 個)。
- 問題 2622099：類型為 LoadBalancer 的 Kubernetes 服務初始化失敗，並顯示錯誤碼 NCP00113 和錯誤訊息「物件已由其他人修改」
在具有原則 API 的單層部署中，如果您使用現有的第 1 層閘道作為頂層閘道，而閘道的集區配置大小為 ROUTING，則類型為 LoadBalancer 的 Kubernetes 服務可能無法初始化，並顯示錯誤碼 NCP00113 和錯誤訊息「物件已由其他人修改。請重試。」
因應措施：當問題出現時，請等待 5 分鐘。然後重新啟動 NCP。問題將會解決。
- 問題 2633679：NCP Operator 不支援連結至使用 API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> 所建立第 1 層區段的 OpenShift 節點
NCP Operator 不支援連結至使用 API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id> 所建立第 1 層區段的 OpenShift 節點。
因應措施：使用 API /policy/api/v1/infra/segments/<segment-id> 來建立區段。
- 在 Kubernetes 安裝期間啟用「記錄至檔案」時，NCP 無法啟動
當容器主機上的 uid:gid=1000:1000 沒有記錄資料夾的權限時，即會發生此問題。
因應措施：請執行下列其中一個動作：
- 將容器主機上記錄資料夾的模式變更為 777。
- 將容器主機上記錄資料夾的「rwx」權限授與 uid:gid=1000:1000。
- 停用「記錄至檔案」功能。
- 問題 2653214：在節點的 IP 位址變更後搜尋節點的區段連接埠時發生錯誤
變更節點的 IP 位址後，如果您升級 NCP，或 NCP Operator 網繭重新啟動，當您使用「oc describe co nsx-ncp」命令檢查 NCP Operator 狀態時，將會顯示錯誤訊息「在搜尋節點的區段連接埠時發生錯誤 ...」
因應措施：無。不支援在同時具有 DHCP 組態的節點介面上新增靜態 IP 位址。
- 問題 2664457：在 OpenShift 中使用 DHCP 期間，當 nsx-node-agent 啟動或重新啟動時，連線可能會暫時中斷
nsx-ovs 會建立並啟動 5 個暫時的連線設定檔以設定 ovs_bridge，但在 NetworkManager 中這些設定檔可能會暫時無法啟用。因此，ovs_uplink_port 和/或 ovs_bridge 上的虛擬機器不會有 IP (連線) 存在。
因應措施：重新開機虛擬機器，或等待 NetworkManager 成功啟用所有設定檔。
- 問題 2672677：在高負荷的 OpenShift 4 環境中，節點可能會沒有回應
在個別節點具有高網繭密度，且頻繁刪除和建立網繭的 OpenShift 4 環境中，RHCOS 節點可能會進入「未就緒」狀態。在受影響的節點上執行的網繭 (daemonset 成員除外)，將會在環境中的其他節點上收回並重新建立。
因應措施：將受影響的節點重新開機。
- 問題 2706551：OpenShift 的完整堆疊自動安裝 (稱為 IPI) 失敗，因為節點在安裝期間變成未就緒狀態
keepalived 網繭會先將 Kubernetes VIP 新增至主要節點上的 ovs_bridge，接著 Kubernetes API 伺服器才會在上面開始執行。因此，對 Kubernetes API 伺服器的所有要求都會失敗，且無法完成安裝。
因應措施：無
- 問題 2707883：如果 NCP 相關的 Kubernetes 資源在 nsx-ncp-operator 未運作時遭到刪除，則 nsx-ncp-operator 不會建立該資源。
例如，如果您在 nsx-ncp-operator 未執行時刪除 nsx-node-agent 或 nsx-ncp-bootstrap DaemonSet，則當 nsx-ncp-operator 再次執行時，將不會重新建立該資源。
因應措施：在 nsx-ncp-operator ConfigMap 中更新任何欄位，例如當 nsx-ncp-operator 再次執行時，更新 [預設] 區段中的 log_level。
- 問題 2697547：RHEL/CentOS/RHCOS 節點不支援 HostPort
您可以在 Ubuntu 節點上指定原生 Kubernetes 和 PKS 的 HostPort，方法是在 nsx-node-agent ConfigMap 中將「enable_hostport_snat」設定為 True。但是在 RHEL/CentOS/RHCOS 節點上不支援 hostPort，且系統會忽略參數「enable_hostport_snat」。
因應措施：無
- 問題 2707174：刪除後再以相同命名空間及名稱重新建立的網繭不具有網路連線
如果在 NCP 未執行而 nsx-ncp-agents 執行時刪除網繭，並使用相同的命名空間和名稱重新建立網繭，則網繭可能會取得錯誤的網路組態，且無法存取網路。
因應措施：在 NCP 執行時刪除網繭並重新建立。
- 問題 2713782：NSX API 呼叫失敗，並出現錯誤「SSL：DECRYPTION_FAILED_OR_BAD_RECORD_MAC」
有時候，NCP 在啟動時可能會重新開機或無法初始化負載平衡器服務。此外，當 NCP 正在執行時，NSX 端點可能會報告為「關閉」一小段時間 (少於 1 秒)。如果負載平衡器無法初始化，NCP 記錄將會顯示訊息「無法初始化負載平衡器服務。」
因應措施：增加 nsx_v3.conn_idle_timeout 參數的值。請注意，使用用戶端負載平衡時，這可能導致暫時中斷連接後，系統需要較長的等待時間才能將端點偵測為可供使用。
- 問題 3033821：在完成管理程式至原則移轉後，分散式防火牆規則無法正確強制執行
在完成管理程式至原則移轉後，新建立的網路原則相關分散式防火牆 (DFW) 規則的優先順序將高於已移轉的 DFW 規則。
因應措施：視需要使用原則 API 變更 DFW 規則的順序。
