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。

Tanzu Kubernetes Grid v2.x 和 vSphere with Tanzu vSphere 8 中的主管

重要

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 vSphere 7 中的 v2.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 独立管理集群及其工作负载集群结合使用。
  • 您可以安装 FIPS 版本的 TKG v2.1.1。有关详细信息，请参见支持 FIPS 的版本。
  • 配置变量：
    • 计算机运行状况检查：MHC_MAX_UNHEALTHY_CONTROL_PLANE 和 MHC_MAX_UNHEALTHY_WORKER_NODE。有关详细信息，请参见配置文件变量参考中的计算机运行状况检查。
    • 支持具有自定义证书的 tdnf 服务器：CUSTOM_TDNF_REPOSITORY_CERTIFICATE（技术预览版）。有关详细信息，请参见配置文件变量参考中的节点配置。
    • 支持节点级别代理设置：TKG_NODE_SYSTEM_WIDE_PROXY（技术预览版）。有关详细信息，请参见配置文件变量参考中的代理配置。

Tanzu Kubernetes Grid v2.1.0

Tanzu Kubernetes Grid v2.1.0 版的新增功能：

  • TKG 2.x 支持：在具有独立管理集群的 vSphere、AWS 或 Azure 上，按照工作负载集群类型中所述配置并创建基于类的集群。
  • 您可以安装 FIPS 版本的 TKG v2.1.0。有关详细信息，请参见支持 FIPS 的版本。
  • Tanzu CLI：
    • 默认情况下，package 插件使用 kctrl 样式命令。请参见《Tanzu CLI 命令参考》中的 tanzu 软件包。
    • isolated-cluster 插件 download-bundle 和 upload-bundle 命令可以检索和传输 TKG 所需的所有容器映像，如准备 Internet 受限环境中所述。
    • 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 映像使用统一可扩展固件接口（Unified Extensible Firmware Interface，UEFI）模式进行引导，以取代传统的 BIOS 固件模式。UEFI 模式启用图形处理单元（GRAPHIC Processing Unit，GPU）工作负载并增强节点安全性。有关 Ubuntu 上 UEFI 的详细信息，请参见 Ubuntu 文档中的 UEFI。
  • 您可以将 Kube-VIP 用作工作负载的 L4 LoadBalancer 服务；请参见 Kube-VIP 负载均衡器（技术预览版）。
  • 您可以为边缘应用程序部署在单个 ESXi 主机上同时运行托管工作负载和控制平面基础架构的单节点工作负载集群，如 vSphere 上的单节点集群（技术预览版）中所述。
    • 您可以基于tiny TKr 部署最小的单节点集群，从而最大限度减少其占用空间。
  • 您可以备份和部署集群基础架构，如备份和还原管理和工作负载集群基础架构中所述（技术预览版）。
  • 支持 Pod 安全准入 (PSA) 控制器，以替换命名空间中所述的 Pod 安全策略，如 Pod 安全准入控制器中所述（技术预览版）。

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 Container Storage Interface 组件的完整列表，请参见组件版本。

