VMware vSphere IaaS 控制平面 8.0 版本說明

版本說明的內容

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

新增功能
此版本的安裝和升級
已知問題

新增功能

2024 年 6 月 25 日的新增功能
2024 年 3 月 26 日的新增功能
2024 年 2 月 29 日的新增功能
2023 年 9 月 21 日的新增內容
2023 年 7 月 27 日的最新內容
2023 年 4 月 18 日的最新內容
2023 年 3 月 30 日的最新內容
2023 年 2 月 14 日的最新內容
2022 年 12 月 15 日的最新內容
2022 年 10 月 11 日的最新內容

2024 年 6 月 25 日的新增功能

VMware vSphere 8.0 Update 3 \| 2024 年 6 月 25 日 vCenter Server 8.0 Update 3 \| 2024 年 6 月 25 日 \| ISO 組建編號 24022515 VMware ESXi 8.0 Update 3 \| 2024 年 6 月 25 日 \| ISO 組建編號 24022510 VMware NSX Advanced Load Balancer avi-22.1.5 \| 2023 年 10 月 11 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 3.0 \| 2024 年 6 月 25 日

VMware vSphere 8.0 Update 3 | 2024 年 6 月 25 日

vCenter Server 8.0 Update 3 | 2024 年 6 月 25 日 | ISO 組建編號 24022515

VMware ESXi 8.0 Update 3 | 2024 年 6 月 25 日 | ISO 組建編號 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 3.0 | 2024 年 6 月 25 日

vSphere IaaS 控制平面 8.0 Update 3 引入了下列新功能和增強功能：

自動主管和 TKG 憑證輪替 - 此版本引入新的憑證輪替機制。主管和 TKG 叢集憑證會在到期之前自動輪替。如果自動輪替失敗，您會在 vCenter 中收到通知，屆時必須手動更新憑證。
在 vSAN 延伸叢集上支援主管、vSphere 網繭和 TKG 叢集 - 從此版本開始，可以將主管設定為在 vSAN 延伸叢集上執行。僅綠地環境支援此組態。這意味著，應延伸您的 vSAN 叢集，且工作負載管理和內容程式庫尚未設定。這兩個元件需要設定 vSAN 延伸叢集儲存區原則。如需詳細資訊，請參閱說明文件。
虛擬機器服務虛擬機器的虛擬機器類別現在限定於命名空間範圍 - 在此版本中，如果使用 kubectl 列出虛擬機器類別，只能檢視範圍限定為特定 vSphere 命名空間的虛擬機器類別。先前，虛擬機器類別是叢集範圍內的資源，因此很難確定哪些虛擬機器類別已指派且可用於特定命名空間。
主管備份和還原 - vSphere 現在支援備份和還原主管。現在，您可以將主管的備份設定為 vCenter 備份的一部分，並在發生災難復原、升級失敗、中斷和其他復原情況時從備份還原主管。請參閱〈備份和還原主管控制平面〉。
虛擬機器服務虛擬機器備份與還原 - vSphere 現在支援備份和還原虛擬機器服務虛擬機器。現在，您可以使用任何以 VADP 為基礎的備份廠商來保護虛擬機器服務虛擬機器。如果發生中斷或其他涉及資料遺失的情況，可以從備份還原 vSphere 命名空間中的虛擬機器。
虛擬機器 Operator API v1alpha2 現已推出 - 虛擬機器 Operator API 的下一個版本為此處的虛擬機器 Operator v1alpha2 版本。此版本增強了啟動程序提供者支援，包括內嵌 Cloud-Init 和 Windows 支援、增強的客體網路組態、擴增的狀態功能、支援使用者定義的就緒門、新的 VirtualMachineWebConsoleRequest API、改進的 API 說明文件以及其他功能。
利用 Fluent Bit 在主管上進行記錄轉送 - 現在，支援將主管控制平面記錄和系統記錄轉送至外部記錄監控平台。如需詳細資訊，請參閱說明文件。
對主管服務的私人登錄支援 - 現在，可以定義私人登錄詳細資料，以允許部署為主管服務的工作負載從私人登錄提取映像和套件。這是支援氣隙環境的常見需求。如需詳細資訊，請參閱說明文件。
主管升級工作流程改進 - 現在，可以在起始主管 Kubernetes 版本升級時起始主管升級預先檢查。僅當所有預先檢查成功時，才會執行實際更新。此版本引入了從先前的元件升級失敗點繼續執行元件升級程序的功能。如需詳細資訊，請參閱〈更新主管〉。
主管支援 Kubernetes 1.28 - 此版本新增了對 Kubernetes 1.28 的主管支援，且不再支援 Kubernetes 1.25。

主管支援的 Kubernetes 版本：

此版本中支援的 Kubernetes 版本為 1.28、1.27 和 1.26。在 Kubernetes 版本 1.25 上執行的主管將自動升級至版本 1.26，以確保所有主管都在支援的 Kubernetes 版本上執行。

Tanzu Kubernetes Grid Service for vSphere

TKG 服務即主管服務 – 此版本將 TKG 服務元件與 vCenter 分離，並將其封裝為主管服務，可以獨立於 vCenter 和主管版本對其進行更新和管理。您可以在此處找到 TKG 服務的版本說明。
支援在 vSAN 延伸叢集上部署 TKG 服務叢集 – 此版本支援在 vSAN 延伸叢集拓撲上部署 TKG 服務叢集。如需有關如何在 vSAN 延伸叢集上為 TKG 服務叢集設定 HA 的詳細資訊，請參閱說明文件。
自動縮放 TKG 服務叢集 – 此版本支援在 TKG 服務叢集上安裝叢集 Autoscaler 套件，以便能夠自動擴充和縮小 worker 節點。
備份和還原 TKG 叢集 – 此版本支援備份和還原主管資料庫，其中包括 vSphere 命名空間物件和 TKG 叢集虛擬機器。請注意，TKG 叢集工作負載需要單獨備份和還原。
支援 Antrea-NSX 整合和 NSX 管理 Proxy 服務 – 此版本支援將使用 Antrea CNI 的 TKG 叢集與 NSX Manager 整合，以便查看和控制叢集網路。
可設定 MachineHealthCheck – 此版本支援為 v1beta1 叢集設定 MachineHealthCheck。
在叢集範圍內設定 PSA - 此版本支援在建立或更新叢集期間在叢集範圍內設定 PSA。
標準套件安裝更新 - 此版本包括有關在 TKG 服務叢集上安裝標準套件的說明文件更新。
更新用於佈建 TKG 叢集的 v1beta1 API – 此版本包括下列 v1beta1 API 變更：
- 新增了 podSecurityStandard，可實現叢集範圍的 PSA 實作
- 更新了 controlPlaneCertificateRotation
對 TKG 叢集支援擴充控制平面節點磁碟區。

國際化更新

從下一個主要版本開始，我們將減少支援的當地語系化語言數量。支援的三種語言將為：

日文
西班牙文
法文

將不再支援下列語言：

義大利文、德文、巴西葡萄牙文、繁體中文、韓文、簡體中文

影響：

一直使用已過時語言的使用者將不再收到這些語言的更新或支援。
所有使用者介面、說明文件和客戶支援將僅提供英文版本或上述三種支援的語言版本。

2024 年 3 月 26 日的新增功能

VMware vSphere 8.0 Update 2c \| 2024 年 3 月 26 日 ESXi 8.0 Update 2b \| 2024 年 2 月 29 日 \| ISO 組建編號 23305546 vCenter Server 8.0 Update 2c \| 2024 年 3 月 26 日 \| ISO 組建編號 23504390 VMware NSX Advanced Load Balancer avi-22.1.5 \| 2023 年 10 月 11 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0 Update 2c | 2024 年 3 月 26 日

ESXi 8.0 Update 2b | 2024 年 2 月 29 日 | ISO 組建編號 23305546

vCenter Server 8.0 Update 2c | 2024 年 3 月 26 日 | ISO 組建編號 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 控制平面 8.0 Update 2c 引入了下列新功能和增強功能：

新功能

支援 TKR 1.27 - 此版本新增了在 vSphere 8.x 上支援 TKR 1.27 所需的變更 (在未來發行時)。如需詳細資訊，請參閱 VMware Tanzu Kubernetes 發行版本說明。
支援從 vCenter 7.x 升級至 vCenter 8.x - 對於在 vSphere 7.x 上執行 TKR 1.27.6 的使用者，此版本提供升級到 vCenter 8.x 的路徑。先前，針對 vSphere 7.x 發行的 TKR 1.27.6 與 vCenter 8.x 不相容。請參閱知識庫文章 96501。

已解決的問題

升級至 vCenter 8.0 Update 2b 後，vmon 管理的服務 wcp 可能處於 STOPPED 狀態，且 vCenter 修補可能會失敗。
取消連結程式庫或刪除具有共用程式庫的命名空間會從內容程式庫中刪除相關聯的項目。

2024 年 2 月 29 日的新增功能

VMware vSphere 8.0 Update 2b \| 2024 年 2 月 29 日 ESXi 8.0 Update 2b \| 2024 年 2 月 29 日 \| ISO 組建編號 23305546 vCenter Server 8.0 Update 2b \| 2024 年 2 月 29 日 \| ISO 組建編號 23319993 VMware NSX Advanced Load Balancer avi-22.1.5 \| 2023 年 10 月 11 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0 Update 2b | 2024 年 2 月 29 日

