版本說明的內容

更新時間:2021 年 2 月 02 日

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

 

新增功能

VMware vSphere with Tanzu 具有每月修補程式,以推出新的特性和功能、提供 Kubernetes 和其他服務的更新、追蹤上游資訊,以及解決所報告的問題。在這裡,我們說明了每個每月修補程式提供的內容。

 

2021 年 2 月 02 日的最新內容

2021 年 2 月 02 日組建編號資訊

ESXi 7.0 | 2020 年 12 月 17 日 | ISO 組建編號 17325551

vCenter Server 7.0 | 2021 年 2 月 02 日 | ISO 組建編號 17491101

新功能

  • 主管叢集
    • 更新使用 vSphere 網路的主管叢集:現在,您可以將使用 vSphere 網路的主管叢集從舊版 Kubernetes 更新至可用的最新版本。新的主管叢集版本也將提供最新的 Tanzu Kubernetes Grid 服務功能。 

已解決的問題

  • 新的 Tanzu Kubernetes Grid 服務功能在使用 vSphere 網路的現有主管中無法使用

    • 在先前的版本中,新的 Tanzu Kubernetes Grid 服務功能和錯誤修正僅在使用 vSphere 網路時在新建立的主管叢集中可用。在此版本中,使用者現在可以更新使用 vSphere 網路的主管叢集,以利用最新的 Tanzu Kubernetes Grid 服務功能和錯誤修正。
       

 

2020 年 12 月 17 日的最新內容 

2020 年 12 月 17 日組建編號資訊

ESXi 7.0 | 2020 年 12 月 17 日 | ISO 組建編號 17325551

vCenter Server 7.0 | 2020 年 12 月 17 日 | ISO 組建編號 17327517

附註:若要利用此版本中的新 Tanzu Kubernetes Grid 服務功能和錯誤修正,您必須在使用 vSphere 網路時建立新的主管叢集。

新功能

  • 主管叢集
    • 使用專用 T1 路由器的主管命名空間隔離 – 使用 NSX-T 網路的主管叢集會使用新的拓撲,其中每個命名空間都有其自己的專用 T1 路由器。 
      • 新建立的主管叢集會自動使用此新拓撲。
      • 在升級期間,現有的主管叢集會移轉到此新拓撲。
    • 主管叢集支援 NSX-T 3.1.0 – 主管叢集與 NSX-T 3.1.0 相容。
    • 已移除主管叢集 1.16.x 版支援 – 主管叢集 1.16.x 版現已移除。執行 1.16.x 的主管叢集應升級到新版本。
  • Tanzu Kubernetes Grid Service for vSphere
    • HTTP/HTTPS Proxy 支援 – 新建立的 Tanzu Kubernetes 叢集可以將全域 HTTP/HTTPS Proxy 用於出口流量,以及從網際網路登錄提取容器映像。
    • 與登錄服務整合 – 新建立的 Tanzu Kubernetes 叢集與 vSphere 登錄服務整合,可一起使用。現有叢集在更新至新版本後,也可與登錄服務一起使用。
    • 可設定的節點儲存區 – Tanzu Kubernetes 叢集現在可以將額外的儲存磁碟區掛接到虛擬機器,從而增加可用的節點儲存區容量。這可讓使用者部署可能超過預設 16 GB 根磁碟區大小的更大的容器映像。
    • 改善狀態資訊 WCPCluster 和 WCPMachine 自訂資源定義現在會實作條件式狀態報告。成功的 Tanzu Kubernetes 叢集生命週期管理取決於多個子系統 (例如,主管、儲存區、網路),瞭解故障極具挑戰性。現在 WCPCluster 和 WCPMachine CRD 會顯示一般狀態和故障條件,以簡化疑難排解。

已解決的問題

  • 缺少 vSphere 7.0 U1 中引入的新預設虛擬機器類別

    • 升級至 vSphere 7.0.1 並執行主管叢集的 vSphere 命名空間更新時,執行「kubectl get virtualmachineclasses」命令不會列出新虛擬機器類別大小 2 倍大、4 倍大、8 倍大。此問題已解決,所有主管叢集將使用正確的預設虛擬機器類別集進行設定。
       

2020 年 10 月 6 日的最新內容 

2020 年 10 月 6 日組建編號資訊

ESXi 7.0 | 2020 年 10 月 06 日 | ISO 組建編號 16850804

vCenter Server 7.0 | 2020 年 10 月 06 日 | ISO 組建編號 16860138

