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 的版本。
  • 組態變數：
    • 機器健全狀況檢查：MHC_MAX_UNHEALTHY_CONTROL_PLANE 和 MHC_MAX_UNHEALTHY_WORKER_NODE。如需詳細資訊，請參閱組態檔變數參考中的機器健全狀況檢查。
    • 支援具有自訂憑證的 tdnf 伺服器：CUSTOM_TDNF_REPOSITORY_CERTIFICATE (技術預覽)。如需詳細資訊，請參閱組態檔變數參考中的節點組態。
    • 支援節點層級 Proxy 設定：TKG_NODE_SYSTEM_WIDE_PROXY (技術預覽)。如需詳細資訊，請參閱組態檔變數參考中的 Proxy 組態。

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 中的行為變更。
  • (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 上的單節點叢集 (技術預覽) 中所述。
    • 您可以部署以 tiny TKr 為基礎的最小單節點叢集，將磁碟使用量減至最小。
  • 您可以備份及部署叢集基礎結構，如備份和還原管理叢集和工作負載叢集的基礎結構中所述 (技術預覽)。
  • 支援「網繭安全性許可 (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
基礎結構平台
  • vSphere 6.7U3
  • vSphere 7
  • vSphere 8
  • VMware Cloud on AWS**
  • Azure VMware 解決方案
  • Oracle Cloud VMware Solution (OCVS)
  • Google Cloud VMware Engine (GCVE)
 原生 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-style tanzu 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 模式的情況下運作。

  • 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 operations
    • tanzu plugin list 輸出中 TARGET 資料行中的 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

    CNI:none 選項不適用於從獨立管理叢集部署的工作負載叢集。唯一可用的選項是 antrea (預設) 和 calico。

  • TKG 使用者帳戶建立閒置的 vCenter 工作階段

    TKG 的 vSphere 帳戶會建立閒置的 vCenter 工作階段，如 vSphere > 主機和叢集 (Hosts and Clusters) 詳細目錄 > 您的 vCenter (your vCenter) > 監控 (Monitor) 索引標籤 > 工作階段 (Sessions) 中所列。

    因應措施：透過啟動和停止所有工作階段來移除閒置的 vCenter 工作階段：

    1. 透過 ssh 以 root 使用者身分登入 vCenter
    2. 如果出現提示，請輸入 shell
    3. 執行 service-control --stop --all
    4. 等待服務顯示為 Stopped
    5. 執行 service-control --start --all

  • 在 Azure 上，以類別為基礎的工作負載叢集的 LoadBalancer 服務需要進行手動閘道或前端設定

    由於 AzureClusterName 與 ClusterName 之間的名稱不相符，而無法從網際網路來存取 LoadBalancer 類型的服務，這類服務是為了供以類別為基礎的 Azure 工作負載叢集上的應用程式使用而部署。

    因應措施：針對負載平衡器服務，提供您自己的路由 (例如，透過 NAT 閘道、Proxy 或其他內部路由)，以允許負載平衡器後面的節點存取網際網路。

    VMware 建議使用 NAT 閘道 (如果可用) 來進行輸出連線。如果 NAT 閘道無法使用：

    1. 從 Azure 入口網站，導覽至 CAPZ 所建立的 LoadBalancer 資源，該資源應與 AzureCluster 的名稱相同。
    2. 選取前端 IP 組態 (Frontend IP configuration)，然後按一下新增 (Add)。
    3. 為負載平衡器服務建立新的公用 IP 位址。

    4. 使用以下規格來設定及建立服務，其中，將 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

  • 升級叢集時，不會更新 Kube-VIP 版本

    將獨立管理叢集和工作負載叢集升級到 v2.1，並不會將其 kube-vip 升級到目前版本。

    因應措施：如果已升級的叢集使用 Kube-VIP 作為控制平面端點 (亦即，設定了 AVI_CONTROL_PLANE_HA_PROVIDER = false)，請更新 kube-vip 元件：

    1. 擷取用於叢集升級的目前 TKr BoM 檔案。在 ~/.config/tanzu/tkg/bom/ 尋找此檔案的本機複本，其檔名以 tkr- 開頭。例如，tkr-bom-v1.24.10+vmware.1-tkg.1.yaml。

    2. 列出 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

    3. 為叢集取得 kcp 物件。此物件的名稱格式為 CLUSTER-NAME-control-plane。

      • 管理叢集物件會建立在 tkg-system 命名空間中。
      • 工作負載叢集物件位於用來建立叢集的命名空間中，如果未設定 NAMESPACE，則是 default。

    4. 執行 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 之前：

    1. 切換為管理叢集內容：

      kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER>

    2. 擷取 AKO Operator 密鑰並對其資料值進行解碼：

      kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml

    3. 使用文字編輯器開啟 values.yaml 檔案。avi_ingress_node_network_list 設定如下所示：

      avi_ingress_node_network_list: '""'

    4. 使用叢集節點網路的範圍，將設定變更為類似以下的內容：

      avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]'

    5. 對新的資料值進行 base64 編碼，並記錄輸出字串：

      base64 -w 0 values.yaml

    6. 編輯 AKO Operator 密鑰：

      kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system

    7. 貼上新的編碼資料值字串作為密鑰中的 values.yaml 值。儲存並結束。

  • TMC 無法使用不在 Default-Group SEG 的服務引擎部署以類別為基礎的叢集。

    與 TKG 整合的 Tanzu Mission Control 無法部署使用 NSX ALB 且設為使用不在 NSX ALB 中 Default-Group 服務引擎群組中的服務引擎之以類別為基礎的新叢集。對於設定了自訂服務引擎的現有工作負載叢集，這項限制不會影響其升級。

    如需詳細資訊，請參閱 Tanzu Mission Control 版本說明。

  • TMC 目錄不支援列出和部署套件

    您無法使用 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 上升級叢集失敗

    在 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 錯誤。

    因應措施：根據您要升級的叢集類型：

    • 管理叢集：

      1. 切換到管理叢集 kubectl 內容。

      2. 編輯 configMap kapp-controller-config：

        kubectl edit cm kapp-controller-config -n tkg-system

      3. 尋找 data.noProxy 欄位，然後移除 *，以變更其萬用字元主機名稱。例如，變更 *.vmware.com to .vmware.com

      4. 儲存並結束。叢集已準備好進行升級。

    • 工作負載叢集：

      1. 切換到工作負載叢集 kubectl 內容

      2. 設定您的叢集名稱和命名空間的環境變數，例如：

        CLUSTER_NAME=my-test-cluster
NS=my-test-namespace

      3. 取得工作負載叢集的 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"

      4. 編輯 ${CLUSTER_NAME}-${NS}-kapp-controller-data-values 檔案，亦即將 * 從 kappController.config.noProxy 設定中移除。例如，將 *.vmware.com to 變更為 .vmware.com。

      5. 儲存並結束。

      6. 對資料值檔案 ${CLUSTER_NAME}-${NS}-kapp-controller-data-values 重新編碼：

        cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0

      7. 編輯 ${CLUSTER_NAME}-${NS}-kapp-controller-data-values 密鑰，並貼上新編碼的資料值字串，來更新其 data.value.yaml 設定。

        kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"

      8. 儲存並結束。叢集已準備好進行升級。

  • 獨立管理叢集升級後，舊版 Tkr 並沒有立即可用

    將獨立管理叢集從 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.yml
    • external-dns：0.10.0+vmware.1-tkg.3.yml、0.11.0+vmware.1-tkg.3.yml 和 0.12.2+vmware.4-tkg.1.yml
    • grafana：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.yml
    • external-dns：0.12.2+vmware.4-tkg.2.yml
    • grafana：7.5.17+vmware.1-tkg.1.yml

    只有在您需要變更套件組態時才會出現此問題；已安裝的套件會在沒有升級的情況下繼續執行。

    因應措施：請執行下列其中一項作業：

    • 如果您需要更新 cert-manager、external-dns 或 grafana 套件組態：

      1. 執行 tanzu package installed get 以擷取套件的版本。
      2. 如上所述，如果 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-manager v1.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 快取

    您無法在網際網路受限的環境中，將 Harbor 的 Proxy 快取功能用於執行 Tanzu Kubernetes Grid v2.1。您仍然可以使用 Harbor Proxy 快取來代理 Tanzu Kubernetes Grid 之前版本中的映像，以及應用程式映像等非 Tanzu 映像。

    因應措施：無

  • 套件不符合預設的基準 PSA 設定檔

    對於 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 值和其他選項，如建立以類別為基礎的叢集中所述。

  • 以類別為基礎的叢集的 Autoscaler 需要手動註解

    由於叢集 API 中的標籤傳播問題，以類別為基礎的工作負載叢集的叢集組態檔中的 AUTOSCALER_MIN_SIZE_* 和 AUTOSCALER_MAX_SIZE_* 設定並未設定在叢集的 MachineDeployment 物件中。

    因應措施：在建立以類別為基礎的工作負載叢集並啟用 Cluster Autoscaler 後，請針對每個 AZ，手動新增機器計數下限和上限設定，如手動新增大小下限和上限註解中所述。

  • 節點集區 labels 和其他組態內容無法變更

    您無法新增或變更現有節點集區的 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

  • 在 vSphere 8 上不支援 IPv6 網路

    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 或更新版本搭配使用。

身分識別和存取管理

儲存區

  • 如果變更預設 StorageClass 物件，會導致工作負載叢集中的協調失敗

    如果修改 TKG 中包含的預設 StorageClass 物件的內容，會導致在使用該儲存區類別的工作負載叢集中，套件協調失敗。

    因應措施：若要自訂儲存區類別，請使用不同的 StorageClass 來建立新的 name 定義 (而不是修改預設物件定義)，然後將叢集重新設定為使用新的儲存區類別。

  • 工作負載叢集無法跨多個資料存放區分配儲存

    無法啟用工作負載叢集以在多個資料存放區分配儲存，如部署使用資料存放區的叢集中所述。如果將資料存放區叢集中的多個資料存放區標記為工作負載叢集儲存原則的基礎，則工作負載叢集僅使用其中一個資料存放區。

    因應措施：無

CLI

  • HTTP/HTTPS Proxy 密碼中不能使用非英數字元

    使用 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：CLI 輸出資料行標題中的無關字元

    在 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 時，CLI 暫時誤報了最近刪除的節點的狀態

    停用機器健全狀況檢查 (MHC) 後，在重建基礎結構期間，Tanzu CLI 命令 (例如 tanzu cluster status) 可能不會報告最新的節點狀態。

    因應措施：無

vSphere

  • 使用 small 節點來建立的節點集區可能會停滯在 Provisioning 狀態。

    建立節點集區時，如果將節點 SIZE 設定為 small，則集區可能停滯在 Provisioning 狀態，且永遠不會進入 Running 狀態。

    因應措施：將節點集區設定成至少具有 medium 大小的節點。

  • 使用 NSX ALB 時，無法建立同名的叢集

    如果您使用 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) 中的資源標記問題，離線部署無法存取 ResourceTagging API，從而導致在建立或升級管理叢集期間發生協調失敗。

    因應措施：在離線 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 叢集之前，請先手動刪除儲存區帳戶私人端點的網路介面：

    1. 從瀏覽器登入 Azure Resource Explorer。
    2. 按一下左側的訂閱 (subscriptions)，然後展開您的訂閱。
    3. 在您的訂閱下，展開左側 resourceGroups，然後展開您的 TKG 部署的資源群組。
    4. 在資源群組下，展開提供者 (providers) > Microsoft.Network > networkinterfaces。
    5. 在 networkinterfaces 下，選取無法刪除的 NIC 資源。
    6. 按一下頂層的讀取/寫入 (Read/Write) 按鈕，然後按一下其正下方的動作 (張貼、刪除) (Actions (POST, DELETE)) 索引標籤。
    7. 按一下刪除 (Delete)。
    8. 刪除 NIC 後，請刪除 Azure 叢集。

