VMware NSX Container Plugin 4.1.2 版本說明

VMware NSX Container Plugin 4.1.2 | 2023 年 10 月 19 日 | 組建編號 22596735 查看這些版本說明的新增項目和更新。

新增功能

• 支援在管理程式模式的 TAS 中建立新叢集。請注意，下一個版本將不支援此功能。

• 支援將 TAS 基礎從管理程式模式移轉至原則模式。

• 用於為 NCP 組態步驟產生偵錯報告的新 Runbook。

棄用通知

• 對第三方入口控制器的 NAT 支援已棄用，將在未來版本中移除。

  此功能由 k8s.ingress_mode 參數控制，並使用 ncp/ingress_controller 註解在入口控制器網繭上啟用。透過此功能，將使用 DNAT 規則公開入口控制器網繭。公開這些網繭的慣用方式是使用 LoadBalancer 類型的服務。

• NSX OVS 核心模組已棄用，並將在下一個版本中移除。

• Multus 不再受支援。將在下一個版本中移除。

相容性需求

產品	版本
Tanzu Application Service (TAS) 的 NCP/NSX 動態磚	4.1.2
NSX	3.2.3、4.0.1、4.1.1、4.1.2
Kubernetes	1.25、1.26、1.27
OpenShift 4	4.11、4.12
Kubernetes 主機虛擬機器作業系統	Ubuntu 20.04 具有核心 5.15 的 Ubuntu 22.04 (同時支援 nsx-ovs 核心模組和上游 OVS 核心模組) 其核心高於 5.15 的 Ubuntu 22.04 (僅支援上游 OVS 核心模組) RHEL 8.6、8.8、9.2 請參閱以下附註。
Tanzu Application Service (TAS)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0 Ops Manager 2.10 + TAS 5.0 Ops Manager 3.0 + TAS 5.0
Tanzu Kubernetes Grid Integrated (TKGI)	1.18.0

附註：

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

支援升級至此版本：

• 4.1.0。4.1.1 和所有 4.0.x 版本。

限制

• NCP 的「基準原則」功能會建立動態群組，以選取叢集中的所有成員。NSX-T 的動態群組有效成員數目限制為 8,000 個 (如需詳細資料，請參閱組態上限)。因此，不應針對預期成長超過 8,000 個網繭的叢集啟用此功能。超過此限制可能會導致為網繭建立資源延遲。

• 透明模式負載平衡器

  • 僅支援 Kubernetes 叢集的南北向流量。不支援內部叢集流量。

  • 不支援連結至 LoadBalancer CRD 或啟用自動調整時的服務。必須停用自動調整，此功能才能正常運作。

  • 建議僅在新部署的叢集上使用此功能。

• 管理程式至原則移轉

  • 如果先前移轉失敗且叢集已回復，則無法移轉 Kubernetes 叢集。這是僅針對 NSX 4.0.0.1 或更早版本的限制。

• 當實作一些會在入口/出口規則中使用多重選取器準則的網路原則時，實際的群組成員計算中會存在效能顯著降低的風險，且會影響網路流量。為解決此限制，提供了新的組態選項 enable_mixed_expression_groups，這將會影響在原則模式下使用多重選取器的 Kubernetes 網路原則。管理程式模式下的叢集則不受影響。此選項的預設值為 False。我們建議在您的叢集中使用下列值：

  • TKGi

    • 新叢集，原則模式：False

    • 現有叢集 (以原則為基礎)：True

    • 將管理程式移轉至原則後：True

  • OC：設定為 True 可確保符合 Kubernetes 網路原則

  • DIY Kubernetes

    • 新叢集 (以原則為基礎)：False

    • 現有叢集 (以原則為基礎)：True

    • 將管理程式移轉至原則後：True

  當 enable_mixed_expression_groups 設定為 True 時，即適用此限制。這會影響使用 NCP 3.2.0 版及更新版本，以及 NSX-T 3.2.0 版及更新版本的安裝。網路原則所影響的命名空間數目沒有限制。如果此選項設為 True 且 NCP 重新啟動，NCP 將再次同步所有網路原則，以實作此行為。

  當 enable_mixed_expression_groups 設為 False 時，則會利用在計算實際成員期間不受任何效能降低影響的動態 NSX 群組，來實現會在入口/出口規則中使用多重選取器準則的網路原則。但是，根據網路原則中所定義的其他準則，最多只能對 5 個命名空間強制執行這些規則。在任何時間點，只要網路原則影響的命名空間超過 5 個，就會標註為「ncp/error: NETWORK_POLICY_VALIDATION_FAILED」，且不會在 NSX 中強制執行。請注意，當建立新的命名空間且其滿足多重選取器條件時，或是更新現有命名空間時，可能發生此情況。如果此選項設為 False 且 NCP 重新啟動，NCP 將再次同步所有網路原則，以實作此行為。

