除非另有说明,否则这些发行说明适用于 Tanzu Kubernetes Grid (TKG) 的所有 v2.2.x 修补程序版本。
TKG v2.2 作为可下载的 Tanzu CLI 软件包分发,用于部署版本化 TKG 独立管理集群。TKG v2.2 支持使用可在多个基础架构(包括 vSphere 6.7、7 和 8、AWS 和 Azure)上运行的独立管理集群创建和管理工作负载集群。
重要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 8 中的 TKG 2.x 和 vSphere with Tanzu 主管兼容的 Tanzu CLI 版本与 vSphere 7 中的主管集群不兼容。要在 vSphere 7 上对 vSphere with Tanzu 主管集群使用 Tanzu CLI,请使用 TKG v1.6 中的 Tanzu CLI 版本。要使用与具有主管的 TKG 2.x 兼容的 Tanzu CLI 版本,请升级到 vSphere 8。如果 vSphere with Tanzu 主管集群不存在,可以将独立 TKG 2.x 管理集群部署到 vSphere 7。有关 Tanzu CLI 与 VMware 产品之间兼容性的信息,请参见 Tanzu CLI 文档。
Tanzu Kubernetes Grid v2.2.x 包含以下新增功能。
ADDITIONAL_IMAGE_REGISTRY*
变量或 Cluster
对象规范中的 additionalImageRegistries
设置,为多个专用映像注册表配置信任。请参见基于类的集群的受信任注册表。jobservice.scandataExports
持久卷声明。如果之前已将 Harbor Scandata Volume EmptyDir Overlay 应用于 Harbor 软件包,请参见更新运行的 Harbor 部署,然后再将 Harbor 软件包更新到 v2.7.1。vsphereCSI.netpermissions
配置。随着 TKG v2.2 的推出,VMware 对较旧的 TKG 和 TKr 修补程序版本的支持策略发生了变化,这些版本为 TKG 打包了 Kubernetes 版本。TKG v2.1 和较旧次要 TKG 版本的支持策略无变化。
以下几节总结了在适用于每个 TKG 和 TKr 的支持策略下,对所有当前支持的 TKG 和 TKr 版本的支持。
Tanzu Kubernetes Grid 的每个版本都增加了对其管理集群的 Kubernetes 版本以及其他 Kubernetes 版本的支持,这些版本以 Tanzu Kubernetes 版本 (TKr) 分发,除非注明为已知问题。
次要版本:VMware 在发布时支持 TKG v2.2 和 Kubernetes v1.25、v1.24 和 v1.23,并且只要 TKG v2.1 也受支持。一旦 TKG v2.1 达到其“常规支持结束”里程碑,VMware 将不再支持 Kubernetes v1.23 和 v1.24 和 TKG。
修补程序版本:在 VMware 为次要版本发布新的 TKr 修补程序版本后,针对较旧修补程序版本的支持会保留两个月。这为客户提供了 2 个月的时间升级到新的 TKr 修补程序版本。从 TKG v2.2 起,VMware 不支持以前的 Kubernetes 次要版本中的所有 TKr 修补程序版本。
支持的 TKG 和 TKr 版本
当前支持的 TKG 修补程序版本支持如下所示的 TKr 修补程序版本。
Tanzu Kubernetes Grid 版本 | 管理集群 Kubernetes 版本 | 提供的 Kubernetes (TKr) 版本 |
---|---|---|
2.2.0 | 1.25.7 | 1.25.7、1.24.11、1.23.17 |
2.1.1 | 1.24.10 | 1.24.10、1.23.16、1.22.17 |
2.1.0 | 1.24.9 | 1.24.9、1.23.15、1.22.17 |
1.6.1 | 1.23.10 | 1.23.10、1.22.13、1.21.14 |
1.6.0 | 1.23.8 | 1.23.8、1.22.11、1.21.14 |
TKG v2.2.0 支持的 TKr 版本
TKG v2.2.0 根据以下发布日期支持下表中列出的 TKr 修补程序版本:
Kubernetes 次要版本 | Kubernetes 修补程序版本 | 与 TKG 一起发布 | 支持结束日期 (如果不是最新的) |
---|---|---|---|
v1.25 | v1.25.7 | v2.2.0 | 支持的最新版本 |
v1.24 | v1.24.11 | v2.2.0 | 支持的最新版本 |
v1.24.10 | v2.1.1 | 2023 年 7 月 11 日 | |
v1.24.9 | v2.1.0 | 2023 年 5 月 21 日 | |
v1.23 | v1.23.17 | v2.2.0 | 支持的最新版本 |
v1.23.16 | v2.1.1 | 2023 年 7 月 11 日 | |
v1.23.15 | v2.1.0 | 2023 年 5 月 21 日 |
VMware 支持如下所示的 TKG 版本:
次要版本:VMware 支持遵循 N-2 生命周期策略的 TKG,该策略适用于最新和之前的两个次要 TKG 版本。在 TKG v2.2.0 版本中,不再支持 TKG v1.5。有关详细信息,请参见 VMware 产品生命周期矩阵。
修补程序版本:VMware 不支持以前的所有 TKG 修补程序版本。VMware 发布 TKG 的新修补程序版本后,它将对较旧修补程序版本的支持保留两个月。这为客户提供了 2 个月的时间升级到新的 TKG 修补程序版本。
VMware 为 VMware Tanzu Standard 存储库中提供的可选软件包提供以下支持:
有关对 Tanzu Standard 软件包 VMware 支持的详细信息,请参见上面的新增功能和下面的功能行为更改通知。
Tanzu Kubernetes Grid v2.2 支持以下基础架构平台和操作系统 (OS),以及集群创建和管理、网络连接、存储、身份验证、备份和迁移以及可观察性组件。Tanzu Kubernetes Grid v2.2.0 中包含括号中列出的组件版本。有关详细信息,请参见组件版本。
vSphere | AWS | Azure | |
基础架构平台 |
|
本机 AWS | 本机 Azure |
CLI、API 和软件包基础架构 | Tanzu Framework v0.29.0 | ||
集群创建和管理 | 核心集群 API (v1.2.8)、集群 API 提供程序 vSphere (v1.5.3) | 核心集群 API (v1.2.8)、集群 API 提供程序 AWS (v2.0.2) | 核心集群 API (v1.2.8)、集群 API 提供程序 Azure (v1.6.3) |
使用 TKG 分发的 Kubernetes 节点操作系统 | Photon OS 3、Ubuntu 20.04 | Amazon Linux 2、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
构建您自己的映像 | Photon OS 3、Red Hat Enterprise Linux 7*** 和 8、Ubuntu 18.04、Ubuntu 20.04、Windows 2019 | Amazon Linux 2、Ubuntu 18.04、Ubuntu 20.04 | Ubuntu 18.04、Ubuntu 20.04 |
容器运行时 | Containerd (v1.6.18) | ||
容器网络连接 | Antrea (v1.9.0)、Calico (v3.24.1) | ||
容器注册表 | Harbor (v2.7.1) | ||
输入 | NSX Advanced Load Balancer Essentials 和 Avi 控制器 **** (v21.1.5-v21.1.6、v22.1.2-v22.1.3)、Contour (v1.23.5) | Contour (v1.23.5) | Contour (v1.23.5) |
存储 | vSphere 容器存储接口 (v2.7.1*) 和 vSphere 云原生存储 | Amazon EBS CSI 驱动程序 (v1.16.0) 和树内云提供程序 | Azure 磁盘 CSI 驱动程序 (v1.27.0)、Azure 文件 CSI 驱动程序 (v1.26.1) 和树内云提供程序 |
身份验证 | 通过 Pinniped (v0.12.1) 的 OIDC、通过 Pinniped (v0.12.1) 和 Dex 的 LDAP | ||
可观察性 | Fluent Bit (v1.9.5)、Prometheus (v2.37.0)*****、Grafana (v7.5.17) | ||
备份和迁移 | Velero (v1.9.7) |
* vsphere_csi_driver 版本。有关 Tanzu Kubernetes Grid v2.2 版本中包含的 vSphere 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 或更高版本。
***** 如果将集群升级到 Kubernetes v1.25,则必须将 Prometheus 升级到版本 2.37.0+vmware.3-tkg.1
。Prometheus 软件包的早期版本(例如版本 2.37.0+vmware.1-tkg.1
)与 Kubernetes 1.25 不兼容。
有关 Tanzu Kubernetes Grid v2.2 随附的 Kubernetes 版本的完整列表,请参见上述 Tanzu Kubernetes Grid v2.2 中支持的 Kubernetes 版本。
Tanzu Kubernetes Grid v2.2.x 版本包括以下软件组件版本:
组件 | TKG v2.2 |
---|---|
aad-pod-identity | v1.8.15+vmware.1* |
addons-manager | v2.2+vmware.1* |
ako-operator | v1.8.0_vmware.1* |
alertmanager | v0.25.0_vmware.1* |
antrea | v1.9.0_vmware.2-tkg.1-advanced* |
aws-ebs-csi-driver | v1.16.0_vmware.1-tkg.1* |
azuredisk-csi-driver | v1.27.0_vmware.2-tkg.1* |
azurefile-csi-driver | v1.26.1_vmware.2-tkg.1* |
calico | v3.24.1_vmware.1-tkg.2* |
capabilities-package | v0.29.0-dev-capabilities* |
carvel-secretgen-controller | v0.11.2+vmware.1 |
cloud-provider-azure | v1.1.26+vmware.1、 v1.23.23+vmware.1、 v1.24.10+vmware.1 |
cloud_provider_vsphere | v1.25.1+vmware.2* |
cluster-api-provider-azure | v1.6.3_vmware.2* |
cluster_api | v1.2.8+vmware.2* |
cluster_api_aws | v2.0.2+vmware.2* |
cluster_api_vsphere | v1.5.3+vmware.2* |
cni_plugins | v1.1.1+vmware.20* |
configmap-reload | v0.7.1+vmware.2 |
containerd | v1.6.18+vmware.1* |
contour | v1.23.5+vmware.1-tkg.1* |
coredns | v1.9.3_vmware.8* |
crash-diagnostics | v0.3.7+vmware.6 |
cri_tools | v1.24.2+vmware.8* |
csi_attacher | v3.5.0+vmware.1、 v3.4.0+vmware.1、 v3.3.0+vmware.1 |
csi_livenessprobe | v2.7.0+vmware.1、 v2.6.0+vmware.1、 v2.5.0+vmware.1、 v2.4.0+vmware.1 |
csi_node_driver_registrar | v2.5.1+vmware.1、 v2.5.0+vmware.1、 v2.3.0+vmware.1 |
csi_provisioner | v3.2.1+vmware.1、 v3.1.0+vmware.2、 v3.0.0+vmware.1 |
dex | v2.35.3_vmware.3* |
envoy | v1.24.5_vmware.1* |
external-dns | v0.12.2+vmware.5* |
external-snapshotter | v6.0.1+vmware.1、 v5.0.1+vmware.1 |
etcd | v3.5.6+vmware.9* |
fluent-bit | v1.9.5+vmware.1 |
gangway | v3.2.0+vmware.2 |
grafana | v7.5.17+vmware.2 |
guest-cluster-auth-service | v1.3.0* |
harbor | v2.7.1+vmware.1* |
image-builder | v0.1.13+vmware.3* |
image-builder-resource-bundle | v1.25.7+vmware.2-tkg.1* |
imgpkg | v0.31.1+vmware.1 |
jetstack_cert-manager | v1.10.2+vmware.1* |
k8s-sidecar | v1.15.6+vmware.5*、 v1.12.1+vmware.6* |
k14s_kapp | v0.53.2+vmware.1 |
k14s_ytt | v0.43.1+vmware.1 |
kapp-controller | v0.41.7_vmware.1-tkg.1* |
kbld | v0.35.1+vmware.1 |
kube-state-metrics | v2.7.0+vmware.2* |
kube-vip | v0.5.7+vmware.2* |
kube-vip-cloud-provider* | v0.0.4+vmware.4* |
kube_rbac_proxy | v0.11.0+vmware.2 |
kubernetes | v1.25.7+vmware.2* |
kubernetes-csi_external-resizer | v1.4.0+vmware.1、 v1.3.0+vmware.1 |
kubernetes-sigs_kind | v1.25.7+vmware.2-tkg.2_v0.17.0* |
kubernetes_autoscaler | v1.25.0+vmware.1* |
load-balancer-and-ingress-service (AKO) | v1.9.3_vmware.1-tkg.1* |
metrics-server | v0.6.2+vmware.1 |
multus-cni | v3.8.0+vmware.3* |
pinniped | v0.12.1_vmware.3-tkg.4* |
pinniped-post-deploy | v0.12.1+vmware.2-tkg.3 |
prometheus | v2.37.0+vmware.3* |
prometheus_node_exporter | v1.4.0+vmware.3* |
pushgateway | v1.4.3+vmware.3* |
sonobuoy | v0.56.16+vmware.1* |
standalone-plugins-package | v0.29.0-dev-standalone-plugins* |
tanzu-framework | v0.29.0* |
tanzu-framework-addons | v0.29.0* |
tanzu-framework-management-packages | v0.29.0-tf* |
tkg-bom | v2.2.0* |
tkg-core-packages | v1.25.7+vmware.2-tkg.1* |
tkg-standard-packages | v2.2.0* |
tkg-storageclass-package | v0.29.0-tkg-storageclass* |
tkg_telemetry | v2.2.0+vmware.1* |
velero | v1.9.7+vmware.1* |
velero-mgmt-cluster-plugin* | v0.1.0+vmware.1 |
velero-plugin-for-aws | v1.5.5+vmware.1* |
velero-plugin-for-csi | v0.3.5+vmware.1* |
velero-plugin-for-microsoft-azure | v1.5.5+vmware.1* |
velero-plugin-for-vsphere | v1.4.3+vmware.1* |
vendir | v0.30.1+vmware.1 |
vsphere_csi_driver | v2.7.1+vmware.2* |
whereabouts | v0.5.4+vmware.2* |
* 表示自上一版本以来的新组件或版本更新。TKG v2.1.1 是 v2.2.0 之前的版本。
有关 TKG v2.2 随附的软件组件版本的完整列表,请使用 imgpkg
提取存储库包,然后列出其内容。对于 TKG v2.2.0,例如:
imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree
诸如以下内容的本地 BOM 文件也会列出软件包版本,但可能不是最新的:
~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml
在 TKG 升级途径中,v2.2 紧跟 v2.1.1。
只能从 v2.1.x 升级到 Tanzu Kubernetes Grid v2.2.x。如果要从低于 v2.1.x 的版本升级到 Tanzu Kubernetes Grid v2.2.x,必须先升级到 v2.1.x。
在工作负载集群上升级 Kubernetes 版本时,无法跳过次要版本。例如,无法将 Tanzu Kubernetes 集群直接从 v1.23.x 升级到 v1.25.x。必须先将 v1.23.x 集群升级到 v1.24.x,然后再将集群升级到 v1.25.x。
Tanzu Kubernetes Grid v2.2 发布日期为:
与以前最新版 v2.1.1 相比,Tanzu Kubernetes Grid v2.2 中引入了以下新行为。
本节提供了将在未来版本(TKG v2.2 版本之后的版本)中生效的行为更改的预先通知。
重要Tanzu Kubernetes Grid v2.2.x 是 TKG 的最后一个次要版本,其中 VMware Tanzu Standard 存储库打包为该版本的一部分。TKG v2.2.x 和早期版本在 Tanzu Standard Repository 中包含一组可选软件包,您可以在集群上部署这些软件包以添加日志转发、输入控制、容器注册表等功能。在未来的 TKG v2.x 次要版本中,安装 Tanzu CLI 并部署管理集群时,不会自动下载 Tanzu Standard 存储库。要使用此可选软件包集,您需要使用 Tanzu CLI 下载并手动添加这些软件包。通过将可选软件包与 TKG 版本分开,VMware 可以在 TKG 版本之外提供增量软件包更新,并且能够更迅速地响应 CVE。
LDAP_BIND_DN
和 LDAP_BIND_PASSWORD
。有关详细信息,请参见《配置文件变量参考》中的身份提供程序 LDAP。部署和管理 TKG 2.2 独立管理集群中包含与“将 TKG 与 vSphere with Tanzu 主管配合使用”无关的独立管理集群的特定主题。
有关详细信息,请参见“VMware Tanzu Kubernetes Grid 文档 (VMware Tanzu Kubernetes Grid Documentation)”页面上的找到适用于您的部署的正确 TKG 文档。
较低的 Tanzu Kubernetes Grid 版本中记录为已知问题的以下问题已在 Tanzu Kubernetes Grid v2.2.0 中得到解决。
从旧版配置文件创建 ClusterClass
配置文件,--dry-run
包括空的 Antrea 配置
使用 tanzu cluster create --dry-run -f
以及包含 ANTREA_NODEPORTLOCAL
条目的旧版配置文件创建 ClusterClass
配置文件会导致自动生成的 Antrea 配置不包含任何标签,从而导致 Antrea 无法成功协调。
对于 TKG 上处于不受支持的技术预览版状态的 PSA 控制器,某些 TKG 软件包不符合默认的 baseline
配置文件。
运行 tanzu cluster create
时出现验证错误
默认情况下,将平面键值配置文件传递到 tanzu cluster create
的 --file
选项时,命令会将该配置文件转换为 Kubernetes 样式的对象规范文件,然后退出。此行为由 auto-apply-generated-clusterclass-based-configuration
功能控制,该功能默认设置为 false
。在某些情况下,当您将由 --file
选项生成的 Kubernetes 样式对象规范文件传递到 tanzu cluster create
时,命令将失败,并显示类似以下内容的错误:
Error: workload cluster configuration validation failed...
传递由 --dry-run
选项生成的 Kubernetes 样式对象规范文件到 tanzu cluster create
时,也可能会出现此错误。
tanzu cluster create
不会正确验证使用非默认 Kubernetes 版本生成的集群规范
如果使用创建基于类的集群 中所述的两个步骤之一从配置文件创建基于类的工作负载集群,并在第一步中指定 --tkr
值以将集群建立在非默认版本的 Kubernetes 上时,第二步可能会失败,并显示验证错误。
以下是 Tanzu Kubernetes Grid v2.2.x 中的已知问题。v2.2.0 中存在的任何已知问题如果在后续的 v2.2.x 修补程序版本中已解决,都会列在修复这些问题的修补程序版本的已解决问题下。
您可以在管理集群问题故障排除和工作负载集群问题故障排除或VMware 知识库文章中找到常见问题的其他解决方案。
在具有 NSX ALB v21.1.4 或更早版本的 vSphere 6.7 上安装 Grafana 失败
您无法将 Grafana v7.5.17 软件包安装到 vSphere v6.7U3 上使用 NSX ALB v21.1.4 或更低版本作为负载均衡器服务的 TKG v2.2 工作负载集群。
解决办法:如果工作负载集群使用 Grafana 和 NSX ALB,请先将 vSphere 升级到 v7.0+ 并将 ALB NSX 升级到 v21.1.5+,然后再将 TKG 升级到 v2.2。
当执行 ID 超过 1000000+ 时,Harbor CVE 导出可能会失败
Harbor v2.7.1(TKG v2.2 打包的版本)存在已知问题,即在执行主键自动增量 ID 增加到 1000000+ 时,CVE 报告导出错误“404 页面未找到 (404 page not found)”。
此 Harbor 问题已在更高版本的 Harbor 中解决,并准备包含在更高版本的 TKG 中。
Harbor 的 Notary 组件中的 Golang 漏洞
CVE-2021-33194 存在于 Notary 中。如 Harbor v2.6.0 发行说明中注释,Notary 组件已在 Harbor v2.6+ 中已被弃用,并计划在将来的版本中删除。VMware 建议使用 Sigstore Cosign 而不是 Notary 进行容器签名和验证。
运行 tanzu package repository add
将 tanzu-standard
存储库添加到 vSphere 上的单节点集群(技术预览版)中所述类型的单节点集群可能失败。
发生这种情况的原因是,单节点集群使用 cert-manager
作为核心加载项进行引导,这与 tanzu-standard
存储库中不同的 cert-manager
软件包相冲突。
解决办法:在添加 tanzu-standard
存储库之前,请按照安装证书管理器中所述修补 cert-manager
软件包注释。
无法基于具有 Antrea CNI 的非当前 TKr 版本创建新的工作负载集群
您无法创建使用 Antrea CNI 并运行以前版本的 TKG 附带的 Kubernetes 版本(如 Kubernetes v1.23.10)的新工作负载集群,这是 TKG v1.6.1 中的默认 Kubernetes 版本,如 Tanzu Kubernetes Grid v2.2 中支持的 Kubernetes 版本中所列。
解决办法:创建运行 Kubernetes 1.25.7、1.24.11 或 1.23.17 的工作负载集群。Kubernetes 项目建议在当前任何次要版本的最新修补程序版本上运行组件。
由于集群 API 中的标签传播问题,集群的 MachineDeployment
对象中未设置基于类的工作负载集群的集群配置文件中的AUTOSCALER_MIN_SIZE_*
和AUTOSCALER_MAX_SIZE_*
设置。
解决办法:在启用集群 Autoscaler 的情况下创建基于类的工作负载集群后,为每个 AZ 手动添加计算机计数最小值和最大值设置,如手动添加最小和最大的大小注释中所述。
您无法添加或更改现有节点池的 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”。
TKG v2.2 在 vSphere 8 上不支持 IPv6 网络连接,但如 IPv6 网络连接中所述,它在 vSphere 7 上支持使用 Kube-Vip 进行单堆栈 IPv6 网络连接。
解决办法:如果需要或当前在 vSphere 上的 IPv6 环境中使用 TKG,请不要安装或升级到 vSphere 8。
管理集群不支持 NSX ALB NodePortLocal
输入模式
在 TKG v2.2 中,无法将 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 和 Antrea CNI 之间暴露了校验和问题。
TMC:如果管理集群已在 Tanzu Mission Control (TMC) 中注册,则此问题没有解决办法。否则,请参见下面的解决办法。
解决办法:
ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD
设置为 "true"
的工作负载集群。此设置将停用 Antrea 的 UDP 校验和卸载,从而避免某些底层网络和物理网卡网络驱动程序的已知问题。按照备份和还原管理集群和工作负载集群基础架构(技术预览版)中所述重新创建独立管理集群后,用户无法通过 Pinniped 身份验证登录到工作负载集群。
解决办法:重新创建管理集群后,按照在现有部署中启用和配置身份管理中所述重新配置身份管理。
CVE-2022-41723 存在于 Pinniped v0.12.1 中。利用此漏洞可能会导致 Pinniped 服务的 DDoS 攻击。要将被利用概率降到较低水平,可以使用输入筛选以仅允许来自已知 IP 地址(如企业 VPN CIDR)的流量。该漏铜将在 Tanzu Kubernetes Grid 的未来版本中解决。
为主管部署的工作负载集群生成并使用 kubeconfig 会导致出现“未知标记”错误
在 Tanzu CLI v0.25.0 及更早版本中,cluster
插件会生成可能包含参数 --concierge-is-cluster-scoped
的 kubeconfig
文件。Tanzu CLI v0.29.0 pinniped-auth
插件无法识别此参数。此临时回归问题已在后续版本中得到修复。
由于 vSphere 8.0 嵌入了 v0.25.0 cluster
插件,因此从 CLI v0.29.0(TKG v2.2 中的版本)连接到主管部署的集群时可能会生成以下错误:
Error: unknown flag: --concierge-is-cluster-scoped
Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1
解决办法:在 kubeconfig
文件中,移除 args
下设置 --concierge-is-cluster-scoped
的行。
无法启用工作负载集群以在多个数据存储之间分配存储,如部署使用数据存储集群的集群中所述。如果将数据存储集群中的多个数据存储标记为工作负载集群存储策略的基础,则工作负载集群仅使用其中一个数据存储。
解决办法:无
使用 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 计算机。
management-cluster
命令组列出了 tanzu management-cluster osimage
。此功能目前正在开发中,并保留以供将来使用。
解决办法:请勿使用 tanzu management-cluster osimage
。
tanzu package available get
的 --default-values-file-output
选项输出 Harbor 软件包的不完整配置模板文件
运行 tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH
创建 Harbor 软件包的不完整配置模板文件。要获取完整文件,请使用 imgpkg pull
命令,如为服务注册表安装 Harbor 中所述。
使用 small
节点创建的节点池可能会停滞在Provisioning
状态。
使用配置为 small
的节点 SIZE
创建的节点池可能会停滞在 Provisioning
状态,并且永远不会进入 Running
状态。
解决办法:为节点池配置至少 medium
大小的节点。
在 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 CSI 驱动程序创建持久卷 (PV)(该持久卷使用具有专用端点的存储帐户)时,它会创建一个 privateEndpoint
和 vNet
资源,但删除 PV 时不会删除这些资源。因此,删除集群将失败,并显示类似以下内容的错误:subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use
。
解决办法:在删除 Azure 集群之前,手动删除存储帐户专用端点的网络接口:
networkinterfaces
下,选择无法删除的网卡资源。在 Internet 受限的环境中不支持 Windows 工作线程
Vmware 不支持在代理或气隙环境中具有 Windows Worker 节点的 TKG 工作负载集群。
解决办法:请联系您的 VMware 代表。某些 TKG 用户构建了 Windows 自定义映像,并在脱机环境中 Windows 工作线程运行工作负载集群,例如,如此非官方存储库中所述。
运行 Kubernetes Image Builder 以创建自定义 Linux 自定义计算机映像时,goss
测试 python-netifaces
、python-requests
ebtables
失败。命令输出会报告故障。可以忽略这些错误;它们不会阻止映像构建成功。
在 Azure vSphere 解决方案 (AVS) 上,删除 vSphere CSI 持久卷 (PV) 可能会失败。删除 PV 需要 cns.searchable 权限。未使用此权限创建 AVS 的默认管理员帐户 ([email protected])。有关详细信息,请参见 vSphere 角色额权限。
解决办法:要删除 AVS 上的 vSphere CSI PV,请联系 Azure 支持部门。