Windows 和多重作業系統工作負載叢集

  • 無法在 MacOS 機器上建立 Windows 機器映像

    由於 Kubernetes Image Builder 使用的開放原始碼 packer 公用程式有問題，您無法在 MacOS 機器上建置 Windows 機器映像，如 Windows 自訂機器映像中所述。

    因應措施：請使用 Linux 機器來建置自訂的 Windows 機器映像。

  • Windows 和多重作業系統工作負載叢集不支援備份和還原

    您無法備份和還原具有 Windows 系統的工作節點的工作負載叢集。

    因應措施：無

Image-Builder

  • 在映像建置程序期間，發生可忽略的 goss 測試失敗

    在您執行 Kubernetes Image Builder 以建立 Linux 自訂機器映像時，goss 測試 python-netifaces、python-requests 和 ebtables 失敗。命令輸出會報告失敗情況。這些錯誤可以忽略；它們不會妨礙映像建置成功。

AVS

  • AVS 上的 vSphere CSI 磁碟區刪除可能會失敗

    在 Azure vSphere 解決方案 (AVS) 上，刪除 vSphere CSI 持續性磁碟區 (PV) 可能會失敗。刪除 PV 時，需要 cns.searchable 權限。未使用此權限來建立 AVS 的預設管理員帳戶 ([email protected])。如需詳細資訊，請參閱 vSphere 角色和權限。

    因應措施：若要刪除 AVS 上的 vSphere CSI PV，請連絡 Azure 支援。

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