** 有关与此版本兼容的 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 installed create 和 package install 重命名为 --package。
      • --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 控制台为 TKG 部署创建 VPC。

  • Tanzu CLI 使用新的目标 (Targets) 抽象化，以将不同的命令组与这些命令应用到的服务器类型相关联。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 文档 (VMware Tanzu Kubernetes Grid Documentation)”页面上的找到适用于您的部署的正确 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 之间的名称不匹配，无法从 Internet 访问部署供基于类的 Azure 工作负载集群上的应用程序使用的类型为 LoadBalancer 的服务。

    解决办法：为负载均衡器服务提供您自己的路由（例如，通过 NAT 网关、代理或其他内部路由），以允许负载均衡器后面的节点访问 Internet。

    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 命名空间中创建的。
      • 工作负载集群对象位于用于创建集群的命名空间中，或者default，如果未设置 NAMESPACE。

    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 操作员密钥中的 avi_ingress_node_network_list 为空

    对于最初在 TKG v1.5 或更低版本中创建的独立管理集群，升级到 v2.1.0 会将 AKO 操作员密钥中的 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 运算符密钥并解码其数据值：

      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 运算符密钥：

      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 v2.1.0 中记录为已知问题的以下问题已在 Tanzu Kubernetes Grid v1.6.1 中得到解决。

  • 如果将 DaemonSet 配置为自动还原持久卷，则删除 Pod 的集群和 Pod 操作可能会失败

    在 DaemonSet 使用持久卷 (PV) 的安装中，计算机删除可能会失败，因为默认情况下引流进程会忽略 DaemonSet，并且系统无限期地等待卷与节点分离。受影响的集群操作包括升级、横向缩减和删除。

  • 在 vSphere with Tanzu 上，tanzu cluster list 为 DevOps 用户生成错误

    具有 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 命令，请参见安装和管理软件包中所述。

  • Multus CNI 在 medium 和具有 NSX Advanced Load Balancer 的较小 Pod 上失败

    在 vSphere 上，运行带有 NSX ALB 的 Multus CNI 软件包的 medium 或较小工作节点的工作负载群集可能会失败，并显示 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 中所述。

    解决办法：安装 v1.5.3 cert-manager。

  • 停用 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 代理缓存

    无法在 Internet 受限的环境中将 Harbor 的代理缓存功能用于运行 Tanzu Kubernetes Grid v2.1。您仍然可以使用 Harbor 代理缓存来代理以前版本的 Tanzu Kubernetes Grid 中的映像，以及应用程序映像等非 Tanzu 映像。

    解决办法：无

  • 软件包不符合默认的基准 PSA 配置文件

    对于 TKG 上处于不受支持的技术预览版状态的 PSA 控制器，某些 TKG 软件包不符合默认的 baseline 配置文件。

    解决办法：在受影响的软件包命名空间中设置 audit=privileged 和 warn=privileged 标签，如 Pod 安全准入控制器（技术预览版）中所述。

  • 为单节点集群添加标准存储库失败

    运行 tanzu package repository add 将 tanzu-standard 存储库添加到 vSphere 上的单节点集群（技术预览版）中所述类型的单节点集群可能失败。

    发生这种情况的原因是，单节点集群使用 cert-manager 作为核心加载项进行引导，这与 tanzu-standard 存储库中不同的 cert-manager 软件包相冲突。

    解决办法：在添加 tanzu-standard 存储库之前，请按照安装证书管理器中所述修补 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 中的标签传播问题，集群的 MachineDeployment 对象中未设置基于类的工作负载集群的集群配置文件中的AUTOSCALER_MIN_SIZE_*和AUTOSCALER_MAX_SIZE_*设置。

    解决办法：在启用集群 Autoscaler 的情况下创建基于类的工作负载集群后，为每个 AZ 手动添加计算机计数最小值和最大值设置，如手动添加最小和最大的大小注释中所述。

  • 无法更改节点池 labels 和其他配置属性

    您无法添加或更改现有节点池的 labels、az、nodeMachineType 或者 vSphere 属性（如配置属性中所述）。

    解决办法：使用所需属性在集群中创建一个新节点池，将工作负载迁移到该新节点池，然后删除原始节点池。

  • 无法将管理集群控制平面节点数扩展到偶数

    如果在管理集群上运行 tanzu cluster scale 并将偶数传递到 --controlplane-machine-count 选项，TKG 不会扩展控制平面节点，并且 CLI 不会输出错误。要保持仲裁数，控制平面节点计数应始终为奇数。

    解决办法：不要将控制平面节点计数缩放为偶数。

  • 基于类的集群名称具有 25 个字符的限制，NSX ALB 作为负载均衡器服务或输入控制器

    将 NSX Advanced Load Balancer (ALB) 用作基于类的集群的负载均衡器服务或具有独立管理集群的输入控制器时，其应用程序名称包括集群名称和 load-balancer-and-ingress-service、AKO 软件包的内部名称。当组合名称超过 Avi 控制器应用的 64 个字符限制时，tanzu cluster create 命令可能会失败，并显示错误：“找不到 avi-system 命名空间 （the avi-system namespace was not found）”。

    解决办法：使用 NSX ALB 作为负载均衡器或输入控制器时，将基于类的集群名称长度限制为 25 个字符或更少。

网络

注意

对于 v4.0+，VMware NSX-T Data Center 被重命名为“VMware NSX”。

  • 从旧版配置文件创建 ClusterClass 配置文件，--dry-run 包括空的 Antrea 配置

    使用 tanzu cluster create --dry-run -f 以及包含 ANTREA_NODEPORTLOCAL 条目的旧版配置文件创建 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 网络连接，但如 IPv6 网络连接中所述，它支持使用 vSphere 7 上的 Kube-Vip 进行单堆栈 IPv6 网络连接。

    解决办法：如果需要或当前在 vSphere 上的 IPv6 环境中使用 TKG，请不要安装或升级到 vSphere 8。

  • 管理集群不支持 NSX ALB NodePortLocal 输入模式

    在 TKG v2.1 中，无法将 NSX Advanced Load Balancer (ALB) 作为服务类型以输入模式 NodePortLocal 运行，以获取管理集群的流量。

    此问题不会影响对 NodePortLocal 输入工作负载集群的支持，如 NodePortLocal 模式下的 L7 输入中所述。

    解决办法：在将 AVI_INGRESS_SERVICE_TYPE 设置为 NodePort 或 ClusterIP 的情况下配置管理集群。默认值为 NodePort。

  • 对于较旧的 NSX-T 版本和 Photon 3 或具有 Linux 内核 5.8 虚拟机的 Ubuntu，管理集群创建失败或性能下降

    部署具有以下基础架构和配置的管理集群可能会失败或导致 Pod 之间的流量受限：

    • 具有以下任一版本 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 校验和卸载，从而避免某些底层网络和物理网卡网络驱动程序的已知问题。
    • 升级到 NSX-T v3.0.2 热修补程序、v3.1.3 或更高版本，而不启用增强型数据路径
    • 将 Ubuntu 基础映像与 Linux 内核 5.9 或更高版本结合使用。