新功能

  • 主管叢集
    • 設定具有 vSphere 網路的主管叢集 – 我們引入了用於主管叢集的 vSphere 網路,讓您能夠使用現有網路基礎結構提供開發人員就緒的平台。
    • 支援 HAproxy 負載平衡器以設定具有 vSphere 網路的主管叢集 – 如果您設定具有 vSphere 網路的主管叢集,則需要新增負載平衡器以處理您的現代工作負載。您可以使用 HAproxy OVA 部署和設定負載平衡器。
    • 使用 vSphere Lifecycle Manager 管理主管叢集生命週期 – 對於設定了 vSphere 網路的主管叢集,您可以使用 vSphere Lifecycle Manager 進行基礎結構設定和生命週期管理。
    • 有機會在硬體上試用 vSphere with Tanzu – 現在,如果您想在硬體上啟用主管叢集並測試此現代應用程式平台且無需額外付費,我們可以為您提供產品內試用版。
       
  • Tanzu Kubernetes Grid Service for vSphere
    • 向 DevOps 使用者公開 Kubernetes 版本 – 我們在主管叢集中引入了新的「TanzuKubernetesRelease」自訂資源定義。此自訂資源定義向 DevOps 使用者提供有關可在其 Tanzu Kubernetes 叢集中使用的 Kubernetes 版本的詳細資訊。
    • 將 VMware Container Networking 與適用於 Kubernetes 的 Antrea 整合 – 我們整合了商業支援版本 Antrea 以作為新 Tanzu Kubernetes 叢集的預設容器網路介面 (CNI)。Antrea 向 Tanzu Kubernetes Grid 服務提供了全套企業網路原則功能。如需更多詳細資料,請閱讀發行公告。雖然 Antrea 是預設 CNI,但 vSphere 管理員和 DevOps 使用者仍可以選擇 Calico 作為 Tanzu Kubernetes 叢集的 CNI。
    • 支援使用 vSphere 網路的主管叢集環境 – 我們現在支援使用 vSphere 網路的主管叢集環境,以便您可以利用現有的網路基礎結構。

已解決的問題

  • 未列出。這是功能發行版本。

2020 年 8 月 25 日的最新內容 

2020 年 8 月 25 日組建編號資訊

ESXi 7.0 | 2020 年 6 月 23 日 | ISO 組建編號 16324942

vCenter Server 7.0 | 2020 年 8 月 25 日 | ISO 組建編號 16749653

新功能

  • 無,這只是一個錯誤修正版本。

已解決的問題

  • 升級到 7 月 30 日修補程式時的高 CPU 使用率
    • 在升級到 7 月 30 日修補程式後,vCenter Server 會產生高 CPU 使用率。此問題現已修正。
  • 由於憑證含有 Windows 行尾結束符號,主管叢集啟用失敗
    • 如果憑證中含有 Windows 行尾結束符號,則啟用主管叢集可能會失敗。此問題現已修正。

2020 年 7 月 30 日的最新內容 

2020 年 7 月 30 日組建編號資訊

ESXi 7.0 | 2020 年 6 月 23 日 | ISO 組建編號 16324942

vCenter Server 7.0 | 2020 年 7 月 30 日 | ISO 組建編號 16620007

新功能

  • 主管叢集:新版本的 Kubernetes,支援自訂憑證和 PNID 變更
    • 主管叢集現在支援 Kubernetes 1.18.2 (以及 1.16.7 和 1.17.4)
    • 現在支援使用自訂憑證取代機器 SSL 憑證
    • 現在當 vCenter Server 中有主管叢集時支援 vCenter PNID 更新
  • Tanzu Kubernetes Grid Service for vSphere:針對叢集縮小、網路和儲存區新增的功能
    • Tanzu Kubernetes Grid 服務叢集現在支援叢集縮小作業
    • 現在預設會對所有 Tanzu Kubernetes Grid 服務叢集強制執行入口防火牆規則
    • 新版本的 Kubernetes 以非同步方式定期傳送到 vSphere 修補程式,目前版本為 1.16.8、1.16.12、1.17.7、1.17.8
  • 網路服務:新的 NCP 版本
    • ClusterIP 服務現在支援 SessionAffinity
    • Kubernetes 1.18 中的入口支援 IngressClass、PathType 和萬用字元網域
    • 入口控制站目前支援用戶端驗證
  • 登錄服務:新的 Harbor 版本
    • 登錄服務現已升級至 1.10.3

如需有關如何升級的詳細資訊和指示,請參閱《更新 vSphere with Tanzu 叢集》說明文件。

已解決的問題

  • Tanzu Kubernetes Grid 服務叢集 NTP 同步問題

2020 年 6 月 23 日的最新內容 

2020 年 6 月 23 日組建編號資訊

ESXi 7.0 | 2020 年 6 月 23 日 | ISO 組建編號 16324942

vCenter Server 7.0 | 2020 年 6 月 23 日 | ISO 組建編號 16386292

Tanzu Kubernetes 叢集 OVA:v1.16.8+vmware.1-tkg.3.60d2ffd

新功能

  • 無,這只是一個錯誤修正版本。

已解決的問題

  • Tanzu Kubernetes Grid 服務叢集升級失敗
    • 我們已解決因「錯誤: 上一個節點未知」而導致升級 Tanzu Kubernetes Grid 服務叢集失敗的問題
  • 主管叢集升級失敗
    • 我們已解決在內嵌式 Harbor 處於失敗狀態時主管叢集更新可能會停滯的問題

2020 年 5 月 19 日的最新內容 

2020 年 5 月 19 日組建編號資訊

ESXi 7.0 | 2020 年 4 月 2 日 | ISO 組建編號 15843807

vCenter Server 7.0 | 2020 年 5 月 19 日 | ISO 組建編號 16189094

Tanzu Kubernetes 叢集 OVA:v1.16.8+vmware.1-tkg.3.60d2ffd