ESXi 8.0 Update 2b | 2024 年 2 月 29 日 | ISO 組建編號 23305546

vCenter Server 8.0 Update 2b | 2024 年 2 月 29 日 | ISO 組建編號 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023 年 10 月 11 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 控制平面 8.0 Update 2b 引入了下列新功能和增強功能：

新功能

支援透過 vSphere Client 設定虛擬機器服務虛擬機器類別 - 主管上的虛擬機器服務支援使用 vSphere 虛擬機器目前所支援的任何組態部署虛擬機器。若要為虛擬機器類別設定 CPU、記憶體、硬體、安全性裝置和傳遞裝置，您現在可以在 vSphere Client 中使用虛擬機器類別精靈。使用 vSphere Client，可以簡化定義和管理用於執行 AI/ML 工作負載的虛擬機器服務虛擬機器的程序。
主管支援 Avi 雲端設定 - 如果您使用的是 NSX Advanced Load Balancer (也稱為 Avi 負載平衡器)，現在可以為每個主管設定 Avi 雲端。這允許多個 vCenter Server 執行個體和資料中心使用單一 Avi 執行個體，而無需為部署主管的每個 vCenter Server 或資料中心設定 Avi 執行個體。
FQDN 登入支援 - 對於主管和 TKG 叢集，現在可以將產生的 kubeconfigs 中的 IP 取代為有效的 FQDN。必須在 DNS 中新增 FQDN 和 IP 位址，以確保正確解析主機名稱。
主管支援 Kubernetes 1.27 - 主管現在支援 Kubernetes 1.27，且不再支援 Kubernetes 1.24。

支援的 Kubernetes 版本

此版本中支援的 Kubernetes 版本為 1.27、1.26 和 1.25。在 Kubernetes 1.24 上執行的主管將自動升級至版本 1.25 以確保相容性。

升級至 8.0 Update 2b

從低於 8.0 Update 2 的任何 vSphere 8.x 版本升級到 8.0 Update 2b 版本，將對所有已佈建的 TKGS 叢集起始輪流更新以傳播下列變更：

8.0 Update 2 包含作為叢集類別一部分的 TKGS 控制器中 vSphere 7 和 vSphere 8 TKR 的變更。
由於 1.23 及更高版本中的 TKGS 叢集與 8.0 Update 2b 相容，因此，所有 TKGS 叢集都將進行輪流升級。

已解決的問題

主管升級程序停滯在 20%。

2023 年 9 月 21 日的新增內容

VMware vSphere 8.0.2 \| 2023 年 9 月 21 日 ESXi 8.0.2 \| 2023 年 9 月 21 日 \| 組建編號 22380479 vCenter Server 8.0.2 \| 2023 年 9 月 21 日 \| 組建編號 22385739 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 社群版本 2.2.2，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0.2 | 2023 年 9 月 21 日

ESXi 8.0.2 | 2023 年 9 月 21 日 | 組建編號 22380479

vCenter Server 8.0.2 | 2023 年 9 月 21 日 | 組建編號 22385739

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 社群版本 2.2.2，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

vSphere IaaS 控制平面 8.0 Update 2 引入了下列新功能和增強功能：

主管

虛擬機器服務現在支援具有 Windows 作業系統、GPU 以及可用於傳統 vSphere 虛擬機器的所有其他選項的虛擬機器 - 虛擬機器服務現在支援使用 vSphere 虛擬機器目前支援的任何組態來部署虛擬機器，從而實現與 vSphere 上的傳統虛擬機器完全相同，但支援作為基礎結構即服務的一部分部署到主管上的虛擬機器。這包括支援佈建 Windows 虛擬機器與 Linux 虛擬機器，以及 vSphere 上支援的任何硬體、安全性、裝置、自訂或多重 NIC 支援和傳遞裝置。現在，可以透過使用 GPU 佈建工作負載虛擬機器以支援 AI/ML 工作負載。
虛擬機器映像服務 - DevOps 團隊、開發人員和其他虛擬機器取用者可以使用虛擬機器映像服務以自助服務方式發佈和管理虛擬機器映像。服務允許取用者使用 K8s API 在主管命名空間範圍的映像登錄內發佈、修改和刪除映像。將在每個 CCS 區域和 CCS 專案中自動建立虛擬機器映像服務，映像登錄的映像填入範圍會依角色和耗用層級 (全域層級或專案層級) 限定範圍。映像可用於透過虛擬機器服務部署虛擬機器。

請注意，此功能為虛擬機器映像名稱引入了新格式。如需如何解決名稱變更所造成的潛在問題的相關資訊，請參閱〈vSphere 8.0 U2 的虛擬機器映像名稱格式變更〉。
匯入和匯出主管組態 - 在舊版中，啟用主管是一個無法儲存任何組態的手動逐步程序。在目前版本中，現在可以以人工可讀的格式或在原始檔控制系統內匯出主管組態並與同事共用，將組態匯入新主管，以及跨多個主管複寫標準組態。如需有關如何匯出和匯入主管組態的詳細資料，請查看說明文件。
透過減少分段提高了 GPU 使用率 - 工作負載放置現在可感知 GPU，DRS 會嘗試將具有類似設定檔需求的工作負載放置在同一主機上。這可提高資源使用率，進而降低成本，因為必須取得較少的 GPU 硬體資源才能達到所需的效能層級。
主管支援 Kubernetes 1.26 - 此版本新增支援 Kubernetes 1.26，並取消支援 Kubernetes 1.23。此版本中支援的 Kubernetes 版本為 1.26、1.25 和 1.24。在 Kubernetes 1.23 版上執行的主管將自動升級至 1.24 版，以確保所有主管都在支援的 Kubernetes 版本上執行。
設定了 NSX 網路的主管支援 NSX Advanced Load Balancer - 現在，您可以使用 NSX Advanced Load Balancer (Avi Networks) 進行 L4 負載平衡，以及對使用 NSX 網路的主管叢集和 Tanzu Kubernetes Grid 叢集的控制平面節點進行負載平衡，從而啟用主管。如需有關使用 NSX 設定 NSX Advanced Load Balancer 的指引，請查看說明文件頁面。
Telegraf 支援度量和事件串流 - 您現在可以透過 Kubernetes API 設定 Telegraf 以將主管度量推送至與內嵌式 Telegraf 版本相容的任何度量服務。如需設定 Telegraf，請參閱說明文件。

主管上的 Tanzu Kubernetes Grid

vSphere 8.0 上 TKR 的 STIG 合規性 - 使用 vSphere U2 時，1.23.x 以上的所有 Tanzu Kubernetes Grid 叢集均符合 STIG (安全性技術實作指南) 標準，並且包含可從此處找到的有關例外狀況的說明文件。這些改進是朝著簡化合規流程邁出的重要一步，可讓您更輕鬆地滿足合規性需求，從而在美國聯邦市場和其他受監管產業快速自信地使用 Tanzu Kubernetes Grid。
開啟控制平面推出以取得即將到期的憑證 – 更新了用於布建以 ClusterClass 為基礎的 TKG 叢集的 v1beta1 API，使叢集能夠在其控制平面節點虛擬機器憑證到期之前自動更新。此組態可作為變數新增至叢集規格。如需詳細資訊，請參閱

叢集 v1beta1 API 說明文件。
TKR 的 CSI 快照支援- 使用 Tanzu Kubernetes 1.26.5 版及更高版本布建的 TKG 叢集支援 CSI 磁碟區快照，有助於您實現資料保護需求。磁碟區快照提供在特定時間點複製磁碟區內容的標準化方式，而無需建立全新的磁碟區。
安裝和管理 Tanzu 套件 – 用於在 TKG 叢集上安裝和管理 Tanzu 套件的新整合存放庫和出版物。請參閱出版物「安裝和使用 VMware Tanzu 套件」，以瞭解您的所有套件需求。
自訂 ClusterClass 改進 – 針對 vSphere 8 U2 簡化實作自訂 ClusterClass 叢集的工作流程。
TKG 叢集的輪流更新 – 升級至 vSphere 8 U2 時，在下列情況下，您可以預期已布建 TKG 叢集的輪流更新：
- 從先前發行的任何 vSphere 8 版本升級至 vSphere 8 U2 時，因為：
  - vSphere 8 U2 包含作為叢集類別一部分的 TKR 的 Kubernetes 層級 STIG 變更
  - 1.23 及更高版本的 TKG 叢集將進行輪流更新，以便與 v8.0 U2 相容
- 從任何 vSphere 7 版本升級至 vSphere 8 U2 時，因為：
  - 基礎 CAPI 提供者需要從 CAPW 移至 CAPV
  - 現有叢集需要從無類別 CAPI 叢集移轉至以類別為基礎的 CAPI 叢集

已解決的問題

主管控制平面虛擬機器上 /var/log/audit/ 下的稽核記錄檔可能會增長到非常大並填滿根磁碟。您應該會在反映此狀態的 journald 記錄中看到「no space left on device」錯誤。這可能會導致主管控制平面功能的各個方面 (例如 kubernetes API) 失敗。

2023 年 7 月 27 日的最新內容

VMware vSphere 8.0.1c \| 2023 年 7 月 27 日 ESXi 8.0.1c \| 2023 年 7 月 27 日 \| 組建編號 22088125 vCenter Server 8.0.1c \| 2023 年 7 月 27 日 \| 組建編號 22088981 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 社群版本 2.2.2，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.2.0 \| 2023 年 5 月 18 日

