更新時間：2023 年 7 月 6 日
此版本說明涵蓋下列主題：
版本說明的內容
新增功能
VMware vSphere with Tanzu 具有每月修補程式，以推出新的特性和功能、提供 Kubernetes 和其他服務的更新、追蹤上游資訊，以及解決所報告的問題。在這裡，我們說明了每個每月修補程式提供的內容。
2023 年 7 月 6 日的最新內容
| 2023 年 7 月 6 日組建編號資訊 ESXi 7.0 Update 3m | 2023 年 5 月 03 日 | ISO 組建編號 21686933 vCenter Server 7.0 Update 3n | 2023 年 7 月 06 日 | ISO 組建編號 21958406 VMware NSX Advanced Load Balancer AVI-22.1.3 | 2023 年 1 月 31 日 |
新功能
-
主管叢集支援 Kubernetes 1.24 - 此版本新增了對 Kubernetes 1.24 的支援，且不再支援 Kubernetes 1.21。
主管叢集支援的 Kubernetes 版本：
此版本中支援的 Kubernetes 版本為 1.24、1.23 和 1.22。在 Kubernetes 1.21 版上執行的主管將自動升級至 1.22 版，以確保所有主管都在支援的 Kubernetes 版本上執行。
2023 年 3 月 30 日的最新內容
| 2023 年 3 月 30 日組建編號資訊 ESXi 7.0 Update 3l | 2023 年 3 月 30 日 | ISO 組建編號 21424296 vCenter Server 7.0 Update 3l | 2023 年 3 月 30 日 | ISO 組建編號 21477706 VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日 |
新功能：
-
無，這只是一個錯誤修正版本。
主管叢集支援的 Kubernetes 版本
此版本中支援的 Kubernetes 版本為 1.23、1.22 和 1.21。在 Kubernetes 1.20 版上執行的主管將自動升級至 1.21 版，以確保所有主管都在支援的 Kubernetes 版本上執行。
已解決的問題
此修補程式修正了下列問題。
-
啟用大型接收卸載 (LRO) 後，使用 Antrea-ENCAP 的 Tanzu Kubernetes Grid 叢集虛擬機器可能會遇到網路效能問題。
-
在主管上啟用內嵌式 Harbor 登錄可能會導致預設組態不安全。
2023 年 2 月 23 日的最新內容
| 2023 年 2 月 23 日組建編號資訊 ESXi 7.0 Update 3i | 2022 年 12 月 8 日 | ISO 組建編號 20842708 vCenter Server 7.0 Update 3k | 2023 年 2 月 23 日 | ISO 組建編號 21290409 VMware NSX Advanced Load Balancer avi-22.1.3 | 2023 年 1 月 31 日 |
新功能：
主管
-
主管叢集支援 Kubernetes 1.23 - 此版本新增了對 Kubernetes 1.23 的支援，且不再支援 Kubernetes 1.20。此版本中支援的 Kubernetes 版本為 1.23、1.22 和 1.21。在 Kubernetes 1.20 版上執行的主管將自動升級至 1.21 版，以確保所有主管都在支援的 Kubernetes 版本上執行。
2022 年 12 月 8 日的最新內容
| 2022 年 12 月 8 日組建編號資訊 ESXi 7.0 Update 3i | 2022 年 12 月 8 日 | ISO 組建編號 20842708 vCenter Server 7.0 Update 3i | 2022 年 12 月 8 日 | ISO 組建編號 20845200 VMware NSX Advanced Load Balancer avi-21.1.4-9009 | 2022 年 4 月 7 日 |
新功能：
新增了 SecurityPolicy CRD：vSphere 7.0 Update 3i 為使用者引入了 SecurityPolicy CRD，可將以 NSX 為基礎的安全性原則套用至主管中的虛擬機器和網繭。這可讓您透過 CRD 為主管命名空間延伸 Kubernetes 網路原則，以透過代碼設定「Kubernetes 網路原則」。
支援：kube-apiserver-authproxy-svc 服務和系統網繭中使用的 TLS 版本已更新至 TLSv1.2。
2022 年 9 月 13 日的最新內容
| 2022 年 9 月 13 日組建編號資訊 ESXi 7.0 Update 3g | 2022 年 9 月 13 日 | ISO 組建編號 20328353 vCenter Server 7.0 Update 3h | 2022 年 9 月 13 日 | ISO 組建編號 20395099 VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
無，這只是一個錯誤修正版本。
已解決的問題：
此修補程式修正了由於 WCP 服務在升級後未啟動而導致 vCenter Server 升級至 70u3f 版失敗的問題。嘗試在 70u3d 之前的版本上啟用 vSphere with Tanzu 的情況下升級 vCenter Server 時發生錯誤。嘗試將 vCenter Server 從早於 70u3d 的版本升級至 vCenter Server 70u3d，然後再升級至 vCenter Server 70u3f 失敗。
若要進一步瞭解已解決的問題，請閱讀知識庫文章 89010。
2022 年 7 月 12 日的最新內容
| 2022 年 7 月 12 日組建編號資訊 ESXi 7.0 Update 3f | 2022 年 7 月 12 日 | ISO 組建編號 20036589 vCenter Server 7.0 Update 3f | 2022 年 7 月 12 日 | ISO 組建編號 20051473 VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
主管叢集
-
支援虛擬機器服務的 LoadBalancer IP 字串值 – 可讓使用者為 spec.LoadBalancerIP 值提供字串值，表示/符合在 NSX-T 中建立和標記的 IP 集區。
-
備份和還原虛擬機器服務虛擬機器 – VMware 現在支援透過全面且完整記錄的工作流程在內部部署 vSphere 和 VMware Cloud on AWS 中備份和還原虛擬機器服務虛擬機器，該工作流程支援 Veeam 以及其他以 vSphere Storage APIs for Data Protection (vADP) 為基礎的備份廠商，從而確保在 VMware Cloud on AWS 上提供更完整的資料保護解決方案以及虛擬機器服務的全面可用性。
-
2022 年 5 月 12 日的最新內容
| 2022 年 5 月 12 日組建編號資訊 ESXi 7.0 Update 3d | 2022 年 3 月 29 日 | ISO 組建編號 19482537 vCenter Server 7.0 Update 3e | 2022 年 5 月 12 日 | ISO 組建編號 19717403 VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
針對透過 VM Operator 服務部署的虛擬機器新增了網路安全性原則支援 – 可根據標籤透過安全群組建立以 NSX-T 為基礎的安全性原則。現在可以建立以 NSX-T 為基礎的安全性原則，並根據 NSX-T 標籤將其套用至透過 VM Operator 部署的虛擬機器。
-
主管叢集支援 Kubernetes 1.22 - 此版本新增了對 Kubernetes 1.22 的支援，且不再支援 Kubernetes 1.19。此版本中支援的 Kubernetes 版本為 1.22、1.21 和 1.20。在 Kubernetes 1.19 版上執行的主管叢集將自動升級至 1.20 版，以確保所有主管叢集都在支援的 Kubernetes 版本上執行。
升級考量事項
如果從 7.0 Update 3c 之前的版本升級 vCenter Server，且您的主管叢集在 Kubernetes 1.19.x 上執行，則 tkg-controller-manager 網繭會進入 CrashLoopBackOff 狀態，從而使客體叢集無法管理。會顯示類似下列內容的訊息：
出現危急狀態: 記憶體位址或 NIL 指標解除參照無效
因應措施：若要瞭解並解決此問題，請閱讀知識庫文章 88443。
2022 年 3 月 29 日的最新內容
| 2022 年 3 月 29 日組建編號資訊 ESXi 7.0 Update 3d | 2022 年 3 月 29 日 | ISO 組建編號 19482537 vCenter Server 7.0 Update 3d | 2022 年 3 月 29 日 | ISO 組建編號 19480866 VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022 年 3 月 29 日 |
新功能
-
無，這只是一個錯誤修正版本。
已解決的問題
-
在 vTPM 主機上安裝 Spherelet VIB 失敗
-
在 vTPM 主機上安裝 Spherelet VIB 失敗，並顯示錯誤「找不到受信任的簽署者: 自我簽署憑證」。
-
-
vSphere 升級導致主管叢集變得不穩定
-
從 vSphere 7.0 Update 1 升級至 7.0 Update 2 後，主管叢集會進入 [正在設定] 狀態。
-
-
使用 NSX-T Advanced Load Balancer 時，主管叢集啟用會停止
-
根據預設驗證組態，使用 NSX-T Advanced Load Balancer 啟用主管叢集可能會導致組態停止。
-
2021 年 10 月 21 日的最新內容
| 2021 年 10 月 21 日組建編號資訊 ESXi 7.0 Update 3 | 2022 年 1 月 27 日 | ISO 組建編號 19193900 vCenter Server 7.0 Update 3a | 2021 年 10 月 21 日 | ISO 組建編號 18778458 VMware NSX Advanced Load Balancer 20.1.7 | 2021 年 10 月 21 日 | ISO 組建編號 18778458 |
重要事項：由於升級影響問題，VMware 在 2021 年 11 月 19 日從所有站台移除了 ESXi 7.0 Update 3、7.0 Update 3a 和 7.0 Update 3b。ESXi 7.0 Update 3c ISO 的組建 19193900 取代了組建 18644231。如需詳細資訊，請參閱 VMware ESXi 7.0 Update 3c 版本說明。
新功能
-
Tanzu Kubernetes Grid Service for vSphere
-
讓容器化工作負載能夠在 Tanzu Kubernetes 叢集上利用 GPU 加速 - 透過原生 Kubernetes 命令，vSphere 管理員現在可以將 GPU 加速虛擬機器佈建至 Tanzu Kubernetes 叢集，而開發人員現在可以將 GPU 加速的虛擬機器新增至其 Tanzu Kubernetes Grid 叢集。
-
以 Ubuntu 20.04 為基礎的 Tanzu Kubernetes 版本 (TKr) - 這是我們依據 Ubuntu 20.04 的第一個 TKr 版本。此映像已專門針對 GPU (AI/ML) 工作負載進行最佳化和測試。如需詳細資料，請參閱 TKr 版本說明。
-
2021 年 10 月 5 日的最新內容
| 2021 年 9 月 28 日組建編號資訊 ESXi 7.0 Update 3 | 2022 年 1 月 27 日 | ISO 組建編號 19193900 vCenter Server 7.0 Update 3 | 2021 年 10 月 5 日 | ISO 組建編號 18700403 VMware NSX Advanced Load Balancer 20.1.6 | 2021 年 10 月 5 日 | ISO 組建編號 18700403 |
重要事項：由於升級影響問題，VMware 在 2021 年 11 月 19 日從所有站台移除了 ESXi 7.0 Update 3、7.0 Update 3a 和 7.0 Update 3b。ESXi 7.0 Update 3c ISO 的組建 19193900 取代了組建 18644231。如需詳細資訊，請參閱 VMware ESXi 7.0 Update 3c 版本說明。
新功能
-
主管叢集
-
vSphere 服務 - 透過使用 vSphere 服務架構，vSphere 管理員現在可以非同步方式管理主管服務，包括 MinIO、Cloudian Hyperstore、Dell ObjectScale 和 Velero。主管服務的分離特性允許管理員將服務新增至 vCenter Server 版本之外的服務目錄，從而進一步增強 DevOps 社群的能力。主管服務僅在設定了 NSX-T Data Center 網路的主管叢集中可用。如需管理 vSphere Client 中主管服務的相關資訊，請查看說明文件。
-
在虛擬機器服務中支援 vGPU - vSphere 管理員現在可以向開發人員提供自助服務存取權，以便透過使用 Kubernetes 的虛擬機器使用 GPU，但受到透過虛擬機器類別強制執行的限制所約束。然後，DevOps 使用者可以使用這些預先定義的虛擬機器類別和映像快速建立具有 GPU 的虛擬機器。
-
使用 DHCP 網路啟用工作負載管理 - 此版本將 DHCP 網路新增為替代網路設定路徑以簡化啟用，從而加快實現 POC。vSphere 管理員只需選取網路和連接埠群組，即可使用 DHCP 設定管理網路和工作負載網路，而所有其他輸入 (包括 DNS、NTP 和浮動 IP) 都將使用 DHCP 自動擷取。
-
在啟用期間執行網路和負載平衡器健全狀況檢查 - 啟用期間，網路連線、DNS、NTP 和負載平衡器連線的健全狀況檢查會驗證主管叢集啟用是否成功，並提供人工可讀的錯誤訊息，以協助診斷常見問題並採取動作。如需有關解決錯誤訊息的進一步指示，請查看說明文件。
-
主管叢集支援 Kubernetes 1.21 - 此版本新增了對 Kubernetes 1.21 的支援，且不再支援 Kubernetes 1.18。此版本中支援的 Kubernetes 版本為 1.21、1.20 和 1.19。在 Kubernetes 1.18 版上執行的主管叢集將自動升級至 1.19 版，以確保所有主管叢集都在支援的 Kubernetes 版本上執行。
-
對主管命名空間加上標籤和註解 - DevOps 使用者透過命名空間自助服務範本建立的命名空間現在可以具有 Kubernetes 標籤和註解。
-
啟用後編輯主管叢集組態 - 啟用具有 vSphere 網路堆疊的主管叢集後，vSphere 管理員現在可以從 API 和 vSphere Client 編輯下列設定：負載平衡器使用者名稱和密碼、管理網路 DNS 搜尋網域，以及工作負載網路 DNS 伺服器、NTP 伺服器，還可以擴充服務 IP 範圍和新增工作負載網路。對於使用 vSphere 或 NSX-T 網路的叢集，您可以在啟用後垂直擴充控制平面大小。請注意，您只能增加叢集的規模，目前不支援縮減規模。如需如何透過 vSphere Client 變更主管叢集設定的相關資訊，請參閱說明文件。
-
Tanzu 授權金鑰到期 - vSphere 管理員現在能夠更靈活地管理已到期的 Tanzu 版本授權金鑰。Tanzu 授權金鑰到期後，不會自動硬性強制執行，以便管理員能夠更靈活地購買和指派新的授權金鑰，而不會影響一般作業。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
vSAN 持續性磁碟區支援 RWX - 在 Tanzu Kubernetes 叢集上執行的工作負載現在可以使用 RWX 掛接以 vSAN 為基礎的持續性磁碟區。
-
Tanzu Kubernetes Grid Service v1alpha2 API 更新 - 對 Tanzu Kubernetes 叢集 API 進行 API 更新，提供了新欄位，可增強 Tanzu Kubernetes Grid Service 的組態，包括對多個 Worker 節點集區的支援。棄用 v1alpha1 API，以支援新的 v1alpha2 API。如需詳細資訊，請參閱說明文件。
-
度量伺服器 - 從 1.20.9+ 和 1.21 Tanzu Kubernetes 版本開始，Tanzu Kubernetes 叢集中現在預設包含度量伺服器。
-
能夠支援無 NAT (路由) 拓撲 - 現在，可以使用允許叢集節點在叢集網路外部進行路由的網路拓撲來建立 Tanzu Kubernetes 叢集。如需詳細資訊，請參閱說明文件。
-
2021 年 8 月 24 日的最新內容
| 2021 年 8 月 24 日組建編號資訊 ESXi 7.0 Update 2c | 2021 年 8 月 24 日 | ISO 組建編號 18426014 vCenter Server 7.0 Update 2c | 2021 年 8 月 24 日 | ISO 組建編號 18356314 VMware NSX Advanced Load Balancer 20.1.5 | 2021 年 8 月 24 日 | ISO 組建編號 18379150 |
新功能
-
主管叢集
-
主管叢集支援 Kubernetes 1.20 - 此版本新增支援 Kubernetes 1.20，並取消支援 Kubernetes 1.17。此版本中支援的 Kubernetes 版本為 1.20、1.19 和 1.18。在 Kubernetes 1.17 版上執行的主管叢集將自動升級至 1.18 版，以確保所有主管叢集都在支援的 Kubernetes 版本上執行。
-
對 vSphere 網繭的 Velero Plugin for vSphere 支援 - 此版本支援 Velero 1.5.1 和 Velero Plugin for vSphere 1.1.0 及更高版本，可用於備份和還原 vSphere 網繭。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
將 Harbor 和 external-dns 作為新的叢集內延伸 - 平台營運人員現在可以存取其他兩個支援的叢集內延伸：Harbor 和 external-dns。Harbor 是 CNCF 分級容器登錄，而 external-dns 是一種根據 Kubernetes 負載平衡服務動態設定 DNS 記錄的常用工具。
-
改進了控制平面節點的修復 - Tanzu Kubernetes 叢集現在將自動修復常見的控制平面節點失敗，從而提供更強大的 Kubernetes 執行階段。
-
對 Tanzu Kubernetes 叢集工作負載的 Velero Plugin for vSphere 支援 - 此版本支援 Velero 1.5.1 及更高版本和 Velero Plugin for vSphere 1.1.0 及更高版本，可用於備份和還原在 Tanzu Kubernetes 叢集上執行的工作負載。
-
對 Tanzu Kubernetes 叢集工作負載的 Velero 獨立支援 - 此版本提供了對 Velero 1.6 的支援，可以使用獨立 Velero 搭配 Restic 來備份和還原 Tanzu Kubernetes 叢集工作負載。
-
2021 年 4 月 27 日的最新內容
| 2021 年 4 月 27 日組建編號資訊 ESXi 7.0 | 2021 年 3 月 09 日 | ISO 組建編號 17630552 vCenter Server 7.0 | 2021 年 4 月 27 日 | ISO 組建編號 17920168 |
新功能
-
主管叢集
-
透過虛擬機器服務使用 Kubernetes 管理虛擬機器。此版本將虛擬機器服務新增至 vSphere with Tanzu 中所包含的基礎結構服務，為開發人員提供 Kubernetes 原生虛擬機器管理。虛擬機器服務可讓開發人員使用 Kubernetes 命令部署和管理命名空間中的虛擬機器。與此同時，vSphere 管理員能夠管理服務的資源使用量和可用性，並為開發人員提供雲端原生體驗。
-
為開發人員建立命名空間的自助服務。vSphere 管理員現在可以建立主管命名空間，並將其設定為自助服務命名空間範本。此範本定義使用的資源限制和權限。然後，開發人員可以使用此範本來佈建命名空間，並在其中執行工作負載，而不必請求命名空間並等待核准。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
重要事項：針對 TKR 的 CVE 修正：有新的 Tanzu Kubernetes 版本可用，可解決 CVE-2021-30465。
-
重要事項：針對 Contour 入口延伸的 CVE 修正：提供了新的 Envoy 映像版本，可解決 CVE-2021-28682、CVE-2021-28683 和 CVE-2021-29258。如需詳細資訊，請參閱相關的知識庫文章。
-
使用預設虛擬機器類別的新工作流程。提供了使用預設虛擬機器類別佈建 Tanzu Kubernetes 叢集的新工作流程。建立新叢集之前，將預設虛擬機器類別新增至要佈建叢集的 vSphere 命名空間。如需相關指引，請參閱說明文件。
-
系統變動 Webhook 現在支援試執行模式。使用者現在可以將常用工具 (例如 Terraform Kubernetes 提供者) 與 Tanzu Kubernetes Grid 服務整合。系統 Webhook 先前不支援試執行模式，這是 Terraform「plan」命令的需求。
-
自訂虛擬機器類別。Tanzu Kubernetes 叢集可透過虛擬機器服務使用自訂虛擬機器類別。這將允許使用者為配置給組成 Tanzu Kubernetes 叢集之虛擬機器的 CPU 和記憶體設定不同數量。
-
2021 年 3 月 09 日的最新內容
| 2021 年 3 月 09 日組建編號資訊 ESXi 7.0 | 2020 年 3 月 09 日 | ISO 組建編號 17630552 vCenter Server 7.0 | 2021 年 3 月 09 日 | ISO 組建編號 17694817 VMware NSX Advanced Load Balancer | 2020 年 10 月 12 日 | 20.1.X |
新功能
-
主管叢集
-
支援已設定 VDS 網路的主管叢集的 NSX Advanced Load Balancer。現在，您可以使具有 NSX Advanced Load Balancer (Avi Networks) 的主管叢集能夠進行 L4 負載平衡，以及主管叢集和 Tanzu Kubernetes 叢集之控制平面節點的負載平衡。如需有關設定 NSX Advanced Load Balancer 的指引，請查看說明文件頁面。
-
透過自動升級執行 Kubernetes 1.16 的主管叢集，將主管叢集升級至 Kubernetes 1.19。您可以將主管叢集升級至 Kubernetes 1.19。在此更新中，支援下列主管叢集版本：1.19、1.18 和 1.17。更新 vCenter Server 之後，執行 Kubernetes 1.16 的主管叢集將會自動升級至 1.17。這可確保您的所有主管叢集均執行支援的 Kubernetes 版本。
-
擴充 PersistentVolumeClaims (PVC)。現在，可以透過修改 PersistentVolumeClaim 物件來擴充現有磁碟區，即使該磁碟區正在使用中也一樣。這適用於主管叢集和 Tanzu Kubernetes 叢集中的磁碟區。
-
使用 vSphere Lifecycle Manager 管理主管叢集生命週期。對於已設定 NSX-T 網路的主管叢集，您可以使用 vSphere Lifecycle Manager 進行基礎結構設定和生命週期管理。
-
-
Tanzu Kubernetes Grid Service for vSphere
-
支援私人容器登錄。現在，vSphere 管理員和 Kubernetes 平台營運人員可以定義其他憑證授權機構憑證 (CA)，以在 Tanzu Kubernetes 叢集中使用以信任私人容器登錄。此功能支援 Tanzu Kubernetes 叢集從具有企業或自我簽署憑證的容器登錄提取容器映像。可以在主管叢集範圍內或針對每個 Tanzu Kubernetes 叢集將私人 CA 設定為 Tanzu Kubernetes 叢集的預設憑證。若要進一步如何為 Tanzu Kubernetes 叢集設定私人容器登錄支援，請造訪說明文件頁面。
-
為具有 NSX-T 和 NSX Advanced Load Balancer 的 LoadBalancer 服務類型具有 NSX-T 和 NSX Advanced Load Balancer 的 LoadBalancer。Kubernetes 應用程式營運人員現在可以在設定服務類型時提供使用者定義的 LoadBalancerIP：從而允許服務使用靜態 IP 端點。此進階功能要求具有 NSX-T 負載平衡或 NSX Advanced Load Balancer 以及主管叢集。若要瞭解如何設定此功能，請造訪說明文件頁面。
-
為具有 NSX-T 的 LoadBalancer 服務類型設定 ExternalTrafficPolicy 和 LoadBalancerSourceRanges具有 NSX-T 的 LoadBalancer。現在，Kubernetes 應用程式營運人員可針對服務設定值為「local」的 ExternalTrafficPolicy，以將用戶端 IP 位址散佈到結束網繭。此外，還可以為服務定義 loadBalancerSourceRanges，以限制哪些用戶端 IP 可以存取負載平衡服務。這兩個進階功能要求具有 NSX-T 負載平衡以及主管叢集。
-
Kubernetes 版本管理和指示。您現在可使用 kubectl 檢查 TanzuKubernetesReleases 與基礎主管叢集環境的相容性。此外，Tanzu Kubernetes 叢集現在還會指示是否有 Kubernetes 升級可用，並建議可使用的下一個 TanzuKubernetesRelease。如需有關使用此新功能的詳細資訊，請參閱說明文件頁面。
-
改進了叢集狀態概觀。在先前的版本中，VMware 透過實作條件式狀態報告來顯示常見問題和錯誤，從而擴充了 WCPCluster 和 WCPMachine CRD。在 vSphere 7.0 Update 2 版本中，增強了 TanzuKubernetesCluster CRD，以概述子系統元件的條件式狀態報告，提供即時解答和更為精細的指引，從而協助您調查問題。若要瞭解如何設定此功能，請造訪說明文件頁面。
-
針對每個 Tanzu Kubernetes 叢集設定 HTTP Proxy 組態。您現在可以針對每個 Tanzu Kubernetes 叢集定義 HTTP/HTTPS Proxy 組態，或者，透過預設組態在主管叢集範圍內進行定義。如需設定此新功能的相關資訊，請參閱說明文件頁面。
-
支援 Tanzu Kubernetes Grid 延伸。Tanzu Kubernetes Grid Service 現在完全支援叢集內延伸，包括 Fluent Bit、Contour、Prometheus、AlertManager 和 Grafana。
-
Tanzu Kubernetes 叢集的更新考慮事項
vSphere 7.0 Update 2 版本包括在更新 vCenter Server 時自動升級主管叢集的功能。如果在升級至 vCenter Server 7.0 Update 2 之前環境中已佈建 Tanzu Kubernetes 叢集，請閱讀知識庫文章 82592。本文提供有關執行預先檢查的指引，以確定在主管叢集自動升級後是否會有任何 Tanzu Kubernetes 叢集變得不相容。
已解決的問題
-
內嵌式容器登錄 SSL 憑證未複製到 Tanzu Kubernetes 叢集節點
-
當內嵌式容器登錄已針對主管叢集啟用時，Harbor SSL 憑證不會包含在於該 SC 上建立的任何 Tanzu Kubernetes 叢集節點中，且您也無法從這些節點連線到登錄。
-
-
從 Tanzu Kubernetes Grid 1.16.8 升級至 1.17.4 後，其中一個控制平面節點上的「guest-cluster-auth-svc」網繭會停滯在「正在建立容器」狀態
-
將 Tanzu Kubernetes 叢集從 Tanzu Kubernetes Grid 服務 1.16.8 更新至 1.17.4 後，其中一個叢集控制平面節點上的「guest-cluster-auth-svc」網繭會停滯在「正在建立容器」狀態。
-
-
在執行叢集更新期間或之後，使用者無法管理 Tanzu Kubernetes 叢集中的現有網繭
-
在執行叢集更新期間或之後，使用者無法管理 Tanzu Kubernetes 叢集中的現有網繭。
-
-
Tanzu Kubernetes 叢集升級工作失敗，並顯示「等待 etcd 健全狀況檢查通過時發生逾時。」
-
與 Tanzu Kubernetes 叢集升級相關聯的 vmware-system-tkg 命名空間中的升級工作失敗，並顯示下列錯誤訊息「等待 etcd 健全狀況檢查通過時逾時。」此問題是由於遺失 etcd 網繭的 PodIP 位址所致。
-
-
目前 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。請參閱說明文件中關於如何執行此動作的主題。
-
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 Service 功能。
-
已解決的問題
-
新的 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 會顯示一般狀態和故障條件，以簡化疑難排解。
-
已解決的問題
-
缺少 vCenter Server 7.0 Update 1 中引入的新預設虛擬機器類別
-
升級至 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 與 Antrea for Kubernetes。我們已整合商業支援的版本 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 |
- 新功能
- 已解決的問題
- 2020 年 7 月 30 日的最新內容
- 2020 年 6 月 23 日的最新內容
- 2020 年 5 月 19 日的最新內容
- 初始 vSphere with Kubernetes 版本的組建編號資訊
新功能
-
無，這只是一個錯誤修正版本。
已解決的問題
-
升級到 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 Service 叢集強制執行入口防火牆規則
-
新版本的 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 Service 叢集失敗的問題
-
-
主管叢集升級失敗
-
我們已解決在內嵌式 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 開放原始碼元件的位置。
已解決的問題
-
在 vCenter 升級至 vCenter Server 7.0 Update 2c 後，[命名空間摘要] 頁面上的 [虛擬機器服務] 卡消失
將 vCenter 從 vCenter Server 7.0 Update 2a 升級至 vCenter Server 7.0 Update 2c 後，升級前建立的既存命名空間不會在 [命名空間摘要] 視圖下顯示 [虛擬機器類別] 和 [內容程式庫] 卡。此情況特定於 vCenter Server 7.0 Update 2a 來源，不應影響從舊版 (例如 vCenter Server 7.0 Update 2) 進行升級
對於受影響的命名空間，升級主管叢集應還原 [命名空間摘要] 視圖上的卡
-
由於虛擬機器硬體版本不相容，使用虛擬機器服務建立之虛擬機器上的某些作業可能會失敗
如果 OVF 映像的虛擬機器硬體版本不支援此作業，虛擬機器上的作業將會失敗。例如，對於虛擬硬體版本為 vmx-11 的映像，連結持續性磁碟區將會失敗，並出現下列錯誤：
Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed因應措施：無
-
在主管叢集升級期間，如果使用了精靈集，則可能會建立額外的 vSphere 網繭並停滯在擱置狀態
在主管叢集升級期間，精靈集控制器會為每個主管控制平面節點建立額外的 vSphere 網繭。這是由於上游 Kubernetes 問題所致。
因應措施：將 NodeSelector/NodeAffinity 新增至 vSphere 網繭規格，以便精靈集控制器可以略過用於建立網繭的控制平面節點。
-
網繭建立間歇性失敗：
某些環境已報告網繭建立間歇性失敗，並顯示下列錯誤「無法取得映像」。連線逾時，並顯示「無任何到主機的路由」錯誤。這是由於映像擷取程式請求期間逾時值預設為 3 秒所致。
請連絡 GSS 以增加預設逾時值。
-
如果 VC 具有大量已中斷連線的主機，主管服務可能會當機：
在許多主機因使用者名稱和密碼錯誤而中斷連線的環境中，主管服務可能會當機，且無法再次啟動。
已在最新版本中修正此問題。
-
在 vCenter Server 7.0 Update 3 上設定具有 NSX-T Data Center 的主管叢集可能會失敗
設定具有 NSX-T Data Center 的主管叢集可能無法在 ESXi 主機上安裝 spherelet VIB，並顯示下列錯誤：
Could not find a trusted signer: self signed certificate自我簽署的 Spherelet VIB 與 vCenter Server 7.0 Update 3 搭配。但是，如果您在屬於 vSphere 叢集的 ESXi 主機上未啟用安全開機，或主機未在叢集上啟用 vSphere Lifecycle Manager (vLCM)，則主管叢集啟用作業將會成功。現已在最新版本中修正此問題。
-
vCenter 升級至 70u3f 失敗，因為 WCP 服務未啟動
請參閱知識庫文章 89010
可對處於失敗狀態的 vCenter Server 7.0u3f 本身套用此因應措施，也可以對開始升級至 7.0u3f 之前的 vCenter Server 7.0u3d 套用。
1.使用根認證連線至 vCenter Server SSH 工作階段。
2.使用下列命令連線至 WCP 資料庫：
PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost
3.執行下列命令以檢查 instance_id 為 Null 的項目：
SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;
4.將 cluster_db_configs 中值為 Null 的 instance_id 更新為隨機 UUID：
UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;
5.修正資料庫項目後，必須重新啟動 WCP 服務 (以及升級後未啟動的任何其他服務)。
service-control --status --all
service-control --restart --all (--stop 或 --start)
或
service-control --restart wcp (--stop 或 --start)
6.重新執行步驟 2 和 3，以確認 instance_id 不是 NULL。現在 vCenter Server 必須已啟動且正在執行。
7.在此階段，如果使用者對 vCenter Server 70u3d 套用此因應措施，則繼續升級至 vCenter Server 70u3f；或者，如果使用者對 vCenter Server 70u3f 套用此因應措施，請造訪 VMware 應用裝置管理介面 (VAMI) 或 CLI 安裝程式，然後繼續升級。
-
升級後，安全性原則功能可能無法使用
如果 NSX-T 3.1.x/3.0.x 存在，且先升級 vCenter，隨後升級主管，最後將 NSX-T 升級至 3.2 或更高版本，則 SecurityPolicy 功能可能無法使用，因為 NCP 無法感知 NSX-T 升級。
-
啟用 LRO 後，改善了使用 Antrea-ENCAP 的 Tanzu Kubernetes Grid 叢集虛擬機器上的網路輸送量效能
新增了資料路徑最佳化，透過啟用 LRO，針對使用 Antrea-ENCAP 的 Tanzu Kubernetes Grid 叢集改善網路輸送量效能。
無
-
在主管上啟用內嵌式 Harbor 登錄可能會導致預設組態不安全
如果您已完成「在主管叢集上啟用內嵌式 Harbor 登錄」中所述的步驟，則內嵌式 Harbor 登錄上可能存在不安全的預設組態。如需有關此事宜的進一步資訊，請參閱 VMware 知識庫文章 91452。
因應措施：此問題可藉由安裝此版本或實作知識庫 91452 中所述的暫行因應措施加以解決。
已知問題
主管叢集
-
<span style="color:#FF0000">新增：</span>從共用資料存放區 (例如 vSAN) 刪除多個 FCD 和磁碟區時，您可能會發現效能發生變更
效能變更可能是由已修正問題所造成。取消修正後，此問題會導致失效的 FCD 和磁碟區在 FCD 刪除作業失敗後仍保留在資料存放區中。
因應措施：無。儘管效能有所變更，刪除作業仍如常運作。
-
將已中斷連線的 ESXi 節點移出叢集，但其仍保留在同一資料中心下時，在節點上執行的網繭和 PVC 仍保持 [正在終止] 狀態
如果 ESXi 主機因 PSOD 而處於 [無回應] 狀態，並且您將此主機移出叢集，但其仍位於同一資料中心下，則主機上執行的網繭和 PVC 會停滯在 [正在終止] 狀態。即使叢集中有備用節點可用，仍會發生此問題。
出現以下情況時，通常會發生此問題：
-
在主管叢集上啟用合作夥伴服務，並建立服務的執行個體。
-
服務執行個體執行所在的 ESXi 節點出現 PSOD。
-
中斷無回應主機的連線，並將該主機移出叢集，但其仍位於同一資料中心下。
當主機移出叢集時，您會發現節點上存在的網繭和 PVC 仍保持 [正在終止] 狀態。
因應措施：將主機從詳細目錄中移除，而不是將其移出叢集，但仍位於同一資料中心下。
-
-
當 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-class或kubectl get storage-class命令時，該命令會傳回所有儲存區類別，而不只是用於主管命名空間的儲存區類別。因應措施：從配額的詳細名稱推斷與命名空間相關聯的儲存區類別名稱。
-
即使 FQDN 已設定，共用 Kubernetes API 端點按鈕仍會忽略 FQDN
即使已針對主管叢集命名空間的 Kubernetes 控制平面 IP 設定 FQDN，共用命名空間按鈕仍會提供 IP 位址而非 FQDN。
因應措施：手動與 FQDN 共用主管叢集命名空間。
-
無法透過 kubectl vSphere 登入資訊存取負載平衡器
使用負載平衡端點時，您無法透過 kubectl vSphere 登入資訊存取 API 伺服器。
因應措施：此問題會表現在兩個方面。
-
檢查 API 伺服器是否可以透過控制平面 <curl -k https://vip:6443 (或 443)> 進行存取
-
如果無法從 API 伺服器存取負載平衡器，則表示 API 伺服器尚未啟動。
-
因應措施：請等待幾分鐘，以使 API 伺服器變為可存取。
-
-
檢查 Edge 虛擬機器節點的狀態是否為 [啟動]。
-
登入 NSX Manager。
-
移至系統 > 網狀架構 > 節點 > Edge 傳輸節點。節點狀態應為 [開啟]。
-
移至網路 > 負載平衡器 > 虛擬伺服器。尋找以 kube-apiserver-lb-svc-6443 和 kube-apiserver-lb-svc-443 結尾的 vip。如果其狀態不是 [開啟]，則使用以下因應措施。
-
因應措施：將 Edge 虛擬機器重新開機。Edge 虛擬機器應在重新開機後進行重新設定。
-
-
-
在設定期間，vSphere with Tanzu 的叢集組態顯示逾時錯誤
在叢集設定期間，您可能會看到下列錯誤訊息：
Api request to param0 failed或
Config operation for param0 node VM timed out因應措施：無。啟用 vSphere with Tanzu 可能需要 30 到 60 分鐘。當您看到這些或類似的
param0逾時訊息時，它們不屬於錯誤，可放心忽略。 -
在 vSphere with Tanzu 中停用 vSphere 服務並立即重新啟用會導致 vCenter Server 中對應的命名空間沒有回應。
將 vSphere 服務停用並立即重新啟用時，主管叢集中的命名空間會遭到刪除並重新建立。但是，vCenter Server 中對應的命名空間仍會處於「正在終止」狀態。因此，資源配額無法指派給 vCenter Server 中的命名空間，且 DevOps 工程師無法在命名空間上建立網繭和 PVC 等資源。此外，由於服務營運人員網繭無法執行，使用者介面外掛程式部署會失敗。
您可以在主管叢集上執行下列命令以取得應用程式平台記錄：kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0。
因應措施：
重新啟用服務之前，請等待從 vCenter Server 完全刪除命名空間。
如果命名空間停滯在 [正在終止] 狀態，請執行下列步驟：
1.再次停用服務。
2.在 vCenter Server 中重新啟動 wcp 服務。
3.等待刪除資源。此步驟可能需要一些時間。
4.重新啟用服務。
-
啟用容器登錄失敗，並顯示錯誤
當使用者從使用者介面啟用容器登錄時，啟用動作會在 10 分鐘後失敗，並顯示逾時錯誤。
因應措施：停用容器登錄，然後重試啟用。請注意，可能會再次出現逾時錯誤。
-
將叢集停用後再啟用會失敗並顯示錯誤
將叢集停用後再立即啟用，可能會在服務帳戶密碼重設程序中造成衝突。啟用動作失敗，並顯示錯誤。
因應措施：使用命令
vmon-cli --restart wcp重新啟動。 -
刪除內嵌式容器登錄中的容器映像標籤可能會刪除共用相同實體容器映像的所有映像標籤
可以將具有不同標籤的多個映像從相同的容器映像推送至內嵌式容器登錄中的專案。如果專案上的其中一個映像已刪除，則會刪除從相同映像推送的具有不同標籤的所有其他映像。
因應措施：此作業無法復原。再次將映像推送至專案。
-
對登錄專案執行清除作業失敗會導致專案處於「錯誤」狀態
當您在登錄專案上執行清除作業時，此專案會暫時顯示為處於錯誤狀態。您將無法從此類專案推送或提取映像。系統會定期檢查專案，刪除並重新建立處於錯誤狀態的所有專案。發生此情況時，所有先前的專案成員將被新增回重新建立的專案，並將刪除先前存在於專案中的所有存放庫和映像，從而有效地完成清除作業。
因應措施：無。
-
當儲存區容量少於 2000 MiB 時，容器登錄啟用會失敗
容器登錄有最低儲存區容量要求，此要求在 VMODL 中以「限制」欄位表示。這是因為某些 Kubernetes 網繭需要足夠的儲存空間才能正常運作。若要實現容器功能，需至少有 5 GB 的容量。請注意，此限制無法保證可以改善效能或增加可支援的映像數目或大小。
因應措施：部署具有較大總容量的容器登錄可避免此問題。建議儲存磁碟區不小於 5 GB。
-
如果您取代 Kubernetes 叢集的 NSX 負載平衡器的 TLS 憑證，可能無法從 docker 用戶端或 Harbor 使用者介面登入內嵌式 Harbor 登錄
若要取代 Kubernetes 叢集的 NSX 負載平衡器的 TLS 憑證，請從 vSphere 使用者介面導覽至設定 > 命名空間 > 憑證 > NSX 負載平衡器 > 動作，然後按一下取代憑證。當您取代 NSX 憑證時，從 docker 用戶端或 Harbor 使用者介面登入內嵌式 Harbor 登錄的作業可能會失敗，並顯示
unauthorized: authentication required或Invalid user name or password錯誤。因應措施：在
vmware-system-registry命名空間中重新啟動登錄代理程式網繭：-
執行
kubectl get pod -n vmware-system-registry命令。 -
執行
kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry命令以刪除網繭輸出。 -
等待網繭重新啟動。
-
-
使用 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 的瀏覽器快取。
-
大型 vSphere 環境可能需要很長時間才能在雲端上使用 VMware NSX Advanced Load Balancer 控制器進行同步
如果 vSphere 環境的詳細目錄中包含超過 2,000 台 ESXi 主機和 45,000 個虛擬機器，可能需要長達 2 個小時才能在雲端上使用 NSX Advanced Load Balancer 控制器進行同步。
因應措施：無
-
在 vCenter Server 7.0 Update 2 上變更 VMware Certificate Authority (VMCA) 根憑證後，主管叢集的私人容器登錄可能會狀況不良
在 vCenter Server 7.0 Update 2 系統上變更 VMware Certificate Authority (VMCA) 根憑證後，主管叢集的私人容器登錄可能會狀況不良，並且登錄作業可能會如預期停止運作。針對容器登錄的下列健全狀況狀態訊息會顯示在叢集組態使用者介面上：
Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority因應措施：
在 vSphere kubernetes 叢集上的 vmware-system-registry 命名空間中，手動重新啟動登錄代理程式網繭：
-
執行
kubectl get pod -n vmware-system-registry命令以取得登錄代理程式網繭。 -
執行
kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry命令以刪除網繭輸出。 -
等待網繭重新啟動。
-
在叢集組態使用者介面上重新整理映像登錄，且不久後，健全狀況狀態應顯示為執行中。
-
-
主管叢集上新建立命名空間的專案不會自動在私人容器登錄上建立
可能不會自動在私人容器登錄上針對主管叢集上新建立的命名空間建立專案。容器登錄的狀態仍顯示為狀況良好，但在建立新命名空間時，不會在叢集的容器登錄上顯示任何專案。您無法將映像推送或提取至容器登錄上新命名空間的專案。
因應措施：
-
執行 kubectl get pod -n vmware-system-registry 命令以取得登錄代理程式網繭。
-
執行 kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry 命令以刪除網繭輸出。
-
等待網繭重新啟動。
-
登入私人容器登錄，以確認是否為叢集上的命名空間建立了專案。
-
-
在建立具有 10 個複本的網繭時可能會出現 ErrImgPull
在 YAML 中嘗試使用具有 10 個複本網繭的部署時，可能會發生此問題。嘗試使用私人容器登錄在此 YAML 中建立時，在 10 個複本中，至少有 7 個複本可能通過，而 3 個複本可能會失敗，並出現「ErrImgPull」問題。
因應措施：使用較少的複本集 (最多 5 個)。
-
使用自訂連接埠部署 vCenter Server 時，不支援 NSX Advanced Load Balancer 控制器
您無法向 NSX Advanced Load Balancer 控制器登錄 vCenter Server，因為沒有選項可供登錄時在 NSX Advanced Load Balancer 控制器使用者介面中提供自訂 vCenter Server 連接埠。
只有在使用預設連接埠 80 和 443 部署 vCenter Server 時，NSX Advanced Load Balancer 控制器才能運作。
-
在已包含執行中主管叢集的 vCenter Server 上執行網域重新指向時，主管叢集將進入 [正在設定] 狀態
具有主管叢集的 vCenter Server 不支援網域重新指向。嘗試執行網域重新指向時，現有主管叢集將進入 [正在設定] 狀態，並且控制平面虛擬機器和 Tanzu Kubernetes 叢集虛擬機器將停止出現在 [主機和叢集] 視圖下的詳細目錄中。
因應措施：無
-
指派標籤和自訂屬性對於在主管叢集中使用 Kubernetes 所建立之虛擬機器不起作用
當您嘗試透過 vSphere 使用者介面用戶端或使用 vAPI，將標籤或自訂屬性指派給在主管叢集中建立之虛擬機器時，作業會失敗，並出現「連結標籤時發生錯誤」訊息。
因應措施：無
-
具有自助服務命名空間權限的開發人員無法存取叢集範圍的資源，例如儲存區類別
當開發人員嘗試使用
kubectl命令列出叢集範圍的儲存區類別時kubectl get storageclass -n test-ns or kubectl get storageclass他們遇到下列錯誤。
Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope因應措施：這是預期的行為，因為開發人員只能存取指派給其存取的命名空間範本的儲存區類別。這是由 vSphere 管理員預先決定的。
使用下列命令將列出與命名空間相關聯的儲存區類別。
kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE> -
使用「kubectl apply -f」對命名空間進行自助服務失敗
嘗試將資訊清單與
kubectl apply -f搭配使用建立命名空間，並顯示錯誤Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope因應措施：開發人員可以改為使用
kubectl create -f命令來建立命名空間。 -
在自助服務命名空間中建立 vSphere 網繭會間歇性失敗
嘗試在使用自助服務命名空間範本建立的命名空間中建立 vSphere 網繭時，您可能會遇到錯誤「無法建立資源網繭」。
因應措施：在命名空間建立後等待幾秒，再在命名空間中建立 vSphere 網繭。
-
開發人員無法新增標籤和註解至使用自助服務命名空間範本建立的命名空間
嘗試在資訊清單中指定用於使用命令
kubectl apply -f建立或修改命名空間的標籤和註解會失敗，並出現錯誤Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""因應措施：將所需的標籤和註解新增至命名空間資訊清單，並改用
kubectl create -f新增標籤和註解。 -
除非執行主管叢集升級，否則無法使用命名空間範本
啟動主管叢集升級時，與命名空間範本相關的任何工作 (例如啟用、停用或更新) 會保留在佇列中，直到升級完成。
因應措施：請等待升級作業完成，然後再執行命令以操縱命名空間範本
-
嘗試將持續性磁碟區連結至 Tanzu Kubernetes 叢集上的網繭失敗，並顯示「CNS: 由於遺失 SCSI 控制器，無法連結磁碟」錯誤訊息
嘗試將持續性磁碟區連結至 Tanzu Kubernetes 叢集上的網繭時，嘗試失敗，網繭仍然處於擱置狀態。錯誤訊息指示 SCSI 控制器遺失，即使 worker 節點虛擬機器已設定 PVSCSI 控制器。
當 worker 節點虛擬機器達到其 60 個磁碟區的區塊磁碟區限值時，可能會發生此問題。但是，Kubernetes 會忽略 vSphere 磁碟區限值，並排程在該節點上建立區塊磁碟區。
因應措施：將 worker 節點新增到此叢集。刪除網繭，以將其部署排程至新的 worker 節點。
-
在非作用中 vCenter Server 工作階段後刪除可設定狀態的網繭並嘗試稍後在 Tanzu Kubernetes 叢集中重複使用或刪除其磁碟區，可能會導致失敗和無法預期的行為
如果在可設定狀態的網繭處於非作用中狀態大約一天後將其刪除，其磁碟區似乎已成功與 Tanzu Kubernetes 叢集的節點虛擬機器中斷連結。不過，當您嘗試使用該磁碟區建立新的可設定狀態的網繭或刪除磁碟區時，嘗試失敗，因為該磁碟區仍連結至 vCenter Server 中的節點虛擬機器。
因應措施：使用 CNS API 將磁碟區與節點虛擬機器中斷連結，以同步磁碟區在 Tanzu Kubernetes 叢集和 vCenter Server 中的狀態。此外，請重新啟動主管叢集中的 CSI 控制器，以更新非作用中工作階段。
-
由於主管叢集的主要工作負載網路 (如果使用 vSphere 網路) /NCP 叢集網路網繭 CIDR (如果使用 NSX-T Container Plugin) 上的 IP 範圍耗盡，主管叢集升級已停滯/未完成。
主管叢集升級停滯在擱置狀態，並顯示訊息：「命名空間叢集升級正在佈建新的主要步驟」。
在叢集升級期間部署的新控制平面虛擬機器僅收到一個網路介面。控制平面虛擬機器應具有 2 個網路介面，一個連線至管理網路，另一個連線至工作負載網路。
應部署至新的控制平面虛擬機器的某些系統網繭 (例如 coredns) 可能會停滯在擱置狀態。
因應措施：刪除少量工作負載 (虛擬機器、網繭虛擬機器、TKG 叢集)，以釋放足夠的 IP 供升級程序完成。應至少釋放 3 個 IP。
-
更新主管服務組態的索引鍵值配對或登錄認證
您可能想要變更主管服務的組態登錄索引鍵-值配對，因為您輸入的登入認證不正確，或登錄密碼可能已到期。
因應措施：
1.在主管叢集上建立新的密碼資源。
kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=2.更新主管服務資源的服務參考。
# kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services3.更新 spec.config 工作階段：
spec:config:secretNamespace: vmware-system-supervisor-servicessecretRef: new-secret -
Tanzu Kubernetes Grid Service 和主管服務使用者介面外掛程式無法正常運作
如果 vCenter Server 由自訂 CA 憑證簽署並啟用了主管叢集，則部署在 vSphere Client 中的 Tanzu Kubernetes Grid Service 使用者介面外掛程式和任何主管服務使用者介面外掛程式將無法正常運作。使用者介面外掛程式在嘗試與主管叢集中其各自的後端伺服器進行通訊時出現 SSL 驗證問題。Tanzu Kubernetes Grid Service 外掛程式顯示下列錯誤：
The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details因應措施：將信任根憑證新增至 /etc/ssl/certs 內的單獨檔案中 (而不是
vmca.pem中)，並使用c_rehash重新產生雜湊。必須在所有三個控制平面虛擬機器上執行此動作。請注意，不建議編輯 /etc/ssl/certs/vmca.pem，因為在每次叢集同步期間，更新控制器都會覆寫此檔案的內容。
請考慮，如果重新部署主管叢集中的其中一個控制平面虛擬機器 (例如，調整控制平面虛擬機器的大小後或由於修復作業)，則手動新增至
/etc/ssl/certs的憑證將會遺失，並且必須對該虛擬機器重新套用因應措施。 -
主管叢集當機且處於正在設定狀態
將 vSphere 叢集設定為主管叢集後，叢集當機且處於正在設定狀態。您無法建立 vSphere 網繭和 Tanzu Kubernetes 叢集。
因應措施：使用下列命令重新啟動 wcp 服務：
vmon-cli restart wcp請查看說明文件以取得更詳細的指示。
-
即使相關聯的內容程式庫已填入虛擬機器映像，「kubectl get virtualmachineimages」也不會傳回任何結果
如果虛擬機器服務所使用的內容程式庫已啟用安全性原則，則虛擬機器服務將無法讀取映像，且無法使用此內容程式庫中的映像部署虛擬機器。
因應措施：將具有安全性原則的內容程式庫與主管命名空間解除關聯。從相關內容程式庫移除「預設 OVF 安全性原則」設定，然後將內容程式庫與命名空間重新關聯。
-
對於具有 vGPU 的虛擬機器以及由虛擬機器服務管理的傳遞裝置，當其主機進入維護模式時，開發人員將看到錯誤的 POWERSTATE。
當主機進入維護模式時，DRS 會自動將具有 vGPU 的虛擬機器以及由虛擬機器服務管理的傳遞裝置關閉電源。但是，kubectl get vm 的輸出會顯示先前的電源狀態和虛擬機器。這會導致顯示 POWERSTATE=poweredOn，即使該虛擬機器在 vCenter 上已關閉電源也是如此。
無。
-
在設定 NSX-T 的主管叢集上，ESXi 主機可能會繼續使用自我簽署的 Spherelet VIB
如果您已使用 vCenter Server 7.0 Update 3 中提供的 Kubernetes 版本設定或升級主管叢集，並且已進一步將主管叢集的 Kubernetes 版本升級至 vCenter Server 7.0 Update 3a 中提供的版本，則 ESXi 主機可能會繼續使用自我簽署的 Spherelet VIB。發生此情況的原因是，安裝在 vCenter Server 7.0 Update 3 和 vCenter Server 7.0 Update 3a 上的自我簽署 Spherelet VIB 版本相同。此問題不適用於設定了 vSphere 網路堆疊的主管叢集。
因應措施 1：
如果 vSphere 叢集不以 vSphere Lifecycle Manager 為基礎，請執行下列步驟以安裝 VMware 認證的 Spherelet VIB：
-
將 ESXi 主機置於維護模式，並等待主管叢集將其標記為「未就緒」。
-
將該主機作為獨立主機移出叢集，並等待解除安裝 spherelet 和 NSX-T VIB。
-
將同一主機移回叢集，結束維護模式並等待重新設定新的 spherelet 和 NSX-T VIB。
-
針對叢集內的每個 ESXi 主機重複上述步驟。
如果已使用 vSphere Lifecycle Manager 啟用主管叢集，請停用主管叢集，然後再次重新設定。
因應措施 2：
將 vCenter Server 升級至 vCenter Server 7.0 Update 3a 後，請停用主管叢集並將其重新設定。這同時適用於使用 vSphere Lifecycle Manager 啟用的叢集以及以非 vLCM/VUM 為基礎的叢集。
-
-
某些 vSphere 網繭在主機重新開機或主管叢集升級後顯示 NodeAffinity 狀態
將主機重新開機或升級主管叢集後，您可能會看到某些 vSphere 網繭出現 NodeAffinity 狀態。此行為是由於上游 Kubernetes 中的以下問題所導致：Kubernetes 排程器在 kubelet 重新啟動後在叢集中建立狀態為 NodeAffinity 的冗餘網繭。此問題不會影響叢集功能。如需上游 Kubernetes 問題的相關資訊，請參閱 https://github.com/kubernetes/kubernetes/issues/92067。
因應措施：刪除狀態為 NodeAffinity 的冗餘網繭。
-
將環境升級至 7.0 Update 3e 或更新版本後，vSphere with Tanzu 上啟用的 vDPp 服務營運人員和執行個體網繭進入 [擱置中] 狀態
如果主管叢集上安裝的合作夥伴服務版本不支援 Kubernetes 1.22 版，則會發生此問題。將 vSphere with Tanzu 環境升級至符合 1.22 標準的 7.0 Update 3e 版或更新版本後，服務會變得不相容。因此，營運人員和執行個體網繭會進入 [擱置中] 狀態。
嘗試將服務升級至更新版本失敗。
因應措施：將 vDPp 服務升級至與 Kubernetes 1.22 相容的版本，然後再將 vSphere with Tanzu 升級至 7.0 Update 3e。
-
將叢集從 Kubernetes 1.19.1 自動升級至 1.20.8 失敗，無法繼續
在少數情況下，將叢集從 Kubernetes 1.19.1 自動升級至 1.20.8 可能會失敗，並顯示下列錯誤：
找不到升級工作。請再次觸發升級。
因應措施：手動啟動叢集升級。
-
如果已在短時間內重複使用主管命名空間，則對該主管命名空間執行的作業可能會失敗：
如果刪除主管命名空間並在短時間內以相同名稱重新建立，作業可能會因為快取中的無效項目而失敗。
已在最新版本中解決此問題。
-
主管支援服務包包含 VC 支援服務包：
透過產生主管支援服務包，不會自動包含 VC 支援服務包。
已在最新版本中修正。
-
網路支援檢查清單的內容未當地語系化。
在工作負載管理啟用期間，可以下載網路檢查清單工作表。該工作表未套用當地語系化。
已在最新版本中修正。
-
在已擴充的 Tanzu Kubernetes 叢集設定中，發現 WCP 系統網繭 capi-kubeadm-control-plane-controller-manager 存在 OOM 問題
-
安全性原則不會移除更新的規則。
如果建立的安全性原則 CR 包含規則 A 和 B，然後對其更新，則原則會將規則變更為 B 和 C。規則 A 仍會生效。
因應措施：刪除安全性原則並使用更新的規則重新建立
-
當 NSX Advanced Load Balancer 上存在兩個 SE 群組時，不會建立負載平衡器和 Tanzu Kubernetes 叢集。
如果將第二個 SE 群組新增至已指派或未指派 SE 或虛擬服務的 NSX Advanced Load Balancer，則建立新的主管叢集或 Tanzu Kubernetes 叢集會失敗，並且無法升級現有的主管叢集。在 NSX Advanced Load Balancer 控制器上建立虛擬服務失敗，並顯示下列錯誤：
「get() 傳回多個 ServiceEngineGroup – 傳回 2」
因此，新的負載平衡器無法使用，且您無法成功建立新的工作負載叢集。
如需詳細資訊，請參閱 VMware 知識庫文章 90386。
因應措施：應僅將 SEGroup「Default-Group」用於建立虛擬服務，並從 NSX Advanced Load Balancer 中刪除除了 default-group 以外的所有其他 SE 群組，然後重試該作業。
-
更新的安全性原則不會生效。
如果建立了包含規則 A 和 B 的安全性原則 CR，然後對其更新，將規則變更為 B 和 C，則規則 A 仍會生效且不會移除。
因應措施：建立並套用包含規則 B 和 C 的新原則，並刪除包含 A 和 B 的舊原則。
-
命名空間管理 API 有時可能會傳回 HTTP 500 錯誤，無法授權請求
對工作負載管理的請求可能會間歇性失敗。API 將傳回 500 狀態碼，且不會處理任何請求。您將發現一則記錄訊息，指出「授權期間發生非預期的錯誤」。此問題是間歇性的，但在工作負載管理處於負載狀態時更有可能發生，例如主動設定一或多個主管時。
因應措施：發生錯誤時重試您嘗試的作業。
-
主管叢集可能會間歇性地處於 [正在設定] 或 [錯誤] 狀態。
在主管叢集的啟用、升級或其他節點重新部署期間，它可能仍保持 [正在設定] 或 [錯誤] 狀態，並顯示下列錯誤訊息：
"API request to VMware vCenter Server (vpxd) failed.Details 'ServerFaultCode: A general system error occurred: vix error codes = (1, 0)" may become stuck."
可在以下位置找到相關記錄：/var/log/vmware/wcp/wcpsvc.log
刪除與發生此問題的控制平面虛擬機器對應的 vSphere Agent Manager (EAM)，以強制重新部署節點。
-
成功刪除 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。
網路
-
在速度較慢的網路上部署 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. Please use a VLAN ID between 1-4094因應措施：使用下列其中一個程序手動啟用 VLAN 0 支援：
1.透過 SSH 進入已部署的 VC (root/vmware)。
2.開啟 /etc/vmware/wcp/nsxdsvc.yaml。將會有類似如下的內容：
logging: level: debug maxsizemb: 10a. 若要為 NSX 叢集覆疊網路啟用 VLAN0 支援，請將下列幾行附加到 /etc/vmware/wcp/nsxdsvc.yaml，然後儲存檔案。
experimental: supportedvlan: hostoverlay: min: 0 max: 4094 edgeoverlay: min: 1 max: 4094 edgeuplink: min: 1 max: 4094b. 若要為 NSX Edge 覆疊網路啟用 VLAN0 支援，請將下列幾行附加到 /etc/vmware/wcp/nsxdsvc.yaml，然後儲存檔案。
experimental: supportedvlan: hostoverlay: min: 1 max: 4094 edgeoverlay: min: 0 max: 4094 edgeuplink: min: 1 max: 4094c. 若要為 NSX Edge 上行網路啟用 VLAN0 支援，請將下列幾行附加到 /etc/vmware/wcp/nsxdsvc.yaml，然後儲存檔案。
experimental: supportedvlan: hostoverlay: min: 1 max: 4094 edgeoverlay: min: 1 max: 4094 edgeuplink: min: 0 max: 40943.使用
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 叢集中建立的服務。
因應措施：無。
-
NSX Advanced Load Balancer 控制器不支援變更 vCenter Server PNID
為主管叢集設定 NSX Advanced Load Balancer 後，便無法變更 vCenter Server PNID。
因應措施：如果您必須變更 vCenter Server 的 PNID，請移除 NSX Advanced Load Balancer 控制器並變更 vCenter Server PNID，然後重新部署並設定具有新 vCenter Server PNID 的 NSX Advanced Load Balancer 控制器。
-
在 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 範圍。
-
如果連結超過 18 個自訂標籤，則客體叢集虛擬網路建立會失敗
如果使用者想要在命名空間下成功建立客體叢集和虛擬機器，則使用者最多可以為命名空間新增 18 個自訂標籤，否則無法在命名空間下成功建立客體叢集的虛擬網路。
從命名空間中移除標籤，使其總數小於或等於 18。NCP 重試機制將重試並建立命名空間，但視間隔而定，最多可能需要 6 小時。
-
針對 WCP 支援透過 Policy API 建立的傳輸區域：
如果已透過 Policy API 建立 NSX 傳輸區域，則主管啟用可能會失敗。現在支援透過 Policy API 建立 NSX 傳輸區域，同時與使用 MP API 建立的 NSX 傳輸區域保持回溯相容性。
已在最新版本中修正。
-
無法將 NSX Advanced Load Balancer 與使用內嵌式連結模式拓撲的 vCenter Server 搭配使用。
設定 NSX Advanced Load Balancer 控制器時，可在多個雲端上進行設定。但是，在啟用 vSphere with Tanzu 時，您無法選取多個雲端，因為它僅支援 Default-Cloud選項。因此，無法將 NSX Advanced Load Balancer 與使用內嵌式連結模式拓撲的 vCenter Server 版本搭配使用。
為每個 vCenter Server 設定 NSX 負載平衡器。
儲存區
-
<span style="color:#FF0000">新增：</span>嘗試在 vSAN Direct 資料存放區上執行「移除磁碟」作業失敗，並顯示 [VimFault - 無法完成作業] 錯誤
一般情況下，當出現下列其中一種情況時，您可以觀察到此錯誤：
-
作為移除磁碟作業的一部分，放置在 vSAN Direct 資料存放區上的所有持續性磁碟區都會重新放置到相同 ESXi 主機上的另一個 vSAN Direct 資料存放區。如果目標 vSAN Direct 資料存放區上沒有可用空間，則重新放置可能會失敗。若要避免此作業失敗，請確保目標 vSAN Direct 資料存放區有足夠的儲存空間用於執行應用程式。
-
當 ESXi 主機上的目標 vSAN Direct 資料存放區具有足夠的儲存空間時，移除磁碟作業也可能會失敗。當由移除磁碟父系作業產生的基礎持續性磁碟區重新放置作業因磁碟區較大而花費超過 30 分鐘時，可能會發生此問題。在此情況下，您可以觀察到基礎 vSphere 網繭的重新設定在工作視圖中仍保持進行中。
進行中狀態表示，即使移除磁碟作業逾時並失敗，透過重新設定 vSphere 網繭完成的基礎持續性磁碟區重新放置也不會中斷。
因應措施：
vSphere 網繭的重新設定工作完成後，再次執行移除磁碟作業。移除磁碟作業成功繼續。
-
-
在離線或線上模式下擴充主管叢集 PVC 不會導致擴充對應的 Tanzu Kubernetes 叢集 PVC
由於檔案系統尚未調整大小，使用 Tanzu Kubernetes 叢集 PVC 的網繭無法使用主管叢集 PVC 的擴充容量。
因應措施：將 Tanzu Kubernetes 叢集 PVC 的大小調整為等於或大於主管叢集 PVC 的大小。
-
與基礎磁碟區比較，靜態佈建 TKG PVC 中的大小不符
Kubernetes 中的靜態佈建不會驗證 PV 與支援磁碟區大小是否相等。如果您在 Tanzu Kubernetes 叢集中靜態建立 PVC，並且 PVC 大小小於基礎對應主管叢集 PVC 的大小，則您可能可以使用比 PV 中所需空間更大的空間。如果您在 Tanzu Kubernetes 叢集中靜態建立之 PVC 的大小大於基礎主管叢集 PVC 的大小，您可能會注意到
No space left on device錯誤，即使在 Tanzu Kubernetes 叢集 PV 中用盡所需大小之前也是如此。因應措施：
-
在 Tanzu Kubernetes 叢集 PV 中，將
persistentVolumeReclaimPolicy變更為Retain。 -
記下 Tanzu Kubernetes 叢集 PV 的
volumeHandle，然後刪除 Tanzu Kubernetes 叢集中的 PVC 和 PV。 -
使用 volumeHandle 以靜態方式重新建立 Tanzu Kubernetes 叢集 PVC 和 PV，並且將儲存區設定為與對應主管叢集 PVC 的大小相同的大小。
-
-
如果外部 csi.vsphere.vmware.com 佈建程式失去其領導選舉租用，則嘗試從主管命名空間或 TKG 叢集建立 PVC 會失敗
嘗試使用
kubectl命令從主管命名空間或 TKG 叢集建立 PVC 可能會失敗。PVC 保持 [擱置] 狀態。如果您描述 PVC，則 [事件] 欄位會在資料表配置中顯示下列資訊：-
類型 –
Normal -
原因 –
ExternalProvisioning -
存留期 –
56s (x121 over 30m) -
來源 –
persistentvolume-controller -
訊息 –
waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator
因應措施：
-
確認
vmware-system-csi命名空間內vsphere-csi-controller網繭中的所有容器均在執行中。kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi -
使用下列命令檢查外部佈建程式記錄。
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 exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading -
刪除此 vsphere-csi-controller 執行個體。
kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi
Kubernetes 將建立新的 CSI 控制器執行個體，所有 sidecar 都將重新初始化。
-
-
所有 PVC 作業 (例如，建立、連結、中斷連結或刪除磁碟區) 會失敗，同時 CSI 無法連線至 vCenter Server
除了作業失敗之外，而且無法在主管叢集中更新磁碟區健全狀況資訊和儲存區集區 CR。CSI 和 Syncer 記錄將顯示有關無法連線至 vCenter Server 的錯誤。
CSI 會以特定解決方案使用者身分連線至 vCenter Server。此 SSO 使用者的密碼每 24 小時由 wcpsvc 輪替一次，且新密碼將傳輸到 CSI 驅動程式讀取的 [密碼] 中以連線至 vCenter Server。如果新密碼無法傳送至 [密碼]，則失效密碼會保留在主管叢集中，且 CSI 驅動程式的作業會失敗。
此問題會影響 vSAN 資料持續性平台和所有 CSI 磁碟區作業。
因應措施：
通常，WCP 服務會將更新的密碼傳送至 Kubernetes 叢集中執行的 CSI。有時，由於出現問題 (例如連線問題或同步程序早期部分的錯誤)，不會傳送密碼。CSI 會繼續使用舊密碼，並最終因驗證失敗次數過多而鎖定帳戶。
確保 WCP 叢集狀況良好且處於 [正在執行] 狀態。不應在 [工作負載管理] 頁面上報告該叢集的錯誤。解決導致同步失敗的問題後，強制重新整理密碼以解除鎖定已鎖定的帳戶。
強制重設密碼：
-
停止 wcpsvc：
vmon-cli -k wcp -
透過將
/etc/vmware/wcp/.storageUser中的第三行變更為 1，將上次密碼輪替的時間編輯為較小值 (例如 1)。 -
啟動 wcpsvc：
vmon-cli -i wcp
wcpsvc 將重設密碼，這會解除鎖定帳戶並將新密碼傳送至叢集。
-
VMware Tanzu Kubernetes Grid Service for vSphere
-
在主管叢集升級後，Tanzu Kubernetes 叢集在狀態為 [正在更新] 時當機
在主管叢集升級時，它可以觸發所有 Tanzu Kubernetes 叢集的輪流更新，以散佈任何新的組態設定。在此程序期間，先前的「執行中」TKC 叢集可能會在「正在更新」階段當機。「執行中」Tanzu Kubernetes 叢集僅表示控制平面可用，但所需的控制平面和 worker 節點可能尚未成功建立。此類 Tanzu Kubernetes 叢集可能無法通過主管叢集升級完成後啟動的輪流更新期間所執行的健全狀況檢查。這會導致 Tanzu Kubernetes 叢集在「正在更新」階段當機，並且可透過查看與 Tanzu Kubernetes 叢集相關聯的
KubeadmControlPlane資源上的事件來進行確認。資源所發出的事件將類似於以下內容：Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked因應措施：無。
-
Tanzu Kubernetes 叢集繼續存取已移除的儲存區原則
當 VI 管理員從 vCenter Server 命名空間刪除儲存區類別時，不會針對已使用該儲存區類別的任何 Tanzu Kubernetes 叢集移除對儲存區類別的存取權。
因應措施：
-
作為 VI 管理員，從 vCenter Server 命名空間刪除儲存區類別後，請建立一個具有相同名稱的新儲存區原則。
-
將現有儲存區原則或剛剛重新建立的儲存區原則重新新增至主管命名空間。使用此儲存區類別的 TanzuKubernetesCluster 執行個體現在應可以完全正常運作。
-
對於每個使用您想要刪除的儲存區類別的 TanzuKubernetesCluster 資源，請使用不同的儲存區類別建立新的 TanzuKubernetesCluster 執行個體，並使用 Velero 將工作負載移轉至新叢集。
-
一旦沒有 TanzuKubernetesCluster 或 PersistentVolume 使用此儲存區類別，就可以放心地將其移除。
-
-
內嵌式容器登錄 SSL 憑證未複製到 Tanzu Kubernetes 叢集節點
當內嵌式容器登錄已針對主管叢集啟用時，Harbor SSL 憑證不會包含在於該 SC 上建立的任何 Tanzu Kubernetes 叢集節點中，且您也無法從這些節點連線到登錄。
因應措施：從主管叢集控制平面複製 SSL 憑證，並將其貼上至 Tanzu Kubernetes 叢集工作節點。
-
虛擬機器映像無法從內容程式庫取得
在內嵌式連結模式設定中設定多個 vCenter Server 執行個體時，使用者介面會允許使用者選取在不同 vCenter Server 執行個體上建立的內容程式庫。選取此類程式庫會導致 DevOps 使用者無法使用虛擬機器映像來佈建 Tanzu Kubernetes 叢集。在此情況下，「kubectl get virtualmachineimages」不會傳回任何結果。
因應措施：當您將內容程式庫與主管叢集建立關聯以取得 Tanzu Kubernetes 叢集虛擬機器映像時，請選擇在主管叢集所在的同一個 vCenter Server 執行個體中建立的程式庫。或者，建立一個本機內容程式庫，該程式庫還支援 Tanzu Kubernetes 叢集的氣隙佈建。
-
您無法佈建新的 Tanzu Kubernetes 叢集或擴充現有叢集，因為內容程式庫訂閱者無法與發佈者同步。
當您為 Tanzu Kubernetes 叢集 OVA 設定已訂閱內容程式庫時，會產生 SSL 憑證，並且系統會提示您透過確認憑證指紋來手動信任憑證。如果在初始程式庫設定之後變更了 SSL 憑證，則必須透過更新指紋來再次信任新憑證。
編輯已訂閱內容程式庫的設定。即使程式庫並未要求變更，這也會起始對訂閱 URL 的探查。探查將會探索到 SSL 憑證不受信任，並提示您信任該憑證。
-
Tanzu Kubernetes 版本 1.16.8 與 vCenter Server 7.0 Update 1 不相容。
Tanzu Kubernetes 版本 1.16.8 與 vCenter Server 7.0 Update 1 不相容。在對 U1 執行 vSphere 命名空間更新之前，您必須將 Tanzu Kubernetes 叢集更新為更新版本。
對 vCenter Server 7.0 Update 1 版本執行 vSphere 命名空間更新之前，請將執行版本 1.16.8 的每個 Tanzu Kubernetes 叢集更新至更高版本。如需詳細資訊，請參閱說明文件中的〈Tanzu Kubernetes 版本清單〉。
-
將工作負載控制平面升級至 vCenter Server 7.0 Update 1 後，新虛擬機器類別大小無法使用。
說明：升級至 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。
-
為 vSphere with Tanzu 網路設定 NSX-T Data Center 時，將「ExternalTrafficPolicy: Local」服務更新為「ExternalTrafficPolicy: Cluster」會導致此服務的 LB IP 在 SV 主節點上不可存取
如果 LoadBalancer 類型的 Kubernetes 服務最初在工作負載叢集中使用
ExternalTrafficPolicy: Local進行建立，而後來更新為ExternalTrafficPolicy: Cluster，則會阻止在主管叢集虛擬機器上存取此服務的 LoadBalancer IP。因應措施：刪除該服務，然後使用
ExternalTrafficPolicy: Cluster重新建立。 -
Tanzu Kubernetes 叢集控制平面節點上的 CPU 使用率較高
Kubernetes 上游專案中存在一個已知問題，即 kube-controller-manager 偶爾會進入迴圈，導致 CPU 使用率較高，這可能會影響 Tanzu Kubernetes 叢集的功能。您可能會注意到，kube-controller-manager 程序耗用的 CPU 數量超過了預期值，並且輸出重複的記錄，指示
failed for updating Node.Spec.PodCIDRs。因應措施：刪除存在此類問題的控制平面節點內的 kube-controller-manager 網繭。網繭將會重新建立，並且該問題不會再現。
-
無法將使用 K8s 1.16 建立的 Tanzu Kubernetes 叢集更新至 1.19
Kubelet 的組態檔在
kubeadm init執行時產生，然後在叢集升級期間進行複寫。在 1.16 時，kubeadm init會產生一個組態檔 (將resolvConf設定為/etc/resolv.conf)，然後透過命令列旗標--resolv-conf指向/run/systemd/resolve/resolv.conf覆寫該組態檔。在 1.17 和 1.18 期間，kubeadm會繼續使用正確的--resolv-conf設定 Kubelet。自 1.19 起，kubeadm不再設定命令列旗標，而是依賴 Kubelet 組態檔。由於在叢集升級期間執行複寫程序，從 1.16 升級的 1.19 叢集將包含一個組態檔，其中resolvConf指向/etc/resolv.conf而非/run/systemd/resolve/resolv.conf。因應措施：將 Tanzu Kubernetes 叢集升級至 1.19 之前，請重新設定 Kubelet 組態檔以指向正確的
resolv.conf。在kube-system命名空間中手動將ConfigMap kubelet-config-1.18複製到kubelet-config-1.19，然後修改新ConfigMap's資料以指向/run/systemd/resolve/resolv.conf中的resolvConf。 -
將服務從「ExternalTrafficPolicy: Local」更新為「ExternalTrafficPolicy: Cluster」後，如果主管叢集網路已設定 NSX-T，則在主管叢集控制平面節點上對此服務的負載平衡器 IP 提出的請求會失敗
如果使用
ExternalTrafficPolicy: Local在 Tanzu Kubernetes 叢集上建立服務，並稍後將該服務更新為ExternalTrafficPolicy: Cluster，則 kube-proxy 會在主管叢集控制平面節點上錯誤地建立 IP 資料表規則，以封鎖以服務負載平衡器 IP 為目的地的流量。例如，如果此服務具有負載平衡器 IP 192.182.40.4，則會在任何一個控制平面節點上建立以下 IP 資料表規則：-A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable因此，導致無法存取此 IP。
因應措施：刪除該服務，然後使用
ExternalTrafficPolicy: Cluster重新建立。 -
在 TkgServiceConfiguration 規格中啟用 HTTP Proxy 和/或信任設定後，所有沒有 Proxy/信任設定的預先存在的叢集會在更新時繼承全域 Proxy/信任設定。
您可以編輯 TkgServiceConfiguration 規格以設定 TKG 服務，包括指定預設 CNI、HTTP Proxy 和信任憑證。您對 TkgServiceConfiguration 規格所做的任何組態變更會全域套用到此服務佈建或更新的任何 Tanzu Kubernetes 叢集。您無法使用每個叢集設定退出全域組態。
例如，如果您編輯 TkgServiceConfiguration 規格並啟用 HTTP Proxy，由此叢集佈建的所有新叢集均會繼承這些 Proxy 設定。此外，所有沒有 Proxy 伺服器的預先存在的叢集會在修改或更新時繼承全域 Proxy 組態。如果設定了支援每個叢集組態的 HTTP/S Proxy，您可以使用其他 Proxy 伺服器來更新叢集規格，但無法移除全域 Proxy 設定。如果已全域設定 HTTP Proxy，則必須使用 HTTP Proxy，或使用其他 Proxy 伺服器覆寫。
因應措施：瞭解 TkgServiceConfiguration 規格會在全域層級套用。如果您不希望所有叢集均使用 HTTP Proxy，請勿在全域層級啟用。請在叢集層級啟用。
-
在具有許多 Tanzu Kubernetes 叢集和虛擬機器的超大型主管叢集部署中，vmop-controller-manager 網繭可能會由於記憶體不足而失敗，導致無法對 Tanzu Kubernetes 叢集進行生命週期管理
在主管叢集中，vmop-controller-manager 網繭負責管理組成 Tanzu Kubernetes 叢集之虛擬機器的生命週期。在具有非常多此類虛擬機器 (每個主管叢集超過 850 個虛擬機器) 的情況下，vmop-controller-manager 網繭會進入 OutOfMemory CrashLoopBackoff 狀態。發生此情況時，Tanzu Kubernetes 叢集的生命週期管理會中斷，直到 vmop-controller-manager 網繭恢復運作。
刪除叢集或縮減叢集，以減少主管叢集中管理的 Tanzu Kubernetes 叢集 worker 節點總數。
-
使用 Tanzu 從 6.5 之前版本的 vSphere 升級至 vSphere 7 可能會擲出錯誤，指出 PhotonOS 類型不受支援。
成功將 vSphere 6 環境升級至 vSphere 7 with Tanzu 後，嘗試部署 Tanzu Kubernetes 叢集會導致出現錯誤訊息，指出 PhotonOS「不受支援」。尤其是：
無法建立或更新 VirtualMachine: 許可 Webhook「default.validating.virtualmachine.vmoperator.vmware.com」已拒絕請求: 在映像 v1.19.7---vmware.1-tkg.1.fc82c41 上 osType vmwarePhoton64Guest 不支援 GuestOS
如果您從 vSphere 6.5 之前的 vSphere 版本 (例如 vSphere 6) 升級至 vSphere 7 with Tanzu，則需要確定 PhotonOS 的預設虛擬機器相容性層級至少設定為「ESXi 6.5 及更新版本」，才能顯示為支援的客體作業系統。為此，請選取已啟用工作負載管理的 vSphere 叢集，並按一下滑鼠右鍵，然後選擇 [編輯預設虛擬機器相容性]。選取「ESXi 6.5 及更新版本」。
-
使用小型虛擬機器佈建 Tanzu Kubernetes 叢集，然後將工作負載部署到該叢集後，worker 節點會進入 [未就緒] 狀態和嘗試重新產生節點的持續迴圈。
說明：在叢集的小型或超小型 worker 節點上，/bin/opm 程序可能會耗用過多的虛擬機器記憶體，進而導致 worker 節點出現記憶體不足錯誤。
因應措施：避免使用 worker 節點的小型或超小型虛擬機器類別，即使是針對暫時開發或測試叢集也是如此。最佳做法是，在任何環境中 worker 節點的最小虛擬機器類別均為中型。如需詳細資訊，請參閱說明文件中的〈預設虛擬機器類別〉。
-
從已訂閱內容程式庫同步 Tanzu Kubernetes 版本失敗，並顯示下列 HTTP 要求錯誤訊息：「無法驗證主機 wp-content.vmware.com 的 SSL 憑證。」
說明：為 Tanzu Kubernetes 叢集 OVA 設定已訂閱內容程式庫時，將為 wp-content.vmware.com 產生 SSL 憑證。系統會提示您透過確認憑證指紋來手動信任憑證。如果在初始程式庫設定之後變更了 SSL 憑證，則必須透過更新指紋來再次信任新憑證。內容程式庫的目前 SSL 憑證將於 2021 年 6 月底到期。訂閱 wp-content.vmware.com 的客戶將看到其內容程式庫同步失敗，需要透過執行因應措施中的步驟來更新指紋。如需其他指引，請參閱相關聯的 VMware 知識庫文章，網址為 https://kb.vmware.com/s/article/85268。
因應措施：使用 vSphere Client 登入 vCenter Server。選取 [已訂閱內容程式庫]，然後按一下編輯設定。即使程式庫並未要求變更，此動作也會起始對訂閱 URL 的探查。探查將會探索到 SSL 憑證不受信任，並提示您信任該憑證。在顯示的動作下拉式功能表中，選取繼續，指紋隨即更新。現在，您可以繼續同步程式庫的內容。
-
TKGS 不支援同時修改虛擬機器類別和節點垂直擴充。
將更新套用至同時涉及虛擬機器類別修改和節點垂直擴充的叢集後，客戶可能會看到失敗情況。
請修改 TKC 組態以僅修改兩個欄位中的一個，然後重新套用變更。
-
症狀：更新叢集規格中的標籤或污點後，發生未預期的叢集輪流更新。
說明：使用 TKGS v1alpah2 API 時，修改一個節點集區的 spec.topology.nodePools[*].labels或 spec.topology.nodePools[*].taints 將觸發該節點集區的輪流更新。
因應措施：無
-
症狀：叢集更新後，手動新增至節點集區的污點和標籤將不再存在。
說明：使用 TKGS v1alpha2 API 時，在叢集更新期間，系統不會保留在更新之前手動新增且存在的 spec.topology.nodePools[*].taints 和 spec.topology.nodePools[*].labels。
因應措施：更新完成後，手動重新新增標籤和污點欄位。
-
症狀：Tanzu Kubernetes 叢集停滯在正在建立階段，因為其中一個控制平面虛擬機器未取得 IP 位址。
說明：Tanzu Kubernetes 叢集停滯在正在建立階段，因為其中一個控制平面虛擬機器未取得 IP 位址。
因應措施：使用 Tanzu Kubernetes 1.20.7 版或更新版本可避免此問題。
-
症狀：在建立 Tanzu Kubernetes 叢集期間，程序停滯在正在更新狀態，原因為「WaitingForNetworkAddress」。
說明：控制平面虛擬機器和 worker 節點已開啟電源，但未獲指派 IP。這可能是由於 vmware-tools 記憶體不足且未重新啟動所致。
因應措施：已在 Tanzu Kubernetes v1.20.7 版及更新版本中修正此特定問題。此外，還可以透過增加虛擬機器記憶體來修正此問題。best-effort-xsmall 虛擬機器類別僅提供 2G 的記憶體。使用具有更多記憶體的虛擬機器類別來部署 Tanzu Kubernetes 叢集。
-
症狀：自助服務 vSphere 命名空間停滯在「正在移除」狀態。
說明：刪除 vSphere 命名空間後，程序停滯在「正在移除」狀態幾個小時，而沒有任何進度。
因應措施：使用 kubectl 檢查尚未從命名空間刪除的剩餘 Kubernetes 物件。如果有剩餘物件與 kubeadm-control-plane 相關，請重新啟動 capi-kubeadm-control-plane-controller-manager 網繭。此動作應對要刪除的物件重新排入佇列。
附註：這是一項進階作業。請在執行此因應措施之前連絡 VMware 支援。
-
TKC v1alpha2 API 不會阻止使用不相容的 TKr 建立 TKC
從 7.0.3 MP2 版本開始，低於 1.18.x 的 TKr 會不相容，但 TKC API 仍允許建立版本低於 v1.18.x 的 TKC，不會阻止使用不相容的 TKr 建立 TKC 物件。永遠不會建立這些 TKC。
刪除未處於執行中狀態且使用不相容 TKr 建立的 TKC。然後使用相容版本重新建立。
vSAN 資料持續性平台
-
vDPP 使用者介面外掛程式未在 vSphere Client 中部署，並且出現錯誤訊息，指出嘗試從不再存在的主管叢集下載外掛程式
如果在叢集上部署 vDPP 使用者介面外掛程式，然後移除該叢集，則可能會發生此問題。但是，與此 vDPP 使用者介面外掛程式相關的失效項目仍保留在 vCenter Extension Manager 中。如果稍後建立新叢集，則嘗試在此叢集上安裝相同版本的 vDPP 使用者介面外掛程式會失敗，因為 vSphere Client 使用失效項目從不存在的舊叢集中下載外掛程式。
因應措施：
-
使用
https://vc-ip/mob and導覽至 vCenter Extension Manager，然後找到外掛程式延伸。 -
移除包含舊叢集名稱的所有
ClientInfo和ServerInfo項目。 -
從
ClientInfo陣列中，選取版本編號最高的ClientInfo，然後將其類型從vsphere-client-remote-backup變更為vsphere-client-remote。
-
-
主管叢集中的 vSphere 網繭保持擱置狀態且沒有 vm-uuid 註解
有時，網繭可能會長時間保持擱置狀態。使用 vSAN 資料持續性平台 (vDPP) 時，通常會發生此情況，可能由內部錯誤或使用者動作所造成。
使用
kubectl命令查詢網繭執行個體時，中繼資料註解中缺少vmware-system-vm-uuid/vmware-system-vm-moid註解。因應措施：使用
kubectl delete pod pending_pod_name命令刪除網繭。如果網繭是可設定狀態集的一部分，則會自動重新建立網繭。 -
vDPP 服務執行個體在其兩個複本網繭的主機本機 PVC 繫結至同一叢集節點時無法部署
有時，當 vSAN 資料持續性平台服務執行個體 (例如 MinIO 或 Cloudian) 的兩個複本網繭的主機本機 PVC 配置在同一叢集節點上時，可能會進入一種狀態。通常，同一執行個體的兩個複本不能在同一叢集節點上具有主機本機儲存區。如果發生此情況，其中一個複本網繭可能會無限期保持擱置狀態，從而導致執行個體部署失敗。
在失敗期間觀察到的症狀全部列舉如下：
-
執行個體健全狀況顯示黃色。
-
執行個體的至少一個網繭保持擱置狀態超過 10 分鐘。
-
擱置中網繭和同一執行個體的其中一個執行中複本網繭會將其主機本機 PVC 配置在叢集的同一節點上。
可能會造成此問題的失敗情境如下：
-
叢集中的某些節點沒有足夠的儲存資源用於執行個體。
-
複本數目大於叢集中的節點數目。這可能是因為一或多個節點暫時無法使用。
因應措施：
-
請確保您的叢集具有足夠的儲存資源，並且叢集節點數目大於執行個體複本計數。
-
刪除擱置中的網繭及其所有主機本機 PVC。
服務營運人員應在排程網繭的新節點上重建磁碟區資料。這可能需要一些時間才能完成，具體取決於磁碟區大小及其有效資料量。
-
-
當 ESXi 節點在 [確保可存取性] 模式下結束維護後，在維護期間套用至節點的污點可能仍保留在節點上
使用 vSAN 資料持續性平台 (vDPP) 建立合作夥伴服務的執行個體時，可能會出現此問題。當 ESXi 節點在 [確保可存取性] 模式下結束維護後，您仍可在節點上找到剩餘的污點
node.vmware.com/drain=planned-downtime:NoSchedule。通常，執行以下動作時會發生此問題：
1.在主管叢集上啟用合作夥伴服務，並建立服務的執行個體。
2.ESXi 節點在 [確保可存取性] 模式下置於維護模式。
3.節點在 [確保可存取性] 模式下成功進入維護模式。
4.在節點上套用污點
node.vmware.com/drain=planned-downtime:NoSchedule。5.節點結束維護模式。
節點結束維護模式後，請使用下列命令確保節點上沒有保留任何污點：
kubectl describe node | grep Taints因應措施：
如果主機上存在污點
node.vmware.com/drain=planned-downtime:NoSchedule，請手動移除該污點：kubectl taint nodes nodeNamekey=value:Effect-附註：請務必在命令結尾處使用連字號。
遵循此範例：
kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule- -
APD 復原後，在 vSAN 資料持續性平台上執行的持續性服務網繭可能會保持擱置狀態，並顯示 AttachVolume 錯誤
在 ADP 和復原 ESXi 主機後，vDPP 服務執行個體網繭可能會保持擱置狀態。如果執行
kubectl -n instance_namespace describe pod name_of_pod_in_pending命令，則會看到AttachVolume錯誤。如果網繭保持擱置狀態的時間超過 15 分鐘，則不太可能退出此狀態。
因應措施：使用下列命令刪除擱置中的網繭：
kubectl -n instance_namespace delete pod name_of_pod_in_pending。網繭將重新建立並變成正在執行狀態。
虛擬機器服務
-
<span style="color:#FF0000">新增：</span>嘗試部署具有相同名稱的 vSphere 網繭和虛擬機器服務虛擬機器會導致出現錯誤和無法預期的行為
可能會出現故障和錯誤或其他有問題的行為。如果在命名空間中執行 vSphere 網繭，然後嘗試在同一命名空間中部署具有相同名稱的虛擬機器服務虛擬機器 (反之亦然)，則可能會遇到這些問題。
因應措施：請勿針對同一命名空間中的 vSphere 網繭和虛擬機器使用相同的名稱。
-
有限的虛擬機器映像集可供虛擬機器服務使用
嘗試使用與虛擬機器服務不相容的虛擬機器映像時，在建立虛擬機器時遇到下列訊息
Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image因應措施：僅使用來自 VMware Marketplace 的已驗證可與虛擬機器服務一同使用的虛擬機器映像
-
無法使用名稱不符合 DNS 要求的虛擬機器映像
如果內容程式庫中 OVF 映像的名稱不符合 DNS 子網域名稱要求，則虛擬機器服務將不會從 OVF 映像建立 VirtualMachineImage。因此，
kubectl get vmimage將不會列出命名空間中的映像，並且開發人員將無法使用此映像。因應措施：為 OVF 映像使用符合 DNS 子網域名稱要求的名稱。
-
重複的 OVF 映像不會顯示為重複的 VirtualMachineImages
不同內容程式庫中名稱相同的 OVF 映像不會顯示為不同的 VirtualMachineImages
因應措施：為內容程式庫中已設定虛擬機器服務的 OVF 映像使用唯一名稱。
-
虛擬機器服務所建立之虛擬機器不允許存取 Web 或遠端主控台
虛擬機器服務所建立之虛擬機器不允許存取遠端主控台。因此，管理員無法使用 vSphere Web Client 中的啟動 Web 主控台和啟動遠端主控台選項登入虛擬機器。
因應措施：管理員可以透過登入虛擬機器所在的 ESXi 主機來存取虛擬機器主控台。
-
當 ESXi 主機進入維護模式時，由虛擬機器服務管理的具有 vGPU 和傳遞裝置的虛擬機器會關閉電源
透過虛擬機器服務，DevOps 工程師能夠建立連結至 vGPU 或傳遞裝置的虛擬機器。通常，當 ESXi 主機進入維護模式時，DRS 會針對在主機上執行的此類虛擬機器產生建議。然後，vSphere 管理員可以接受觸發 vMotion 的建議。
但是，由虛擬機器服務管理的具有 vGPU 和傳遞裝置的虛擬機器會自動關閉電源。這可能會暫時影響在這些虛擬機器中執行的工作負載。當主機結束維護模式後，虛擬機器會自動開啟電源。
因應措施：無。
