NSX Container Plugin 3.2.0.1 版本說明

VMware NSX Container Plugin 3.2.0.1 | 2021 年 11 月 11 日 | 組建編號 18876345

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

版本說明的內容

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

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

新增功能

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

附註：只有在提及管理程式模式支援時，原則模式才支援所有新功能。

支援在 Kubernetes 入口中針對多個 Kubernetes 叢集 (多個 NCP 執行個體) 使用相同的萬用字元憑證。
除了 UPI (使用者佈建的基礎結構) 方法之外，還支援使用 IPI (安裝程式佈建的基礎結構) 方法安裝具有 NCP 的 OpenShift。
新增「baseline_policy_type: allow_namespace_strict」組態選項。設定此選項後，預設原則是捨棄命名空間與外部服務之間的任何通訊，除非 Kubernetes 網路原則或 NSX-T 手動管理原則明確允許。
支援 Kubernetes 網路原則的新 endPort 欄位。
可以為 Kubernetes 命名空間指定子網路。(如果指定 IPv6 子網路，則不支援 64 位元子網路首碼。)
StatefulSet 以命名空間子網路為基礎的持續性 IP 配置。
對於類型為 ClusterIP 的 Kubernetes 服務，能夠建立以用戶端 IP 為基礎的工作階段相似性。此功能在管理程式模式中也可用。
在原則模式下使用 TAS。

棄用通知

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

相容性需求

產品	版本
Tanzu Application Service (TAS) 的 NCP/NSX-T 動態磚	3.2
NSX-T	3.1.2、3.1.3
vSphere	6.7、7.0
Kubernetes	1.19、1.20、1.21、1.22
OpenShift 4	RHCOS 4.6、4.7、4.8
Kubernetes 主機虛擬機器作業系統	Ubuntu 18.04、20.04 CentOS 7.8、7.9、8.2 RHEL 8.2、8.4 請參閱以下附註。
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7 (LTS) (支援終止日期：2022 年 4 月 30 日) Ops Manager 2.10 + TAS 2.10 (支援終止日期：2022 年 3 月 31 日) Ops Manager 2.10 + TAS 2.11 Ops Manager 2.10 + TAS 2.12 (支援終止日期：2023 年 3 月 31 日)
Tanzu Kubernetes Grid Integrated (TKGI)	1.13

附註：

在 CentOS/RHEL 上安裝 nsx-ovs 核心模組需要特定的核心版本。無論 CentOS/RHEL 版本為何，支援的 CentOS/RHEL 核心版本為 1127、1160、193、240 和 305。請注意，RHEL 7.8 的預設核心版本是 1127、RHEL 7.9 是 1160、RHEL 8.2 是 193、RHEL 8.3 是 240，而 RHEL 8.4 是 305。如果您執行的是其他核心版本，則可以 (1) 將核心版本修改為支援的版本。修改核心版本然後重新啟動虛擬機器時，請確定 IP 和靜態路由保留在上行介面上 (依 ovs_uplink_port 指定)，以確保與 Kubernetes API 伺服器的連線不會中斷。或 (2) 略過 nsx-ovs 核心模組的安裝，方法是在 nsx-node-agent 組態對應的「nsx_node_agent」區段下方，將「use_nsx_ovs_kernel_module」設定為「False」。

若要在 RHEL 8.2 (核心版本 193) 上執行 nsx-ovs 核心模組，您必須在 vCenter Server 的虛擬機器設定中，停用「開機選項」下方的「UEFI 安全開機」選項。

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

支援升級至此版本：

所有舊有 3.1.x 版本

已解決的問題

對於類型為 ClusterIP 的 Kubernetes 服務，不支援以用戶端 IP 為基礎的工作階段相似性
對於類型為 ClusterIP 的 Kubernetes 服務，NCP 不支援以用戶端 IP 為基礎的工作階段相似性。

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