新功能

  • Tanzu Kubernetes Grid Service for vSphere:輪流升級和服務升級
    • 客戶現在可以針對 Tanzu Kubernetes Grid Service for vSphere,在其工作節點和控制平面節點上執行輪流升級,並升級 pvCSI、Calico 和 authsvc 服務。這包括此服務矩陣的預先檢查和升級相容性。
    • 輪流升級可用於垂直調整工作節點,也就是,將工作節點的虛擬機器類別變更為較小或較大的大小。
  • 主管叢集:新版本的 Kubernetes,支援升級
    • 主管叢集現在支援 Kubernetes 1.17.4
    • 主管叢集現在支援從 Kubernetes 1.16.x 升級至 1.17.x

已解決的問題

  • 已刪除命名空間的命名衝突
    • 如果使用者刪除了 vSphere 命名空間,然後建立具有相同名稱的新 vSphere 命名空間,則會發生命名衝突,從而導致無法建立 Tanzu Kubernetes 叢集。我們已解決此問題。
  • 改進的發行版名稱
    • 我們透過將 OVF 版本設定資訊移動到單獨的資料行,以更清楚地顯示您所執行的 Kubernetes 版本。

初始 vSphere with Kubernetes 版本的組建編號資訊

2020 年 4 月 2 日組建編號資訊

ESXi 7.0 | 2020 年 4 月 2 日 | ISO 組建編號 15843807

vCenter Server 7.0 | 2020 年 4 月 2 日 | ISO 組建編號 15952498

Tanzu Kubernetes 叢集 OVA:v1.16.8+vmware.1-tkg.3.60d2ffd

瞭解 vSphere with Tanzu

VMware 提供了多種資源,您可以使用這些資源來瞭解 vSphere with Tanzu。

  • 閱讀 vSphere with Tanzu 設定與管理,瞭解如何設定、管理和使用 vSphere with Tanzu。本指南專為 vSphere 系統管理員和 DevOps 團隊所設計,提供了有關 vSphere with Tanzu 架構、服務、授權、系統需求、設定和使用量的詳細資料。

  • 使用《VMware 相容性指南》瞭解 vSphere with Tanzu 的硬體相容性產品互通性。vSphere with Tanzu 與 vSphere 7.0 具有相同的硬體需求。為取得特定組態,還需要使用 NSX-T Edge 虛擬機器,而這些虛擬機器有其自己較小子集的 CPU 相容性。如需詳細資訊,請參閱《NSX-T Data Center 安裝指南》。

  • 透過造訪《vSphere 7.0 版本說明》的〈國際化〉章節,瞭解 vSphere with Tanzu 提供哪些語言。這些語言即是 VMware 為 vSphere 提供的語言。

  • 透過造訪《vSphere 7.0 版本說明》的〈開放原始碼〉章節,檢視 vSphere with Tanzu 開放原始碼元件的版權和授權。《vSphere 7.0 版本說明》還會告訴您下載 vSphere 開放原始碼元件的位置。

已知問題

已知問題分類如下。