VMware vSphere 8.0.1c | 2023 年 7 月 27 日

ESXi 8.0.1c | 2023 年 7 月 27 日 | 組建編號 22088125

vCenter Server 8.0.1c | 2023 年 7 月 27 日 | 組建編號 22088981

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 社群版本 2.2.2，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023 年 5 月 18 日

新功能

主管支援 Kubernetes 1.25 - 此版本新增了對 Kubernetes 1.25 的支援，且不再支援 Kubernetes 1.22。
主管上的 Tanzu Kubernetes Grid 2.2.0 - 管理主管上的 Tanzu Kubernetes Grid 2.2.0 叢集。

支援的 Kubernetes 版本

此版本中支援的 Kubernetes 版本為 1.25、1.24 和 1.23。在 Kubernetes 1.22 版上執行的主管將自動升級至 1.23 版，以確保所有主管都在支援的 Kubernetes 版本上執行。

支援

棄用 vRegistry 建立功能 - 建立內嵌式 Harbor 執行個體 vRegistry 的功能已棄用。現有 vRegistry 執行個體將繼續運作，但建立新 vRegistry 執行個體的功能已棄用。vRegistry 建立 API 已標記為已棄用，並且即將推出的版本中將移除部署新 vRegistry 執行個體的功能。因而，我們建議改用 Harbor 作為主管服務來管理容器映像和存放庫，以增強效能和功能。若要將現有 vRegistry 移轉至 Harbor 作為主管服務，請參閱「將映像從內嵌式登錄移轉至 Harbor」以取得移轉詳細資料。

已解決的問題

vSphere Client 中將顯示新的警示訊息，以警告主管或 TKG 叢集上的憑證即將到期。警示將提供詳細資訊，包括主管的名稱和憑證到期日期。此外，還將包含知識庫 90627 連結，逐步說明如何取代受影響的憑證。
kubectl get clustervirtualmachineimages 命令傳回錯誤或 No resources found。在舊版中，使用 kubectl get clustervirtualmachineimages 命令時，會發生錯誤。但是，升級至 8.0 Update 1c 後，命令現在會傳回以下訊息：No resources found。若要擷取虛擬機器映像的相關資訊，請改用以下命令： kubectl get virtualmachineimages
antrea-nsx-routed CNI 不適用於 vSphere IaaS 控制平面 8.x 版本上的 v1alpha3 Tanzu Kubernetes 叢集。
v1beta1 叢集的節點清空逾時未正確傳播。

2023 年 4 月 18 日的最新內容

VMware vSphere 8.0.1 \| 2023 年 4 月 18 日 ESXi 8.0.1 \| 2023 年 4 月 18 日 \| 組建編號 21495797 vCenter Server 8.0.1 \| 2023 年 4 月 18 日 \| 組建編號 21560480 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 社群版本 2.2.2，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

VMware vSphere 8.0.1 | 2023 年 4 月 18 日

ESXi 8.0.1 | 2023 年 4 月 18 日 | 組建編號 21495797

vCenter Server 8.0.1 | 2023 年 4 月 18 日 | 組建編號 21560480

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 社群版本 2.2.2，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新功能

主管

主管服務現已在以 VDS 為基礎的主管上可用 - 先前，主管服務僅在以 NSX 為基礎的主管上可用。在目前版本中，可在以 VDS 為基礎的主管上部署 Harbor、Contour、S3 物件儲存區和 Velero 主管服務。附註：以 VDS 為基礎的主管上的主管服務功能需要 ESXi 更新至 8.0 U1。
所有 Linux 映像的虛擬機器服務支援 - 現在，可使用 CloudInit 以符合虛擬機器服務映像規格的 OVF 格式自訂任何 Linux 映像，以及透過 vAppConfig 利用 OVF 範本來啟用舊版 Linux 映像的部署。
虛擬機器服務虛擬機器的 Web 主控台支援 - 部署虛擬機器服務虛擬機器後，身為 DevOps 工程師，您現在能夠使用 kubectl CLI 為該虛擬機器啟動 Web 主控台工作階段，以便在客體作業系統內啟用疑難排解和偵錯，而無需 vSphere 管理員取得對客體虛擬機器的存取權。
主管合規性 - 適用於 vSphere IaaS 控制平面 8 主管版本的安全性技術實作指南 (STIG)。如需詳細資訊，請參閱〈Tanzu STIG 強化〉。

主管上的 Tanzu Kubernetes Grid 2.0

自訂叢集類別- 針對主管上的 TKG 叢集引入自己的叢集類別。如需相關資訊，請參閱 https://kb.vmware.com/s/article/91826。
TKG 節點的自訂映像- 使用 vSphere TKG Image Builder (Ubuntu 和 Photon) 建置自己的自訂節點映像。

附註：若要將特定 TKR 與 v1alpha1 API 搭配使用，請使用 fullVersion。
新增 TKR 映像：如需詳細資料，請參閱 Tanzu Kubernetes 發行版本說明。

vSpere IaaS 控制平面 8.0.0 GA 客戶的關鍵需求

附註：此需求不適用於透過虛擬機器服務佈建虛擬機器所用的內容程式庫，它僅適用於 TKR 內容程式庫。

如果您已部署 vSphere IaaS 控制平面 8.0.0 GA，則在升級至 vSphere IaaS 控制平面 8 U1 之前，必須建立暫存 TKR 內容程式庫，以避免將 TKG 2.0 TKR 推送至現有內容程式庫時造成 TKG 控制器網繭進入 CrashLoopBackoff 的已知問題。若要避免此問題，請完成下列步驟。

建立新的訂閱內容程式庫並將暫存訂閱 URL 指向 https://wp-content.vmware.com/v2/8.0.0/lib.json。
同步暫存內容程式庫中的所有項目。
將暫存內容程式庫與已部署 TKG 2 叢集的每個 vSphere 命名空間建立關聯。
執行 kubectl get tkr 命令，並確認已建立所有 TKR。
此時，TKG 控制器應處於執行中狀態，您可以透過列出主管命名空間中的網繭進行驗證。
如果 TKG 控制器處於 CrashLoopBackOff (CLBO) 狀態，則使用下列命令重新啟動 TKG 控制器部署：

kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager
升級至 vSphere IaaS 控制平面 8 Update 1。
更新每個 vSphere 命名空間，以使用原始的已訂閱內容程式庫 (網址為 https://wp-content.vmware.com/v2/latest/lib.json)。

已解決的問題

使用 v1beta1 API 佈建的 Tanzu Kubernetes Grid 2.0 叢集必須以預設 ClusterClass 為基礎

如果您使用 v1beta1 API 在主管上建立 Tanzu Kubernetes Grid 2.0 叢集，則叢集必須以預設 tanzukubernetescluster ClusterClass 為基礎。系統不會根據不同的 ClusterClass 來協調叢集。

2023 年 3 月 30 日的最新內容

ESXi 8.0.0c \| 2023 年 3 月 30 日 \| 組建編號 21493926 vCenter Server 8.0.0c \| 2023 年 3月 30 日 \| 組建編號 21457384 VMware NSX Advanced Load Balancer avi-22.1.3 \| 2023 年 1 月 31 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0.0c | 2023 年 3 月 30 日 | 組建編號 21493926

vCenter Server 8.0.0c | 2023 年 3月 30 日 | 組建編號 21457384

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

已解決的問題：

Harbor 預設組態不安全問題

此版本解決了在主管 7.0 或 8.0 上已啟用內嵌式 Harbor 登錄時存在的 Harbor 預設組態不安全問題。

已在此 vCenter 版本 8.0.0c 中解決。如需瞭解此問題的詳細資料以及如何透過安裝此版本或套用暫行因應措施來解決此問題，請參閱 VMware 知識庫文章 91452。
升級至 vCenter Server 8.0b 後，嘗試登入主管叢集和 TKG 叢集失敗

vCenter Server 8.0b 中執行的元件與使用舊版 vCenter Server 部署的主管不回溯相容。

因應措施：將 vCenter Server 升級至較新版本或升級所有已部署的主管。

2023 年 2 月 14 日的最新內容

ESXi 8.0.0b \| 2023 年 2 月 14 日 \| 組建編號 21203435 vCenter Server 8.0.0b \| 2023 年 2 月 14 日 \| 組建編號 21216066 VMware NSX Advanced Load Balancer avi-22.1.1-9052 \| 2022 年 7 月 15 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0.0b | 2023 年 2 月 14 日 | 組建編號 21203435

vCenter Server 8.0.0b | 2023 年 2 月 14 日 | 組建編號 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022 年 7 月 15 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新功能：

新增 Cert-Manager CA 叢集簽發者支援 - 讓管理員能夠在主管上定義叢集範圍的 CA 簽發者並將其部署為主管服務。部署叢集範圍的 CA 簽發者可讓主管命名空間的取用者請求和管理 CA 簽發者簽署的憑證。

除了這項新功能之外，此版本還提供了錯誤修正。

已解決的問題：

主管控制平面虛擬機器根磁碟填滿

主管控制平面虛擬機器上 /var/log/audit/ 下的稽核記錄檔可能會增長到非常大並填滿根磁碟。您應該會在反映此狀態的 journald 記錄中看到「no space left on device」錯誤。這可能會導致主管控制平面功能的各個方面 (例如 kubernetes API) 失敗。

已在此 vSphere 8.0.0b 版本中解決

2022 年 12 月 15 日的最新內容

ESXi 8.0 \| 2022 年 10 月 11 日 \| 組建編號 20513097 vCenter Server 8.0.0a \| 2022 年 12 月 15 日 \| 組建編號 20920323 VMware NSX Advanced Load Balancer avi-22.1.1-9052 \| 2022 年 7 月 15 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

ESXi 8.0 | 2022 年 10 月 11 日 | 組建編號 20513097

vCenter Server 8.0.0a | 2022 年 12 月 15 日 | 組建編號 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022 年 7 月 15 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

新功能

新增 Harbor 作為主管服務 - 提供主管上執行之功能完整的 Harbor (OCI 映像登錄) 執行個體。Harbor 執行個體可讓 Harbor 管理員建立和管理專案及使用者，以及設定映像掃描。
取代 vRegistry - 在未來版本中將移除稱為 vRegistry 的內嵌式 Harbor 執行個體。在其位置，您可以使用 Harbor 作為主管服務。如需移轉詳細資料，請參閱將映像從內嵌式登錄移轉至 Harbor。
主管支援 Kubernetes 1.24 – 此版本新增了 Kubernetes 1.24 支援並捨棄 Kubernetes 1.21 支援。此版本中支援的 Kubernetes 版本為 1.24、1.23 和 1.22。在 Kubernetes 1.21 版上執行的主管叢集將自動升級至 1.22 版，以確保所有主管叢集都在支援的版本上執行。
vSphere 區域 API – vSphere 區域是一種建構，可讓您將可用性區域指派給 vSphere 叢集，以提供高度可用的主管和 Tanzu Kubernetes 叢集。在 vSphere 8.0 中，可以從 vSphere Client 建立和管理 vSphere 區域功能。透過 vSphere 8.0.0a 版本，使用者可以使用 DCLI 或 vSphere Client API Explorer 建立和管理 vSphere 區域。完整的 SDK 繫結支援 (例如 Java、Python 等) 將在未來版本中提供。

升級考量事項：

在下列主管升級案例中，將會滾動更新 Tanzu Kubernetes 叢集：
- 從 8.0 升級至 8.0.0a，然後將主管從任何 Kubernetes 版本升級至主管 Kubernetes 1.24 時，以及滿足其中一個條件時。
  - 如果您要將 Proxy 設定與 Tanzu Kubernetes 叢集上的非空 noProxy 清單搭配使用
  - 如果在主管上啟用 vRegistry。此設定僅適用於 NSX 型主管。
- 從任何 vSphere 7.0 版本升級至 vSphere 8.0.0a 時。

已解決的問題：

vSphere 8 支援 Tanzu 7 授權金鑰，而非 Tanzu 8 授權金鑰

vCenter 8.0 支援 Tanzu 7 授權金鑰，而非 Tanzu 8 授權金鑰。此問題不會影響您在 vCenter 8.0 上完全使用 Tanzu 功能的能力。在 vCenter 8.0 部署中修改 Tanzu 授權之前，如需更多詳細資料，請參閱 VMware 知識庫文章 89839。
當 NSX-ALB 上存在兩個 SE 群組時，不會建立負載平衡器和客體叢集。

如果將第二個 SE 群組新增至已經或未指派 SE 或虛擬服務的 NSX-ALB，則建立新的主管或客體叢集會失敗，並且無法升級現有的主管叢集。在 NSX-ALB 控制器上建立虛擬服務失敗，並顯示下列錯誤：
```
get() returned more than one ServiceEngineGroup – it returned 2
```
因此，新的負載平衡器無法使用，且您無法成功建立新的工作負載叢集。如需詳細資訊，請參閱 VMware 知識庫文章 90386。

2022 年 10 月 11 日的最新內容

VMware vSphere 8.0 \| 2022 年 10 月 11 日 ESXi 8.0 \| 2022 年 10 月 11 日 \| 組建編號 20513097 vCenter 8.0 \| 2022 年 10 月 11 日 \| 組建編號 20519528 VMware NSX Advanced Load Balancer 21.1.4 \| 2022 年 4 月 7 日 HAProxy 2.2.2 社群版本，數據平面 API 2.1.0 Tanzu Kubernetes Grid 2.0 \| 2022 年 10 月 11 日

VMware vSphere 8.0 | 2022 年 10 月 11 日

ESXi 8.0 | 2022 年 10 月 11 日 | 組建編號 20513097

vCenter 8.0 | 2022 年 10 月 11 日 | 組建編號 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 2022 年 4 月 7 日

HAProxy 2.2.2 社群版本，數據平面 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022 年 10 月 11 日

vSphere IaaS 控制平面 8.0 引入了下列新功能和增強功能：

工作負載管理組態監控 - 現在，您可以詳細追蹤主管的啟用、停用和升級狀態。起始主管啟用、停用或升級後，主管會嘗試透過滿足與主管的不同元件 (例如控制平面虛擬機器) 相關聯的各種條件來達到所需狀態。您可以追蹤每個條件的狀態、檢視相關聯的警告、重試狀態，檢視已滿足的條件及其時間戳記。
vSphere 區域 - vSphere 區域是一個新建構，用於將可用性區域指派給 vSphere 叢集。透過跨 vSphere 區域部署主管，可以在特定可用性區域和故障網域中佈建 Tanzu Kubernetes Grid 叢集。這可讓工作負載跨越多個叢集，從而提高硬體和軟體故障的復原能力。
多叢集主管 - 透過使用 vSphere 區域，您可以跨多個 vSphere 叢集部署主管，為 Tanzu Kubernetes Grid 叢集提供高可用性和故障網域。您可以將 vSphere 叢集新增至單獨的 vSphere 區域，並啟用跨越多個 vSphere 區域的主管。這樣可以為當地語系化硬體和軟體故障提供容錯移轉和復原能力。當區域或 vSphere 叢集離線時，主管偵測到故障，並在其他 vSphere 區域上重新啟動工作負載。只要不超過延遲上限，就可以在跨越距離的環境中使用 vSphere 區域。如需有關延遲需求的詳細資訊，請參閱〈分區主管部署的需求〉。
主管支援 Kubernetes 1.23 - 此版本新增了對 Kubernetes 1.23 的支援，且不再支援 Kubernetes 1.20。此版本中支援的 Kubernetes 版本為 1.23、1.22 和 1.21。在 Kubernetes 1.20 版上執行的主管將自動升級至 1.21 版，以確保所有主管都在支援的 Kubernetes 版本上執行。
透過 SecurityPolicy CRD 提供一次性的網路原則 - 透過 SecurityPolicy 自訂資源定義，能夠為主管命名空間中的虛擬機器和 vSphere 網繭設定網路安全性控制。
主管上的 Tanzu Kubernetes Grid 2.0 - Tanzu Kubernetes Grid 現已移至 2.0 版。Tanzu Kubernetes Grid 2.0 是 Tanzu 和 Kubernetes 社群巨大創新的結晶，並為使用 Tanzu Kubernetes Grid 的私有雲和公有雲的一組通用介面奠定了基礎。此版本中的新增內容包括下列兩個主要功能：
- ClusterClass - Tanzu Kubernetes Grid 2.0 現在支援 ClusterClass。ClusterClass 提供了與上游一致的介面，取代了 Tanzu Kubernetes 叢集，這會在我們的 Tanzu Kubernetes Grid 平台中引入自訂功能。透過 ClusterClass，管理員能夠定義符合其企業環境需求的範本，同時減少樣板並啟用委派自訂。
- Carvel - Carvel 提供一組可靠的單用途可組合工具，有助於應用程式建置、設定和部署至 Kubernetes。特別是，kapp 和 kapp-controller 透過一組與上游一致的宣告式工具來提供套件管理、相容性和生命週期。再加上用於範本的 ytt，這就形成了一種靈活但可管理的套件管理功能。
vSphere 8 中的新說明文件結構和登陸頁面 - vSphere IaaS 控制平面說明文件現已改善結構，可更好地反映產品工作流程，並讓您更側重於內容的體驗。您也可以從新的說明文件登陸頁面存取 vSphere IaaS 控制平面的所有可用技術說明文件。

此版本的安裝和升級

如需有關安裝和設定 vSphere IaaS 控制平面的指引，請閱讀《安裝和設定 vSphere IaaS 控制平面》說明文件。如需更新 vSphere IaaS 控制平面的相關資訊，請參閱〈更新 vSphere IaaS 控制平面〉說明文件。

執行升級時，請記住下列幾點：

更新至 vCenter Server 8.0 之前，請確保所有主管的 Kubernetes 版本至少為 1.21，最好是支援的最新版本。Tanzu Kubernetes Grid 叢集的 Tanzu Kubernetes 發行版本必須為 1.21，最好是支援的最新版本。
從 vSphere IaaS 控制平面 8.0 MP1 版本開始，允許從舊版 TKGS TKR 升級至 TKG 2 TKR。如需支援的版本對照表，請參閱 Tanzu Kuberentes 版本的版本說明。如需升級資訊，請參閱〈將主管上的 TKG 與 vSphere IaaS 控制平面搭配使用〉說明文件。

主管已知問題

在 vSphere 8.0 Update 3 中，vSphere 命名空間建立頁面中不再顯示網路覆寫選項

在 8.0 Update 3 版本之前，vSphere 管理員可以提供自訂網路組態，而不是建立 vSphere 命名空間時使用的預設網路組態。在 8.0 Update 3 版本中，用於覆寫網路組態的 UI 選項不可用。

因應措施：您可以使用 DCLI 建立具有自訂網路組態的 vSphere 命名空間。
有時，ESXi 主機可能無法加入主管叢集，因為無法載入 vds-vsip 模組

如果 ESXi 主機無法加入主管叢集，則 ESXi 主機記錄檔中可能會出現下列錯誤 /var/run/log/spherelet.log:

cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

在主管叢集升級、憑證升級或重新啟動 spherelet 的任何其他主管組態變更期間，可能會發生此問題。

因應措施：將無法載入 vds-vsip 模組的 ESXi 主機重新開機。
如果主管使用微型控制平面虛擬機器，則嘗試將 vSphere IaaS 控制平面環境從 7.0 Update 3o 升級至 8.0 Update 3 會失敗並顯示錯誤

將 vCenter 從 7.0 Update 3o 升級至 8.0 Update 3 後，已設定微型控制平面虛擬機器的主管無法從 Kubernetes v1.26.8 升級至 v1.27.5。

可能會出現下列錯誤： Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

因應措施：升級之前，將控制平面虛擬機器的大小從微型垂直擴充至小型或更高版本。請參閱〈變更主管的控制平面大小〉。
將 vCenter 和 vSphere IaaS 控制平面環境升級至 vSphere 8.0 U3 後，如果主管使用 Kubernetes 版本 1.26，則嘗試建立 vSphere 網繭失敗

將環境升級至 vSphere 8.0 U3 並將主管升級至 Kubernetes 版本 1.26 後，vSphere 網繭建立作業會在系統嘗試提取映像時失敗。即使叢集已啟用靜態網路，也可能會出現 failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface 錯誤。

因應措施：將 vSphere IaaS 控制平面和主管升級至 Kubernetes 版本 1.27 或更高版本。
有時，同時嘗試刪除磁碟區快照並執行 PVC 還原作業時，這些作業會因為內部相依性而無法完成

在下列情況下，可能會發生這些問題。針對磁碟區快照啟動還原作業，但由於各種不同的內部原因，還原作業需要較長的時間才能完成或者需要重試。同時，觸發來源快照刪除作業。因此，這兩項作業會發生衝突，且始終無法完成。快照刪除作業由於此快照的還原作業正在進行中而持續失敗，而還原作業由於已觸發快照刪除作業而開始失敗。

因應措施：若要解決此問題，必須刪除已還原的 PVC 以停止還原作業，然後繼續執行快照刪除。在此情況下，快照資料將遺失且無法還原，因為刪除已還原的 PVC 後會刪除快照。
虛擬機器服務虛擬機器無法使用儲存區類別中的 volumeBindingMode 參數設定為 WaitForFirstConsumer 的 PVC

將此類型的 PVC 用於虛擬機器服務虛擬機器時，會發生無法預期的行為和錯誤。例如，可能會出現 Waiting for first consumer to be created before binding 錯誤。

因應措施：虛擬機器服務虛擬機器支援儲存區類別中具有即時 volumeBidingMode 的 PVC，但不支援 WaitForFirstConsumer。
新的授權模式會變更 VMware vSphere IaaS 控制平面環境中 NSX Container Plugin (NCP) 的行為

在 8.0 Update 3 版本中，NSX Distributed Firewall (DFW) 授權作為單獨的附加元件授權提供。如果沒有此授權，VMware vSphere IaaS 控制平面環境中的 NCP 將對 NSX 上的 DFW 規則進行調整，從而導致無法預期的行為。

例如，如果沒有 DFW 授權，則為 VMware vSphere IaaS 控制平面建立的新安全性和網路原則將不起作用，因為 NCP 無法在 NSX Manager 上新增規則。此外，新建立命名空間中的網繭等資源也可以從其他命名空間進行連線。相反地，如果具有 DFW 授權，新建立的命名空間依預設不應從其他命名空間進行存取。

因應措施：NSX Distributed Firewall (DFW) 授權在 NSX Manager 上作為單獨的附加元件授權提供。若要避免出現問題，請將授權新增至 NSX Manager。
Velero vSphere Operator 安裝成功，但嘗試具現化 Velero 執行個體可能會失敗

Velero vSphere Operator 將其 Operator 網繭部署在控制平面虛擬機器上，而 Velero 的執行個體部署為 vSphere 網繭。

當 vCenter 升級至 8.x 且主管使用 VDS 網路時，可能會發生部署問題。但是，該主管的 ESXi 主機尚未升級，且使用的是早於 8.x 的異步版本。在此案例中，ESXi 主機無法部署 vSphere 網繭。因此，雖然 Velero vSphere Operator 安裝成功，但當管理員嘗試使用 Velero 的執行個體時，無法具現化該執行個體。

因應措施：若要確保 Velero 主管服務正常運作，您必須先將 ESXi 升級至版本 8.x，然後再將 vCenter 和主管升級至相同的 8.x 版本。
由於大規模執行時資源不足，虛擬機器 Operator 網繭當機

如果在大規模 (例如數千個虛擬機器) 執行時需要很長時間才能實現虛擬機器資源，可能是由於記憶體不足導致虛擬機器 Operator 網繭當機。

因應措施：如需因應措施和詳細資訊，請參閱知識庫文章 88442。
升級至 vCenter 8.0 Update 2b 後，vmon 管理的服務 wcp 可能處於 STOPPED 狀態，且 vCenter 修補可能會失敗

僅當 vCenter 8.0 Update 1 或更新版本升級至 vCenter 8.0 Update 2b，並且至少有一個主管使用 VDS 網路拓撲且位於 Kubernetes 1.24 上時，才會發生此問題。

因應措施：若要避免此問題，請將主管升級至 Kubernetes 1.25 或更新版本，然後再將 vCenter 升級至 8.0 Update 2b。如需詳細資訊，請連絡客戶支援。
如果自訂 vCenter 憑證大小大於 8K，主管作業會失敗

在 vSphere 8.0 Update 2b 中，vCenter 系統中 CSR 的金鑰大小上限從 16384 位元降至 8192 位元。如果憑證的金鑰大小大於 8192 位元，主管作業可能會出現無法預期的行為。例如，此類作業 (例如主管啟用或升級) 可能會失敗。
因應措施：

重新產生金鑰大小大於 8192 位元的任何 vCenter 憑證。
1. 識別金鑰大小大於 8192 位元的任何憑證。
```
for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done
```
2. 取代金鑰大小大於 8192 位元的任何憑證。
3. 如果使用 NSX，請在 NSX 中重新登錄 vCenter。
4. 重新啟動 WCP 服務。
如需詳細資訊，請參閱知識庫文章 96562。
如果 vCenter 中的內容程式庫連結至多個 vSphere 命名空間，可能會從該內容程式庫中刪除範本

如果將某個程式庫連結至 vSphere IaaS 控制平面中的多個命名空間，並且該程式庫已與命名空間取消連結或命名空間已刪除，則可能會出現此問題。

因應措施：

如果要將程式庫連結至多個命名空間，請避免使用本機程式庫。相反，請在 vCenter 上建立已發佈程式庫，並將所有範本上傳至該已發佈程式庫。然後，在同一 vCenter 上建立已訂閱程式庫以同步已發佈程式庫中的範本，並將此已訂閱程式庫連結至多個命名空間。在此情況下，即使程式庫已與任何命名空間取消連結或命名空間已刪除，也不會從 vCenter 中刪除程式庫項目。
使用 VMware vSphere Automation REST API 建立或更新虛擬機器類別並在 configSpec 中包含整數欄位時發生錯誤

當 configSpec 包含整數欄位 (例如 numCPU 或 memoryMB) 時，可能會顯示下列錯誤：

未知錯誤 - vcenter.wcp.vmclass.configspec.invalid: json: unsupported discriminator kind: struct。

未知錯誤 - vcenter.wcp.vmclass.configspec.invalid: json: cannot unmarshal string into Go struct field VirtualMachineConfigSpec.<fieldName> of type int32。

發生此問題的原因是，VAPI 端點中存在一個已知問題，即使用整數剖析原始 REST configSpec JSON 並將整數作為字串傳遞，從而導致失敗。僅當透過 VMware 開發人員中心使用 REST API 時，才會發生此問題。

因應措施：請使用 DCLI 或 vSphere Client 建立或更新虛擬機器類別，而不是使用 REST API。

或者，也可以使用適用於 python/java 的 vSphere Automation SDK。以下範例示範了如何利用公用通訊協定轉碼器服務，使用 pyvmomi 轉換從 vCenter 取得的 VirtualMachineConfigSpec (vim.vm.ConfigSpec) 物件。範例的最後一個項目顯示如何剖析手動製作的 JSON。然後，可以將該物件傳送至 VirtualMachineClasses API。
將有效的 vSphere VMware Foundation 授權套用至主管後，[工作負載管理] 頁面繼續顯示舊評估授權並出現到期警告

如果已為主管啟用評估授權並將 vSphere VMware Foundation 授權套用至主管，則可能會遇到此問題。但是，新授權不會顯示在 vSphere Client 之 [工作負載管理] 頁面上的 vCenter > 工作負載管理 > 主管 > 主管下。即使已成功套用新授權金鑰，vSphere Client 仍會繼續顯示包含舊評估授權到期日期的警告。

因應措施：無。新授權將正確顯示在 vSphere Client 的管理 > 授權 > 資產 > 主管下。
如果新增或刪除的規則不是最後一個規則，則安全性原則 CRD 中的已更新安全性原則規則不會生效

作為 DevOps，您可以將安全性原則 CRD 設定為將以 NSX 為基礎的安全性原則套用至主管叢集命名空間。更新 CRD 並新增或刪除安全性原則規則時，除非更新的規則是規則清單中的最後一個規則，否則該規則不會生效。

因應措施：將規則新增至規則清單的結尾，或使用單獨的安全性原則來新增或刪除規則。
使用舊虛擬機器映像名稱時，vSphere 8.0 U2 中的虛擬機器映像名稱格式變更可能會導致出現問題

在 vSphere 8.0 Update 2 之前，虛擬機器映像資源的名稱衍生自內容程式庫項目的名稱。例如，如果內容程式庫項目命名為 photonos-5-x64，則其對應的 VirtualMachineImage 資源也會命名為 photonos-5-x64。當不同程式庫中的程式庫項目具有相同的名稱時，這會導致出現問題。

在 vSphere 8.0 Update 2 版本中，引入了虛擬機器映像服務，以便能夠以自助服務方式管理虛擬機器映像。請參閱〈在 vSphere IaaS 控制平面中建立和管理獨立虛擬機器的內容程式庫〉。

此新功能允許內容程式庫與命名空間或整個主管叢集相關聯，並且要求 Kubernetes 叢集中的虛擬機器映像資源名稱唯一且具有決定性。因此，為避免與程式庫項目名稱發生潛在衝突，虛擬機器映像現在遵循新的命名格式 vmi-xxx。但是，如果您使用參考舊映像名稱 (例如 photonos-5-x64 或 centos-stream-8) 的舊虛擬機器 YAML，此變更可能會導致 vSphere 8.0 Update 2 版本中出現問題。
因應措施：
1. 使用下列命令擷取虛擬機器映像的相關資訊：
  - 若要顯示與其命名空間相關聯的映像，請執行 kubectl get vmi -n <namespace>。
  - 若要擷取叢集中的可用映像，請執行 kubectl get cvmi。
2. 取得名稱欄下列出的映像資源名稱後，請更新虛擬機器部署規格中的名稱。
在主管自動升級期間，vSphere 上的 WCP 服務程序可能會觸發危急狀態並意外停止

您可能會注意到為 WCP 服務程序產生的核心傾印檔案。

因應措施：無。VMON 程序會自動重新啟動 WCP 服務，且 WCP 服務會繼續升級，且不會再發生任何問題。
在 vSphere 網繭中，主管升級暫停並顯示 ErrImagePull 和提供者失敗狀態。出現 ErrImagePull 故障時，連結至 vSphere 網繭 (包括主管服務) 的持續性磁碟區可能不會中斷連結。

對於失敗並顯示 ErrImagePull 的 vSphere 網繭，持續性磁碟區可能不會中斷連結。這可能會導致大量 vSphere 網繭出現故障，因為所需的持續性磁碟區已連結至失敗的執行個體。在主管升級期間，主管內的 vSphere 網繭可能會轉換為provider failed狀態，並且變得沒有回應。

因應措施：刪除已連結持續性磁碟區且出現故障的 vSphere 網繭的執行個體。請務必注意，可以保留與 vSphere 網繭相關聯的持續性磁碟區宣告 (PVC) 和持續性磁碟區。完成升級後，請使用相同的 PodSpecPVC 重新建立 vSphere 網繭，以維持資料完整性和功能。若要緩解此問題，請使用 ReplicaSet (DaemonSet、Deployment) 建立 vSphere 網繭，以維持一組穩定的複本 vSphere 網繭在任何指定時間執行。
由於主節點選擇，主管升級停滯在 50% 且 Pinniped 升級失敗

Pinniped 網繭在推出期間停滯在擱置狀態，且在 Pinniped 元件升級期間主管升級失敗。
解決步驟包括：
1. 執行 kubectl get pods -n vmware-system-pinniped，以檢查 Pinniped 網繭的狀態。
2. 執行 kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml，以確認 holderIdentity 不是處於擱置狀態的任何 Pinniped 網繭。
3. 執行 kubectl delete leases -n vmware-system-pinniped pinniped-supervisor，以移除無作用網繭作為 holderIdentity 之 pinniped-supervisor 的租用物件。
4. 再次執行 kubectl get pods -n vmware-system-pinniped，以確保 vmware-system-pinniped 下的所有網繭已啟動且正在執行。
當主管控制平面虛擬機器處於已開啟電源狀態時，ESXi 主機節點無法進入維護模式

在具有 NSX Advanced Load Balancer 的主管設定中，如果有 Avi 服務引擎虛擬機器處於已開啟電源狀態，則 ESXi 主機無法進入維護模式，這將會影響維護模式下的 ESXi 主機升級和 NSX 升級。

因應措施：關閉 Avi 服務引擎虛擬機器的電源，以便 ESXi 可以進入維護模式。
無法使用 VDIS 上具有 vSphere 網繭的 ClusterIP 接收回送流量

如果 vSphere 網繭內的應用程式嘗試連線至同一 vSphere 網繭 (位於不同容器中) 內提供的 ClusterIP，VSIP 內的 DLB 則無法將流量路由回 vSphere 網繭。

因應措施：無。
網路原則不會在以 VDS 為基礎的主管中強制執行

使用 NetworkPolicy 的現有服務 YAML 不需要進行任何變更。如果檔案中存在 NetworkPolicy，將不會強制執行該原則。

因應措施：您必須在 VDS 的網路上設定以原則為基礎的規則。若要取得 NetworkPolicy 支援，則需要 NSX 網路支援。
從主管解除安裝服務後，Carvel 服務的命名空間可能會繼續顯示在 vSphere Client 中

如果 Carvel 服務需要 20 分鐘以上的時間才能從主管中解除安裝，則其命名空間在服務解除安裝後可能仍會顯示在 vSphere Client 中。

嘗試在同一主管上重新安裝服務失敗，直到刪除命名空間。在重新安裝期間顯示 ns_already_exist_error 訊息。

您會在記錄檔中看到下列項目：

/var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"
因應措施：從 vSphere Client 手動刪除命名空間。
1. 從 vSphere Client 主功能表中，選取工作負載管理。
2. 按一下命名空間索引標籤。
3. 從命名空間清單中，選取未清除的命名空間，然後按一下移除按鈕以刪除命名空間。
如果將 ESXi 主機從 7.0 Update 3 升級至 8.0 而不升級主管，會導致 ESXi 主機顯示為 [未就緒] 且工作負載離線

如果將屬於主管的 ESXi 主機從 vSphere 7.0 Update 3 升級至 vSphere 8.0 但未升級主管的 Kubernetes 版本，則 ESXi 主機會顯示為 [未就緒]，並且在主機上執行的工作負載會離線。

因應措施：將主管的 Kubernetes 版本至少升級至 1.21、1.22 或 1.23。
一鍵升級 vCenter Server 後，將不會自動升級主管

如果主管的 Kubernetes 版本低於 1.22，則在單鍵升級 vCenter Server 至 8.0 時，主管無法自動升級至 8.0 支援的最低 Kubernetes 版本 (即 1.23)。

因應措施：將 vCenter Server 升級至 8.0 之前，請先將主管的 Kubernetes 版本升級至 1.22。如果已將 vCenter Server 升級至 8.0，請手動將主管的 Kubernetes 版本升級至 1.23。
如果變更安全性原則自訂資源中的規則，可能無法刪除失效的規則

更新安全性原則時，可能會發生此問題。例如，您可以建立包含規則 A 和 B 的安全性原則自訂資源，然後更新原則以將規則變更為 B 和 C。這樣一來，將不會刪除規則 A。除了 B 和 C 之外，NSX 管理平面還會繼續顯示規則 A。

因應措施：刪除安全性原則，然後建立相同的安全性原則。

升級 vCenter Server 和 vSphere IaaS 控制平面後，由於磁碟區顯示為已連結至叢集節點，Tanzu Kubernetes Grid 叢集無法完成升級

當 Tanzu Kubernetes Grid 叢集無法升級時，您會發現磁碟區顯示為已連結至叢集節點且未清除。此問題可能是由上游 Kubernetes 中的問題所造成。

因應措施：

使用下列命令取得已停用排程之 TKG 叢集節點的相關資訊：

kubectl get node tkc_node_name -o yaml

範例：

# kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

檢查此節點在 status.volumeAttached 內容中是否有任何 vSphere CSI 磁碟區。如果有任何磁碟區，請繼續進行下一個步驟。

確認在步驟 1 中識別的節點上未執行任何網繭。使用以下命令：

kubectl get pod -o wide | grep tkc_node_name

範例：
```
kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
```
此命令輸出空白表示沒有網繭。繼續進行下一個步驟，因為步驟 1 中的輸出顯示了連結至沒有任何網繭之節點的磁碟區。

取得所有節點物件的相關資訊，以確保將相同的磁碟區連結至另一個節點：

kubectl get node -o yaml

範例：

同一磁碟區名稱顯示在兩個 TKG 叢集節點物件中。

On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...

根據磁碟區名稱中的磁碟區控點搜尋 PV。

在上述範例中，磁碟區名稱為 kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd，磁碟區控點為 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd。

使用此命令取得所有 PV 並搜尋上述磁碟區控點：

kubectl get pv -o yaml

在上述範例中，具有該磁碟區控點的 PV 為 pvc-59c73cea-4b75-407d-8207-21a9a25f72fd。

使用 volumeattachment 命令搜尋在上一個步驟中找到的 PV：

kubectl get volumeattachment | grep pv_name

範例：

# kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

您可以觀察到連結至節點 gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 (而非節點 gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95) 的磁碟區連結。這表示 gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 中的 status.volumeAttached 不正確。

從節點物件刪除失效的 volumeAttached 項目：

kubectl edit node tkc_node_name

範例：

kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

從 status.volumeAttached 移除失效的磁碟區項目。
針對 status.volumeAttached 內容中的所有失效磁碟區重複上述步驟。

如果 WCPMachines 仍存在，請手動將其刪除並等待幾分鐘以協調叢集。

# kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

如果 vSphere 管理員為自助服務命名空間範本設定超過叢集容量的資源限制，則不會觸發警示。

如果 vSphere 管理員設定超過叢集容量的資源限制，DevOps 工程師可能會使用範本部署具有較高資源的 vSphere 網繭。因此，工作負載可能會失敗。

因應措施：無
刪除包含 Tanzu Kubernetes Grid 叢集的主管命名空間時，主管中存在的持續性磁碟區宣告可能仍處於正在終止狀態

當系統刪除命名空間並將磁碟區與 Tanzu Kubernetes Grid 叢集中的網繭中斷連結時，如果發生資源衝突，則會出現此問題。

刪除主管命名空間的作業尚未完成，並且 vSphere Client 將命名空間狀態顯示為正在終止。連結至 Tanzu Kubernetes Grid 叢集中網繭的持續性磁碟區宣告也仍處於正在終止狀態。

如果您執行下列命令，則會看到無法在 persistentvolumeclaims 上完成作業錯誤：

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

無法在以下命名空間上更新 PersistentVolumeClaim\\\"<pvc-name>\\\": \\\"<supervisor-namespace>\\\"。錯誤：無法在 persistentvolumeclaims \\\"<pvc-name>\\\" 上完成作業: 物件已修改；請將您的變更套用至最新版本，然後再試一次\

因應措施：

使用以下命令修正問題：

kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge
從共用資料存放區 (例如 vSAN) 刪除多個 FCD 和磁碟區時，您可能會發現效能發生變更

效能變更可能是由已修正問題所造成。取消修正後，此問題會導致失效的 FCD 和磁碟區在 FCD 刪除作業失敗後仍保留在資料存放區中。

因應措施：無。儘管效能有所變更，刪除作業仍如常運作。
如果 DevOps 使用者在 vCenter Server 重新開機時啟動磁碟區作業或可設定狀態的應用程式部署，則作業可能會失敗

發生此問題的原因是，工作負載儲存區管理使用者帳戶已鎖定，且主管上執行的 vSphere CSI 外掛程式無法驗證。因此，磁碟區作業會失敗，並顯示 InvalidLogin 錯誤。

記錄檔 /var/log/vmware/vpxd/vpxd.log 會顯示下列訊息：

Authentication failed: The account of the user trying to authenticate is locked.:: The account of the user trying to authenticate is locked.:: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})
因應措施：
1. 取得帳戶解除鎖定時間。
  1. 在 vSphere Client 中，導覽至 [管理]，然後按一下 Single Sign On 下的 [組態]。
  2. 按一下 [選取帳戶] 索引標籤。
  3. 在 [鎖定原則] 下，取得解除鎖定時間 (以秒為單位)。
