VMware Tanzu Kubernetes Grid v2.2 版本說明
除非另有說明，否則這些版本說明適用於 Tanzu Kubernetes Grid (TKG) 的所有 v2.2.x 修補程式版本。
TKG v2.2 以可下載的 Tanzu CLI 套件形式發行，用來部署版本化 TKG 獨立管理叢集。TKG v2.2 支援使用可在多個基礎架構 (包括 vSphere 6.7、7 和 8、AWS 和 Azure) 上執行的獨立管理叢集建立和管理工作負載叢集。
Tanzu Kubernetes Grid v2.0、v2.2 和 vSphere 8 中的 vSphere with Tanzu 主管
重要vSphere 8.0.1c 和更新版本中的 vSphere with Tanzu 主管執行 TKG v2.2。舊版的 vSphere 8 執行 TKG v2.0，該版本並非獨立於主管發佈。從 TKG 2.1 開始，可以使用執行 TKG 2.x 的獨立管理叢集。更新的 TKG 版本將嵌入到未來 vSphere 更新版本的主管中。因此，在指定時間內嵌于最新vSphere with Tanzu版本的 TKG 版本可能與所使用的 TKG 獨立版本不同。但是，完全支援與所有 TKG v2.x 版本相容的 Tanzu CLI 版本與 vSphere 8 所有版本中的主管一起使用。
Tanzu Kubernetes Grid v2.2 和 vSphere 7 中的 vSphere with Tanzu
注意與 vSphere 8 中的 TKG 2.x 和 vSphere with Tanzu 主管相容的 Tanzu CLI 版本與 vSphere 7 中的主管叢集不相容。如要在 vSphere 7 上對 vSphere with Tanzu 主管叢集使用 Tanzu CLI，請使用 TKG v1.6 中的 Tanzu CLI 版本。如要使用與具有主管的 TKG 2.x 相容的 Tanzu CLI 版本，請升級到 vSphere 8。如果 vSphere with Tanzu 主管叢集不存在，您可以將獨立 TKG 2.x 管理叢集部署到 vSphere 7。有關 Tanzu CLI 與 VMware 產品之間相容性的資訊，請參閱 Tanzu CLI 文件。
新增功能
Tanzu Kubernetes Grid v2.2.x 包含以下的新功能：
- 支援 Kubernetes v1.25.7、1.24.11 和 1.23.17。請參閱下面的 Tanzu Kubernetes Grid v2.2 中支援的 Kubernetes 版本
- 對於獨立管理叢集和以類別為基礎的工作負載叢集，可以使用叢集組態檔中的
ADDITIONAL_IMAGE_REGISTRY*變數或Cluster物件規格中的additionalImageRegistries設定，為多個私人映像登錄設定信任。請參閱以類別為基礎的叢集的受信任登錄。 - 從 Harbor v2.7.1 中移除
jobservice.scandataExports持續性磁碟區聲明。如果之前已將 Harbor Scandata Volume EmptyDir Overlay 套用至 Harbor 套件，請參閱更新正在執行的 Harbor 部署，然後再將 Harbor 套件更新到 v2.7.1。 - 從 TKG 2.2.0 起，在 Tanzu Kubernetes Grid 上部署 VMware 支援的套件 (如 Harbor、Contour 和 Velero) 時，VMware 會為它們提供執行階段層級支援。
- vSphere CSI 套件支援
vsphereCSI.netpermissions組態。
支援的 Kubernetes 和 TKG 版本
隨著 TKG v2.2 的推出，VMware 對 TKG 和 TKrs 較舊的修補程式版本支援政策發生變化，這些版本為 TKG 封裝了 Kubernetes 版本。TKG v2.1 和較舊次要 TKG 版本的支援政策則無變化。
以下幾節總結了在適用於每個 TKG 和 TKr 的支援政策下，對所有目前支援的 TKG 和 TKr 版本的支援。
支援的 Kubernetes 版本：
Tanzu Kubernetes Grid 的每個版本都增加了對其管理叢集的 Kubernetes 版本以及其他 Kubernetes 版本的支援，且這些版本是以 Tanzu Kubernetes 版本 (Tkr) 形式發行，但標記為已知問題者除外。
次要版本：VMware 在發行時支援 TKG v2.2 和 Kubernetes v1.25、v1.24 和 v1.23，而且只要 TKG v2.1 也受支援。一旦 TKG v2.1 達到其「標準支援結束」里程碑，VMware 將不再支援 Kubernetes v1.23 和 v1.24 與 TKG 一起使用。
修補程式版本：在 VMware 為次要分支版本發佈新的 TKr 修補程式版本後，會將對較舊修補程式版本的支援保留兩個月。這為客戶提供了 2 個月的時間升級到新的 TKr 修補程式版本。從 TKG v2.2 起，VMware 不支援 Kubernetes 先前次要分支版本中的所有 TKr 修補程式版本。
支援的 TKG 和 TKr 版本
目前支援的 TKG 修補程式版本支援以下的 TKr 修補程式版本。
| Tanzu Kubernetes Grid 版本 | 管理叢集的 Kubernetes 版本 | 提供的 Kubernetes (TKr) 版本 |
|---|---|---|
| 2.2.0 | 1.25.7 | 1.25.7、1.24.11、1.23.17 |
| 2.1.1 | 1.24.10 | 1.24.10、1.23.16、1.22.17 |
| 2.1.0 | 1.24.9 | 1.24.9、1.23.15、1.22.17 |
| 1.6.1 | 1.23.10 | 1.23.10、1.22.13、1.21.14 |
| 1.6.0 | 1.23.8 | 1.23.8、1.22.11、1.21.14 |
TKG v2.2.0 支援的 TKr 版本
TKG v2.2.0 根據以下發行日期支援下表中列出的 TKr 修補程式版本：
- v2.2.0：2023 年 5 月 18 日
- v2.1.1：2023 年 3 月 21 日
| Kubernetes 次要 | Kubernetes 修補程式 | 與 TKG 一起發行 | 支援結束日期 (如果不是最新的) |
|---|---|---|---|
| v1.25 | v1.25.7 | v2.2.0 | 支援的最新版本 |
| v1.24 | v1.24.11 | v2.2.0 | 支援的最新版本 |
| v1.24.10 | v2.1.1 | 2023 年 7 月 11 日 | |
| v1.24.9 | v2.1.0 | 2023 年 5 月 21 日 | |
| v1.23 | v1.23.17 | v2.2.0 | 支援的最新版本 |
| v1.23.16 | v2.1.1 | 2023 年 7 月 11 日 | |
| v1.23.15 | v2.1.0 | 2023 年 5 月 21 日 |
支援的 Tanzu Kubernetes Grid 版本
VMware 支援如下所示的 TKG 版本：
次要版本：VMware 支援遵循 N-2 生命週期政策的 TKG，該政策適用於最新和之前的兩個次要 TKG 版本。在 TKG v2.2.0 版本中，不再支援 TKG v1.5。有關詳細資訊，請參見 VMware產品生命週期矩陣。
修補程式版本：VMware 不支援以前的所有 TKG 修補程式版本。在 Vmware 發行新的 TKG 修補程式版本後，會將對較舊修補程式版本的支援保留兩個月。這為客戶提供了 2 個月的時間升級到新的 TKG 修補程式版本。
- 例如，對 TKG v2.2.0 的支援將在 TKG v2.2.1 正式發行兩個月後終止。
Tanzu 標準存放庫套件支援說明
VMware 為 VMware Tanzu Standard 存放庫中提供的可選套件提供以下支援：
- VMware 為可選 VMware Tanzu Standard 存放庫中部署在 Tanzu Kubernetes Grid 上的套件提供安裝和升級驗證。此驗證僅限於安裝和升級套件，但包括解決 CVE 所需的任何可用更新。任何錯誤修復、功能增強和安全修復將在新的套件版本中提供，但前提是這些版本在上游套件專案中可用。
- VMware 不會為 Tanzu 標準存放庫提供的元件提供執行階段層級支援。VMware 不提供組態和效能相關問題的偵錯，或偵錯和修復套件本身。
有關對 Tanzu Standard 套件 VMware 支援的詳細資訊，請參閱上面的新增功能和下面的未來行為變更通知。
Tanzu Kubernetes Grid v2.2 的產品快照
Tanzu Kubernetes Grid v2.2 支援下列基礎結構平台和作業系統 (OS)，以及叢集的建立和管理、網路、儲存區、驗證、備份和移轉以及可觀察性元件。以括弧列出的元件版本則會包含在 Tanzu Kubernetes Grid v2.2.0 中。如需詳細資訊，請參閱元件版本。
| vSphere | AWS | Azure | |
| 基礎結構平台 |
|
原生 AWS | 原生 Azure |
| CLI、API 和套件基礎結構 | Tanzu Framework v0.29.0 | ||
| 叢集的建立和管理 | 核心叢集 API (v1.2.8)、叢集 API 提供者 vSphere (v1.5.3) | 核心叢集 API (v1.2.8)、叢集 API 提供者 AWS (v2.0.2) | 核心叢集 API (v1.2.8)、叢集 API 提供者 Azure (v1.6.3) |
| 隨 TKG 發行的 Kubernetes 節點作業系統 | Photon OS 3、Ubuntu 20.04 | Amazon Linux 2、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
| 建置您自己的映像 | Photon OS 3、Red Hat Enterprise Linux 7*** 和 8、Ubuntu 18.04、Ubuntu 20.04、Windows 2019 | Amazon Linux 2、Ubuntu 18.04、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
| 容器執行階段 | Containerd (v1.6.18) | ||
| 容器網路 | Antrea (v1.7.2)、Calico (v3.24.1) | ||
| 容器登錄 | Harbor (v2.7.1) | ||
| 輸入 | NSX Advanced Load Balancer Essentials 和 Avi 控制器 **** (v21.1.5-v21.1.6、v22.1.2-v22.1.3)、Contour (v1.23.5) | Contour (v1.23.5) | Contour (v1.23.5) |
| 儲存區 | vSphere 容器儲存區介面 (v2.7.1*) 和 vSphere 雲端原生儲存區 | Amazon EBS CSI 驅動程式 (v1.16.0) 和樹狀結構內雲端提供者 | Azure 磁碟 CSI 驅動程式 (v1.27.0)、Azure 檔案 CSI 驅動程式 (v1.26.1) 以及樹狀結構內雲端提供者 |
| 驗證 | 透過 Pinniped (v0.12.1) 的 OIDC、透過 Pinniped (v0.12.1) 和 Dex 的 LDAP | ||
| 可觀察性 | Fluent Bit (v1.9.5)、Prometheus (v2.37.0)*****、Grafana (v7.5.17) | ||
| 備份和移轉 | Velero (v1.9.7) | ||
* vsphere_csi_driver 版本。如需 Tanzu Kubernetes Grid v2.2 版本中包含的 vSphere 容器儲存區介面元件的完整清單，請參閱元件版本。
** 如需與此版本相容的 VMware Cloud on AWS SDDC 版本清單，請參閱 VMware 產品互通性對照表。
*** Tanzu Kubernetes Grid v1.6 是支援建置 Red Hat Enterprise Linux 7 映像的最新版本。
**** 在 vSphere 8 上，若要將 NSX Advanced Load Balancer 與 TKG 獨立管理叢集及其工作負載叢集結合使用，您需要 NSX ALB v22.1.2 或更新版本以及 TKG v2.1.1 或更新版本。
如果將叢集升級到 Kubernetes v1.25，則必須將 Prometheus 升級到版本 2.37.0+vmware.3-tkg.1。Prometheus 軟體套件的早期版本 (例如版本 2.37.0+vmware.1-tkg.1) 與 Kubernetes 1.25 不相容。
如需 Tanzu Kubernetes Grid v2.2 隨附的 Kubernetes 版本完整清單，請參閱上述 Tanzu Kubernetes Grid v2.2 中支援的 Kubernetes 版本。
元件版本
Tanzu Kubernetes Grid v2.2.x 版本包含下列軟體元件版本：
| 元件 | TKG v2.2 |
|---|---|
| aad-pod-identity | v1.8.15+vmware.1* |
| addons-manager | v2.2+vmware.1* |
| ako-operator | v1.8.0_vmware.1* |
| alertmanager | v0.25.0_vmware.1* |
| antrea | v1.9.0_vmware.2-tkg.1-advanced* |
| aws-ebs-csi-driver | v1.16.0_vmware.1-tkg.1* |
| azuredisk-csi-driver | v1.27.0_vmware.2-tkg.1* |
| azurefile-csi-driver | v1.26.1_vmware.2-tkg.1* |
| calico | v3.24.1_vmware.1-tkg.2* |
| capabilities-package | v0.29.0-dev-capabilities* |
| carvel-secretgen-controller | v0.11.2+vmware.1 |
| cloud-provider-azure | v1.1.26+vmware.1、 v1.23.23+vmware.1、 v1.24.10+vmware.1 |
| cloud_provider_vsphere | v1.25.1+vmware.2* |
| cluster-api-provider-azure | v1.6.3_vmware.2* |
| cluster_api | v1.2.8+vmware.2* |
| cluster_api_aws | v2.0.2+vmware.2* |
| cluster_api_vsphere | v1.5.3+vmware.2* |
| cni_plugins | v1.1.1+vmware.20* |
| configmap-reload | v0.7.1+vmware.2 |
| containerd | v1.6.18+vmware.1* |
| contour | v1.23.5+vmware.1-tkg.1* |
| coredns | v1.9.3_vmware.8* |
| crash-diagnostics | v0.3.7+vmware.6 |
| cri_tools | v1.24.2+vmware.8* |
| csi_attacher | v3.5.0+vmware.1、 v3.4.0+vmware.1、 v3.3.0+vmware.1 |
| csi_livenessprobe | v2.7.0+vmware.1、 v2.6.0+vmware.1、 v2.5.0+vmware.1、 v2.4.0+vmware.1 |
| csi_node_driver_registrar | v2.5.1+vmware.1、 v2.5.0+vmware.1、 v2.3.0+vmware.1 |
| csi_provisioner | v3.2.1+vmware.1、 v3.1.0+vmware.2、 v3.0.0+vmware.1 |
| dex | v2.35.3_vmware.3* |
| envoy | v1.24.5_vmware.1* |
| external-dns | v0.12.2+vmware.5* |
| external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.9* |
| fluent-bit | v1.9.5+vmware.1 |
| gangway | v3.2.0+vmware.2 |
| grafana | v7.5.17+vmware.2 |
| guest-cluster-auth-service | v1.3.0* |
| harbor | v2.7.1+vmware.1* |
| image-builder | v0.1.13+vmware.3* |
| image-builder-resource-bundle | v1.25.7+vmware.2-tkg.1* |
| imgpkg | v0.31.1+vmware.1 |
| jetstack_cert-manager | v1.10.2+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.5*、 v1.12.1+vmware.6* |
| k14s_kapp | v0.53.2+vmware.1 |
| k14s_ytt | v0.43.1+vmware.1 |
| kapp-controller | v0.41.7_vmware.1-tkg.1* |
| kbld | v0.35.1+vmware.1 |
| kube-state-metrics | v2.7.0+vmware.2* |
| kube-vip | v0.5.7+vmware.2* |
| kube-vip-cloud-provider* | v0.0.4+vmware.4* |
| kube_rbac_proxy | v0.11.0+vmware.2 |
| kubernetes | v1.25.7+vmware.2* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
| kubernetes-sigs_kind | v1.25.7+vmware.2-tkg.2_v0.17.0* |
| kubernetes_autoscaler | v1.25.0+vmware.1* |
| load-balancer-and-ingress-service (AKO) | v1.9.3_vmware.1-tkg.1* |
| metrics-server | v0.6.2+vmware.1 |
| multus-cni | v3.8.0+vmware.3* |
| pinniped | v0.12.1_vmware.3-tkg.4* |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 |
| prometheus | v2.37.0+vmware.3* |
| prometheus_node_exporter | v1.4.0+vmware.3* |
| pushgateway | v1.4.3+vmware.3* |
| sonobuoy | v0.56.16+vmware.1* |
| standalone-plugins-package | v0.29.0-dev-standalone-plugins* |
| tanzu-framework | v0.29.0* |
| tanzu-framework-addons | v0.29.0* |
| tanzu-framework-management-packages | v0.29.0-tf* |
| tkg-bom | v2.2.0* |
| tkg-core-packages | v1.25.7+vmware.2-tkg.1* |
| tkg-standard-packages | v2.2.0* |
| tkg-storageclass-package | v0.29.0-tkg-storageclass* |
| tkg_telemetry | v2.2.0+vmware.1* |
| velero | v1.9.7+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.5+vmware.1* |
| velero-plugin-for-csi | v0.3.5+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.5+vmware.1* |
| velero-plugin-for-vsphere | v1.4.3+vmware.1* |
| vendir | v0.30.1+vmware.1 |
| vsphere_csi_driver | v2.7.1+vmware.2* |
| whereabouts | v0.5.4+vmware.2* |
* 表示自先前版本以來新增的元件或版本更新。TKG v2.1.1 是 v2.2.0 之前的版本。
如需 TKG v2.2 隨附的軟體元件版本的完整清單，請使用 imgpkg 提取存放庫服務包，然後列出其內容。對於 TKG v2.2.0，例如：
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree
如以下所列的本機 BOM 檔案也會列出套件版本，但可能不是最新的：
~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml
支援的升級路徑
在 TKG 升級路徑中，v2.2 緊接在 v2.1.1 之後。
您只能從 v2.1.x 升級到 Tanzu Kubernetes Grid v2.2.x。如果要從早於 v2.1.x 的版本升級到 Tanzu Kubernetes Grid v2.2.x，必須先升級到 v2.1.x。
在工作負載叢集上升級 Kubernetes 版本時，無法跳過次要版本。例如，您無法將 Tanzu Kubernetes 叢集直接從 v1.23.x 升級到 v1.25.x。必須先將 v1.23.x 叢集升級到 v1.24.x，再將叢集升級到 v1.25.x。
發行日期
Tanzu Kubernetes Grid v2.2 發行日期為：
- v2.2.0：2023 年 5 月 9 日
Tanzu Kubernetes Grid v2.2 中的行為變更
相較於 v2.2 (先前的最新版本)，Tanzu Kubernetes Grid v2.1.1 中引入了下列的新行為。
未來行為變更通知
本節提供了將在未來版本 (TKG v2.2 版本之後的版本) 中生效的行為變更的預先通知。
VMware Tanzu Standard 存放庫
重要Tanzu Kubernetes Grid v2.2.x 是 TKG 的最後一個次要版本，其中 VMware Tanzu Standard 存放庫封裝為該版本的一部分。TKG v2.2.x 和早期版本在 Tanzu Standard Repository 中包含一組可選套件，您可以在叢集上部署這些套件以新增記錄轉送、輸入控制、容器登錄等功能。在未來的 TKG v2.x 次要版本中，安裝 Tanzu CLI 並部署管理叢集時，不會自動下載 Tanzu Standard 存放庫。要使用此可選套件集，您需要使用 Tanzu CLI 下載並手動新增它們。通過將可選套件與 TKG 版本分開，VMware 可以在 TKG 版本之外提供增量套件更新，並且能夠更迅速地回應 CVE。
取代通知
- 在未來版本的 TKG 中，將移除 Dex 元件，因為 Pinniped 不再需要該元件即可與 LDAP 提供者配合使用。進行此變更後，LDAP 身分驗證將需要以下叢集組態變數：
LDAP_BIND_DN和LDAP_BIND_PASSWORD。如需詳細資訊，請參閱〈組態檔變數參考〉中的機器健全狀況檢查。
使用者說明文件
部署和管理 TKG 2.2 獨立管理叢集中含有獨立管理叢集的特定主題，這些主題與「將 TKG 與 vSphere with Tanzu 主管搭配使用」無關。
如需詳細資訊，請參閱《VMware Tanzu Kubernetes Grid 說明文件》頁面上的尋找適合您部署的 TKG 文件。
已解決的問題
以下是在 Tanzu Kubernetes Grid 舊版發行中記錄成「已知問題」，但已在 Tanzu Kubernetes Grid v2.2.0 中解決的問題。
-
從舊版組態檔建立
ClusterClass組態檔，--dry-run包括空的 Antrea 組態使用包含
ANTREA_NODEPORTLOCAL項目的舊版組態檔配置檔，透過tanzu cluster create --dry-run -f建立ClusterClass會導致自動產生的 Antrea 組態不包含任何標籤，導致 Antrea 無法成功協調。 -
對於 TKG 上處於不支援的技術預覽狀態的 PSA 控制器，某些 TKG 套件不符合預設的
baseline設定檔。 -
執行
tanzu cluster create時出現驗證錯誤依預設，當您將一般索引鍵值組態檔傳遞到
tanzu cluster create的--file選項時，命令會將該組態檔轉換為 Kubernetes 樣式的物件規格檔案，然後退出。此行為由auto-apply-generated-clusterclass-based-configuration功能控制，此功能依預設為false。在某些情況下，當您傳遞由--file選項產生的 Kubernetes 樣式物件規格檔案到tanzu cluster create時，命令會失敗並顯示類似以下內容的錯誤：Error: workload cluster configuration validation failed...當您傳遞由
--dry-run選項產生的 Kubernetes 樣式物件規格檔案到tanzu cluster create時，也可能出現此錯誤。 -
tanzu cluster create不會正確驗證使用非預設 Kubernetes 版本產生的叢集規格如果使用建立以類別為基礎的叢集中所述的兩個步驟之一從組態檔建立以類別為基礎的工作負載叢集，並在第一步中指定
--tkr值以將叢集建立在非預設版本的 Kubernetes 上時，第二步可能會失敗，並顯示驗證錯誤。
已知問題
以下是 Tanzu Kubernetes Grid v2.2.x 中的已知問題。在後續 v2.2.x 修補程式發行版本中解決的存在於 v2.2.0 中的任何已知問題，都列在修正這些問題的修補程式發行版本的已解決的問題之下。
您可以在疑難排解管理叢集問題和疑難排解工作負載叢集問題或 VMware 知識庫文章中找到常見問題的其他解決方案。
套件
-
在具有 NSX ALB v21.1.4 或更早版本的 vSphere 6.7 上安裝 Grafana 失敗
您無法將 Grafana v7.5.17 套件安裝到使用 NSX ALB v21.1.4 或更早版本作為負載均衡器服務的 vSphere v6.7U3 上的 TKG v2.2 工作負載叢集。
因應措施：如果工作負載叢集使用 Grafana 和 NSX ALB，請先將 vSphere 升級到 v7.0+ 並將 NSX ALB 升級到 v21.1.5+，然後再將 TKG 升級到 v2.2。
-
當執行 ID 超過 1000000 時，Harbor CVE 匯出可能會失敗
Harbor v2.7.1 (TKG v2.2 封裝的版本) 存在已知問題，即在執行主要金鑰時自動增量 ID 到 1000000+ 時，CVE 報告匯出錯誤「找不到 404 (404 page not found)」。
此 Harbor 問題已在更高版本的 Harbor 中解決，並準備包含在更高版本的 TKG 中。
-
Harbor 的 Notary 元件中的 Golang 漏洞
CVE-2021-33194 存在於 Notary 中。如 Harbor v2.6.0 版本資訊中所述，Notary 元件已在 Harbor v2.6+ 中被取代，並計劃在未來的版本中移除。VMware 建議使用 Sigstore Cosign 而不是 Notary 進行容器簽名和驗證。
-
執行
tanzu package repository add將tanzu-standard存放庫新增至 vSphere 上的單節點叢集 (技術預覽) 中所述類型的單節點叢集可能會失敗。發生這種情況的原因是，單節點叢集會使用
cert-manager作為核心附加元件進行開機，這與tanzu-standard存放庫中不同的cert-manager套件相衝突。因應措施：在新增
tanzu-standard存放庫之前，請依照安裝 cert-manager 中所述修補cert-manager套件註解。
叢集作業
-
無法根據具有 Antrea CNI 的非目前 TKr 版本建立新的工作負載叢集
您無法建立使用 Antrea CNI 並執行先前版本 TKG 隨附的 Kubernetes 版本 (如 Kubernetes v1.23.10) 的新工作負載叢集，這是 TKG v1.6.1 中預設的 Kubernetes 版本，如 Tanzu Kubernetes Grid v2.2 中支援的 Kubernetes 版本所列。
因應措施：建立執行 Kubernetes 1.25.7、1.24.11 或 1.23.17 的工作負載叢集。Kubernetes 專案建議您在目前任何次要版本的最新修補程式版本上執行元件。
-
由於叢集 API 中的標籤傳播問題，以類別為基礎的工作負載叢集的叢集組態檔中的
AUTOSCALER_MIN_SIZE_*和AUTOSCALER_MAX_SIZE_*設定並未設定在叢集的MachineDeployment物件中。因應措施：在建立以類別為基礎的工作負載叢集並啟用 Cluster Autoscaler 後，請針對每個 AZ，手動新增機器計數下限和上限設定，如手動新增大小下限和上限註解中所述。
-
您無法新增或變更現有節點集區的
labels、az、nodeMachineType或 vSphere 內容，如組態內容中所列。因應措施：使用所需的內容在叢集中建立一個新節點集區，將工作負載移轉至該新的節點集區，然後刪除原始的節點集區。
-
如果您在管理叢集上執行
tanzu cluster scale，並傳遞一個偶數給--controlplane-machine-count選項，則 TKG 不會調整控制平面節點，且 CLI 不會輸出錯誤。為了維護仲裁，控制平面節點計數應一律是奇數。因應措施：不要將控制平面節點計數調整為偶數。
-
以類別為基礎的叢集名稱具有 25 個字元的限制，並以 NSX ALB 作為負載平衡器服務或輸入控制器
將 NSX Advanced Load Balancer (ALB) 用作以類別為基礎的叢集的負載平衡器服務或具有獨立管理叢集的輸入控制器時，其應用程式名稱包括叢集名稱和 AKO 套件的內部名稱
load-balancer-and-ingress-service。當組合名稱超過 Avi 控制器應用程式的 64 個字元限制時，tanzu cluster create命令可能會失敗，並顯示錯誤：「找不到avi-system命名空間」。因應措施：使用 NSX ALB 作為負載平衡器或輸入控制器時，請將以類別為基礎的叢集名稱長度限制為 25 個或以下的字元。
網路
附註若為 v4.0 以上，VMware NSX-T Data Center 已重新命名為「VMware NSX」。
-
TKG v2.2 在 vSphere 8 上不支援 IPv6 網路，但是在 vSphere 7 上它支援使用 Kube-Vip 來建立單堆疊 IPv6 網路 (如 IPv6 網路中所述)。
因應措施：如果您需要或目前正在 vSphere 上的 IPv6 環境中使用 TKG，請不要安裝或升級到 vSphere 8。
-
管理叢集不支援 NSX ALB
NodePortLocal輸入模式在 TKG v2.1 中，當使用輸入模式 來將流量傳輸至管理叢集時，您無法將 NSX Advanced Load Balancer (ALB) 當成服務類型來執行。
此問題不會影響支援使用
NodePortLocal輸入來傳輸到工作負載叢集，如 NodePortLocal 模式下的 L7 輸入中所述。因應措施：將
AVI_INGRESS_SERVICE_TYPE設定為NodePort或ClusterIP，來設定管理叢集。預設值為NodePort。 -
如果使用較舊的 NSX-T 版本和 Photon 3，或使用具有 Linux 核心 5.8 虛擬機器的 Ubuntu，則管理叢集會建立失敗或是效能下降
如果部署具有以下基礎結構和組態的管理叢集，則可能失敗或導致網繭之間的流量受限：
- 具有以下任一版本 NSX-T 的 vSphere：
- 啟用了「增強型資料路徑」的 NSX-T v3.1.3
- 低於 v3.1.3 的 NSX-T v3.1.x
- 低於 v3.0.2 即時修補程式的 NSX-T v3.0.x
- NSX-T v2.x。這包括使用 NSX-T v2.5 的 Azure VMware 解決方案 (AVS) v2.0
- 基礎映像：Photon 3 或具有 Linux 核心 5.8 的 Ubuntu
此組合暴露了舊版 NSX-T 和 Antrea CNI 之間的總和檢查問題。
TMC：如果管理叢集已向 Tanzu Mission Control (TMC) 登錄，則此問題沒有因應措施。否則，請參閱下面的因應措施。
因應措施：
- 在部署工作負載叢集時，將
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD設定為"true"。此設定會停用 Antrea 的 UDP 總和檢查卸載，從而避免某些底層網路和實體 NIC 網路驅動程式的已知問題。 - 升級到 NSX-T v3.0.2 即時修補程式、v3.1.3 或更新版本，且不啟用「增強型資料路徑」
- 將 Ubuntu 基礎映像與 Linux 核心 5.9 或更新版本搭配使用。
- 具有以下任一版本 NSX-T 的 vSphere：
身分識別和存取管理
-
在您依照備份和還原管理叢集和工作負載叢集的基礎結構 (技術預覽) 中所述，來重建獨立管理叢集後，使用者無法透過 Pinniped 驗證來登入工作負載叢集。
因應措施：重建管理叢集後，請依照在現有部署中啟用和設定身分識別管理中所述，來重新設定身分識別管理。
-
CVE-2022-41723 存在於 Pinniped v0.12.1 中。利用此漏洞可能會導致 Pinniped 服務的 DDoS 攻擊。如要降低此漏洞被利用的可能性，可以使用輸入篩選以僅允許來自已知 IP 位址 (如企業 VPN CIDR) 的流量。該漏洞將在 Tanzu Kubernetes Grid 的未來版本中解決。
-
為主管部署的工作負載叢集產生並使用 kubeconfig 會導致出現「未知旗標」錯誤
在 Tanzu CLI v0.25.0 及更早版本中，
cluster外掛程式會產生可能包含引數kubeconfig的--concierge-is-cluster-scoped檔。Tanzu CLI v0.29.0pinniped-auth外掛程式無法識別此引數。此臨時回歸問題已在後續版本中得到修復。由於 vSphere 8.0 嵌入了 v0.25.0
cluster外掛程式，因此從 CLI v0.29.0 (TKG v2.2 中的版本) 連接到主管部署的叢集時可能會產生以下錯誤：Error: unknown flag: --concierge-is-cluster-scoped Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1因應措施：在
kubeconfig檔中，移除args下設定--concierge-is-cluster-scoped的行。
儲存區
-
無法啟用工作負載叢集以在多個資料存放區分配儲存，如部署使用資料存放區的叢集中所述。如果將資料存放區叢集中的多個資料存放區標記為工作負載叢集儲存原則的基礎，則工作負載叢集僅使用其中一個資料存放區。
因應措施：無
Tanzu CLI
-
使用 CLI 來部署管理叢集時，不能在密碼中使用非英數字元
# ` ^ | / ? % ^ { [ ] } \ " < >。此外，當使用 UI 來部署管理叢集時，不能在 HTTP/HTTPS Proxy 密碼中使用任何非英數字元。因應措施：使用 CLI 來部署管理叢集時，您可以在密碼中使用
# ` ^ | / ? % ^ { [ ] } \ " < >以外的非英數字元。 -
Tanzu CLI 在具有 ARM 處理器的 macOS 機器上無法運作
Tanzu CLI v0.11.6 在具有 ARM (Apple M1) 晶片的 macOS 機器上無法運作，如 Finder > 關於這台 Mac (About This Mac) > 概觀 (Overview) 下所示。
因應措施：使用具有 Linux 或 Windows 作業系統的啟動機器，或使用具有 Intel 處理器的 macOS 機器。
-
Tanzu CLI 列出 tanzu management-cluster osimage
management-cluster命令群組列出了tanzu management-cluster osimage。此功能目前正在開發中，並保留供未來使用。因應措施：請勿使用
tanzu management-cluster osimage。 -
tanzu package available get的--default-values-file-output選項為 Harbor 套件輸出不完整的組態範本檔執行
tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH會為 Harbor 套件建立不完整的組態範本檔。若要取得完整的檔案，請使用imgpkg pull命令，如安裝 Harbor 以用於服務登錄中所述。
vSphere
-
使用
small節點來建立的節點集區可能會停滯在Provisioning狀態。建立節點集區時，如果將節點
SIZE設定為small，則集區可能停滯在Provisioning狀態，且永遠不會進入Running狀態。因應措施：將節點集區設定成至少具有
medium大小的節點。
AWS
-
在 AWS 管理叢集部署和升級期間，CAPA 資源標記問題會導致協調失敗。
由於上游叢集 API 提供者 AWS (CAPA) 中的資源標記問題，離線部署無法存取
ResourceTaggingAPI，從而導致在建立或升級管理叢集期間發生協調失敗。因應措施：在離線 AWS 環境中，請先在本機環境或管理叢集組態檔中設定
EXP_EXTERNAL_RESOURCE_GC=false，之後再執行tanzu mc create或tanzu mc upgrade。 -
AWS 上的工作負載叢集節點集區必須與獨立管理叢集位於相同的可用區域中。
建立節點集區時，如果所設定的
az不同於管理叢集的所在位置，則新的節點集區可能會一直停滯在ScalingUp狀態 (如tanzu cluster node-pool list所列)，且永遠不會達到Ready狀態。因應措施：僅在與獨立管理叢集相同的 AZ 中建立節點集區。
-
如果叢集使用的網路資源不是透過 Tanzu Kubernetes Grid 所部署，則刪除 AWS 上的叢集將會失敗。
如果叢集使用 AWS 雲端控制器管理程式所建立的網路資源 (獨立於 Tanzu Kubernetes Grid 部署程序之外)，則
tanzu cluster delete和tanzu management-cluster delete命令可能會當機。此類資源可能包括負載平衡器和其他網路服務，如 Kubernetes AWS 雲端提供者說明文件中的服務控制器中所列。如需詳細資訊，請參閱下列叢集 API 問題：在卸除時清空服務類型為 Loadbalancer 的工作負載叢集。
因應措施：使用
kubectl delete，從叢集中刪除類型為LoadBalancer的服務。或者，如果這樣做仍失敗，請使用 AWS 主控台，手動刪除雲端控制器管理程式為此服務所建立的任何LoadBalancer和SecurityGroup物件。注意
請勿刪除受 Tanzu 管理的負載平衡器或安全群組，它們具有下列標籤：
key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME、value: owned。
Azure
-
如果未受管理的資源群組中有一個 Azure 工作負載叢集，當 Azure CSI 驅動程式建立一個持續性磁碟區 (PV)，且該持續性磁碟區使用具有私人端點的儲存區帳戶時，它會建立一個
privateEndpoint和vNet資源，但在刪除 PV 時，並不會刪除這些資源。因此，刪除叢集將失敗，並顯示類似如下的錯誤：subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use。因應措施：在刪除 Azure 叢集之前，請先手動刪除儲存區帳戶私人端點的網路介面：
- 從瀏覽器登入 Azure Resource Explorer。
- 按一下左側的訂閱 (subscriptions)，然後展開您的訂閱。
- 在您的訂閱下，展開左側 resourceGroups，然後展開您的 TKG 部署的資源群組。
- 在資源群組下，展開提供者 (providers) > Microsoft.Network > networkinterfaces。
- 在
networkinterfaces下，選取無法刪除的 NIC 資源。 - 按一下頂層的讀取/寫入 (Read/Write) 按鈕，然後按一下其正下方的動作 (張貼、刪除) (Actions (POST, DELETE)) 索引標籤。
- 按一下刪除 (Delete)。
- 刪除 NIC 後，請刪除 Azure 叢集。
Windows
-
Vmware 不支援在代理或氣隙環境中具有 Windows Worker 節點的 TKG 工作負載叢集。
因應措施：請聯絡您的 VMware 代表。某些 TKG 使用者建立了 Windows 自訂映像，並在離線環境中使用 Windows worker 執行工作負載叢集，例如，如此非官方存儲庫中所述。
Image-Builder
-
在您執行 Kubernetes Image Builder 以建立 Linux 自訂機器映像時，
goss測試python-netifaces、python-requests和ebtables失敗。命令輸出會報告失敗情況。這些錯誤可以忽略；它們不會妨礙映像建置成功。
AVS
在 Azure vSphere 解決方案 (AVS) 上，刪除 vSphere CSI 持續性磁碟區 (PV) 可能會失敗。刪除 PV 時，需要 cns.searchable 權限。未使用此權限來建立 AVS 的預設管理員帳戶 ([email protected])。如需詳細資訊，請參閱 vSphere 角色和權限。
因應措施：若要刪除 AVS 上的 vSphere CSI PV，請連絡 Azure 支援。