主管叢集
  • 當 DRS 設定為手動模式時,在主管叢集上建立網繭有時會失敗

    啟用了工作負載管理的叢集還必須啟用 HA 和自動化 DRS。如果在未啟用 HA 和 DRS 或 DRS 於手動模式下執行的叢集上啟用工作負載管理,可能會導致行為不一致以及網繭建立失敗。

    因應措施:在叢集上啟用 DRS 並將其設為全自動半自動。同時確保叢集上已啟用 HA。

  • 即使移除了對應的儲存區原則,在您執行 kubectl get sc 時也會顯示儲存區類別

    如果在建立儲存區原則之後執行 kubectl get sc,將原則新增至命名空間,然後移除原則,則命令回應仍會列出對應的儲存區類別。

    因應措施:執行 kubectl describe namespace,以查看實際與命名空間相關聯的儲存區類別。

  • 在主管叢集上執行 kubectl describe storage-class 或 kubectl get storage-class 時傳回了所有儲存區類別,而不只是用於主管命名空間的儲存區類別

    當您在主管叢集上執行 kubectl describe storage-classkubectl get storage-class 命令時,該命令會傳回所有儲存區類別,而不只是用於主管命名空間的儲存區類別。

    因應措施:從配額的詳細名稱推斷與命名空間相關聯的儲存區類別名稱。

  • 即使 FQDN 已設定,共用 Kubernetes API 端點按鈕仍會忽略 FQDN

    即使已針對主管叢集命名空間的 Kubernetes 控制平面 IP 設定 FQDN,共用命名空間按鈕仍會提供 IP 位址而非 FQDN。

    因應措施:手動與 FQDN 共用主管叢集命名空間。

  • 在主管叢集升級期間,如果使用了精靈集,則可能會建立額外的 vSphere 網繭並停滯在擱置狀態

    在主管叢集升級期間,精靈集控制器會為每個主管控制平面節點建立額外的 vSphere 網繭。這是由於上游 Kubernetes 問題所致。

    因應措施:將 NodeSelector/NodeAffinity 新增至 vSphere 網繭規格,以便精靈集控制器可以略過用於建立網繭的控制平面節點。

  • 無法透過 kubectl vSphere 登入資訊存取負載平衡器

    使用負載平衡端點時,您無法透過 kubectl vSphere 登入資訊存取 API 伺服器。

    因應措施:此問題會表現在兩個方面。

    1. 檢查 API 伺服器是否可以透過控制平面 <curl -k https://vip:6443 (或 443)> 進行存取

      1. 如果無法從 API 伺服器存取負載平衡器,則表示 API 伺服器尚未啟動。

      2. 因應措施:請等待幾分鐘,以使 API 伺服器變為可存取。

    2. 檢查 Edge 虛擬機器節點的狀態是否為 [開啟]。

      1. 登入 NSX Manager。

      2. 移至系統 > 網狀架構 > 節點 > Edge 傳輸節點。節點狀態應為 [開啟]。

      3. 移至網路 > 負載平衡器 > 虛擬伺服器。尋找以 kube-apiserver-lb-svc-6443 和 kube-apiserver-lb-svc-443 結尾的 vip。如果其狀態不是 [開啟],則使用以下因應措施。

      4. 因應措施:將 Edge 虛擬機器重新開機。Edge 虛擬機器應在重新開機後進行重新設定。

  • 在設定期間,vSphere with Tanzu 的叢集組態顯示逾時錯誤

    在叢集設定期間,您可能會看到下列錯誤訊息:

    向 param0 發出 API 要求失敗

    param0 節點虛擬機器的設定作業已逾時

    因應措施:無。啟用 vSphere with Tanzu 可能需要 30 到 60 分鐘。當您看到這些或類似的 param0 逾時訊息時,它們不屬於錯誤,可放心忽略。

  • 啟用容器登錄失敗,並顯示錯誤

    當使用者從使用者介面啟用容器登錄時,啟用動作會在 10 分鐘後失敗,並顯示逾時錯誤。

    因應措施:停用容器登錄,然後重試啟用。請注意,可能會再次出現逾時錯誤。

  • 將叢集停用後再啟用會失敗並顯示錯誤

    將叢集停用後再立即啟用,可能會在服務帳戶密碼重設程序中造成衝突。啟用動作失敗,並顯示錯誤。

    因應措施:使用命令 vmon-cli --restart wcp 重新啟動。

  • 刪除內嵌式容器登錄中的容器映像標籤可能會刪除共用相同實體容器映像的所有映像標籤

    可以將具有不同標籤的多個映像從相同的容器映像推送至內嵌式容器登錄中的專案。如果專案上的其中一個映像已刪除,則會刪除從相同映像推送的具有不同標籤的所有其他映像。

    因應措施:此作業無法復原。再次將映像推送至專案。

  • vSphere 上 Kubernetes 叢集的內嵌式容器登錄可能無法啟用,並顯示錯誤

    在網繭啟動期間,內嵌式容器登錄命名空間中的某些容器登錄可能會連結 PVC (持續性磁碟區宣告) 磁碟區。當此類網繭失敗時,新的網繭可能無法啟動,因為網繭無法連結 PVC 磁碟區。在這些情況下,您會在網繭事件中看到錯誤訊息,例如無法連結 cns 磁碟區資源「磁碟區」正在使用中。如果在內嵌式容器登錄啟用期間或啟用後網繭失敗,可能會發生此情況。

    因應措施:刪除容器登錄命名空間中所有失敗的網繭。

  • 對登錄專案執行清除作業失敗會導致專案處於「錯誤」狀態

    當您在登錄專案上執行清除作業時,此專案會暫時顯示為處於錯誤狀態。您將無法從此類專案推送或提取映像。系統會定期檢查專案,刪除並重新建立處於錯誤狀態的所有專案。發生此情況時,所有先前的專案成員將被新增回重新建立的專案,並將刪除先前存在於專案中的所有存放庫和映像,從而有效地完成清除作業。

    因應措施:無。

  • 當儲存區容量少於 2000 MiB 時,容器登錄啟用會失敗

    容器登錄有最低儲存區容量要求,此要求在 VMODL 中以「限制」欄位表示。這是因為某些 Kubernetes 網繭需要足夠的儲存空間才能正常運作。若要實現容器功能,需至少有 5 GB 的容量。請注意,此限制無法保證可以改善效能或增加可支援的映像數目或大小。

    因應措施:部署具有較大總容量的容器登錄可避免此問題。建議儲存磁碟區不小於 5 GB。

  • 如果您取代 Kubernetes 叢集的 NSX 負載平衡器的 TLS 憑證,可能無法從 docker 用戶端或 Harbor 使用者介面登入內嵌式 Harbor 登錄

    若要取代 Kubernetes 叢集的 NSX 負載平衡器的 TLS 憑證,請從 vSphere 使用者介面導覽至設定 > 命名空間 > 憑證 > NSX 負載平衡器 > 動作,然後按一下取代憑證。當您取代 NSX 憑證時,從 docker 用戶端或 Harbor 使用者介面登入內嵌式 Harbor 登錄的作業可能會失敗,並顯示未經授權: 需要驗證使用者名稱或密碼無效錯誤。

    因應措施:在 vmware-system-registry 命名空間中重新啟動登錄代理程式網繭:

    1. 執行 kubectl get pod -n vmware-system-registry 命令。
    2. 執行 kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry 命令以刪除網繭輸出。
    3. 等待網繭重新啟動。
  • 使用 DNSDefault 部署的網繭將使用 clusterDNS 設定

    在主管叢集中部署的使用 DNSDefault 的任何 vSphere 網繭,將改為使用為叢集設定的 clusterDNS

    因應措施:無。

  • 在升級主管叢集時,叢集中的所有主機都可能同時更新

    在某些情況下,叢集中的所有主機將在主管叢集升級程序期間並行更新。這將會導致此叢集上執行的所有網繭停機。

    因應措施:在主管叢集升級期間,不要重新啟動 wcpsvc 或移除/新增主機。

  • 如果將 VMCA 用作中繼 CA,則主管叢集升級會無限期停滯

    如果要將 VMCA 用作中繼 CA,則主管叢集升級會無限期停滯在「正在設定」。

    因應措施:針對 VMCA 切換至非中繼 CA,並刪除停滯在「正在設定」的任何控制平面虛擬機器。

  • 如果將已啟用加密的儲存區原則指派用於網繭暫時磁碟,則 vSphere 網繭部署將會失敗

    如果將已啟用加密的儲存區原則用於網繭暫時磁碟,則 vSphere 網繭部署將會失敗,並顯示「對磁碟區執行 AttachVolume.Attach 失敗」錯誤。

    因應措施:將不含加密的儲存區原則用於網繭暫時磁碟。

  • 在「命名空間叢集升級處於升級主機步驟」期間,主管叢集升級在進度為 50% 時當機

    在 Kubernetes 控制平面節點升級期間,如果 vSphere 網繭在狀態為 [正在終止] 時當機,則會發生此問題。控制平面節點的控制器嘗試升級 Spherelet 程序,並且在該階段期間,將在該控制平面節點上收回或終止 vSphere 網繭,以從 Kubernetes 控制平面解除登錄節點。由於此原因,主管叢集升級會在較舊的版本中當機,直到從詳細目錄中移除處於 [正在終止] 狀態的 vSphere 網繭為止。

    因應措施

    1.登入 vSphere 網繭在狀態為 [正在終止] 時當機的 ESXi 主機。

    2.使用下列命令移除處於 [正在終止] 狀態的 vSphere 網繭:

      # vim-cmd vmsvc/getallvms

      # vim-cmd vmsvc/destroy

        在此步驟之後,vSphere 網繭會在 vSphere Client 中顯示為孤立狀態。

    3.先將使用者新增至 ServiceProviderUsers 群組,再刪除孤立的 vSphere 網繭。

        a.) 登入 vSphere Client,選取管理 -> 使用者和群組 -> 建立使用者,然後按一下群組

       b.) 搜尋 ServiceProviderUsers 或管理員群組,並將使用者新增至群組。

     4.使用剛建立的使用者登入 vSphere Client,然後刪除孤立的 vSphere 網繭。

     5.在 kubectl 中,使用下列命令:

       kubectl patch pod -p -n '{"metadata":{"finalizers":null}}'

  • 工作負載管理使用者介面擲回下列授權錯誤:沒有連線至此 vCenter 的任何主機授權用於工作負載管理

    成功啟用 vSphere 叢集上的工作負載管理之後,您可能會在將 vCenter Server 重新開機或升級已啟用工作負載管理的 ESXI 主機後看到下列授權錯誤:連線至此 vCenter 的主機均未獲得用於工作負載管理的授權。  這是外觀使用者介面錯誤。您的授權應該仍然有效,且工作負載應該仍在執行中。

    因應措施:使用者應清除其 vSphere Client 的瀏覽器快取。