已解決的問題

• 問題 3239352：在 TAS 環境中，如果無法配置工作，重試可能無法正常運作

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

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

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

• 問題 3043496：如果管理程式至原則移轉失敗，NCP 會停止執行

  NCP 提供 migrate-mp2p 工作，以移轉 NCP 和 TKGI 所使用的 NSX 資源。如果移轉失敗，則會復原所有已移轉的資源，但不會在管理程式模式下重新啟動 NCP。

  因應措施：

  1. 確保所有資源均已復原。您可以透過檢查 migrate-mp2p 工作的記錄來完成此動作。記錄必須以「All imported MP resources to Policy completely rolled back」一行結尾。

  2. 如果所有資源均已復原，請以 ssh 連線至每個主節點，然後執行命令「sudo /var/vcap/bosh/bin/monit start ncp」。

• 問題 2939886：將物件從管理程式模式移轉至原則模式失敗

  如果在網路原則規格中出口和入口具有相同的選取器，則將物件從管理程式模式移轉至原則模式會失敗。

  因應措施：無

已知問題

• 問題 3293981：在短時間內使用 defaultBackend 建立兩個入口會導致 DEFAULT_BACKEND_IN_USE 錯誤

  如果在短時間內使用指定的 defaultBackend 建立了兩個入口，則這兩個入口都可能會導致 DEFAULT_BACKEND_IN_USE 錯誤。

  因應措施：一次建立一個入口。若要解決 DEFAULT_BACKEND_IN_USE 錯誤，請從兩個入口中刪除 defaultBackend，並一次將其新增回到一個入口。

• 問題 3292003：在 OCP 環境中，在套用具有 NoExecute 效果的污點後，節點會關閉

  在 OCP 環境中，如果您移除節點代理程式 DaemonSet 的 {"effect":"NoExecute","operator":"Exists"} 容許度，並在節點上新增 NoExecute 效果污點 (例如 test=abc:NoExecute)，節點可能會關閉。在此案例中，節點代理程式網繭將被從具有污點的節點中收回。在節點代理程式網繭收回期間，節點可能會中斷連線，因為節點代理程式網繭未正常結束，且未正確地將節點上行介面從 br-int 設定回到 ens192。

  因應措施：從 vCenter Server 將節點虛擬機器重新開機。

• 問題 3293969：在 OCP 環境中，NCP 升級期間，節點狀態變為未就緒

  在 OCP 環境中，NCP 升級期間，將會重新啟動節點代理程式。節點可能會中斷連線，因為節點代理程式網繭未正常結束，且未正確地將節點上行介面從 br-int 設定回到 ens192。節點狀態將變為 NotReady。

  因應措施：從 vCenter Server 將節點虛擬機器重新開機。

• 問題 3252571：如果 NSX Manager 變成無法使用，則管理程式至原則的移轉永遠不會完成

  在管理程式至原則的移轉期間，如果 NSX Manager 無法使用，則移轉可能永遠不會完成。其中一個跡象是記錄中將不會有關於移轉的更新。

  因應措施：重新建立與 NSX Manager 的連線，然後重新開始移轉。

• 問題 3248662：Worker 節點無法存取服務。未在節點上建立服務的 OVS 流量。

  nsx-kube-proxy 記錄含有錯誤訊息「greenlet.error: cannot switch to a different thread.」

  因應措施：在節點上重新啟動 nsx-kube-proxy。

• 問題 3241693：當建立的路由數目超過某些限制時，第 7 層路由需要 10 分鐘以上的時間才能開始運作

  在 OpenShift 環境中，您可以藉由在 ConfigMap 中將「relax_scale_validation」旗標設定為 True，以及將「l4_lb_auto_scaling」旗標設定為 False，來部署超過 1000 個路由。但是，當建立的路由數目超過限制時，路由將需要 10 分鐘以上的時間才能開始運作。限制是 500 個 HTTPS 路由和 2000 個 HTTP 路由。

  因應措施：請勿超過路由數目的限制。如果您建立 500 個 HTTPS 加上 2000 個 HTTP 路由，則必須使用大型 Edge 虛擬機器來部署路由。

• 問題 3158230：在 Ubuntu 20.04 上載入 AppArmor 設定檔時，nsx-ncp-bootstrap 容器無法初始化

  nsx-ncp-bootstrap DaemonSet 中的 nsx-ncp-bootstrap 容器無法初始化，因為主機作業系統和容器映像上的 AppArmor 套件版本不同。容器的記錄會顯示類似如下的訊息：「Failed to load policy-features from '/etc/apparmor.d/abi/2.13': No such file or directory」。

  因應措施：將 AppArmor 更新至 2.13.3-7ubuntu5.2 版或主機作業系統上的 focal-updates 所提供的最新版本。