2. 使用 kubectl 適用的 vSphere 外掛程式向主管進行驗證。
  
  kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME
3. 請記下 vmware-system-csi- 命名空間中 vsphere-csi-controller 部署的原始複本計數。
  
  kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'
  
  original-replica-count
4. 將 vsphere-csi-controller 部署複本計數縮減至零。
  
  kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi
5. 等待解除鎖定時間下方指出的秒數。
6. 將 vsphere-csi-controller 部署複本計數垂直擴充至原始值。
  
  kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

主管上的 TKG 已知問題

將 vSphere IaaS 控制平面 7.0.x 環境升級至 vSphere 8.0.x 後，任何 TKG v1.27.6 叢集都變得不相容

vSphere 8.0.x 不支援 TKR 1.27.6。

因此，將 vSphere IaaS 控制平面 7.0.x 升級至 vSphere 8.0.x 後，TKG v1.27.6 叢集變得不相容。在主管升級期間，您將不會收到任何預先檢查警告。
因應措施：
- 如果 vSphere 7.0.x 上有任何 TKGS v1.27.6 叢集正在執行，請勿升級至 vCenter 8.0.x，尤其是 vCenter 8.0 Update 2b。如需詳細資訊，請參閱 VMware Tanzu Kubernetes 發行版本說明和知識庫文章 96501。
- 如果您計劃將 vSphere 7.x 環境升級至 vCenter 8.x，請勿升級至 TKR 1.27.6。
TKG 叢集 worker 節點無法開啟電源，並在 nsx-ncp pod 中顯示錯誤記錄：VIF restore activity already completed for attachment ID