身份和访问管理

存储

  • 更改默认 StorageClass 对象会导致工作负载集群中协调失败

    修改 TKG 中包含的默认 StorageClass 对象的属性会导致使用该存储类的工作负载集群中的软件包协调失败。

    解决办法：要自定义存储类，请使用不同的  name 创建新的 StorageClass 定义，而不是修改默认对象定义，然后重新配置集群以使用新的存储类。

  • 工作负载集群无法跨多个数据存储分配存储

    无法启用工作负载集群以在多个数据存储之间分配存储，如部署使用数据存储集群的集群中所述。如果将数据存储集群中的多个数据存储标记为工作负载集群存储策略的基础，则工作负载集群仅使用其中一个数据存储。

    解决办法：无

CLI

  • HTTP/HTTPS 代理密码中不能使用非字母数字字符

    使用 CLI 部署管理集群时，密码中不能使用非字母数字字符 # ` ^ | / ? % ^ { [ ] } \ " < >。此外，使用 UI 部署管理集群时，无法在 HTTP/HTTPS 代理密码中使用任何非字母数字字符。

    解决办法：使用 CLI 部署管理群集时，您可以密码中使用 # ` ^ | / ? % ^ { [ ] } \ " < > 以外的非字母数字字符。

  • Tanzu CLI 在具有 ARM 处理器的 macOS 计算机上不起作用

    Tanzu CLI v0.11.6 在具有 ARM (Apple M1) 芯片的 macOS 计算机上不起作用，如访达 (Finder) > 关于本机 (About This Mac) > 概览 (Overview) 下所示。

    解决办法：使用具有 Linux 或 Windows 操作系统的引导计算机，或使用具有 Intel 处理器的 macOS 计算机。

  • Tanzu CLI 列出 tanzu 管理集群操作系统映像

    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-configurationtrue，请运行：

    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 错误

    通过 vSphere with Tanzu 使用 tanzu cluster create 命令将工作负载集群部署到 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 状态。

    使用配置为 small 的节点 SIZE 创建的节点池可能会停滞在 Provisioning 状态，并且永远不会进入 Running 状态。

    解决办法：为节点池配置至少 medium 大小的节点。

  • 使用 NSX ALB 时，无法创建具有相同名称的集群

    如果对工作负载 (AVI_ENABLE) 或控制平面 (AVI_CONTROL_PLANE_HA_PROVIDER) 使用 NSX Advanced Load Balancer，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 上的集群将失败。

    tanzu cluster delete 和 tanzu management-cluster delete 命令在使用 AWS Cloud Controller Manager 创建的网络连接资源的集群中可能会挂起，而与 Tanzu Kubernetes Grid 部署过程无关。此类资源可能包括负载均衡器和其他网络服务，如 Kubernetes AWS 云提供商文档中的服务控制器中所列。

    有关详细信息，请参见集群 API 问题引流服务类型的工作负载集群 = 拆卸时的 Loadbalancer。

    解决办法：使用 kubectl delete 从集群中删除类型为 LoadBalancer 的服务。或者，如果失败，请使用 AWS 控制台手动删除 Cloud Controller 管理器为此服务创建的任何 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 资源浏览器。
    2. 单击左侧的订阅 (subscriptions)，然后展开您的订阅。
    3. 在订阅下，展开左侧 resourceGroups，然后展开 TKG 部署的资源组。
    4. 在资源组下，展开提供程序 (providers) > Microsoft.Network > networkinterfaces。
    5. 在 networkinterfaces 下，选择无法删除的网卡资源。
    6. 单击顶部的读取/写入 (Read/Write) 按钮，然后单击下面的操作（张贴、删除）[Actions (POST， DELETE)] 选项卡。
    7. 单击删除 (Delete)。
    8. 删除网卡后，删除 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-requestsebtables 失败。命令输出会报告故障。可以忽略这些错误；它们不会阻止映像构建成功。

AVS

  • vSphere AVS 上的 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