網路
  • 在速度較慢的網路上部署 NSX Edge 虛擬機器失敗

    NSX Edge OVF 部署和 NSX Edge 虛擬機器登錄總共有 60 分鐘的逾時時間。在較慢的網路或具有較慢儲存的環境中,如果 Edge 部署和登錄所需的時間超過此 60 分鐘的逾時時間,則作業將會失敗。

    因應措施:清理 Edge 並重新啟動部署。

  • 如果在叢集設定後變更 vCenter Server DNS、NTP 或 Syslog 設定,則 NSX Edge 不會更新

    在叢集設定期間,DNS、NTP 和 Syslog 設定會從 vCenter Server 複製到 NSX Edge 虛擬機器。如果上述任何 vCenter Server 設定在設定後發生變更,則不會更新 NSX Edge。

    因應措施:使用 NSX Manager API 更新 NSX Edge 的 DNS、NTP 和 Syslog 設定。

  • NSX Edge 管理網路組態僅在特定連接埠群組上提供子網路和閘道組態

    僅當主機上設定的 ESXi VMKnic 受到所選 VDS 上的 DVPG 支援時,NSX Edge 管理網路相容性下拉式清單才會顯示子網路和閘道資訊。如果選取的分散式連接埠群組未連結 VMKnic,則必須為網路組態提供子網路和閘道。

    因應措施:使用下列其中一個組態:

    • 謹慎選擇連接埠群組:這是目前沒有 VMK 的位置。您必須為此連接埠群組提供適當的子網路和閘道資訊。

    • 共用管理連接埠群組:這是 ESXi 主機的管理 VMK 所在的位置。將自動提取子網路和閘道資訊。

  • 在叢集設定期間無法使用 VLAN 0

    嘗試將 VLAN 0 用於覆疊通道端點或上行組態時,此作業失敗並顯示訊息:

    Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network.請使用介於 1 到 4094 之間的 VLAN 識別碼。

    因應措施:使用下列其中一個程序手動啟用 VLAN 0 支援:

    1.透過 SSH 進入已部署的 VC (root/vmware)。

    2.開啟 /etc/vmware/wcp/nsxdsvc.yaml。將會有類似如下的內容:

    logging: 
      level: debug
      maxsizemb: 10 

    a. 若要為 NSX 叢集覆疊網路啟用 VLAN0 支援,請將下列幾行附加到 /etc/vmware/wcp/nsxdsvc.yaml,然後儲存檔案。

    experimental:
     supportedvlan: 
      hostoverlay: 
        min: 0 
        max: 4094 
      edgeoverlay:     
    min: 1 
        max: 4094 
      edgeuplink:     
    min: 1 
        max: 4094 

    b. 若要為 NSX Edge 覆疊網路啟用 VLAN0 支援,請將下列幾行附加到 /etc/vmware/wcp/nsxdsvc.yaml,然後儲存檔案。

    experimental: 
     supportedvlan: 
      hostoverlay: 
        min: 1 
        max: 4094 
      edgeoverlay:     
    min: 0 
        max: 4094 
      edgeuplink:     
    min: 1 
        max: 4094 

    c. 若要為 NSX Edge 上行網路啟用 VLAN0 支援,請將下列幾行附加到 /etc/vmware/wcp/nsxdsvc.yaml,然後儲存檔案。

    experimental: 
     supportedvlan: 
      hostoverlay: 
        min: 1 
        max: 4094 
      edgeoverlay:     
    min: 1 
        max: 4094 
      edgeuplink:     
    min: 0 
        max: 4094 

    3.使用 vmon-cli --restart wcp 重新啟動工作負載管理服務。

  • 無法在已啟用 vSphere Lifecycle Manager 映像的叢集上啟用 vSphere with Tanzu 和 NSX-T

    vSphere with Tanzu 和 NSX-T 與 vSphere Lifecycle Manager 映像不相容。它們僅與 vSphere Lifecycle Manager 基準相容。當叢集上啟用 vSphere Lifecycle Manager 映像時,您無法在該叢集上啟用 vSphere with Tanzu 或 NSX-T。

    因應措施:將主機移至已停用 vSphere Lifecycle Manager 映像的叢集。必須將叢集與 vSphere Lifecycle Manager 基準搭配使用。當主機移動後,您可以依序在新叢集上啟用 NSX-T 和 vSphere with Tanzu。

  • 使用 NSX-T 設定 vSphere with Tanzu 網路時,不支援「ExternalTrafficPolicy: local」

    對於類型為 LoadBalancer 的 Kubernetes 服務,不支援「ExternalTrafficPolicy: local」組態。

    因應措施:無。

  • 使用 NSX-T 設定 vSphere with Tanzu 網路時,Tanzu Kuberetes 叢集可支援的類型為 LoadBalancer 的服務數目受主管叢集的 NodePort 範圍所限制

    每個類型為 LoadBalancer 的 VirtualMachineService 會轉譯為一個類型為 LoadBalancer 的 Kubernetes 服務和一個 Kubernetes 端點。可在主管叢集中建立的類型為 LoadBalancer 的 Kubernetes 服務數目上限為 2767,這包括在主管叢集本身以及在 Tanzu Kubernetes 叢集中建立的服務。

    因應措施:無。

  • 在 vSphere Distributed Switch (vDS) 環境中,可以使用與主管叢集的網路 CIDR 範圍重疊或衝突的網路 CIDR 範圍設定 Tanzu Kubernetes 叢集 (反之亦然),進而導致元件無法通訊。

    在 vDS 環境中,當您為主管叢集設定 CIDR 範圍或設定 Tanzu Kubernetes 叢集的 CIDR 範圍時,不會執行任何設計階段網路驗證。因此,可能會出現兩個問題:

    1) 您建立具有 CIDR 範圍的主管叢集,與為 Tanzu Kubernetes 叢集保留的預設 CIDR 範圍相衝突。

    2) 使用與用於主管叢集的 CIDR 範圍重疊的自訂 CIDR 範圍建立 Tanzu Kubernetes 叢集。

    因應措施:

    對於 vDS 環境,當您設定主管叢集時,請勿使用任何一個用於 Tanzu Kubernetes 叢集的預設 CIDR 範圍,包括為服務保留的 192.168.0.0/16,以及為網繭保留的 10.96.0.0/12。另請參閱《vSphere with Tanzu》說明文件中的〈Tanzu Kubernetes 叢集的組態參數〉。

    對於 vDS 環境,當您建立 Tanzu Kubernetes 叢集時,請勿使用用於主管叢集的相同 CIDR 範圍。