因應措施：無
問題 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 參數的值。請注意，使用用戶端負載平衡時，這可能導致暫時中斷連接後，系統需要較長的等待時間才能將端點偵測為可供使用。
問題 2795268：nsx-node-agent 與 Hyperbus 翻轉和 Kubernetes 網繭之間的連線停滯在建立中狀態
在大規模環境中，nsx-node-agent 可能無法連線至 Kubernetes API 伺服器以取得網繭資訊。由於正在傳輸大量資訊，無法將保持運作訊息傳送至 Hyperbus，並且 Hyperbus 將會關閉連線。

因應措施：重新啟動 nsx-node-agent。請確定 Kubernetes API 伺服器可供使用，並且用於連線至 API 伺服器的憑證正確無誤。

已知問題

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

因應措施：若要刪除 NGINX 所建立的規則，請在類別值為 nginx 時刪除 Kubernetes 入口。然後，重新建立 Kubernetes 入口。
對於類型為 ClusterIP 的 Kubernetes 服務，不支援 hairpin-mode 旗標
對於類型為 ClusterIP 的 Kubernetes 服務，NCP 不支援 hairpin-mode 旗標。

因應措施：無
問題 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 建立的虛擬伺服器，則可能會中斷其他應用程式的工作流程。

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

因應措施：請勿透過 NSX Manager 或 NSX-T API 更新由 NCP 建立的 NSX-T 資源。
問題 2416376：NCP 無法處理繫結到超過 128 個空間的 TAS ASG (應用程式安全群組)
由於 NSX-T 分散式防火牆中的限制，NCP 無法處理繫結到超過 128 個空間的 TAS ASG。

因應措施：建立多個 ASG，並將每個 ASG 繫結到不超過 128 個空間。
問題 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 超載。
問題 2552564：在 OpenShift 4.3 環境中，如果找到重疊位址，則 DNS 轉寄站可能會停止運作
在 OpenShift 4.3 環境中，叢集安裝需要設定 DNS 伺服器。如果您使用 NSX-T 來設定 DNS 轉寄站，且 IP 位址與 DNS 服務重疊，則 DNS 轉寄站將停止運作，且叢集安裝將失敗。

因應措施：設定外部 DNS 服務，刪除安裝失敗的叢集，然後重新建立叢集。
問題 2555336：由於在管理程式模式中建立的邏輯連接埠重複，因此網繭流量無法運作
當多個叢集中有許多網繭時，可能會發生此問題。當您建立網繭時，網繭的流量無法運作。NSX-T 會顯示針對相同容器所建立的多個邏輯連接埠。在 NCP 記錄中，僅能找到其中一個邏輯連接埠的識別碼。

因應措施：刪除網繭並加以重新建立。當 NCP 重新啟動時，將會移除 NSX-T 上的失效連接埠。
問題 2597423：將管理程式物件匯入原則時，復原會導致部分資源的標籤遺失
將管理程式物件匯入原則時，如果有必要復原，將不會還原下列物件的標籤：
- Spoofguard 設定檔 (共用和叢集資源的一部分)
- BgpneighbourConfig (共用資源的一部分)
- BgpRoutingConfig (共用資源的一部分)
- StaticRoute BfdPeer (共用資源的一部分)
因應措施：對於屬於共用資源一部分的資源，請手動還原標籤。使用備份和還原功能來還原屬於叢集資源一部分的資源。
問題 2579968：對類型為 LoadBalancer 的 Kubernetes 服務進行高頻率的變更時，某些虛擬伺服器和伺服器集區不會如預期般刪除
對類型為 LoadBalancer 的 Kubernetes 服務進行高頻率的變更時，某些虛擬伺服器和伺服器集區可能會在應已刪除時仍保留在 NSX-T 環境中。

因應措施：重新啟動 NCP。或者，手動移除失效的虛擬伺服器及其相關聯的資源。如果類型為 LoadBalancer 的 Kubernetes 服務在 external_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 成員除外)，將會在環境中的其他節點上收回並重新建立。

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