• 問題 3179549：不支援變更現有命名空間的 NAT 模式

  對於具有現有網繭的命名空間，如果您將 NAT 模式從 SNAT 變更為 NO_SNAT，則網繭仍將使用從 container_ip_blocks 中指定的 IP 區塊所配置的 IP 位址。如果命名空間中的區段子網路仍有可用的 IP 位址，則新建立的網繭仍將使用現有區段子網路的 IP 位址。對於新建立的區段，則會從 no_snat_ip_block 來配置子網路。但在命名空間上，將會刪除 SNAT 規則。

  因應措施：無。

• 問題 3218243：將 NCP 升級至 4.1.1 版後，或當使用者建立/更新命名空間時，會移除 NSX 中針對使用多重選取器準則的 Kubernetes 網路原則所建立的安全性原則

  確認 NCP 中的「enable_mixed_expression_groups」選項設定為 False (預設值為 False)。如果是這種情況，網路原則會導致在 NSX 上建立超過 5 個群組準則，但不支援此狀況。

  因應措施：在 NCP 組態對應中將 enable_mixed_expression_groups 設為 True，然後重新啟動 NCP。請注意，在此情況下，當計算實際群組成員時將存在效能明顯降低的風險，且會影響網路流量。

• 問題 3235394：含有命名空間設定的基準原則在 TKGI 設定中無法運作

  在 TGKI 環境中，如果您將 baseline_policy_type 設定為 allow_namespace 或 allow_namespace_strict，NCP 將建立明確的基準原則，以便僅允許相同命名空間內的網繭彼此通訊，而會拒絕來自其他命名空間的入口。此基準原則也會封鎖系統命名空間 (例如 kube-system)，不讓其存取不同命名空間中的網繭。

  因應措施：無。NCP 在 TKGI 設定中不支援此功能。

• 問題 3179960：執行 vMotion 後無法連線到應用程式執行個體，且具有與另一個應用程式執行個體相同的 IP 位址

  例如，在 NSX 主機升級期間執行大量 vMotion 時，主機會逐一進入維護模式，且會在主機之間進行 Diego Cell 移轉。執行 vMotion 後，某些區段連接埠可能遺失，某些應用程式執行個體可能無法連線，且兩個應用程式執行個體可能具有相同的 IP 位址。使用 TAS 2.13.18 時，更可能發生此問題。

  因應措施：重新建立受此問題影響的應用程式執行個體。

• 問題 3108579：刪除 LB CRD 並使用相同密碼立即重新建立，但卻失敗

  在管理程式模式下，如果您刪除 LB CRD 上的入口，接著刪除 LB CRD，然後立即使用相同的憑證來重新建立入口和 LB CRD，您可能會看到「嘗試匯入的憑證早已匯入」錯誤。這是時機問題所致，因為若要刪除 LB CRD，必須等入口刪除完成才行。

  因應措施：請執行下列其中一個動作：

  - 執行下列命令，等待入口刪除完成，之後再刪除 LB CRD。

  • kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep 'name: <Ingress name>'

  - 等待至少 2 分鐘後，再重新建立入口和 LB CRD。

• 問題 3221191：當叢集具有 4000 個以上的網繭時，建立網域群組會失敗

  如果 NCP 選項 k8s.baseline_policy_type 設定為 allow_cluster、allow_namespace 或 allow_namespace_strict，且叢集具有 4000 個以上的網繭時，則無法建立含有網繭所有 IP 位址的網域群組 (具有 dg-k8sclustername 之類的名稱)。這是由於 NSX 上的限制所致。

  因應措施：請勿設定 k8s.baseline_policy_type 選項，或是確定叢集中的網繭少於 4000 個。

• 問題 2131494：將入口類別從 nginx 變更為 nsx 之後，NGINX Kubernetes 入口仍然正常運作

  當您建立 NGINX Kubernetes 入口時，NGINX 會建立流量轉送規則。如果將入口類別變更為任何其他值，即使您在變更類別後刪除 Kubernetes 入口，NGINX 也不會刪除規則，並且會繼續套用這些規則。這是 NGINX 的限制。

  因應措施：若要刪除 NGINX 所建立的規則，請在類別值為 nginx 時刪除 Kubernetes 入口。然後，重新建立 Kubernetes 入口。