TKG 叢集 worker 節點無法開啟電源，並顯示下列錯誤：

nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

NCP 記錄錯誤：

VIF restore activity already completed for attachment ID

如果 NSX 備份後所建立的 TKG 叢集節點的虛擬機器在 NSX 還原後立即透過 vMotion 進行移轉，則 NCP 無法還原該虛擬機器的連接埠，因為在 vMotion 中將重複使用連結識別碼並封鎖 NCP 的還原要求。
因應措施：
1. 移至 NSX Manager 以取得應刪除的區段連接埠，其顯示名稱的格式為 <vm name>.vmx@<attachment id>
2. 刪除新建立的連接埠之前，找到正在執行虛擬機器的主機，並透過在主機上執行 /etc/init.d/nsx-opsagent stop 來關閉 ops-agent。
3. 使用 NSX API 刪除連接埠 https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true
4. 透過在主機上執行 /etc/init.d/nsx-opsagent start 來開啟 ops-agent。
5. 等待 NCP 還原連接埠。
在 TKG 叢集清理期間或從 ESXi 主機停機時間復原期間，TKG 叢集中的網繭、PV 和 PVC 可能會停滯在Terminating狀態

在一般 TKG 叢集刪除和清理程序中，會刪除所有部署、狀態集、PVC、PV 和類似物件。但是，對於以 TKR v1.24 及更低版本為基礎的 TKG 叢集，由於 DetachVolume 錯誤，部分 PV 可能會停滯在Terminating狀態。當 VolumeAttachment 物件上的 DetachVolume 錯誤導致 VolumeAttachment 上的 finalizers 未移除，從而導致無法刪除相關物件時，會發生此問題。如果 ESXi 主機停機，也可能發生此案例。
因應措施：在 TKG 叢集中執行下列命令，以使用 detachError 從 volumeattachments 中移除 finalizers：
```
kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments
```
TGK 叢集在備份和還原後無法連線