因應措施：在 NCP 執行時刪除網繭並重新建立。
問題 2745904：[對預設執行的 ASG 使用 IPSet] 功能不支援移除或取代現有的容器 IP 區塊
如果您在 NCP 動態磚上啟用 [對預設執行的 ASG 使用 IPSet]，NCP 將針對相同 NCP 動態磚上透過 [容器網路的 IP 區塊] 設定的所有容器 IP 區塊建立專用的 NSGroup。此 NSGroup 將用於為全域執行 ASG 所建立防火牆規則，以允許所有容器的流量。如果您稍後移除或取代現有的容器 IP 區塊，系統將在 NSGroup 中將其移除或取代。原始 IP 區塊中所有現有的容器將不再與全域執行的 ASG 相關聯。其流量可能不再正常運作。

因應措施：僅將新 IP 區塊附加至 [容器網路的 IP 區塊]。
問題 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/。
問題 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 移除靜態網繭。
問題 2795482：在節點/Hypervisor 重新開機或任何其他作業之後，執行中的網繭會停滯在容器建立中狀態。
如果 wait_for_security_policy_sync 旗標為 true，則由於 Worker 節點強制重新開機、Hypervisor 重新開機或某些其他原因，網繭處於執行中狀態超過一小時之後可以前往容器建立中狀態。該網繭將永久處於建立中狀態。

因應措施：刪除並重新建立網繭。
問題 2860091：如果 baseline_policy_type 設定為 allow_namespace，DNS 流量會失敗
在 OpenShift 或 Kubernetes 環境中，如果 baseline_policy_type 設為 allow_namespace，將會封鎖其他命名空間中的網繭 (hostNetwork: False)，而無法存取 DNS 服務。

因應措施：新增規則網路原則，以允許從其他網繭至 DNS 網繭的流量。
問題 2841030：使用 Kubernetes 1.22 時，nsx-node-agent 的狀態一律為「AppArmor」
在 Kubernetes 1.22 中，當 nsx-node-agent 網繭處於「就緒」時，其狀態並不會從「AppArmor」更新為「執行中」。這不會影響 NCP 或 nsx-node-agent 的功能。

因應措施：重新啟動 nsx-node-agent 網繭。
問題 2824129：重新啟動之後，節點處於「網路無法使用」狀態超過 3 分鐘
如果您使用 NCP Operator 來管理 NCP 的生命週期，當 nsx-node-agent DaemonSet 從非執行中狀態復原時，其節點仍會處於「網路無法使用」狀態，直到它執行了 3 分鐘為止。這是預期的行為。

因應措施：nsx-node-agent 重新啟動後，請等待至少 3 分鐘。
問題 2867361：進行 NCP 清理後，未移除 nsx-node-agent 和 hyperbus 警示
如果因某些原因 (例如，停止所有 NSX 節點代理程式) 而出現 nsx-node-agent 和 hyperbus 警示，且您停止 NCP 並執行清理指令碼，則清理之後警示仍在。

因應措施：無
問題 2869247：在 Ubuntu 18.04 主機作業系統上，nsx-ovs 容器仍維持重新啟動
nsx-ovs 容器仍維持重新啟動，因為其活躍度探查仍然失敗。/var/log/nsx-ujo/openvswitch/ovs-vswitchd.log 含有記錄，指出其仍維持重新啟動。例如：
```
2021-10-28T17:38:49.364Z|00004|backtrace(monitor)|WARN|Backtrace using libunwind not supported. 
2021-10-28T17:38:49.364Z|00005|daemon_unix(monitor)|WARN|2 crashes: pid 282 died, killed (Aborted), core dumped, waiting until 10 seconds since last restart 
2021-10-28T17:38:57.364Z|00006|daemon_unix(monitor)|ERR|2 crashes: pid 282 died, killed (Aborted), core dumped, restarting 
```
此問題是由於安裝在 nsx-ovs 容器中的上游 OVS 使用者空間套件，與 OVS 核心模組不相容所致。