• 問題 2999131：無法從網繭連線到 ClusterIP 服務

  在大型 TKGi 環境中，無法從網繭連線到 ClusterIP 服務。其他相關問題包括：(1) nsx-kube-proxy 停止輸出 nsx-kube-proxy 的記錄；以及 (2) 節點上未建立 OVS 流量。

  因應措施：重新啟動 nsx-kube-proxy。

• 問題 2984240：matchExpressions 中的「NotIn」運算子在網路原則規則的 namespaceSelector 中無法運作

  指定網路原則的規則時，如果您指定 namespaceSelector、matchExpressions 和「NotIn」運算子，則規則將無法運作。NCP 記錄有錯誤訊息「NS 選取器不支援 NotIn 運算子。」

  因應措施：重新寫入 matchExpressions 以避免使用「NotIn」運算子。

• 問題 3033821：在完成管理程式至原則移轉後，分散式防火牆規則無法正確強制執行

  在完成管理程式至原則移轉後，新建立的網路原則相關分散式防火牆 (DFW) 規則的優先順序將高於已移轉的 DFW 規則。

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

• 對於類型為 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 個空間。

• 在 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 位址。

• 問題 2672677：在高負荷的 OpenShift 4 環境中，節點可能會沒有回應

  在個別節點具有高網繭密度，且頻繁刪除和建立網繭的 OpenShift 4 環境中，RHCOS 節點可能會進入「未就緒」狀態。在受影響的節點上執行的網繭 (daemonset 成員除外)，將會在環境中的其他節點上收回並重新建立。

  因應措施：將受影響的節點重新開機。

• 問題 2707174：刪除後再以相同命名空間及名稱重新建立的網繭不具有網路連線

  如果在 NCP 未執行而 nsx-ncp-agents 執行時刪除網繭，並使用相同的命名空間和名稱重新建立網繭，則網繭可能會取得錯誤的網路組態，且無法存取網路。

  因應措施：在 NCP 執行時刪除網繭並重新建立。

• 問題 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 容器的逾時值。

• 問題 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 移除靜態網繭。

• 問題 2824129：重新啟動之後，節點處於「網路無法使用」狀態超過 3 分鐘

  如果您使用 NCP Operator 來管理 NCP 的生命週期，當 nsx-node-agent DaemonSet 從非執行中狀態復原時，其節點仍會處於「網路無法使用」狀態，直到它執行了 3 分鐘為止。這是預期的行為。

  因應措施：nsx-node-agent 重新啟動後，請等待至少 3 分鐘。

• 問題 2832480：對於類型為 ClusterIP 的 Kubernetes 服務，sessionAffinityConfig.clientIP.timeoutSeconds 不能超過 65535

  對於類型為 ClusterIP 的 Kubernetes 服務，如果您所設定的 sessionAffinityConfig.clientIP.timeoutSeconds 的值大於 65535，則實際值將會是 65535。

  因應措施：無

• 問題：2940772：將 NCP 資源從管理程式移轉至原則導致 NSX-T 3.2.0 發生失敗

  NSX-T 3.1.3 和 NSX-T 3.2.1 支援將 NCP 資源從管理程式移轉至原則，但 NSX-T 3.2.0 不支援。

  因應措施：無

• 問題 2934195：分散式防火牆規則不支援部分類型的 NSX 群組

  分散式防火牆 (DFW) 規則不支援類型為「僅限 IP 位址」的 NSX 群組。類型為「一般」且手動新增 IP 位址為成員的 NSX 群組亦不受支援。

  因應措施：無

• 問題 3066449：當 use_ip_blocks_in_order 設定為 True 時，不一定會從第一個可用的 IP 區塊配置命名空間子網路

  在 use_ip_blocks_in_order 設定為 True 的情況下建立多個命名空間時，有時不會從第一個可用的 IP 區塊配置第一個命名空間的子網路。例如，假設 container_ip_blocks = '172.52.0.0/28,172.53.0.0/28'，子網路首碼長度為 29，且已配置子網路 172.52.0.0/29。如果建立 2 個命名空間 ns-1 和 ns-2，子網路配置可以是 (1) ns-1：172.52.0.8/29，ns-2：172.53.0.0/29，或 (2) ns-1：172.53.0.0/29，ns-2：172.52.0.8/29。

  use_ip_blocks_in_order 參數只能確保依照 container_ip_blocks 參數中顯示的 IP 區塊順序，使用不同的 IP 區塊。同時建立多個命名空間時，任何命名空間都會在其他命名空間之前，透過 API 呼叫要求子網路。因此，無法保證能從特定的 IP 區塊，為特定命名空間配置子網路。

  因應措施：分別建立命名空間，即建立第一個命名空間，確保為其配置子網路，然後再建立下一個命名空間。