VMware Tanzu Kubernetes Grid Service for vSphere
  • 在主管叢集升級後,Tanzu Kubernetes 叢集在狀態為 [正在更新] 時當機

    在主管叢集升級時,它可以觸發所有 Tanzu Kubernetes 叢集的輪流更新,以散佈任何新的組態設定。在此程序期間,先前的「執行中」TKC 叢集可能會在「正在更新」階段當機。「執行中」Tanzu Kubernetes 叢集僅表示控制平面可用,但所需的控制平面和 worker 節點可能尚未成功建立。此類 Tanzu Kubernetes 叢集可能無法通過主管叢集升級完成後啟動的輪流更新期間所執行的健全狀況檢查。這會導致 Tanzu Kubernetes 叢集在「正在更新」階段當機,並且可透過查看與 Tanzu Kubernetes 叢集相關聯的 KubeadmControlPlane 資源上的事件來進行確認。資源所發出的事件將類似於以下內容:

    警告 ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller 正在等待控制平面通過控制平面健全狀況檢查以繼續進行重新調整: 機器的 (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) 節點 (tkg-cluster-3-control-plane-4bz9r) 未經檢查

    因應措施:無。

  • Tanzu Kubernetes 叢集繼續存取已移除的儲存區原則

    當 VI 管理員從 vCenter Server 命名空間刪除儲存區類別時,不會針對已使用該儲存區類別的任何 Tanzu Kubernetes 叢集移除對儲存區類別的存取權。

    因應措施:

    1. 作為 VI 管理員,從 vCenter Server 命名空間刪除儲存區類別後,請建立一個具有相同名稱的新儲存區原則。

    2. 將現有儲存區原則或剛剛重新建立的儲存區原則重新新增至主管命名空間。使用此儲存區類別的 TanzuKubernetesCluster 執行個體現在應可以完全正常運作。

    3. 對於每個使用您想要刪除的儲存區類別的 TanzuKubernetesCluster 資源,請使用不同的儲存區類別建立新的 TanzuKubernetesCluster 執行個體,並使用 Velero 將工作負載移轉至新叢集。

    4. 一旦沒有 TanzuKubernetesCluster 或 PersistentVolume 使用此儲存區類別,就可以放心地將其移除。

  • 內嵌式容器登錄 SSL 憑證未複製到 Tanzu Kubernetes 叢集節點

    當內嵌式容器登錄已針對主管叢集啟用時,Harbor SSL 憑證不會包含在於該 SC 上建立的任何 Tanzu Kubernetes 叢集節點中,且您也無法從這些節點連線到登錄。

    因應措施:從主管叢集控制平面複製 SSL 憑證,並將其貼上至 Tanzu Kubernetes 叢集工作節點。

  • 從 Tanzu Kubernetes Grid 1.16.8 升級至 1.17.4 後,其中一個控制平面節點上的「guest-cluster-auth-svc」網繭會停滯在「正在建立容器」狀態。

    將 Tanzu Kubernetes 叢集從 Tanzu Kubernetes Grid Service 1.16.8 更新至 1.17.4 後,其中一個叢集控制平面節點上的「guest-cluster-auth-svc」網繭會停滯在「正在建立容器」狀態。

    因應措施

    1.依照標題為「以系統使用者身分建立對 Tanzu Kubernetes 叢集節點的 SSH 連線」的說明文件主題中的指示,建立對其中一個 Tanzu Kuberenets 叢集控制平面節點的 SSH 連線。

    2.當您以「vmware-system-user」使用者身分登入後,執行命令「sudo su -」以切換為根使用者。

    3.執行下列命令:「KUBECONFIG=/etc/kubernetes/admin.conf /usr/lib/vmware-wcpgc-manifests/generate_key_and_csr.sh」

    4.幾分鐘後,所有 authsvc 網繭都應處於執行中狀態。

  • 在執行叢集更新期間或之後,使用者無法管理 Tanzu Kubernetes 叢集中的現有網繭。

    在執行叢集更新期間或之後,使用者無法管理 Tanzu Kubernetes 叢集中的現有網繭。

    因應措施

    1.依照標題為「以系統使用者身分建立對 Tanzu Kubernetes 叢集節點的 SSH 連線」的說明文件主題中的指示,建立對其中一個 Tanzu Kuberenets 叢集控制平面節點的 SSH 連線。

    2.當您以「vmware-system-user」使用者身分登入後,執行命令「sudo su -」以切換為根使用者。

    3.執行下列命令:「KUBECONFIG=/etc/kubernetes/admin.conf /usr/lib/vmware-wcpgc-manifests/generate_key_and_csr.sh」

    4.幾分鐘後,所有 authsvc 網繭都應處於執行中狀態。

  • 虛擬機器映像無法從內容程式庫取得

    在內嵌式連結模式設定中設定多個 vCenter Server 執行個體時,使用者介面會允許使用者選取在不同 vCenter Server 執行個體上建立的內容程式庫。選取此類程式庫會導致 DevOps 使用者無法使用虛擬機器映像來佈建 Tanzu Kubernetes 叢集。在此情況下,「kubectl get virtualmachineimages」不會傳回任何結果。

    因應措施:當您將內容程式庫與主管叢集建立關聯以取得 Tanzu Kubernetes 叢集虛擬機器映像時,請選擇在主管叢集所在的同一個 vCenter Server 執行個體中建立的程式庫。或者,建立一個本機內容程式庫,該程式庫還支援 Tanzu Kubernetes 叢集的氣隙佈建。

  • Tanzu Kubernetes 叢集升級工作失敗,並顯示「等待 etcd 健全狀況檢查通過時發生逾時。」

    與 Tanzu Kubernetes 叢集升級相關聯的 vmware-system-tkg 命名空間中的升級工作失敗,並顯示下列錯誤訊息「等待 etcd 健全狀況檢查通過時逾時。」此問題是由於遺失 etcd 網繭的 PodIP 位址所致。

    因應措施

    在受影響的節點上重新啟動 kubelet,導致 etcd 網繭重新啟動並收到 PodIP。然後,執行下列復原步驟,以從失敗的升級復原。在嘗試這些步驟之前,請聯絡 VMware 支援以獲得相關指引。

    1) 對於已成功升級的任何機器,但未移除原始機器。

    • 從 etcd 的成員清單中移除原始機器的節點參考
    • 刪除原始機器 (保留新升級的機器) 

    2) 對於狀況不良的任何機器:

    • 擷取 TanzuKubernetesCluster 的資源版本 (.metadata.resourceVersion)。
    • 使用註解擷取機器清單:「upgrade.cluster-api.vmware.com/id」。這些是先前升級嘗試中已升級的節點。
    • 更新註解以符合資源版本 (如果沒有差異,則不需要)。
    • 刪除屬於叢集的升級工作。
    • 確認升級繼續。
  • 目前 TKC 版本不支援 Antrea CNI

    佈建 Tanzu Kubernetes 叢集時,您會收到錯誤「目前 TKC 版本不支援 Antrea CNI」。

    選項 1 (建議):更新 Tanzu Kubernetes 叢集以使用支援 Antrea (v1.17.8 或更新版本) 的 OVA 版本。

    選項 2:在 Tanzu Kubernetes 叢集規格 YAML 中,在 spec.settings.network.cni 區段中輸入「calico」。

    選項 3:將預設 CNI 變更為 Calico。請參閱說明文件中關於如何執行此動作的主題。

  • 您無法佈建新的 Tanzu Kubernetes 叢集或擴充現有叢集,因為內容程式庫訂閱者無法與發佈者同步。

    當您為 Tanzu Kubernetes 叢集 OVA 設定已訂閱內容程式庫時,會產生 SSL 憑證,並且系統會提示您透過確認憑證指紋來手動信任憑證。如果在初始程式庫設定之後變更了 SSL 憑證,則必須透過更新指紋來再次信任新憑證。

    編輯已訂閱內容程式庫的設定。即使程式庫並未要求變更,這也會起始對訂閱 URL 的探查。探查將會探索到 SSL 憑證不受信任,並提示您信任該憑證。

  • Tanzu Kubernetes 版本 1.16.8 與 vSphere 7 U1 不相容。

    Tanzu Kubernetes 版本 1.16.8 與 vSphere 7 U1 不相容。在對 U1 執行 vSphere 命名空間更新之前,您必須將 Tanzu Kubernetes 叢集更新為更新版本。

    對 vSphere 7 U1 版本執行 vSphere 命名空間更新之前,請將執行版本 1.16.8 的每個 Tanzu Kubernetes 叢集更新為更新版本。如需詳細資訊,請參閱《vSphere with Tanzu》說明文件中的〈支援的更新路徑〉主題。

  • 將工作負載控制平面升級至 vSphere 7 U1 後,新虛擬機器類別大小無法使用。

    說明:升級至 vSphere 7.0.1 並針對 Tanzu Kubernetes 叢集執行主管叢集的 vSphere 命名空間更新時,執行「kubectl get virtualmachineclasses」命令不會列出新虛擬機器類別大小 2 倍大、4 倍大、8 倍大。

    因應措施:無。新虛擬機器類別大小只能用於新安裝的工作負載控制平面。

  • Tanzu Kubernetes 版本 1.17.11 vmware.1-tkg.1 使用 Calico CNI 連線至叢集 DNS 伺服器逾時。

    Tanzu Kubernetes 版本 v1.17.11+vmware.1-tkg.1 存在 Photon OS 核心問題,此問題會阻止映像按預期使用 Calico CNI。

    因應措施:對於 Tanzu Kubernetes 版本 1.17.11,識別為「v1.17.11+vmware.1-tkg.2.ad3d374.516」的映像會修正 Calico 的問題。若要執行 Kubernetes 1.17.11,請使用此版本,而非「v1.17.11+vmware.1-tkg.1.15f1e18.489」。或者,請使用其他 Tanzu Kubernetes 版本,例如版本 1.18.5、1.17.8 或 1.16.14。

