VMware Tanzu Kubernetes Grid v2.1 版本說明
除非另有說明，否則這些版本說明適用於 Tanzu Kubernetes Grid (TKG) 的所有 v2.1.x 修補程式版本。
TKG v2.1 是以可下載 Tanzu CLI 套件的形式散佈，用於部署已進行版本的 TKG 獨立管理叢集。TKG v2.1 是 TKG 的第一個版本，它支援建立及管理以類別為基礎的工作負載叢集，以及可在多個基礎結構上執行的獨立管理叢集，包括 vSphere、AWS 和 Azure。
在 vSphere 8 中Tanzu Kubernetes Grid v2.x 和 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 所有版本中的主管一起使用。
vSphere 7 中Tanzu Kubernetes Grid 2.1 版和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.1.x 包含以下的新功能：
Tanzu Kubernetes Grid v2.1.1
Tanzu Kubernetes Grid v2.1.1 的新增功能：
- 支援將 vSphere 8 上的 NSX Advanced Load Balancer v22.1.2 或更新版本與 TKG 獨立管理叢集及其工作負載叢集結合使用。
- 您可以安裝 TKG v2.1.1 的 FIPS 版本。如需詳細資訊，請參閱支援 FIPS 的版本。
- 組態變數：
Tanzu Kubernetes Grid v2.1.0
Tanzu Kubernetes Grid v2.1.0 的新增功能：
- TKG 2.x 支援：在具有獨立管理叢集的 vSphere、AWS 或 Azure 上，依照工作負載叢集類型中所述，來設定及建立以類別為基礎的叢集。
- 您可以安裝 TKG v2.1.0 的 FIPS 版本。如需詳細資訊，請參閱支援 FIPS 的版本。
- Tanzu CLI：
- 依預設，
package外掛程式會使用kctrl樣式的命令。請參閱〈Tanzu CLI 命令參考〉中的 tanzu 套件。 isolated-cluster外掛程式download-bundle和upload-bundle命令會擷取及傳輸 TKG 所需的所有容器映像，如準備網際網路受限的環境中所述。tanzu cluster list的-A和--all-namespaces選項包含由管理叢集所管理的所有命名空間 (而不單是預設命名空間) 中的叢集，且使用者對於這些叢集具有「檢視」權限 (甚至更大的權限)。context命令群組允許使用者設定及管理 Tanzu CLI 的內容，其中包括目標伺服器和要套用的kubeconfig。請參閱〈Tanzu CLI 命令參考〉中的 tanzu 內容。- 未來版本會棄用
tanzu login命令，以支援tanzu context命令。
- 未來版本會棄用
- 外掛程式的
Target類別會變更 CLI 行為，並新增保留供將來使用的功能，如下面的 Tanzu Kubernetes Grid v2.1 中的行為變更中所述。 auto-apply-generated-clusterclass-based-configuration功能會在您將舊版叢集組態檔傳遞到tanzu cluster create時，自動套用 Tanzu CLI 產生的以類別為基礎的叢集組態。依預設，該功能設定為false。請參閱〈Tanzu CLI 架構和組態〉中的功能。allow-legacy-cluster功能允許您建立以計劃為基礎的叢集。依預設，該功能設定為false。請參閱〈Tanzu CLI 架構和組態〉中的功能。tanzu mc credentials update和tanzu cluster credentials update命令會新增 Azure 的選項。這包括--azure-client-id、--azure-client-secret和--azure-tenant-id。
- 依預設，
- 以類別為基礎的叢集和獨立管理叢集支援以下叢集組態變數，如組態檔變數參考中所述：
- 節點組態：
CONTROL_PLANE_NODE_LABELS、CONTROL_PLANE_NODE_NAMESERVERS、CONTROL_PLANE_NODE_SEARCH_DOMAINS、WORKER_NODE_NAMESERVERS、WORKER_NODE_SEARCH_DOMAINS ExtraArgs內容：APISERVER_EXTRA_ARGS、CONTROLPLANE_KUBELET_EXTRA_ARGS、ETCD_EXTRA_ARGS、KUBE_CONTROLLER_MANAGER_EXTRA_ARGS、KUBE_SCHEDULER_EXTRA_ARGS、WORKER_KUBELET_EXTRA_ARGS- 速率限制和同步：
NTP_SERVERS、APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
- 節點組態：
- 叢集可以自動更新控制平面節點虛擬機器的憑證；請參閱控制平面節點憑證自動更新。
- (vSphere) 您可以部署同時執行 Windows 系統和 Linux 系統的工作節點的多重作業系統工作負載叢集，如部署多重作業系統工作負載叢集中所述。在此版本中，Windows 工作負載叢集將取代為多操作系統工作負載叢集。有關詳細資訊，請參閱 Tanzu Kubernetes Grid v2.1 中的行為變更。
- 您可以在多個可用區中部署具有 worker 的多作業系統工作負載叢集，如部署工作負載叢集到多個可用區 (vSphere 技術預覽)中所述。
- (vSphere) 可以透過所配置的 IP 集區，為以類別為基礎的工作負載叢集設定叢集內 IP 位址管理 (IPAM)，從而當節點計數或執行個體有所變更時，就無須設定 DHCP 保留。
- (vSphere) 叢集節點
Machine物件標籤會識別其 ESXi 主機的位址，以支援使用 nodeSelector 在專用硬體上執行特定的工作負載。 - (vSphere) Ubuntu OVA 映像會使用整合可延伸韌體介面 (UEFI) 模式進行開機，以取代傳統的 BIOS 韌體模式。UEFI 模式會啟用圖形處理器 (GPU) 工作負載，並增強節點安全性。如需 Ubuntu 上 UEFI 的詳細資訊，請參閱 Ubuntu 說明文件中的 UEFI。
- 您可以將 Kube-VIP 當成 L4
LoadBalancer服務來用於工作負載；請參閱 Kube-VIP 負載平衡器 (技術預覽)。 - 您可以為 Edge 應用程式部署在單一 ESXi 主機上，同時執行主控工作負載和控制平面基礎結構的單節點工作負載叢集，如 vSphere 上的單節點叢集 (技術預覽) 中所述。
- 您可以部署以
tinyTKr 為基礎的最小單節點叢集，將磁碟使用量減至最小。
- 您可以部署以
- 您可以備份及部署叢集基礎結構，如備份和還原管理叢集和工作負載叢集的基礎結構中所述 (技術預覽)。
- 支援「網繭安全性許可 (PSA)」控制器，以取代命名空間中所述的「網繭安全原則」，如 網繭安全性許可控制器中所述 (技術預覽)。
Tanzu Kubernetes Grid v2.1 中支援的 Kubernetes 版本
Tanzu Kubernetes Grid 的每個版本都增加了對其管理叢集的 Kubernetes 版本以及其他 Kubernetes 版本的支援，且這些版本是以 Tanzu Kubernetes 版本 (Tkr) 形式發行。
任何版本的 Tanzu Kubernetes Grid 都支援 Kubernetes 前兩個次要版本中的所有 TKr 版本，除非註明為已知問題。例如，TKG v2.1.x 支援下面列出的 Kubernetes 版本 v1.23.x 和 v1.22.x，但不支援 v1.21.x 或更舊版本。
| Tanzu Kubernetes Grid 版本 | 管理叢集的 Kubernetes 版本 | 提供的 Kubernetes (TKr) 版本 |
|---|---|---|
| 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 |
| 1.5.4 | 1.22.9 | 1.22.9、1.21.11、1.20.15 |
| 1.5.3 | 1.22.8 | 1.22.8、1.21.11、1.20.15 |
| 1.5.2、1.5.1、1.5.0 | 1.22.5 | 1.22.5、1.21.8、1.20.14 |
Tanzu Kubernetes Grid v2.1 的產品快照
Tanzu Kubernetes Grid v2.1 支援下列基礎結構平台和作業系統 (OS)，以及叢集的建立和管理、網路、儲存區、驗證、備份和移轉以及可觀察性元件。以括弧列出的元件版本則會包含在 Tanzu Kubernetes Grid v2.1.1 中。如需詳細資訊，請參閱元件版本。
| vSphere | AWS | Azure | |
| 基礎結構平台 |
|
原生 AWS | 原生 Azure |
| CLI、API 和套件基礎結構 | Tanzu Framework v0.28.1 | ||
| 叢集的建立和管理 | 核心叢集 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.6) | ||
| 容器網路 | Antrea (v1.7.2)、Calico (v3.24.1) | ||
| 容器登錄 | Harbor (v2.6.3) | ||
| 輸入 | NSX Advanced Load Balancer Essentials 和 Avi 控制器 **** (v21.1.3- v21.1.6、v22.1.1、v22.1.2)、Contour (v1.22.3) | Contour (v1.22.3) | Contour (v1.22.3) |
| 儲存區 | vSphere 容器儲存區介面 (v2.5.2*) 和 vSphere 雲端原生儲存 | Amazon EBS CSI 驅動程式 (v1.8.0) 和樹狀結構內雲端提供者 | Azure 磁碟 CSI 驅動程式 (v1.19.0)、Azure 檔案 CSI 驅動程式 (v1.21.0) 以及樹狀結構內雲端提供者 |
| 驗證 | 透過 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.5) | ||
* vsphere_csi_driver 版本。如需 Tanzu Kubernetes Grid v1.6 版本中包含的 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 或更新版本。
如需 Tanzu Kubernetes Grid v2.1 隨附的 Kubernetes 版本完整清單，請參閱上述 Tanzu Kubernetes Grid v2.1 中支援的 Kubernetes 版本。
元件版本
Tanzu Kubernetes Grid v2.1.x 版本包含下列軟體元件版本：
| 元件 | TKG v2.1.1 | TKG v2.1.0 |
|---|---|---|
| aad-pod-identity | v1.8.13+vmware.2* | v1.8.13+vmware.1* |
| addons-manager | v2.1+vmware.1-tkg.3 | v2.1+vmware.1-tkg.3 |
| ako-operator | v1.7.0+vmware.3 | v1.7.0+vmware.3* |
| alertmanager | v0.24.0+vmware.2* | v0.24.0+vmware.1 |
| antrea | v1.7.2+vmware.1-advanced | v1.7.2+vmware.1-advanced* |
| aws-ebs-csi-driver | v1.8.0+vmware.2 | v1.8.0+vmware.2* |
| azuredisk-csi-driver | v1.19.0+vmware.1 | v1.19.0+vmware.1* |
| azurefile-csi-driver* | v1.21.0+vmware.1 | v1.21.0+vmware.1 |
| calico_all | v3.24.1+vmware.1 | v3.24.1+vmware.1* |
| capabilities-package | v0.28.1-dev-capabilities* | v0.28.0-dev-capabilities* |
| carvel-secretgen-controller | v0.11.2+vmware.1 | v0.11.2+vmware.1* |
| cloud-provider-azure | v1.1.26+vmware.1、 v1.23.23+vmware.1、 v1.24.10+vmware.1 |
v1.1.26+vmware.1*、 v1.23.23+vmware.1*、 v1.24.9+vmware.1* |
| cloud_provider_vsphere | v1.24.3+vmware.1 | v1.24.3+vmware.1* |
| cluster-api-provider-azure | v1.6.3_vmware.1* | v1.6.1_vmware.1* |
| cluster_api | v1.2.8+vmware.1 | v1.2.8+vmware.1* |
| cluster_api_aws | v2.0.2+vmware.1 | v2.0.2+vmware.1* |
| cluster_api_vsphere | v1.5.3+vmware.1l* | v1.5.1+vmware.1l* |
| cni_plugins | v1.1.1+vmware.18* | v1.1.1+vmware.16* |
| configmap-reload | v0.7.1+vmware.2* | v0.7.1+vmware.1 |
| containerd | v1.6.6+vmware.3* | v1.6.6+vmware.1* |
| contour | v1.22.3+vmware.1 | v1.22.3+vmware.1* |
| coredns | v1.8.6+vmware.17* | v1.8.6+vmware.15* |
| crash-diagnostics | v0.3.7+vmware.6 | v0.3.7+vmware.6* |
| cri_tools | v1.23.0+vmware.8* | v1.23.0+vmware.7* |
| csi_attacher | v3.5.0+vmware.1、 v3.4.0+vmware.1、 v3.3.0+vmware.1 |
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 |
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 |
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 |
v3.2.1+vmware.1*、 v3.1.0+vmware.2、 v3.0.0+vmware.1 |
| dex | v2.35.3+vmware.2 | v2.35.3+vmware.2* |
| envoy | v1.23.3+vmware.2 | v1.23.3+vmware.2* |
| external-dns | v0.12.2+vmware.4 | v0.12.2+vmware.4* |
| external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
v6.0.1+vmware.1、 v5.0.1+vmware.1 |
| etcd | v3.5.6+vmware.6* | v3.5.6+vmware.3* |
| fluent-bit | v1.9.5+vmware.1 | v1.9.5+vmware.1* |
| gangway | v3.2.0+vmware.2 | v3.2.0+vmware.2 |
| grafana | v7.5.17+vmware.1* | v7.5.16+vmware.1 |
| guest-cluster-auth-service | v1.2.0* | v1.1.0* |
| harbor | v2.6.3+vmware.1 | v2.6.3+vmware.1* |
| image-builder | v0.1.13+vmware.2 | v0.1.13+vmware.2* |
| image-builder-resource-bundle | v1.24.10+vmware.1-tkg.1* | v1.24.9+vmware.1-tkg.1* |
| imgpkg | v0.31.1+vmware.1 | v0.31.1+vmware.1* |
| jetstack_cert-manager | v1.10.1+vmware.1 | v1.10.1+vmware.1* |
| k8s-sidecar | v1.15.6+vmware.3*、 v1.12.1+vmware.5* |
v1.15.6+vmware.2、 v1.12.1+vmware.3* |
| k14s_kapp | v0.53.2+vmware.1 | v0.53.2+vmware.1* |
| k14s_ytt | v0.43.1+vmware.1 | v0.43.1+vmware.1* |
| kapp-controller | v0.41.5+vmware.1、 v0.38.5+vmware.2 |
v0.41.5+vmware.1*、 v0.38.5+vmware.2* |
| kbld | v0.35.1+vmware.1 | v0.35.1+vmware.1* |
| kube-state-metrics | v2.6.0+vmware.2* | v2.6.0+vmware.1* |
| kube-vip | v0.5.7+vmware.1 | v0.5.7+vmware.1* |
| kube-vip-cloud-provider* | v0.0.4+vmware.2 | v0.0.4+vmware.2 |
| kube_rbac_proxy | v0.11.0+vmware.2 | v0.11.0+vmware.2 |
| kubernetes | v1.24.10+vmware.1* | v1.24.9+vmware.1* |
| kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
v1.4.0+vmware.1*、 v1.3.0+vmware.1 |
| kubernetes-sigs_kind | v1.24.10+vmware.1-tkg.1_v0.17.0* | v1.24.9+vmware.1-tkg.1_v0.17.0* |
| kubernetes_autoscaler | v1.24.0+vmware.1 | v1.24.0+vmware.1* |
| load-balancer-and-ingress-service (AKO) | v1.8.2+vmware.1 | v1.8.2+vmware.1* |
| metrics-server | v0.6.2+vmware.1 | v0.6.2+vmware.1* |
| multus-cni | v3.8.0+vmware.2 | v3.8.0+vmware.2* |
| pinniped | v0.12.1+vmware.1-tkg.1 | v0.12.1+vmware.1-tkg.1 |
| pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 | v0.12.1+vmware.2-tkg.3* |
| prometheus | v2.37.0+vmware.2* | v2.37.0+vmware.1* |
| prometheus_node_exporter | v1.4.0+vmware.2* | v1.4.0+vmware.1* |
| pushgateway | v1.4.3+vmware.2* | v1.4.3+vmware.1 |
| sonobuoy | v0.56.13+vmware.1 | v0.56.13+vmware.1* |
| standalone-plugins-package | v0.28.1-dev-standalone-plugins* | v0.28.1-dev-standalone-plugins* |
| tanzu-framework | v0.28.1* | v0.28.0* |
| tanzu-framework-addons | v0.28.1* | v0.28.0* |
| tanzu-framework-management-packages | v0.28.1-tf* | v0.28.0-tf* |
| tkg-bom | v2.1.1* | v2.1.0* |
| tkg-core-packages | v1.24.10+vmware.1-tkg.1* | v1.24.9+vmware.1-tkg.1* |
| tkg-standard-packages | v2.1.1* | v2.1.0* |
| tkg-storageclass-package | v0.28.1-tkg-storageclass* | v0.28.0-tkg-storageclass* |
| tkg_telemetry | v2.1.1+vmware.1* | v2.1.0+vmware.1* |
| velero | v1.9.5+vmware.1 | v1.9.5+vmware.1* |
| velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 | v0.1.0+vmware.1 |
| velero-plugin-for-aws | v1.5.3+vmware.1 | v1.5.3+vmware.1* |
| velero-plugin-for-csi | v0.3.3+vmware.1 | v0.3.3+vmware.1* |
| velero-plugin-for-microsoft-azure | v1.5.3+vmware.1 | v1.5.3+vmware.1* |
| velero-plugin-for-vsphere | v1.4.2+vmware.1 | v1.4.2+vmware.1* |
| vendir | v0.30.1+vmware.1 | v0.30.1+vmware.1* |
| vsphere_csi_driver | v2.6.2+vmware.2 | v2.6.2+vmware.2* |
| whereabouts | v0.5.4+vmware.1 | v0.5.4+vmware.1* |
* 表示自先前版本以來新增的元件或版本更新。TKG v2.1.0 是 v2.1.1 之前的版本，而 v1.6.1 是 v2.1.0 之前的版本。
如需 TKG v2.1 隨附的軟體元件版本的完整清單，請使用 imgpkg 提取存放庫服務包，然後列出其內容。對於 TKG v2.1.1，例如：
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.1.1 -o standard-2.1.1
cd standard-2.1.1/packages
tree
如以下所列的本機 BOM 檔案也會列出套件版本，但可能不是最新的：
~/.config/tanzu/tkg/bom/tkg-bom-v2.1.yaml~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml
支援的升級路徑
在 TKG 升級路徑中，v2.1 緊接在 v1.6 之後。TKG v2.0 不是可下載的 TKG 版本：它是內嵌于 vSphere 8 中vSphere with Tanzu主管中的 TKG 版本。
您只能從 v1.6.x 升級到 Tanzu Kubernetes Grid v2.1.x。如果要從早於 v1.6.x 的版本升級到 Tanzu Kubernetes Grid v2.1.x，必須先升級到 v1.6.x。
在工作負載叢集上升級 Kubernetes 版本時，無法跳過次要版本。例如，您無法將 Tanzu Kubernetes 叢集直接從 v1.21.x 升級到 v1.23.x。您必須先將 v1.21.x 叢集升級到 v1.22.x，然後再將叢集升級到 v1.23.x。
發行日期
Tanzu Kubernetes Grid v2.1 發行日期為：
- v2.1.0：2023 年 1 月 29 日
- v2.1.1：2023 年 3 月 21 日
Tanzu Kubernetes Grid v2.1 中的行為變更
相較於 v1.6.1 (先前的最新版本)，Tanzu Kubernetes Grid v2.1 中引入了下列的新行為。
tanzu cluster list的--include-management-cluster選項需要-A選項，以列出獨立管理叢集。當含有-A選項時，該命令會列出所有命名空間中的叢集。-
依預設，Tanzu CLI
package外掛程式會使用kctrl樣式的命令。請參閱〈Tanzu CLI 命令參考〉中的包含 kctrl 的 Tanzu 套件。- 在 TKG v1.6 中，
package外掛程式預設在停用kctrl模式下執行，下面稱為舊版模式。 -
kctrl模式和舊版模式命令不同，如下所示：- 如要為套件組態建立預設值檔，
kctrl-styletanzu package available get命令使用旗標--generate-default-values-file而不是--default-values-file-output。 --create-namespace旗標已移除。如果使用-n或--namespace指定目標命名空間，則命名空間必須已存在。--create旗標已針對package repository update移除。--package-name旗標已針--package和package installed create重新命名為package install。--install旗標已針對package installed update移除。--verbose全域旗標已移除。--poll-interval和-poll-timeout旗標已重新命名為--wait-interval和--wait-timeout。- 在
package available get輸出中，另一個表格列出套件的可用版本。 - 在
package available list輸出中，移除了LATEST-VERSION列，預設情況下不顯示SHORT-DESCRIPTION；可使用--wide旗標進行顯示。 - 在
package repository list輸出中，REPOSITORY和TAG欄將取代為包含來源類型 (例如imgpkg）、存放庫 URL 和標記的SOURCE欄。
- 如要為套件組態建立預設值檔，
-
請參閱 TKG v1.6 說明文件中 CLI 管理的套件下的主題，瞭解
tanzu package外掛程式如何在停用kctrl模式的情況下運作。
- 在 TKG v1.6 中，
tanzu-standard套件存放庫沒有預先安裝在以類別為基礎的叢集上。若要新增套件存放庫，請參閱新增套件存放庫。- Tanzu CLI 管理叢集建立程序不再支援建立新的 VPC。安裝程式介面不包含用來建立新 VPC 的選項，且叢集組態檔不再支援
AWS_*選項，來為指定的 CIDR 建立新的 VPC。如果要使用新的 VPC，當您在 AWS 上部署獨立管理叢集之前，必須先使用 AWS 主控台建立 VPC 以進行 TKG 部署。 -
Tanzu CLI 會使用新的目標抽象化，以將不同的命令群組與套用這些命令的伺服器類型產生關聯。
tanzu context list命令會參照與具有--target旗標的內容類型相同的概念。由於命令群組是以 CLI 外掛程式為基礎，因此：- 為 Kubernetes 叢集定義命令的外掛程式會有目標
k8s - 為 TMC 命令定義命令的外掛程式保留了目標
tmc，以供將來使用 - 會定義與內容無關的命令的外掛程式不會有目標
- 因不同目標有同名的外掛程式，可讓 Tanzu CLI 依命令群組 (如
tanzu cluster) 來調整命令，以符合內容。
在 TKG v2.1 中，唯一支援的目標或內容類型為
k8s，這也會用以下內容表示：tanzu help命令輸出中的Kubernetes cluster operationstanzu plugin list輸出中TARGET資料行中的kubernetes
- 為 Kubernetes 叢集定義命令的外掛程式會有目標
- VMware 不建議部署只有 Windows 系統的工作節點的 Windows 工作負載叢集，如 TKG v1.6 說明文件中所述。相反的，VMware 則建議建立多重作業系統叢集，如部署多重作業系統工作負載叢集中所述。多重作業系統叢集可以同時執行 Windows 和 Linux 容器，從而同時支援 Linux 系統的 TKG 元件和 Linux 工作負載。
- 由於 Go v1.18 中的憑證處理有所改變，MacOS 啟動機器需要先將 vCenter 憑證新增至其金鑰鏈中，然後才能透過指紋驗證執行
tanzu cluster create；請參閱叢集部署的必要條件。
使用者說明文件
新出版物部署和管理 TKG 2.1 獨立管理叢集中含有獨立管理叢集的特定主題，這些主題與「將 TKG 與 vSphere with Tanzu 主管搭配使用」無關。
如需詳細資訊，請參閱《VMware Tanzu Kubernetes Grid 說明文件》頁面上的尋找適合您部署的 TKG 文件。
已解決的問題
已在 v2.1.1 中解決
以下是在 Tanzu Kubernetes Grid v2.1.0 中記錄成「已知問題」，但已在 Tanzu Kubernetes Grid v2.1.1 中解決的問題。
-
CNI:none選項不適用於從獨立管理叢集部署的工作負載叢集。唯一可用的選項是antrea(預設) 和calico。 -
TKG 的 vSphere 帳戶會建立閒置的 vCenter 工作階段，如 vSphere > 主機和叢集 (Hosts and Clusters) 詳細目錄 > 您的 vCenter (your vCenter) > 監控 (Monitor) 索引標籤 > 工作階段 (Sessions) 中所列。
因應措施：透過啟動和停止所有工作階段來移除閒置的 vCenter 工作階段：
- 透過
ssh以root使用者身分登入 vCenter - 如果出現提示，請輸入
shell - 執行
service-control --stop --all - 等待服務顯示為
Stopped - 執行
service-control --start --all
- 透過
-
在 Azure 上，以類別為基礎的工作負載叢集的
LoadBalancer服務需要進行手動閘道或前端設定由於
AzureClusterName與ClusterName之間的名稱不相符，而無法從網際網路來存取LoadBalancer類型的服務，這類服務是為了供以類別為基礎的 Azure 工作負載叢集上的應用程式使用而部署。因應措施：針對負載平衡器服務，提供您自己的路由 (例如，透過 NAT 閘道、Proxy 或其他內部路由)，以允許負載平衡器後面的節點存取網際網路。
VMware 建議使用 NAT 閘道 (如果可用) 來進行輸出連線。如果 NAT 閘道無法使用：
- 從 Azure 入口網站，導覽至 CAPZ 所建立的
LoadBalancer資源，該資源應與AzureCluster的名稱相同。 - 選取前端 IP 組態 (Frontend IP configuration)，然後按一下新增 (Add)。
- 為負載平衡器服務建立新的公用 IP 位址。
-
使用以下規格來設定及建立服務，其中，將
loadBalancerIP值設定為IP-ADDRESS所指示的公用 IP 位址：apiVersion: v1 kind: Service metadata: name: frontend labels: app: guestbook tier: frontend namespace: sample-app spec: # Add the frontend public IP here loadBalancerIP: IP-ADDRESS type: LoadBalancer ports: - port: 80 selector: app: guestbook tier: frontend
- 從 Azure 入口網站，導覽至 CAPZ 所建立的
-
將獨立管理叢集和工作負載叢集升級到 v2.1，並不會將其
kube-vip升級到目前版本。因應措施：如果已升級的叢集使用 Kube-VIP 作為控制平面端點 (亦即，設定了
AVI_CONTROL_PLANE_HA_PROVIDER = false)，請更新kube-vip元件：-
擷取用於叢集升級的目前 TKr BoM 檔案。在
~/.config/tanzu/tkg/bom/尋找此檔案的本機複本，其檔名以tkr-開頭。例如，tkr-bom-v1.24.10+vmware.1-tkg.1.yaml。 -
列出 BoM 檔案中的目前
kube-vip版本，例如：$ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml | yq '.components.kube-vip' - version: v0.5.7+vmware.1 images: kubeVipImage: imagePath: kube-vip tag: v0.5.7_vmware.1 -
為叢集取得
kcp物件。此物件的名稱格式為CLUSTER-NAME-control-plane。- 管理叢集物件會建立在 tkg-system 命名空間中。
- 工作負載叢集物件位於用來建立叢集的命名空間中，如果未設定
NAMESPACE，則是default。
-
執行
kubectl edit，以編輯kcp物件，並更新kube-vip的路徑，以與 BoM 映像中的目前版本相符。藉由執行以下命令，尋找這項設定的位置：kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
-
-
將管理叢集從 v1.5.x 升級到 v2.1.0 會導致節點網路錯誤，因為 AKO Operator 密鑰中的
avi_ingress_node_network_list為空值對於最初在 TKG v1.5 或更早版本中建立的獨立管理叢集，升級到 v2.1.0 會將 AKO Operator 密鑰中的
avi_ingress_node_network_list設定為空值。這會導致升級至 v2.1.0 時出現節點網路錯誤，並在記錄中產生缺少 Avi 組態錯誤。因應措施：將 Tanzu CLI 升級至 v2.1.0 後，但在執行
tanzu mc upgrade之前：-
切換為管理叢集內容：
kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER> -
擷取 AKO Operator 密鑰並對其資料值進行解碼：
kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml -
使用文字編輯器開啟
values.yaml檔案。avi_ingress_node_network_list設定如下所示：avi_ingress_node_network_list: '""' -
使用叢集節點網路的範圍，將設定變更為類似以下的內容：
avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]' -
對新的資料值進行 base64 編碼，並記錄輸出字串：
base64 -w 0 values.yaml -
編輯 AKO Operator 密鑰：
kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system -
貼上新的編碼資料值字串作為密鑰中的
values.yaml值。儲存並結束。
-
-
TMC 無法使用不在
Default-GroupSEG 的服務引擎部署以類別為基礎的叢集。與 TKG 整合的 Tanzu Mission Control 無法部署使用 NSX ALB 且設為使用不在 NSX ALB 中
Default-Group服務引擎群組中的服務引擎之以類別為基礎的新叢集。對於設定了自訂服務引擎的現有工作負載叢集，這項限制不會影響其升級。如需詳細資訊，請參閱 Tanzu Mission Control 版本說明。
-
您無法使用 Tanzu Mission Control (TMC) 的目錄功能，將套件列出或安裝到 TKG v2.1 工作負載叢集，如 TMC 說明文件中的檢視套件所述。TMC UI 將顯示套件存放庫停滯在協調狀態。
已在 v2.1.0 中解決
以下是在 Tanzu Kubernetes Grid v1.6.1 中記錄成「已知問題」，但已在 Tanzu Kubernetes Grid v2.1.0 中解決的問題。
-
如果將 DaemonSet 設定為自動還原持續性磁碟區，則會刪除網繭的叢集和網繭作業可能會失敗
在 DaemonSet 使用持續性磁碟區 (PV) 的安裝中，機器刪除作業可能會失敗，因為依預設，清空程序會忽略 DaemonSet，且系統會無限期地等待磁碟區與節點中斷連結。受影響的叢集作業包括升級、縮減和刪除。
-
在 vSphere with Tanzu 上，對於 DevOps 使用者，
tanzu cluster list會產生錯誤當具有 DevOps 工程師角色的使用者依照 vSphere with Tanzu 使用者角色和工作流程中所述，執行
tanzu cluster list時，他們可能會看到類似如下的錯誤：Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope。發生這種情況的原因是，不帶
-n選項的tanzu cluster command會嘗試存取所有命名空間，而其中有些命名空間可能是 DevOps 工程師使用者無法存取的。因應措施：執行
tanzu cluster list時，請包含--namespace值，以指定使用者可以存取的命名空間。
已知問題
以下是 Tanzu Kubernetes Grid v2.1.x 中的已知問題。在後續 v2.1.x 修補程式發行版本中解決的存在於 v2.1.1 中的任何已知問題，都列在修正這些問題的修補程式發行版本的已解決的問題之下。
升級
v2.1.1 中的已知問題
以下是 v2.1.1 中的已知升級問題。
-
在 vSphere 上無法從 v2.1 升級至 v2.1.1
在 vSphere 上無法從 v2.1 升級至 v2.1.1，並顯示錯誤
Reconcile failed:Error。出現此錯誤的原因是，tkg-clusterclass-vsphere套件無法協調且安裝遭到封鎖。因應措施：如果在本機環境中設定了下列 vSphere 資源變數，請取消設定：
unset VSPHERE_CLONE_MODE unset VSPHERE_DATACENTER unset VSPHERE_DATASTORE unset VSPHERE_FOLDER unset VSPHERE_NETWORK unset VSPHERE_RESOURCE_POOL unset VSPHERE_SERVER unset VSPHERE_STORAGE_POLICY_ID unset VSPHERE_TEMPLATE unset VSPHERE_WORKER_DISK_GIB unset VSPHERE_WORKER_MEM_MIB unset VSPHERE_WORKER_NUM_CPUS
v2.1.x 中的已知問題
以下是 v2.1.x 中的已知升級問題。
-
在 Azure 上，升級管理叢集和工作負載叢集失敗，並顯示
context deadline exceeded或unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane等錯誤。發生這種情況的原因是，作業在 Azure 上的執行時間有時比在其他平台上還久。因應措施：重新執行
tanzu management-cluster upgrade或tanzu cluster upgrade，並在--timeout旗標中指定更長的逾時值。預設逾時為 30m0s。 -
對於最初建立於 TKG v1.3 或更早版本中的獨立管理叢集，升級會失敗
在 TKG v2.1 中，將一般叢集轉換為 TKG 獨立管理叢集的元件會封裝在 Carvel 套件
tkg-pkg中。最初建立於 TKG v1.3 或更早版本中的獨立管理叢集缺少一個組態密鑰，而升級程序在安裝tkg-pkg時需要此密鑰，從而導致升級失敗。因應措施：針對建立於 TKG v1.3 或更早版本中的獨立管理叢集，執行升級獨立管理叢集中列出的其他步驟。
-
如果在
TKG_NO_PROXY設定中使用萬用字元 (*) 來建立叢集，則升級會失敗TKG v1.6 不允許在
TKG_NO_PROXY的叢集組態檔設定中使用萬用字元 (*)。對於先前 TKG 版本利用此設定所建立的叢集，則需要在升級之前進行特殊處理，以避免出現workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY錯誤。因應措施：根據您要升級的叢集類型：
-
管理叢集：
- 切換到管理叢集
kubectl內容。 -
編輯 configMap kapp-controller-config：
kubectl edit cm kapp-controller-config -n tkg-system -
尋找
data.noProxy欄位，然後移除*，以變更其萬用字元主機名稱。例如，變更*.vmware.com to.vmware.com -
儲存並結束。叢集已準備好進行升級。
- 切換到管理叢集
-
工作負載叢集：
- 切換到工作負載叢集
kubectl內容 -
設定您的叢集名稱和命名空間的環境變數，例如：
CLUSTER_NAME=my-test-cluster NS=my-test-namespace -
取得工作負載叢集的 kapp 控制器資料值，並進行解碼：
kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" -
編輯
${CLUSTER_NAME}-${NS}-kapp-controller-data-values檔案，亦即將*從kappController.config.noProxy設定中移除。例如，將*.vmware.com to變更為.vmware.com。 - 儲存並結束。
-
對資料值檔案
${CLUSTER_NAME}-${NS}-kapp-controller-data-values重新編碼：cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0 -
編輯
${CLUSTER_NAME}-${NS}-kapp-controller-data-values密鑰，並貼上新編碼的資料值字串，來更新其data.value.yaml設定。kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}" -
儲存並結束。叢集已準備好進行升級。
- 切換到工作負載叢集
-
-
將獨立管理叢集從 TKG v1.6 升級到 v2.1 時，會將 Tkr 原始碼控制器取代為可支援以類別為基礎的叢集的新版本，然後重新同步 TKr。因此，
tanzu mc upgrade命令完成後，tanzu cluster available-upgrades get和tanzu kubernetes-release get可能不會顯示所有有效的 TKr 版本，且 Tanzu CLI 可能無法立即升級工作負載叢集。因應措施：請等待幾分鐘以重新下載 TKr。
套件
-
以下版本中的已知問題：v2.1.1
適用於 TKG v2.1.1 的 Tanzu Standard 套件存放庫缺少 v2.1.0 存放庫中的下列套件版本：
cert-manager：1.10.1+vmware.1-tkg.1.yml、1.5.3+vmware.7-tkg.1.yml和1.7.2+vmware.3-tkg.1.ymlexternal-dns：0.10.0+vmware.1-tkg.3.yml、0.11.0+vmware.1-tkg.3.yml和0.12.2+vmware.4-tkg.1.ymlgrafana：7.5.16+vmware.1-tkg.2.yml
因此，將工作負載叢集從 TKG v2.1.0 升級至 v2.1.1 後，如果不將套件升級至最新版本，則無法執行
tanzu package installed update來更新這些套件的組態：cert-manager：1.10.1+vmware.1-tkg.2.ymlexternal-dns：0.12.2+vmware.4-tkg.2.ymlgrafana：7.5.17+vmware.1-tkg.1.yml
只有在您需要變更套件組態時才會出現此問題；已安裝的套件會在沒有升級的情況下繼續執行。
因應措施：請執行下列其中一項作業：
-
如果您需要更新
cert-manager、external-dns或grafana套件組態：- 執行
tanzu package installed get以擷取套件的版本。 - 如上所述，如果 v2.1.1 存放庫缺少已安裝的套件版本，請在執行
tanzu package installed update時，將最新版本傳遞至-v旗標。
- 執行
-
將工作負載叢集升級至 TKG v2.1.1 後，將三個套件更新至上述版本。
有關
tanzu package命令，請參閱安裝和管理套件中所述內容。 -
在具有 NSX Advanced Load Balancer 的
medium和小型 Pod 上，Multus CNI 執行失敗在 vSphere 上，如果工作負載叢集具有
medium或小型工作節點，且這些節點將 Multus CNI 套件與 NSX ALB 搭配執行，則可能因Insufficient CPU或其他錯誤而失敗。因應措施：若要將 Multus CNI 與 NSX ALB 搭配使用，在部署工作負載叢集時，請包含
large或extra-large大小的工作節點。 -
TKG BoM 檔案包含無關的 cert-manager 套件版本
Tanzu CLI 安裝到
~/.config/tanzu/tkg的 TKG 用料表清單 (BOM) 檔案同時列出了cert manager(jetstack_cert-manager) 套件的 v1.5.3 和 v1.7.2 版本。要安裝的正確版本是 v1.5.3，如安裝 cert-manager 中所述。因應措施：安裝
cert-managerv1.5.3。 -
如果停用 Pinniped，則需要在舊版叢集上手動刪除
Secret當您在管理叢集上停用外部身分識別管理時，未用的 Pinniped
Secret物件仍存在於舊版工作負載叢集上。之後若是使用者嘗試使用舊有
kubeconfig來存取叢集，則會顯示登入快顯視窗，並且失敗。因應措施：手動刪除舊版叢集的 Pinniped
Secret，如停用身分識別管理中所述。 -
當執行 ID 超過 1000000 時，Harbor CVE 匯出可能會失敗
Harbor v2.6.3 (TKG v2.1 封裝的版本) 存在已知問題，即在執行主要金鑰時自動增量 ID 到 1000000+ 時，CVE 報告匯出錯誤「找不到 404 (404 page not found)」。
此 Harbor 問題已在更高版本的 Harbor 中解決，並準備包含在更高版本的 TKG 中。
-
您無法在網際網路受限的環境中，將 Harbor 的 Proxy 快取功能用於執行 Tanzu Kubernetes Grid v2.1。您仍然可以使用 Harbor Proxy 快取來代理 Tanzu Kubernetes Grid 之前版本中的映像，以及應用程式映像等非 Tanzu 映像。
因應措施：無
-
對於 TKG 上處於不支援的技術預覽狀態的 PSA 控制器，某些 TKG 套件不符合預設的
baseline設定檔。因應措施：在受影響的套件命名空間中設定
audit=privileged和warn=privileged標籤，如網繭安全性許可控制器 (技術預覽) 中所述。 -
執行
tanzu package repository add將tanzu-standard存放庫新增至 vSphere 上的單節點叢集 (技術預覽) 中所述類型的單節點叢集可能會失敗。發生這種情況的原因是，單節點叢集會使用
cert-manager作為核心附加元件進行開機，這與tanzu-standard存放庫中不同的cert-manager套件相衝突。因應措施：在新增
tanzu-standard存放庫之前，請依照安裝 cert-manager 中所述修補cert-manager套件註解。
叢集作業
v2.1.1 中的已知問題
以下是 v2.1.1 中的已知叢集作業問題。
-
無法根據具有 Antrea CNI 的非目前 TKr 版本建立新的工作負載叢集
您無法建立使用 Antrea CNI 並執行先前版本 TKG 隨附的 Kubernetes 版本 (如 Kubernetes v1.23.10) 的新工作負載叢集，這是 TKG v1.6.1 中預設的 Kubernetes 版本，如 Tanzu Kubernetes Grid v2.1 中支援的 Kubernetes 版本所列。
TKG v2.1.1 完全支援執行舊版 Kubernetes 的現有叢集。
因應措施：建立執行 Kubernetes 1.24.10、1.23.16 或 1.22.17 的工作負載叢集。Kubernetes 專案建議您在目前任何次要版本的最新修補程式版本上執行元件。
v2.1 中的已知問題
-
tanzu cluster create不會正確驗證使用非預設 Kubernetes 版本產生的叢集規格如果使用建立以類別為基礎的叢集中所述的兩個步驟之一從組態檔建立以類別為基礎的工作負載叢集，並在第一步中指定
--tkr值以將叢集建立在非預設版本的 Kubernetes 上時，第二步可能會失敗，並顯示驗證錯誤。因應措施：在第二步中，當您第二次執行
tanzu cluster create並傳遞產生的叢集清單時，請指定您在第一步中所做的相同--tkr值和其他選項，如建立以類別為基礎的叢集中所述。 -
由於叢集 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」。
-
從舊版組態檔建立
ClusterClass組態檔，--dry-run包括空的 Antrea 組態使用包含
ANTREA_NODEPORTLOCAL項目的舊版組態檔配置檔，透過tanzu cluster create --dry-run -f建立ClusterClass會導致自動產生的 Antrea 組態不包含任何標籤，導致 Antrea 無法成功協調。發生這種情況的原因是，在 TKG 2.1.1 中，AntreaConfig資源需要tkg.tanzu.vmware.com/package-name label以便附加元件管理器在指定的工作負載叢集中安裝 Antrea。此問題不適用於 2.1.0。因應措施：將缺少的標籤新增到
ClusterClass組態檔中的AntreaConfig，然後再次嘗試建立叢集：labels: tkg.tanzu.vmware.com/cluster-name: rito tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced -
TKG v2.1 在 vSphere 8 上不支援 IPv6 網路，但是在 vSphere 7 上它支援使用 Kube-Vip 來建立單堆疊 IPv6 網路 (如 IPv6 網路中所述)。
因應措施：如果您需要或目前正在 vSphere 上的 IPv6 環境中使用 TKG，請不要安裝或升級到 vSphere 8。
-
管理叢集不支援 NSX ALB
NodePortLocal輸入模式在 TKG v2.1 中，當使用入口模式
NodePortLocal來將流量傳輸至管理叢集時，您無法將 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 驗證來登入工作負載叢集。
因應措施：重建管理叢集後，請依照在現有部署中啟用和設定身分識別管理中所述，來重新設定身分識別管理。
儲存區
-
如果變更預設
StorageClass物件，會導致工作負載叢集中的協調失敗如果修改 TKG 中包含的預設
StorageClass物件的內容，會導致在使用該儲存區類別的工作負載叢集中，套件協調失敗。因應措施：若要自訂儲存區類別，請使用不同的
StorageClass來建立新的name定義 (而不是修改預設物件定義)，然後將叢集重新設定為使用新的儲存區類別。 -
無法啟用工作負載叢集以在多個資料存放區分配儲存，如部署使用資料存放區的叢集中所述。如果將資料存放區叢集中的多個資料存放區標記為工作負載叢集儲存原則的基礎，則工作負載叢集僅使用其中一個資料存放區。
因應措施：無
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 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時，也可能出現此錯誤。因應措施：將錯誤輸出中列出的一或多個組態參數設定為本機環境變數。或者，若要避免此錯誤，您可以在一個步驟中建立以類別為基礎的叢集，而無需預覽其組態，其方法是將
auto-apply-generated-clusterclass-based-configuration功能設定為true，然後執行tanzu cluster create。若要將auto-apply-generated-clusterclass-based-configuration設定為true，請執行：tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration true這會將 Tanzu CLI 設定為始終在一個步驟中建立以類別為基礎的叢集。如需詳細資訊，請參閱建立以類別為基礎的叢集。
-
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 以用於服務登錄中所述。 -
在 Windows 命令提示字元 (CMD) 中，Tanzu CLI 命令輸出 (採資料行格式) 在資料行標題中包含了無關字元。
Windows 終端機或 PowerShell 中不會出現此問題。
因應措施：在 Windows 啟動機器上，從 Windows 終端機執行 Tanzu CLI。
-
建立管理叢集期間，發生可忽略的
AKODeploymentConfig錯誤執行
tanzu management-cluster create以建立具有 NSX ALB 的管理叢集時，輸出了以下錯誤：no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???。可忽略此錯誤。如需詳細資訊，請參閱知識庫中的這篇文章。 -
在 vSphere 上建立工作負載叢集期間，發生可忽略的
machinehealthcheck和clusterresourceset錯誤當使用
tanzu cluster create命令，透過 vSphere with Tanzu 將工作負載叢集部署到 vSphere 時，輸出中可能包含錯誤，且這些錯誤與執行machinehealthcheck和存取clusterresourceset資源有關，如下所示：Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg" ... Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet" ...已成功建立工作負載叢集。您可以忽略這些錯誤。
-
停用機器健全狀況檢查 (MHC) 後，在重建基礎結構期間，Tanzu CLI 命令 (例如
tanzu cluster status) 可能不會報告最新的節點狀態。因應措施：無
vSphere
-
使用
small節點來建立的節點集區可能會停滯在Provisioning狀態。建立節點集區時，如果將節點
SIZE設定為small，則集區可能停滯在Provisioning狀態，且永遠不會進入Running狀態。因應措施：將節點集區設定成至少具有
medium大小的節點。 -
如果您使用 NSX Advanced Load Balancer 來處理工作負載 (
AVI_ENABLE) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER)，Avi 控制器可能無法區分同名的叢集。因應措施：請為每個叢集設定唯一的
CLUSTER_NAME值：-
管理叢集：即使是從不同的啟動機器來建立多個管理叢集，也不要使用相同的
CLUSTER_NAME值。 -
工作負載叢集：請勿建立多個具有相同
CLUSTER_NAME且位於同一管理叢集命名空間 (如其NAMESPACE值所設定) 的工作負載叢集。
-
-
將外部身分識別管理新增到現有部署時，可能需要設定虛設的
VSPHERE_CONTROL_PLANE_ENDPOINT值若要將外部身分識別提供者與現有 TKG 部署整合在一起，可能需要在用來建立附加元件密鑰的管理叢集組態檔中，設定一個虛設的
VSPHERE_CONTROL_PLANE_ENDPOINT值，如為管理叢集產生 Pinniped 附加元件密鑰中所述
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 和多重作業系統工作負載叢集
-
由於 Kubernetes Image Builder 使用的開放原始碼
packer公用程式有問題，您無法在 MacOS 機器上建置 Windows 機器映像，如 Windows 自訂機器映像中所述。因應措施：請使用 Linux 機器來建置自訂的 Windows 機器映像。
-
您無法備份和還原具有 Windows 系統的工作節點的工作負載叢集。
因應措施：無
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 支援。