如果在 NSX 備份後建立 vSphere 命名空間並設定了自訂的入口/出口 CIDR，則從備份還原 NSX 後，NCP 將無法完成還原程序，並且 vSphere 命名空間上的 TKG 叢集將無法使用。NCP 在還原程序期間失敗，並顯示類似下列內容的錯誤：

NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

因應措施：如果建立主管備份的時間與 NSX 備份大致相同，但在建立受影響的 vSphere 命名空間之前，請同時從備份還原主管。或者，刪除 vSphere 命名空間和相關聯的 TKG 叢集，等待 NCP 重新同步，然後重新建立已刪除的資源。
NSX 備份和還原後，TKG 叢集無法連線

為主管設定自訂入口 CIDR 時，在 NSX 備份還原後，TKG 叢集可能會變得無法使用，因為 NCP 元件無法正確驗證 TKG 叢集的入口 VIP。

因應措施：透過使用 NSX API，為 NSX 中的 TKG 叢集手動設定 VIP 以還原存取權。
設定了 Proxy 伺服器的現有 Tanzu Kubernetes Grid 叢集無法升級至 vSphere 8 主管

已修正：已在 vSphere 8 with Tanzu MP1 版本中修正此已知問題。

如果已為現有 Tanzu Kubernetes Grid 叢集設定 Proxy 伺服器，則無法將該叢集從 vSphere 7 主管升級至 vSphere 8 主管上的 Tanzu Kubernetes Grid 2.0。

因應措施：noProxy 欄位的內容與升級檢查衝突。由於在 Proxy 部分已新增至叢集規格的情況下此欄位為必填，因此，必須先完全移除 Proxy 組態，然後再升級至 vSphere 8。
antrea-resource-init 網繭當機且處於 [擱置中] 狀態

升級 Tanzu Kubernetes Grid 叢集的 Tanzu Kubernetes 發行版本後，antrea-resource-init 網繭可能處於 [擱置中] 狀態。

因應措施：重新啟動主管上的網繭。
Tanzu Kubernetes Grid 叢集 v1.21.6 可能會進入 FALSE 狀態，且某些機器可能不會移轉

升級至 vCenter Server 8 並更新主管後，Tanzu Kubernetes Grid 叢集 v1.21.6 可能會進入 FALSE 狀態，且某些 wcpmachines 可能不會移轉至 vspheremachines。