儲存區
  • 如果外部 csi.vsphere.vmware.com 佈建程式失去其領導選舉租用,則嘗試從主管命名空間或 TKG 叢集建立 PVC 會失敗

    嘗試使用 kubectl 命令從主管命名空間或 TKG 叢集建立 PVC 可能會失敗。PVC 保持 [擱置] 狀態。如果要說明 PVC,則 [事件] 欄位會顯示下列內容:

    
    類型       原因                  存留期                    來自                            訊息
    ----       ------                  ---                    ----                            -------
    一般     ExternalProvisioning    56s (x121 over 30m)    persistentvolume-controller     正在等待外部佈建程式「csi.vsphere.vmware.com」建立磁碟區或等待系統管理員手動建立
    

    因應措施:

    1. 確認 vmware-system-csi 命名空間內 vsphere-csi-controller 網繭中的所有容器均在執行中。
      kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi
    2. 使用下列命令檢查外部佈建程式記錄。
      kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c csi-provisioner
      以下條目表示外部佈建程式 sidecar 容器失去其領導選舉:
      I0817 14:02:59.582663       1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceeded
      F0817 14:02:59.685847       1 leader_election.go:169] stopped leading
      
    3. 刪除此 vsphere-csi-controller 執行個體。
      kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi

    Kubernetes 將建立新的 CSI 控制器執行個體,所有 sidecar 都將重新初始化。

check-circle-line exclamation-circle-line close-line
Scroll to top icon