本主题介绍如何在 vSphere 上通过以下方法备份和还原具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 的集群基础架构:
注意
- VMware不支持使用 Velero 备份 TKG 独立管理集群。
- 如果在部署独立管理集群后重新配置该集群,按照此处所述重新创建该集群可能不会恢复其所有资源。
要备份和还原具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 工作负载集群上托管的工作负载和动态存储卷,请参见备份和还原集群工作负载。
要备份和还原 vSphere with Tanzu 集群(包括主管集群及其创建的工作负载集群),请参见 VMware vSphere 8.0 文档中的备份和还原 vSphere with Tanzu。
注意
此功能处于不受支持的技术预览版状态;请参见 TKG 功能状态。
重新创建工作负载集群的管理集群后,对工作负载集群执行 Pinniped 身份验证不起作用。
您可以使用 Velero(开源社区标准工具)备份和还原 TKG 独立管理集群基础架构和工作负载。
Velero 支持各种存储提供程序以存储其备份。Velero 还支持:
Tanzu Kubernetes Grid 订阅包括对 VMware 测试的、兼容的 Velero 发行版的支持,可从 Tanzu Kubernetes Grid 下载页面获取。
要备份和还原 TKG 集群,您需要:
完成上述必备条件后,还可以使用 Velero 在集群之间迁移工作负载。有关说明,请参见 Velero 文档中的集群迁移和资源筛选。
注意如果已安装 Velero CLI v1.8.1 或更低版本(随早期版本的 TKG 一起分发),则需要升级到 v1.9.7。较旧的 Velero 版本不能与 v1.9 及更高版本中使用的 CRD 一起使用。
要安装 Velero CLI v1.9.7,请执行以下操作:
.gz
文件。其文件名以 velero-linux-
、velero-mac-
或 velero-windows64-
开头。使用 gunzip
命令或您选择的解压缩工具解压缩二进制文件:
gzip -d <RELEASE-TARBALL-NAME>.gz
将适用于您的平台的 CLI 二进制文件重命名为 velero
,确保它是可执行的,然后将其添加到 PATH
。
macOS 和 Linux 平台:
/usr/local/bin
文件夹并将其重命名为 velero
。chmod +x /usr/local/bin/velero
Windows 平台:
Program Files\velero
文件夹并将二进制文件复制到其中。velero.exe
。velero
文件夹,选择属性 (Properties) > 安全 (Security),并确保您的用户帐户具有完全控制 (Full Control) 权限。env
。Path
,然后单击编辑 (Edit)。velero
二进制文件的路径。要备份 Tanzu Kubernetes Grid 工作负载集群内容,您需要以下存储位置:
请参见 Velero 文档中的 备份存储位置和卷快照位置。Velero 支持各种存储提供程序,这些提供程序可以是:
VMware 建议将唯一的存储桶专用于每个集群。
要设置 MinIO,请执行以下操作:
使用 MinIO 凭据和存储位置运行 minio
容器映像,例如:
$ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7
将凭据保存到本地文件以传递到 velero install
的 --secret-file
选项,例如:
[default]
aws_access_key_id=minio
aws_secret_access_key=minio123
在 vSphere 上,集群对象存储备份和卷快照将保存到同一存储位置。此位置必须是 Amazon Web Services (AWS) 或 S3 提供程序(如 MinIO)上与 S3 兼容的外部存储。
要为 vSphere 上的 Velero 设置存储,请参见适用于 v1.4.3 插件的 Vanilla Kubernetes 集群中适用于 vSphere 的 Velero 插件。
要为 AWS 上的 Velero 设置存储,请按照适用于 AWS 存储库的 Velero 插件中的过程操作:
根据需要为每个插件设置 S3 存储。对象存储插件存储和检索集群对象备份,卷快照程序存储和检索数据卷。
要为 Azure 上的 Velero 设置存储,请按照适用于 Azure 存储库的 Velero 插件中的过程操作:
根据需要为每个插件设置 S3 存储。对象存储插件存储和检索集群对象备份,卷快照程序存储和检索数据卷。
要备份工作负载集群对象,请将 Velero v1.9.7 服务器安装到独立管理集群并验证安装。
要安装 Velero,请使用以下选项运行 velero install
:
--provider $PROVIDER
:例如,aws
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1
--bucket $BUCKET
:S3 存储桶的名称--backup-location-config region=$REGION
:存储桶所在的 AWS 区域--snapshot-location-config region=$REGION
:存储桶所在的 AWS 区域--kubeconfig
将 Velero 服务器安装到当前默认集群以外的集群。(可选)--secret-file ./VELERO-CREDS
授予 Velero 访问 S3 存储桶的权限的一种方法是向该选项传递一个本地 VELERO-CREDS
文件,该文件如下所示:
[default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
有关其他选项,请参见安装和启动 Velero。
运行 velero install
命令以在集群上创建一个名为 velero
的命名空间,并在其中放置一个名为 velero
的部署。
需要以下设置:
--plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
注意您可以添加多个以逗号分隔的选项。例如:
--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.5_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1
--snapshot-location-config
velero install
命令完成后,确认 Velero 已成功安装:
确认 Velero Pod 的状态为 Running
:
kubectl -n velero get pod
NAME READY STATUS RESTARTS AGE
velero-78fdbcd446-v5cqr 1/1 Running 0 3h41m
验证备份位置是否处于 Available
阶段:
velero backup-location get
NAME PROVIDER BUCKET/PREFIX PHASE LAST VALIDATED ACCESS MODE DEFAULT
default aws mgmt Available 2022-11-11 05:55:55 +0000 UTC ReadWrite true
要备份由独立管理集群管理的所有工作负载集群对象,请运行:
velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait
注意
--exclude-namespaces tkg-system
排除管理集群本身。
--include-resources cluster.cluster.x-k8s.io
包括工作负载集群对象VMware 建议在进行任何结构更改(如纵向扩展或横向缩减)后立即备份工作负载集群。这可避免备份对象和物理基础架构之间出现不匹配问题,从而避免还原过程失败。
在最近一次备份后更改集群对象时,还原后系统的状态与所需的最新状态不匹配。此问题称为“偏差”。有关如何从某些常见类型的偏差中恢复的信息,请参见下面的处理偏差部分。
为了缓解偏差,VMware 建议使用 Velero 计划定期备份。例如,要每天备份所有工作负载集群并将每个备份保留 14 天,请执行以下操作:
velero create schedule daily-bak --schedule="@every 24h" --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s
有关更多 Velero 调度选项,请参见 Velero 文档中的调度备份。
要还原独立管理集群及其管理的工作负载集群对象,请执行以下操作:
从配置文件 mgmt-cluster-config.yaml
重新创建管理集群,如从配置文件部署管理集群中所述。
注意部署管理集群后应用于管理集群的任何配置更改都必须反映在配置文件或环境变量中,否则不会还原。
创建管理集群后,应只有一个 TKR:
tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.25.7---vmware.1-tkg.1 v1.25.7+vmware.1-tkg.1 True True
等待几分钟,直到备份的工作负载集群使用的所有 TKR 变得可用:
tanzu kubernetes-release get
NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE
v1.23.17---vmware.2-tkg.2 v1.23.17+vmware.2-tkg.2 True True
v1.24.11---vmware.1-tkg.1 v1.24.11+vmware.1-tkg.1 True True
v1.25.7---vmware.1-tkg.1 v1.25.7+vmware.1-tkg.1 True True
按照上述将 Velero 服务器部署到集群说明在管理集群上安装 Velero。确保凭据和备份位置配置设置具有与执行备份时相同的值。
Velero 安装后,运行 velero backup get
直到备份同步且命令列出要使用的备份:
velero backup get
NAME STATUS ERRORS WARNINGS CREATED EXPIRES STORAGE LOCATION SELECTOR
my-backup Completed 0 0 2022-12-07 17:10:42 +0000 UTC 24d default <none>
运行 velero restore create
以还原工作负载集群资源。VMware 建议使用最新的备份:
velero restore create my-restore --from-backup my-backup --wait
还原完成后,集群将处于 createdStalled
状态:
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
tkg-vc-antrea default createdStalled 0/3 0/3 v1.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1
修补集群对象以将其 paused
属性设置为 false
。这是必需的,因为在新的管理集群上以 paused
状态重新创建了集群对象,以防止其控制器尝试协调:
要在还原集群后对其取消暂停,请运行:
kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'
要取消暂停多个命名空间中的所有集群,请运行以下脚本:
#!/bin/bash
for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
do
clusters=$(kubectl -n $ns get cluster -o name)
if [[ -n $clusters ]];then
kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
fi
done
确认所有工作负载集群都处于 running
状态,例如:
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
tkg-vc-antrea default running 3/3 3/3 v1.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1
对于每个工作负载集群,运行 tanzu cluster get CLUSTER-NAME
以检查所有组件是否都处于 running
状态,例如:
tanzu cluster get tkg-vc-antrea
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
tkg-vc-antrea default running 3/3 3/3 v1.25.7+vmware.1 <none> v1.25.7---vmware.1-tkg.1
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/tkg-vc-antrea True 4h14m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5 True 4h36m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn True 4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt True 4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp True 4h23m
│ └─Machine/tkg-vc-antrea-ch5hn-x7nmm True 4h32m
└─Workers
├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn True 4h23m
│ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9 True 4h24m
├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh True 4h24m
│ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667 True 4h28m
└─MachineDeployment/tkg-vc-antrea-md-2-brm2m True 4h21m
└─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn True 4h23m
所有工作负载集群都运行后,可以使用 Tanzu CLI 管理工作负载集群。
偏差情况可能很复杂,但一些常见的模式和缓解措施包括:
失效的工作节点:
Ghost 工作节点基础架构:
缓解:
kubeconfig
并将其设置为 kubectl
上下文。比较以下 kubectl
和 tanzu
命令的输出:
# Get the actual worker nodes of the workload cluster
$ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
NAME STATUS ROLES AGE VERSION
tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9 Ready <none> 44m v1.25.7+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt Ready <none> 114m v1.25.7+vmware.1
tkg-vc-antrea-wdsfx-2hkxp Ready control-plane 116m v1.25.7+vmware.1
# Get the worker nodes managed by the TKG
$ tanzu cluster get tkg-vc-antrea
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
tkg-vc-antrea default running 1/1 1/1 v1.25.7+vmware.1 <none> v1.25.7---vmware.1-tkg.1-zshippable
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/tkg-vc-antrea True 13m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9 True 13m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx True 13m
│ └─Machine/tkg-vc-antrea-wdsfx-2hkxp True 13m
└─Workers
└─MachineDeployment/tkg-vc-antrea-md-0-p9vn5 True 13m
└─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt True 13m
对于 kubectl
列出的每个没有来自 tanzu cluster get
的 Workers
> Machine
列表的工作节点:
将工作节点纵向扩展到预期值,例如:
tanzu cluster scale ${cluster_name} --worker-machine-count 2
kubeconfig
引流 ghost 节点,ghost 节点会将其工作负载移至 TKG 管理的节点:kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets
从集群中移除 ghost 节点:
kubectl delete node ${node_name}
登录到 vSphere 或其他基础架构,然后手动移除虚拟机。
控制平面上的失效节点和 ghost 基础架构
缓解:
kubeconfig
并将其设置为 kubectl
上下文。比较以下 kubectl
和 tanzu
命令的输出:
# Get the actual control plane nodes of the workload cluster
$ kubectl --context wc-admin@wc get node
NAME STATUS ROLES AGE VERSION
wc-2cjn4-4xbf8 Ready control-plane 107s v1.25.7+vmware.1
wc-2cjn4-4zljs Ready control-plane 26h v1.25.7+vmware.1
wc-2cjn4-59v95 Ready control-plane 26h v1.25.7+vmware.1
wc-2cjn4-ncgxb Ready control-plane 25h v1.25.7+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w Ready <none> 26h v1.25.7+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc Ready <none> 26h v1.25.7+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv Ready <none> 26h v1.25.7+vmware.1
# Get the control plane nodes managed by the TKG
$ tanzu cluster get wc
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES TKR
wc default updating 4/3 3/3 v1.25.7+vmware.1 <none> v1.25.7---vmware.1-tkg.1-zshippable
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/wc True 24m
├─ClusterInfrastructure - VSphereCluster/wc-9nq7v True 26m
├─ControlPlane - KubeadmControlPlane/wc-2cjn4 True 24m
│ ├─Machine/wc-2cjn4-4xbf8 True 24m
│ ├─Machine/wc-2cjn4-4zljs True 26m
│ └─Machine/wc-2cjn4-59v95 True 26m
└─Workers
├─MachineDeployment/wc-md-0-nl928 True 26m
│ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w True 26m
├─MachineDeployment/wc-md-1-j4m55 True 26m
│ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc True 26m
└─MachineDeployment/wc-md-2-sd4ww True 26m
└─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv True 26m
对于 kubectl
列出的不具有 tanzu cluster get
中的 ControlPlane
> Machine
列表的每个 control-plane
节点:
删除节点:
kubectl delete node ${node_name}