因應措施：將主機作業系統升級至 Ubuntu 20.0，或執行下列步驟，以使用 NSX 提供的 OVS 核心模組：
1. 在 nsx-node-agent 的組態對應中，將 use_nsx_ovs_kernel_module 設為 True。
2. 在 ncp-ubuntu*.yaml 檔案中，取消註解 nsx-ncp-bootstrap DaemonSet 中的磁碟區掛接 (請搜尋「Uncomment these mounts if installing NSX-OVS kernel module」和「Uncomment these volumes if installing NSX-OVS kernel module」)。
3. 重新套用 ncp-ubuntu*.yaml 檔案，然後重新啟動 nsx-node-agent 網繭。
問題 2867871：如果網繭的 Kubernetes 節點名稱與主機名稱不同，當從服務所參考的網繭存取 clusterIP 服務時，將會失敗
目前，僅當 Kubernetes 節點名稱與主機名稱相同時，NCP 才支援網繭自我存取 clusterIP 服務。這是因為只有在主機名稱與節點名稱相同時，nsx-kube-proxy 才會新增自我存取流程。

因應措施：無
問題 2868572：執行 NCP 之前，必須在主機虛擬機器上停用 Open vSwitch (OVS)
若要在主機虛擬機器上部署 NCP，您必須先停止 OVS 相關程序，並使用下列命令來刪除主機上的某些檔案：
1. sudo systemctl disable openvswitch-switch.service
2. sudo systemctl stop openvswitch-switch.service
3. rm -rf /var/run/openvswitch
如果您已在主機虛擬機器上部署 NCP，且 OVS 未正確執行，請執行下列步驟以復原：
1. 執行上述 3 個步驟。
2. 使用「kubectl delete pod $agent-pod -n nsx-system」命令，在有問題的節點上刪除 nsx-node-agent 網繭，以重新啟動節點代理程式網繭。
因應措施：請參閱上述內容。
問題 2832480：對於類型為 ClusterIP 的 Kubernetes 服務，sessionAffinityConfig.clientIP.timeoutSeconds 不能超過 65535
對於類型為 ClusterIP 的 Kubernetes 服務，如果您所設定的 sessionAffinityConfig.clientIP.timeoutSeconds 的值大於 65535，則實際值將會是 65535。

因應措施：無
問題 2882699：在 IPv6 環境中，將 baseline_policy_type 設定為 allow_namespace_strict 會導致通訊失敗
在 IPv6 環境中，如果 baseline_policy_type 設定為 allow_namespace_strict，網繭將無法存取 Kubernetes 節點。

因應措施：新增優先順序高於基準規則的分散式防火牆規則，以允許從網繭到 Kubernetes 節點的流量。
問題 2939886：將物件從管理程式模式移轉至原則模式失敗
如果在網路原則規格中出口和入口具有相同的選取器，則將物件從管理程式模式移轉至原則模式會失敗。

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

因應措施：視需要使用原則 API 變更 DFW 規則的順序。
問題 3042916：啟動後 nsx-kube-proxy 失敗，並顯示錯誤「in_port 的連接埠無效或未知」
在極少數情況下，nsx-kube-proxy 會在啟動後不久失敗，因為此時 OVS 上行「ofport」為空白。記錄中有錯誤訊息「執行階段錯誤：執行 xxx 時發生嚴重錯誤：()：in_port 的連接埠無效或未知。」

因應措施：將 nsx-kube-proxy 重新開機。
問題 3239352：在 TAS 環境中，如果無法配置工作，重試可能無法正常運作
在 NCP TAS 環境中，如果無法配置工作，則 Auctioneer 會拒絕工作，且 BBS 會重試放置工作，重試次數最多達到 task.max_retries 設定所指定的次數。達到 task.max_retries 時，BBS 會將工作從擱置中狀態更新為已完成狀態，並將其標記為失敗，並包含失敗原因，說明叢集沒有用於執行工作的容量。

在重試期間，可能會將工作排程到新的儲存格，以向 NCP 通知 task_changed 事件。由於 NCP 不會處理 task_changed，因此無法在新的儲存格中為工作指派新連接埠。工作無法正常執行。

因應措施：停用重試，並將 task.max_retries 值設定為 0。