因應措施：無
依預設，對於執行 TKR 版本 v1.23.8---vmware.2-tkg.2-zshippable 的 TKG 叢集，vmware-system-user 帳戶的密碼將於 60 天後到期

作為 STIG 強化的一部分，對於執行 TKR 版本 v1.23.8---vmware.2-tkg.2-zshippable 的 TKG 叢集，vmware-system-user 帳戶設定為在 60 天後到期。這可能會影響使用 vmware-system-user 帳戶透過 SSH 連線至叢集節點的使用者。

請參閱下列知識庫文章以更新 vmware-system-user 密碼到期時間，如果需要，允許建立與 TKG 叢集節點的 SSH 工作階段：https://kb.vmware.com/s/article/90469

tanzu-capabilities-controller-manager Pod 會持續重新啟動，並前往 vSphere IaaS 控制平面 8.0.0a 中 TKC 上的 CLBO

由於服務帳戶權限問題，在使用 TKR 版本 v1.23.8+vmware.2-tkg.2-zshippable 時，TKG 叢集上的 tanzu-capabilities-controller-manager Pod 將停滯在 CLBO (當機回送) 中。

因應措施：將所需權限新增至 TKC 上的功能服務帳戶 tanzu-capabilities-manager-sa。

暫停 TKC 上的功能套件重新調整：

kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

建立新檔案 capabilities-rbac-patch.yaml：

apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

修補 TKC 上的功能叢集角色：

//Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

在 TKC 上刪除 tanzu-capabilities-controller-manager。

在三個 vSphere 區域中部署的主管上的 Tanzu Kubernetes Grid 2.0 叢集不支援具有 vGPU 和執行個體儲存區的虛擬機器。

在三個 vSphere 區域中部署的主管執行個體上佈建的 Tanzu Kubernetes Grid 2.0 叢集不支援具有 vGPU 和執行個體儲存區的虛擬機器。

因應措施：無
TKR 版本 v1.22.9 列在內容程式庫映像中，但未列在 kubectl 命令中

TKR 映像的內容程式庫會列出 TKR v1.22.9。命令 kubectl get tkr 不會將此映像列為可用，因為 TKR v1.22.9 無法使用且不應使用。此映像錯誤地出現在內容程式庫中。

因應措施：使用 TKR v1.22.9 以外的 TKR。如需可用 TKR 的清單，請參閱 TKR 版本說明。
在 vSphere IaaS 控制平面 8.0.0a 中，無法使用 v1alpha1 API 和 v1.23.8 TKR 佈建 TKC

使用 TKC v1alpha1 API 佈建版本為 v1.23.8 的 TKC 時。請求將會失敗，並顯示「找不到相容的完整版本比對版本提示「1.23.8」和預設作業系統標籤: 「os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0」。」

因應措施：佈建 TKC 時切換至 TKC v1alpha2 或 v1alpha3 API
使用 v1beta1 API 佈建的 Tanzu Kubernetes Grid 2.0 叢集必須以預設 ClusterClass 為基礎

如果您使用 v1beta1 API 在主管上建立 Tanzu Kubernetes Grid 2.0 叢集，則叢集必須以預設 tanzukubernetescluster ClusterClass 為基礎。系統不會根據不同的 ClusterClass 來協調叢集。

因應措施：從 vSphere 8 U1 版本開始，您可以根據自訂 ClusterClass 佈建 v1beta1 叢集。請參閱知識庫文章 https://kb.vmware.com/s/article/91826。

網路已知問題

在 NSX Advanced Load Balancer 設定中，clusternetworkinfo 或 namespacenetworkinfo 輸出中沒有區段 usage.ingressCIDRUsage

在 NSX Advanced Load Balancer 設定中，入口 IP 由 Avi 控制器配置，入口 CIDR 的使用量將不會顯示在 clusternetworkinfo 或 namespacenetworkinfo 輸出中。

因應措施：從 Avi 控制器使用者介面的應用程式 > VS VIP 取得 ingressCIDR 使用量。
為路由主管刪除命名空間後，不會移除第 0 層首碼清單上的網繭 CIDR

在路由的主管中，在命名空間刪除後，不會刪除第 0 層首碼清單中的網繭 CIDR。

因應措施：刪除首碼清單物件：

curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json
使用 NSX Advanced Load Blanacer 時，clusternetworkinfo 和 namespacenetworkinfo Kubernetes 資源不包含 usage.ingressCIDRUsage。

在以 NSX 為基礎的 Sueprvisor 中使用 NSX Advanced Load Balancer 時，clusternetworkinfo 和 namespacenetworkinfo Kuberentes 資源不再包含 usage.ingressCIDRUsage 欄位。這表示執行 kubectl get clusternetworkinfo <supervisor-cluster-name> -o json 或 kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json 將不會在輸出中包含 ingressCIDR 使用量物件。

因應措施：使用 Avi 控制器使用者介面頁面存取 ingressCIDR 使用量。
NSX 備份和還原後，某些命名空間存在失效的第 1 層區段

NSX 備份和還原程序完成後，不會清理具有服務引擎 NIC 的失效第 1 層區段。

NSX 備份後刪除命名空間時，還原作業會還原與 NSX Advanced Load Balancer 控制器服務引擎 NIC 相關聯的失效第 1 層區段。
因應措施：手動刪除第 1 層區段。
1. 登入 NSX Manager。
2. 選取網路 > 區段。
3. 尋找與已刪除命名空間相關聯的失效區段。
4. 從連接埠/介面區段中刪除失效的服務引擎 NIC。
負載平衡器監視器可能會停止運作，主管可能會在 vSphere Client 中停滯於「正在設定」狀態

如果已啟用 NSX Advanced Load Balancer，由於 NSX 中存在多個強制執行點，NCP 可能無法提取負載平衡器狀態。一旦在 NSX 上啟用，這會影響設定了 NSX Advanced Load Balancer 的現有主管。此問題會影響利用 NSX Advanced Load Balancer 的新主管。受此問題影響的主管仍可正常運作 - LB 監控功能除外。

因應措施：在 NSX 中停用 NSX Advanced Load Balancer這可能會限制在執行 NSX Advanced Load Balancer 的現有主管所在的 WCP 環境中部署具有 NSX Advanced Load Balancer 之主管的能力。
無法將 NSX Advanced Load Balancer 與使用內嵌式連結模式拓撲的 vCenter Server 搭配使用。

設定 NSX Advanced Load Balancer 控制器時，可在多個雲端上進行設定。但是，在啟用 vSphere IaaS 控制平面時，您無法選取多個雲端，因為它僅支援 Default-Cloud 選項。因此，無法將 NSX Advanced Load Balancer 與使用內嵌式連結模式拓撲的 vCenter Server 版本搭配使用。

為每個 vCenter Server 設定 NSX 負載平衡器。

儲存區已知問題

在 vCenter 系統之間共用資料存放區的環境中，顯示多個 CNS 磁碟區同步錯誤

CNS 不支援跨 vCenter 移轉。但是，會自動執行 CNS 定期同步，並為共用資料存放區上的磁碟區建立鎖定爭用。
因應措施：若要避免此問題，請為 CNS 定期同步設定較大的時間間隔。
1. 在 vCenter 中找到 CNS 組態檔：
  
  /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml
2. 導覽至以下行：
  
  <newSyncInterval>60</newSyncInterval>
  
  依預設，定期同步設定為 60 秒。
3. 將時間變更為更長的期間，例如，31536000 (1 年)。
無法變更 vSAN Direct 資料存放區中磁碟的磁碟區配置類型

一旦決定 vSAN Direct 資料存放區中磁碟的磁碟區配置類型，便無法對其進行變更。這是因為基礎層不支援類型轉換。但是，允許變更新磁碟的磁碟區配置類型以執行複製和重新放置等作業。

因應措施：無
已刪除的虛擬機器導致 CNS 工作停滯在已排入佇列狀態。

傳送至 CNS 的作業會傳回工作識別碼，但工作狀態永遠不會從已排入佇列變更。這些工作適用於連結至剛刪除之虛擬機器的磁碟區。
因應措施：如果應用程式層可以修正呼叫順序，則無需在 CNS 端執行任何動作。如果不是，請遵循下列步驟停用 CNS 新序列化：
1. 在 vCenter 上開啟 /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml。
2. 將下列組態變更為 false： <newSerializationEnabled>true</newSerializationEnabled>
3. 使用以下命令重新啟動 vsan-health： vmon-cli -r vsan-health
如需詳細資料，請參閱知識庫 93903。
成功刪除 PVC 後，PV 仍保持已終止狀態

刪除 PersistentVolumeClaim (PVC) 後，對應的 PersistentVolume (PV) 可能會在主管中保持已終止狀態。此外，vSphere Client 可能會顯示多個失敗的 deleteVolume 工作。
因應措施：
1. 向主管進行驗證：
  
  kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME
2. 取得處於正在終止狀態的持續性磁碟區的名稱：
  
  kubectl get pv
3. 請記下持續性磁碟區中的磁碟區控點：
  
  kubectl describe pv <pv-name>
4. 使用上一個步驟中的磁碟區控點，刪除主管中的 CnsVolumeOperationRequest 自訂資源：
  
  kubectl delete cnsvolumeoperationrequest delete-<volume-handle>
備註：
刪除 PV 之前，請確保叢集中的任何其他資源未使用該 PV。