| VMware NSX Container Plugin 3.2.1.1 | 2022 年 5 月 17 日 | 組建編號 19750154 查看這些版本說明的新增項目和更新。 |
新增功能
-
支援部署具有多個 vNIC 的 OCP Worker 節點
支援部署具有多個 vNIC 的 OCP Worker 節點，並假設第一個 vNIC 用於容器網路。
-
支援「natfirewallmatch」選項
「natfirewallmatch」選項指定 NSX-T 閘道防火牆如何與為 Kubernetes 命名空間建立的 NAT 規則搭配運作。此選項僅適用於新建立的 Kubernetes 命名空間，而不適用於現有命名空間。
棄用通知
註解「ncp/whitelist-source-range」將在 NCP 4.0 中棄用。從 NCP 3.1.1 開始，您可以改用註解「ncp/allowed-source-range」。
使用註解「ncp/ingress_controller」允許透過 NAT 存取入口控制器網繭的功能已棄用，將於 2023 年移除。公開入口控制器網繭的建議方式是使用類型為 LoadBalancer 的服務。
相容性需求
| 產品 |
版本 |
|---|---|
| Tanzu Application Service (TAS) 的 NCP/NSX-T 動態磚 |
3.2.1 |
| NSX-T |
3.1.3、3.2、3.2.1 (請參閱以下說明) |
| vSphere |
6.7、7.0 |
| Kubernetes |
1.21、1.22、1.23 |
| OpenShift 4 |
4.7、4.8、4.9 |
| OpenShift 主機虛擬機器作業系統 |
RHCOS 4.7、4.8 |
| Kubernetes 主機虛擬機器作業系統 |
Ubuntu 18.04、20.04 CentOS 8.2 RHEL 8.4、8.5 請參閱以下附註。 |
| Tanzu Application Service |
Ops Manager 2.10 + TAS 2.11 Ops Manager 2.10 + TAS 2.12 (支援終止日期：2023 年 3 月 31 日) |
| Tanzu Kubernetes Grid Integrated (TKGI) |
1.13.6、1.14 |
附註：
在 CentOS/RHEL 上安裝 nsx-ovs 核心模組需要特定的核心版本。無論 CentOS/RHEL 版本為何，支援的 CentOS/RHEL 核心版本為 193、305 和 348。請注意，RHEL 8.2 的預設核心版本為 193、RHEL 8.4 是 305，而 RHEL 8.5 是 348。如果您執行的是其他核心版本，則可以 (1) 將核心版本修改為支援的版本。修改核心版本然後重新啟動虛擬機器時，請確定 IP 和靜態路由保留在上行介面上 (依 ovs_uplink_port 指定)，以確保與 Kubernetes API 伺服器的連線不會中斷。或 (2) 略過 nsx-ovs 核心模組的安裝，方法是在 nsx-node-agent 組態對應的「nsx_node_agent」區段下方，將「use_nsx_ovs_kernel_module」設定為「False」。
若要在 RHEL/CentOS 上執行 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。
NCP 3.2.1.0 隨附的 TKGI 1.14.0，不支援 NSX-T 3.2.1。
TKGI 1.13.x 和 TKGI 1.14.x 與 NSX-T 3.2.0.x 不相容。
支援升級至此版本：
-
所有 3.1.x 版本
-
所有舊有 3.2.x 版本
限制
NCP 的「基準原則」功能會建立動態群組，以選取叢集中的所有成員。NSX-T 的動態群組有效成員數目限制為 8,000 個 (如需詳細資料，請參閱組態上限)。因此，不應針對預期成長超過 8,000 個網繭的叢集啟用此功能。超過此限制可能會導致為網繭建立資源延遲。
已解決的問題
-
問題 3042916：啟動後 nsx-kube-proxy 失敗，並顯示錯誤「in_port 的連接埠無效或未知」
在極少數情況下，nsx-kube-proxy 會在啟動後不久失敗，因為此時 OVS 上行「ofport」為空白。記錄中有錯誤訊息「執行階段錯誤：執行 xxx 時發生嚴重錯誤：()：in_port 的連接埠無效或未知。」
因應措施：將 nsx-kube-proxy 重新開機。
-
問題 2863155：無法從大型環境中的網繭連線到某些叢集 IP 服務
在大型環境中，大型記錄的大小可能會導致 nsx-kube-proxy 出現問題。無法從網繭連線到某些叢集 IP 服務，並且 nsx-kube-proxy 無法在 nsxcli 中報告其狀態。
因應措施：重新啟動 nsx-kube-proxy。
-
問題 2944368：指定了「主機」的入口規則會同時比對主機和具有尾碼的主機
例如，指定主機為「test.co」的規則將同時比對「test.co」和「test.co.uk」。
因應措施：無
-
問題 2882699：在 IPv6 環境中，將 baseline_policy_type 設定為 allow_namespace_strict 會導致通訊失敗
在 IPv6 環境中，如果 baseline_policy_type 設定為 allow_namespace_strict，網繭將無法存取 Kubernetes 節點。
因應措施：新增優先順序高於基準規則的分散式防火牆規則，以允許從網繭到 Kubernetes 節點的流量。
-
問題 2867871：如果網繭的 Kubernetes 節點名稱與主機名稱不同，當從服務所參考的網繭存取 clusterIP 服務時，將會失敗
目前，僅當 Kubernetes 節點名稱與主機名稱相同時，NCP 才支援網繭自我存取 clusterIP 服務。這是因為只有在主機名稱與節點名稱相同時，nsx-kube-proxy 才會新增自我存取流程。
因應措施：無
-
問題 2555336：由於在管理程式模式中建立的邏輯連接埠重複，因此網繭流量無法運作
當多個叢集中有許多網繭時，可能會發生此問題。當您建立網繭時，網繭的流量無法運作。NSX-T 會顯示針對相同容器所建立的多個邏輯連接埠。在 NCP 記錄中，僅能找到其中一個邏輯連接埠的識別碼。
因應措施：刪除網繭並加以重新建立。當 NCP 重新啟動時，將會移除 NSX-T 上的失效連接埠。
-
問題 2664457：在 OpenShift 中使用 DHCP 期間，當 nsx-node-agent 啟動或重新啟動時，連線可能會暫時中斷
nsx-ovs 會建立並啟動 5 個暫時的連線設定檔以設定 ovs_bridge，但在 NetworkManager 中這些設定檔可能會暫時無法啟用。因此，ovs_uplink_port 和/或 ovs_bridge 上的虛擬機器不會有 IP (連線) 存在。
因應措施：重新開機虛擬機器，或等待 NetworkManager 成功啟用所有設定檔。
已知問題
-
問題 3239352：在 TAS 環境中，如果無法配置工作，重試可能無法正常運作
在 NCP TAS 環境中，如果無法配置工作，則 Auctioneer 會拒絕工作，且 BBS 會重試放置工作，重試次數最多達到 task.max_retries 設定所指定的次數。達到 task.max_retries 時，BBS 會將工作從擱置中狀態更新為已完成狀態，並將其標記為失敗，並包含失敗原因，說明叢集沒有用於執行工作的容量。
在重試期間，可能會將工作排程到新的儲存格，以向 NCP 通知 task_changed 事件。由於 NCP 不會處理 task_changed，因此無法在新的儲存格中為工作指派新連接埠。工作無法正常執行。
因應措施：停用重試，並將 task.max_retries 值設定為 0。
-
問題 3033821：在完成管理程式至原則移轉後，分散式防火牆規則無法正確強制執行
在完成管理程式至原則移轉後，新建立的網路原則相關分散式防火牆 (DFW) 規則的優先順序將高於已移轉的 DFW 規則。
因應措施：視需要使用原則 API 變更 DFW 規則的順序。
-
問題 2960121：對於類型為 LoadBalancer 的服務，如果未正確設定，則無法連線至 Windows Worker 節點上的網繭
對於類型為 LoadBalancer 的服務，如果將 NCP 設定為使用預設 LB 區段子網路，則無法連線至 Windows Worker 節點上的網繭。預設子網路 169.254.128.0/22 屬於 IPv4 連結本機空間，且不會在 Windows 節點上轉送。
因應措施：將 NCP 設定為使用非預設 LB 區段子網路。若要這麼做，請在 nsx_v3 區段中設定參數 lb_segment_subnet。請注意，這僅會影響新建立的 NSX 負載平衡器。
-
問題 2972811：在大型環境中，與某些 Worker 節點的 Hyperbus 連線已關閉
在大型環境中，由於 RPC 通道逾時，網繭建立可能會停滯 10-15 分鐘。可能會發生下列問題：
-
在 Kubernetes 叢集中，某些網繭的容器建立中狀態會持續 10-15 分鐘。
-
在 cfgAgent 中，通道的 COMMUNICATION_ERROR 狀態會持續 10-15 分鐘。
-
在 NSX UI 中，可能會產生一個指示 Hyperbus 連線已關閉的警示。
因應措施：不需要執行任何動作。此問題將在 10-15 分鐘後自動復原。
-
-
問題：2966586：將管理程式物件移轉至原則後，命名空間建立失敗
如果在管理程式模式中建立 IP 區塊，則在管理程式物件移轉至原則後，命名空間建立會失敗，因為 NCP 無法從此 IP 區塊配置子網路。
因應措施：在原則模式中建立新的 IP 區塊，並將 NCP 設定為使用這些新的 IP 區塊。
-
問題：2961789：將管理程式物件移轉至原則後，無法刪除部分健全狀況檢查網繭的相關資源
將管理程式物件移轉至原則後，當您刪除健全狀況檢查網繭時，網繭的相關區段連接埠和分散式防火牆規則的目標群組不會刪除。
因應措施：手動刪除這些資源。
-
問題 2923436：Kubernetes 資源名稱太長導致失敗
如果 Kubernetes 資源名稱太長，則無法建立對應的 NSX 資源，因為 NSX 資源名稱超過 NSX 中顯示名稱的限制。記錄會顯示錯誤訊息，例如「欄位層級驗證錯誤：{display_name ipp-k8scl-two-aaaaaa...已超過其有效長度上限 255 個字元}」。NSX 具有下列限制：
-
區段顯示名稱：80 個字元
-
群組名稱 + 網域名稱：245 個字元
-
其他 NSX 資源顯示名稱：255 個字元
因應措施：縮短 Kubernetes 資源名稱。
-
-
問題 2939886：將物件從管理程式模式移轉至原則模式失敗
如果在網路原則規格中出口和入口具有相同的選取器，則將物件從管理程式模式移轉至原則模式會失敗。
因應措施：無
-
問題 2936436：NSX Manager UI 不會在容器叢集頁面上顯示 NCP 版本
當 NSX Manager UI 在詳細目錄索引標籤中顯示容器叢集時，不會顯示 NCP 版本。
因應措施：NCP 版本可透過呼叫 API /policy/api/v1/fabric/container-clusters 來使用。
-
問題 2934195：分散式防火牆規則不支援部分類型的 NSX 群組
分散式防火牆 (DFW) 規則不支援類型為「僅限 IP 位址」的 NSX 群組。類型為「一般」且手動新增 IP 位址為成員的 NSX 群組亦不受支援。
因應措施：無
-
問題：2940772：將 NCP 資源從管理程式移轉至原則導致 NSX-T 3.2.0 發生失敗
NSX-T 3.1.3 和 NSX-T 3.2.1 支援將 NCP 資源從管理程式移轉至原則，但 NSX-T 3.2.0 不支援。
因應措施：無
-
問題 2832480：對於類型為 ClusterIP 的 Kubernetes 服務，sessionAffinityConfig.clientIP.timeoutSeconds 不能超過 65535
對於類型為 ClusterIP 的 Kubernetes 服務，如果您所設定的 sessionAffinityConfig.clientIP.timeoutSeconds 的值大於 65535，則實際值將會是 65535。
因應措施：無
-
問題 2868572：執行 NCP 之前，必須在主機虛擬機器上停用 Open vSwitch (OVS)
若要在主機虛擬機器上部署 NCP，您必須先停止 OVS 相關程序，並使用下列命令來刪除主機上的某些檔案：
-
sudo systemctl disable openvswitch-switch.service
-
sudo systemctl stop openvswitch-switch.service
-
rm -rf /var/run/openvswitch
如果您已在主機虛擬機器上部署 NCP，且 OVS 未正確執行，請執行下列步驟以復原：
-
執行上述 3 個步驟。
-
使用「kubectl delete pod $agent-pod -n nsx-system」命令，在有問題的節點上刪除 nsx-node-agent 網繭，以重新啟動節點代理程式網繭。
因應措施：請參閱上述內容。
-
-
問題 2867361：進行 NCP 清理後，未移除 nsx-node-agent 和 hyperbus 警示
如果因某些原因 (例如，停止所有 NSX 節點代理程式) 而出現 nsx-node-agent 和 hyperbus 警示，且您停止 NCP 並執行清理指令碼，則清理之後警示仍在。
因應措施：無
-
問題 2824129：重新啟動之後，節點處於「網路無法使用」狀態超過 3 分鐘
如果您使用 NCP Operator 來管理 NCP 的生命週期，當 nsx-node-agent DaemonSet 從非執行中狀態復原時，其節點仍會處於「網路無法使用」狀態，直到它執行了 3 分鐘為止。這是預期的行為。
因應措施：nsx-node-agent 重新啟動後，請等待至少 3 分鐘。
-
問題 2841030：使用 Kubernetes 1.22 時，nsx-node-agent 的狀態一律為「AppArmor」
在 Kubernetes 1.22 中，當 nsx-node-agent 網繭處於「就緒」時，其狀態並不會從「AppArmor」更新為「執行中」。這不會影響 NCP 或 nsx-node-agent 的功能。
因應措施：重新啟動 nsx-node-agent 網繭。
-
問題 2860091：如果 baseline_policy_type 設定為 allow_namespace，DNS 流量會失敗
在 OpenShift 或 Kubernetes 環境中，如果 baseline_policy_type 設為 allow_namespace，將會封鎖其他命名空間中的網繭 (hostNetwork: False)，而無法存取 DNS 服務。
因應措施：新增規則網路原則，以允許從其他網繭至 DNS 網繭的流量。
-
問題 2795482：在節點/Hypervisor 重新開機或任何其他作業之後，執行中的網繭會停滯在容器建立中狀態。
如果 wait_for_security_policy_sync 旗標為 true，則由於 Worker 節點強制重新開機、Hypervisor 重新開機或某些其他原因，網繭處於執行中狀態超過一小時之後可以前往容器建立中狀態。該網繭將永久處於建立中狀態。
因應措施：刪除並重新建立網繭。
-
問題 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 移除靜態網繭。
-
問題 2736412：如果設定了 max_allowed_virtual_servers，則會忽略參數 members_per_small_lbs
如果同時設定了 max_allowed_virtual_servers 和 members_per_small_lbs，因為僅會考量 max_allowed_virtual_servers，虛擬伺服器可能無法連結至可用的負載平衡器。
因應措施：放寬調整限制，而不要啟用自動調整。
-
問題 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 容器的逾時值。
-
-
問題 2745907：「monit」命令傳回 nsx-node-agent 不正確的狀態資訊
在 diego_cell 虛擬機器上，當 monit 重新啟動 nsx-node-agent 時，如果 nsx-node-agent 需要超過 30 秒的時間才能完全啟動，monit 會將 nsx-node-agent 的狀態顯示為「執行失敗」，且即使稍後 nsx-node-agent 完全運作，也不會將其狀態更新為「執行中」。
因應措施：無。
-
問題 2745904：[對預設執行的 ASG 使用 IPSet] 功能不支援移除或取代現有的容器 IP 區塊
如果您在 NCP 動態磚上啟用 [對預設執行的 ASG 使用 IPSet]，NCP 將針對相同 NCP 動態磚上透過 [容器網路的 IP 區塊] 設定的所有容器 IP 區塊建立專用的 NSGroup。此 NSGroup 將用於為全域執行 ASG 所建立防火牆規則，以允許所有容器的流量。如果您稍後移除或取代現有的容器 IP 區塊，系統將在 NSGroup 中將其移除或取代。原始 IP 區塊中所有現有的容器將不再與全域執行的 ASG 相關聯。其流量可能不再正常運作。
因應措施：僅將新 IP 區塊附加至 [容器網路的 IP 區塊]。
-
問題 2707174：刪除後再以相同命名空間及名稱重新建立的網繭不具有網路連線
如果在 NCP 未執行而 nsx-ncp-agents 執行時刪除網繭，並使用相同的命名空間和名稱重新建立網繭，則網繭可能會取得錯誤的網路組態，且無法存取網路。
因應措施：在 NCP 執行時刪除網繭並重新建立。
-
問題 2672677：在高負荷的 OpenShift 4 環境中，節點可能會沒有回應
在個別節點具有高網繭密度，且頻繁刪除和建立網繭的 OpenShift 4 環境中，RHCOS 節點可能會進入「未就緒」狀態。在受影響的節點上執行的網繭 (daemonset 成員除外)，將會在環境中的其他節點上收回並重新建立。
因應措施：將受影響的節點重新開機。
-
問題 2653214：在節點的 IP 位址變更後搜尋節點的區段連接埠時發生錯誤
變更節點的 IP 位址後，如果您升級 NCP，或 NCP Operator 網繭重新啟動，當您使用「oc describe co nsx-ncp」命令檢查 NCP Operator 狀態時，將會顯示錯誤訊息「在搜尋節點的區段連接埠時發生錯誤 ...」
因應措施：無。不支援在同時具有 DHCP 組態的節點介面上新增靜態 IP 位址。
-
在 Kubernetes 安裝期間啟用「記錄至檔案」時，NCP 無法啟動
當容器主機上的 uid:gid=1000:1000 沒有記錄資料夾的權限時，即會發生此問題。
因應措施：請執行下列其中一個動作：
-
將容器主機上記錄資料夾的模式變更為 777。
-
將容器主機上記錄資料夾的「rwx」權限授與 uid:gid=1000:1000。
-
停用「記錄至檔案」功能。
-
-
問題 2579968：對類型為 LoadBalancer 的 Kubernetes 服務進行高頻率的變更時，某些虛擬伺服器和伺服器集區不會如預期般刪除
對類型為 LoadBalancer 的 Kubernetes 服務進行高頻率的變更時，某些虛擬伺服器和伺服器集區可能會在應已刪除時仍保留在 NSX-T 環境中。
因應措施：重新啟動 NCP。或者，手動移除失效的虛擬伺服器及其相關聯的資源。如果類型為 LoadBalancer 的 Kubernetes 服務在 external_id 標籤中有虛擬伺服器的識別碼，則虛擬伺服器會失效。
-
問題 2597423：將管理程式物件匯入原則時，復原會導致部分資源的標籤遺失
將管理程式物件匯入原則時，如果有必要復原，將不會還原下列物件的標籤：
-
Spoofguard 設定檔 (共用和叢集資源的一部分)
-
BgpneighbourConfig (共用資源的一部分)
-
BgpRoutingConfig (共用資源的一部分)
-
StaticRoute BfdPeer (共用資源的一部分)
因應措施：對於屬於共用資源一部分的資源，請手動還原標籤。使用備份和還原功能來還原屬於叢集資源一部分的資源。
-
-
問題 2552564：在 OpenShift 4.3 環境中，如果找到重疊位址，則 DNS 轉寄站可能會停止運作
在 OpenShift 4.3 環境中，叢集安裝需要設定 DNS 伺服器。如果您使用 NSX-T 來設定 DNS 轉寄站，且 IP 位址與 DNS 服務重疊，則 DNS 轉寄站將停止運作，且叢集安裝將失敗。
因應措施：設定外部 DNS 服務，刪除安裝失敗的叢集，然後重新建立叢集。
-
問題 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 超載。
-
問題 2416376：NCP 無法處理繫結到超過 128 個空間的 TAS ASG (應用程式安全群組)
由於 NSX-T 分散式防火牆中的限制，NCP 無法處理繫結到超過 128 個空間的 TAS ASG。
因應措施：建立多個 ASG，並將每個 ASG 繫結到不超過 128 個空間。
-
問題 2518111：NCP 無法刪除已從 NSX-T 更新的 NSX 資源
NCP 會根據您指定的組態建立 NSX-T 資源。如果您透過 NSX Manager 或 NSX API 對這些 NSX-T 資源進行任何更新，則 NCP 可能無法刪除這些資源，且會在必要時重新建立這些資源。
因應措施：請勿透過 NSX Manager 或 NSX-T API 更新由 NCP 建立的 NSX-T 資源。
-
問題 2404302：如果 NSX-T 上存在相同資源類型 (例如 HTTP) 的多個負載平衡器應用程式設定檔，NCP 將選擇其中任何一個來連結至虛擬伺服器。
如果 NSX-T 上存在多個 HTTP 負載平衡器應用程式設定檔，則 NCP 會選擇其中任何一個具有適當 x_forwarded_for 組態的設定檔，來連結至 HTTP 和 HTTPS 虛擬伺服器。如果 NSX-T 上存在多個 FastTCP 和 UDP 應用程式設定檔，則 NCP 會分別選擇其中一個以連結至 TCP 和 UDP 虛擬伺服器。負載平衡器應用程式設定檔可能已由具有不同設定的不同應用程式建立。如果 NCP 選擇將其中一個負載平衡器應用程式設定檔連結至 NCP 建立的虛擬伺服器，則可能會中斷其他應用程式的工作流程。
因應措施：無
-
問題 2224218：刪除服務或應用程式後，需要 2 分鐘才能將 SNAT IP 釋放回 IP 集區
如果您刪除服務或應用程式，並在 2 分鐘內重新建立，它將從 IP 集區取得新的 SNAT IP。
因應措施：刪除服務或應用程式後，如果您想要重複使用相同的 IP，則等待 2 分鐘之後再重新建立服務或應用程式。
-
對於類型為 ClusterIP 的 Kubernetes 服務，不支援 hairpin-mode 旗標
對於類型為 ClusterIP 的 Kubernetes 服務，NCP 不支援 hairpin-mode 旗標。
因應措施：無
-
問題 2131494：將入口類別從 nginx 變更為 nsx 之後，NGINX Kubernetes 入口仍然正常運作
當您建立 NGINX Kubernetes 入口時，NGINX 會建立流量轉送規則。如果將入口類別變更為任何其他值，即使您在變更類別後刪除 Kubernetes 入口，NGINX 也不會刪除規則，並且會繼續套用這些規則。這是 NGINX 的限制。
因應措施：若要刪除 NGINX 所建立的規則，請在類別值為 nginx 時刪除 Kubernetes 入口。然後，重新建立 Kubernetes 入口。
