times

VMware NSX Container Plugin 3.1.2 | 2021 年 4 月 15 日 | 組建編號 17855682

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

版本說明的內容

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

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

新增功能

NSX Container Plugin (NCP) 3.1.2 具有下列新功能：

針對第 7 層負載平衡器持續性，支援指定 Cookie 名稱

棄用通知

註解「ncp/whitelist-source-range」將在 NCP 3.3 中棄用。從 NCP 3.1.1 開始，您可以改用註解「ncp/allowed-source-range」。

相容性需求

產品	版本
Tanzu Application Service (TAS) 的 NCP/NSX-T 動態磚	3.1.2
NSX-T	3.0.3、3.1.0、3.1.1、3.1.2、3.1.3
vSphere	6.7、7.0
Kubernetes	1.18、1.19、1.20
OpenShift 3	3.11 附註：在未來版本中，OpenShift 3.x 支援將變為棄用。
OpenShift 4	RHCOS 4.6、4.7
Kubernetes 主機虛擬機器作業系統	Ubuntu 18.04、Ubuntu 20.04 CentOS 7.8、CentOS 7.9、CentOS 8.3 RHEL 7.8、RHEL 7.9、RHEL 8.1、RHEL 8.3 請參閱以下附註。
OpenShift 3 主機虛擬機器作業系統	RHEL 7.7、RHEL 7.8 (附註：在未來版本中，對原始版本 Kubernetes 的 RHEL 支援將變為棄用。）
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7 (LTS) Ops Manager 2.9 + TAS 2.9 Ops Manager 2.10 + TAS 2.10 Ops Manager 2.10 + TAS 2.11
Tanzu Kubernetes Grid Integrated (TKGI)	1.11

附註：

在 CentOS/RHEL 上安裝 nsx-ovs 核心模組需要特定的核心版本。無論 RHEL 版本為何，支援的 RHEL 核心版本都是 1127 和 1160。請注意，RHEL 7.8 的預設核心版本為 1127，而 RHEL 7.9 為 1160。如果您執行其他的核心版本，則可以略過 nsx-ovs 核心模組的安裝，方法是在 nsx-node-agent 組態對應的「nsx_node_agent」區段下方，將「use_nsx_ovs_kernel_module」設定為「False」。

從 NCP 3.1.2 開始，將不再發佈 RHEL 映像。針對所有支援的整合，請使用 Red Hat 通用基礎映像 (UBI)。如需詳細資訊，請參閱 https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image。

支援升級至此版本：

所有先前 3.1.x 版本及所有 NCP 3.0.x 版本

已解決的問題

問題 2707883：如果 NCP 相關的 Kubernetes 資源在 nsx-ncp-operator 未運作時遭到刪除，則 nsx-ncp-operator 不會建立該資源。
例如，如果您在 nsx-ncp-operator 未執行時刪除 nsx-node-agent 或 nsx-ncp-bootstrap DaemonSet，則當 nsx-ncp-operator 再次執行時，將不會重新建立該資源。

已知問題

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

因應措施：無。此為 TAS 問題。
問題 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 個空間的 TAS ASG (應用程式安全群組)
由於 NSX-T 分散式防火牆中的限制，NCP 無法處理繫結到超過 128 個空間的 TAS 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 中，[詳細目錄] > [容器] 索引標籤會顯示容器相關物件及其狀態。在 TKGI 環境中，將 NSX-T 升級至 3.0 後，容器相關物件的網路狀態會顯示為「未知」。此問題是由於 TKGI 未偵測到 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 服務將不會處於作用中狀態。

因應措施：在 /var/vcap/jobs/ncp/config/ncp.ini 中 (針對 TKGI 部署) 和 nsx-ncp-configmap 中 (針對其他部署) 設定 nsx_v3.lb_segment_subnet = FE80::/10。然後重新啟動 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 叢集索引標籤中。此問題通常出現在 TKGI 環境中。

因應措施：在 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 伺服器的所有要求都會失敗，且無法完成安裝。

因應措施：無
問題 2697547：RHEL/CentOS/RHCOS 節點不支援 HostPort
您可以透過將 nsx-node-agent ConfigMap 中的「enable_hostport_snat」設定為 True，在 Ubuntu 節點上指定原生 Kubernetes 和 TKGI 的 hostPorts。但是在 RHEL/CentOS/RHCOS 節點上不支援 hostPort，且系統會忽略參數「enable_hostport_snat」。

因應措施：無
問題 2707174：刪除後再以相同命名空間及名稱重新建立的網繭不具有網路連線
如果在 NCP 未執行而 nsx-ncp-agents 執行時刪除網繭，並使用相同的命名空間和名稱重新建立網繭，則網繭可能會取得錯誤的網路組態，且無法存取網路。

因應措施：在 NCP 執行時刪除網繭並重新建立。
問題 2713782：NSX API 呼叫失敗，並出現錯誤「SSL：DECRYPTION_FAILED_OR_BAD_RECORD_MAC」
有時，當 NCP 啟動時，由於存在重複的負載平衡伺服器或負載平衡器的第 1 層邏輯路由器，NCP 可能會重新啟動或無法初始化負載平衡器服務。此外，當 NCP 正在執行時，NSX 端點可能會報告為「關閉」一小段時間 (少於 1 秒)。如果負載平衡器無法初始化，NCP 記錄將會顯示訊息「無法初始化負載平衡器服務。」

僅在 NCP 跨多個 NSX Manager 執行個體執行用戶端負載平衡時，才會發生此行為。當 ncp.ini 中已設定單一 API 端點時，不會發生此問題。

因應措施：增加 nsx_v3.conn_idle_timeout 參數的值。請注意，使用用戶端負載平衡時，這可能導致暫時中斷連接後，系統需要較長的等待時間才能將端點偵測為可供使用。
問題 2745904：[對預設執行的 ASG 使用 IPSet] 功能不支援移除或取代現有的容器 IP 區塊
如果您在 NCP 動態磚上啟用 [對預設執行的 ASG 使用 IPSet]，NCP 將針對相同 NCP 動態磚上透過 [容器網路的 IP 區塊] 設定的所有容器 IP 區塊建立專用的 NSGroup。此 NSGroup 將用於為全域執行 ASG 所建立防火牆規則，以允許所有容器的流量。如果您稍後移除或取代現有的容器 IP 區塊，系統將在 NSGroup 中將其移除或取代。原始 IP 區塊中所有現有的容器將不再與全域執行的 ASG 相關聯。其流量可能不再正常運作。

因應措施：僅將新 IP 區塊附加至 [容器網路的 IP 區塊]。
問題 2744480：KVM 上不支援 Kubernetes 服務自助存取
如果 Kubernetes 網繭嘗試透過網繭為端點的 Kubernetes 服務存取本身，將會在 KVM 主機上捨棄回覆封包。

因應措施：無
問題 2744361：當 nsx-node-agent 網繭終止時，設定為使用靜態 IP 位址之 OpenShift 中的工作負載虛擬機器可能會中斷連線
有時，當 nsx-node-agent 網繭終止時，設定為使用靜態 IP 位址之 OpenShift 中的工作負載虛擬機器會中斷連線。

因應措施：將虛擬機器重新開機。
問題 2746362：nsx-kube-proxy 無法從 Kubernetes API 伺服器接收 Kubernetes 服務事件
有時，在 OpenShift 叢集中，nsx-kube-proxy 無法從 Kubernetes API 伺服器接收任何 Kubernetes 服務事件。命令「nsxcli -c get kube-proxy-watchers」會提供此輸出「監看程式執行緒狀態：啟動」，但 [處理的事件數目] 為 0，表示 nsx-kube-proxy 尚未從 API 伺服器接收任何事件。

因應措施：重新啟動 nsx-kube-proxy 網繭。
問題 2745907：「monit」命令傳回 nsx-node-agent 不正確的狀態資訊
在 diego_cell 虛擬機器上，當 monit 重新啟動 nsx-node-agent 時，如果 nsx-node-agent 需要超過 30 秒的時間才能完全啟動，monit 會將 nsx-node-agent 的狀態顯示為「執行失敗」，且即使稍後 nsx-node-agent 完全運作，也不會將其狀態更新為「執行中」。

因應措施：無。
問題 2735244：由於活躍度探查失敗，nsx-node-agent 和 nsx-kube-proxy 當機
nsx-node-agent 和 nsx-kube-proxy 使用 sudo 來執行某些命令。如果 /etc/resolv.conf 中有關於 DNS 伺服器和搜尋網域的許多項目，則 sudo 可能需要很長時間才能解析主機名稱。這將會導致 nsx-node-agent 和 nsx-kube-proxy 長時間受到 sudo 命令封鎖，且活躍度探查將會失敗。

因應措施：執行下列兩個動作的其中一個：
- 將主機名稱項目新增至 /etc/hosts。例如，如果主機名稱為「host1」，則新增項目「127.0.0.1 host1」。
- 為 nsx-node-agent 活躍度探查逾時設定較大的值。執行命令「kubectl edit ds nsx-node-agent -n nsx-system」以一併更新 nsx-node-agent 和 nsx-kube-proxy 容器的逾時值。
問題 2744557：入口路徑比對不支援同時包含一個擷取群組 () 和 {0} 的複雜規則運算式模式
例如，如果規則運算式 (RegEx) 模式為：/foo/bar/(abc){0,1}，它將不會比對 /foo/bar/。

因應措施：建立入口 Regex 規則時，請勿使用擷取群組 () 和 {0}。使用一般模式 EQUALS 來比對 /foo/bar/。
問題 2751080：KVM 主機升級後，容器主機無法執行 Kubernetes 網繭
KVM 主機升級後，升級後主機上部署的容器主機將無法執行 Kubernetes 網繭。這些網繭將保持在容器建立中狀態。如果已部署 NCP Operator，則節點的狀態可能會變為 NotReady，而 networkUnavailable 節點條件將為 True。此問題僅會在 RHEL 上出現，而不會在 Ubuntu 上出現。

因應措施：在 KVM Hypervisor 上重新啟動 nsx-opsagent。
問題 2736412：如果設定了 max_allowed_virtual_servers，則會忽略參數 members_per_small_lbs
如果同時設定了 max_allowed_virtual_servers 和 members_per_small_lbs，因為僅會考量 max_allowed_virtual_servers，虛擬伺服器可能無法連結至可用的負載平衡器。

因應措施：放寬調整限制，而不要啟用自動調整。
問題 2740552：使用 api-server 刪除靜態網繭時，nsx-node-agent 不會移除網繭的 OVS 橋接器連接埠，並且 Kubernetes 自動重新建立的靜態網繭網路無法使用
Kubernetes 不允許藉由 api-server 移除靜態網繭。Kubernetes 所建立靜態網繭的鏡像網繭，讓 api-server 可以搜尋該靜態網繭。藉由 api-server 刪除網繭時，僅將會刪除鏡像網繭，而 NCP 將會接收和處理刪除要求，以移除為網繭配置的所有 NSX 資源。但是，靜態網繭仍然存在，並且 nsx-node-agent 將不會從 CNI 取得靜態網繭的刪除要求來移除靜態網繭的 OVS 橋接器連接埠。

因應措施：藉由刪除資訊清單檔案來移除靜態網繭，而非藉由 api-server 移除靜態網繭。
問題 2795268：nsx-node-agent 與 Hyperbus 翻轉和 Kubernetes 網繭之間的連線停滯在建立中狀態
在大規模環境中，nsx-node-agent 可能無法連線至 Kubernetes API 伺服器以取得網繭資訊。由於正在傳輸大量資訊，無法將保持運作訊息傳送至 Hyperbus，並且 Hyperbus 將會關閉連線。

因應措施：重新啟動 nsx-node-agent。請確定 Kubernetes API 伺服器可供使用，並且用於連線至 API 伺服器的憑證正確無誤。
問題 2795482：在節點/Hypervisor 重新開機或任何其他作業之後，執行中的網繭會停滯在容器建立中狀態。
如果 wait_for_security_policy_sync 旗標為 true，則由於 Worker 節點強制重新開機、Hypervisor 重新開機或某些其他原因，網繭處於執行中狀態超過一小時之後可以前往容器建立中狀態。該網繭將永久處於建立中狀態。

因應措施：刪除並重新建立網繭。
問題 2871314：在 TKGI 從 1.10.x 升級至 1.11.x (1.11.6 之前) 後，會刪除 NSX 負載平衡器的入口憑證。
從 NCP 3.1.1 開始，會使用修訂編號來追蹤憑證。這會導致將 TKGI 1.10.x 升級至 TKGI 1.11.x (1.11.6 之前) 時出現問題，從而導致 NSX 負載平衡器的入口憑證遭到刪除且不會重新匯入。

因應措施：請執行下列其中一個動作：
1. 重新啟動 NCP。或者，
2. 刪除 Kubernetes 環境中的密碼，然後重新建立相同的密碼。或者，
3. 升級至 TKGI 1.11.6 或更新版本。
問題 2871321：將 TKGI 從 1.10.x 升級至 1.11.x (1.11.6 之前)，如果 CRD LoadBalancer 正在使用 L7 Cookie 持續性，將會遺失 IP 位址。
此問題是由於 NCP 3.1.1 中支援在 NSX 負載平衡器中更新 Cookie 名稱的新功能所致。

因應措施：請執行下列其中一個動作：
1. 使用來源 IP 持續性，而非 Cookie 持續性。
2. 升級至 TKGI 1.11.6 或更新版本。
問題 3033821：在完成管理程式至原則移轉後，分散式防火牆規則無法正確強制執行
在完成管理程式至原則移轉後，新建立的網路原則相關分散式防火牆 (DFW) 規則的優先順序將高於已移轉的 DFW 規則。

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