|
VMware NSX Container Plugin 3.0.1 | 2020 年 4 月 30 日 | 組建編號 16118386 請定期查看此文件的增補和更新。 |
版本說明的內容
此版本說明涵蓋下列主題:
新增功能
- 支援 IPv6 Kubernetes 叢集中的 IPAM 與 L3 連線、服務叢集 IP 和負載平衡
- 支援每個網繭的多個介面 (類似 Multus 的功能)
- 支援 OpenShift Container Platform (OCP) 4
- 在 NCP ConfigMap 中顯示 DFW 規則記錄選項
- 在 NCP ConfigMap 中顯示第 1 層路由器設定
- 針對 NCP ConfigMap 中的標頭大小調整和逾時,顯示負載平衡器 HTTP 設定檔設定
- 在原則 API 中新增負載平衡器 CRD 的支援
- 支援 X 轉送的連接埠
- SSL 傳遞 (SNI 型主機交換) 和重新加密
- 報告網路原則控制器的改進時發生錯誤
- 支援將管理程式物件匯入原則
- 容器工作負載的第 3 層多點傳播支援 (僅限單一階層共用的第 0 層拓撲)
- 原則模式 NCP 部署的專用 YAML 檔案
相容性需求
| 產品 | 版本 |
|---|---|
| Tanzu 應用程式服務 (PCF) 的 NCP/NSX-T 圖標 | 3.0.1 |
| NSX-T | 2.5.0、2.5.1、2.5.2、2.5.2.2、2.5.3、3.0.0、3.0.1 |
| vSphere | 6.7、7.0 |
| Kubernetes | 1.17、1.18 |
| OpenShift 3 | 3.11 |
| OpenShift 4 | RHCOS 4.3 |
| Kubernetes 主機虛擬機器作業系統 | Ubuntu 16.04、Ubuntu 18.04、CentOS 7.7、RHEL 7.7、RHEL 7.8 附註:對於 RHEL 7.8,不支援 nsx-ovs。它僅與上游 OVS 相容。 |
| OpenShift 主機虛擬機器作業系統 | RHEL 7.6、RHEL 7.7 |
| OpenShift BMC (在未來的版本中將變為棄用) |
RHEL 7.6、RHEL 7.7 |
| Tanzu 應用程式服務 (Pivotal Cloud Foundry) | Ops Manager 2.6 + PAS 2.6 Ops Manager 2.8 + PAS 2.8 Ops Manager 2.9 + PAS 2.9 |
棄用通知:VMware 打算在未來的版本中棄用對 OpenShift 裸機容器的支援。
支援升級至此版本:
- NCP 3.0 及所有 NCP 2.5.x 版本
已解決的問題
- 問題 2330811:在 NCP 關閉的情況下建立類型 LoadBalancer 的 Kubernetes 服務時,NCP 重新啟動時可能不會建立服務
類型 LoadBalancer 的 Kubernetes 服務的 NSX-T 資源用盡時,您可以在刪除部分現有的服務後建立新服務。但是,如果您在 NCP 關閉時刪除並建立服務,NCP 將無法建立新服務。
因應措施:類型 LoadBalancer 的 Kubernetes 服務的 NSX-T 資源用盡時,在 NCP 關閉時請勿執行刪除和建立作業。
- 問題 2408100:在多個 NCP 執行個體處於作用中/待命模式或是已啟用活躍性探查的大型 Kubernetes 叢集中,NCP 經常重新啟動
在大型 Kubernetes 叢集中 (大約 25,000 個網繭、2,500 個命名空間和 2,500 個網路原則),如果多個 NCP 執行個體在作用中/待命模式下執行,或是啟用了活躍性探查,則 NCP 程序可能會因為「取得鎖定衝突」或活躍性探查失敗而經常遭刪除並重新啟動。
因應措施:執行下列步驟:
- 將 NCP 部署的
replicas設定為 1,或將 ncp.ini 的組態選項ha.master_timeout從預設值 18 提高到 30。 - 提高活躍性探查引數,如下所示:
containers: - name: nsx-ncp livenessProbe: exec: 命令: - /bin/sh - -c - timeout 20 check_pod_liveness nsx-ncp initialDelaySeconds: 20 timeoutSeconds: 20 periodSeconds: 20 failureThreshold: 5
- 將 NCP 部署的
- 問題 2517201:無法在 ESXi 主機上建立網繭
從 vSphere 叢集中移除 ESXi 主機並將其新增回叢集後,在主機上建立網繭會失敗。
因應措施:將 NCP 重新開機。
已知問題
- 問題 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 後,節點狀態會變更為「就緒」。
- 問題 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 資源。
- 問題 2518312:NCP 啟動程序容器無法在 Ubuntu 18.04.4 核心 4.15.0-88 上安裝 nsx-ovs 核心模組。
NCP 啟動程序容器 (nsx-ncp-bootstrap) 無法在 Ubuntu 18.04.4 核心 4.15.0-88 上安裝 nsx-ovs 核心模組。
請勿透過在 nsx-node-agent-config 中設定 use_nsx_ovs_kernel_module = False 以在此核心上安裝 NSX-OVS。請改用主機上的上游 OVS 核心模組 (Ubuntu 依預設會隨附於 OVS 核心模組)。如果主機上沒有任何 OVS 核心模組,請手動安裝 OVS 核心模組,並在 nsx-node-agent-config 中設定 use_nsx_ovs_kernel_module = False,或將核心版本降級至 4.15.0-76,以便可以安裝 NSX-OVS。
- 問題 2524778:刪除 NCP 主節點後,NSX Manager 會將 NCP 顯示為關閉或狀況不良
刪除 NCP 主節點後,例如,在成功切換至備份節點後,當 NCP 的健全狀況狀態應為開啟時,仍會顯示為關閉。
因應措施:使用 Manager API DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status 手動清除過時狀態。
- 問題 2548815:在從管理程式匯入原則的 NCP 叢集中,NCP 無法刪除自動縮放的第 1 層路由器
在管理程式匯入原則之後,在原則模式中執行的 NCP 無法刪除自動縮放的第 1 層路由器,因為其 LocaleService 仍在參考該路由器。
因應措施:使用 NSX Manager UI 手動刪除第 1 層路由器。
- 問題 2549433:當 DHCP 租用到期時,使用設定為 ovs_uplink_port 之單一介面的 OpenShift 節點會遺失名稱伺服器資訊
當 ovs_uplink_port 的 DHCP 租用到期時,具有單一介面的 OpenShift 節點 (在 nsx-node-agent 組態中設定為 ovs_uplink_port) 會遺失名稱伺服器資訊。
因應措施:使用靜態 IP 位址。
- 問題 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。
- 問題 2550625:將叢集從管理程式移轉至原則之後,不會釋放共用 IP 集區中的 IP 位址
在叢集從管理程式移轉至原則之後,刪除命名空間並不會釋放配置給該命名空間的 IP 位址。
因應措施:無。
- 問題 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 超載。
- 問題 2549765:如果 NAT 規則有多個目的地連接埠,則將管理程式物件匯入原則會失敗
如果頂層路由器上的 NAT 規則有多個目的地連接埠,則將管理程式匯入原則的程序會失敗。其中一種情況是當 NCP 組態中的 Kubernetes 參數 ingress_mode 為「NAT」,且 Kubernetes 中存在具有註解「ncp/ingress-controller」的網繭時。
因應措施:當 NCP 非執行中,且在起始匯入之前,請編輯 NAT 規則並移除「80」和「443」目的地連接埠。
- 問題 2552918:針對分散式防火牆執行管理程式匯入原則的復原作業失敗,從而導致叢集復原失敗
在極少數情況下,管理程式匯入原則程序必須執行復原,分散式防火牆區段和規則的復原會出現失敗。這會導致叢集復原失敗,並使失效資源保留在 NSX Manager 中。
因應措施:使用備份和還原功能將 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。
- 問題 2593017:未在 NSX-T 上刪除失效的邏輯路由器連接埠
在具有管理程式 API 的雙層拓撲中,有時候不會刪除失效的邏輯路由器連接埠。存在大量失效路由器連接埠時,路由器行為可能會受到影響。
因應措施:從 NSX Manager 手動刪除失效的路由器連接埠。
- 問題 3033821:在完成管理程式至原則移轉後,分散式防火牆規則無法正確強制執行
在完成管理程式至原則移轉後,新建立的網路原則相關分散式防火牆 (DFW) 規則的優先順序將高於已移轉的 DFW 規則。
因應措施:視需要使用原則 API 變更 DFW 規則的順序。