备份和还原 vSphere 上的管理和工作负载集群基础架构（技术预览版）
本主题介绍如何在 vSphere 上通过以下方法备份和还原具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 的集群基础架构：
- 使用 Velero 备份和还原独立管理集群上的工作负载集群对象，以及
- 从其配置文件重新创建独立管理集群
注意
- VMware不支持使用 Velero 备份 TKG 独立管理集群。
- 如果在部署独立管理集群后重新配置该集群，按照此处所述重新创建该集群可能不会恢复其所有资源。
要备份和还原具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 工作负载集群上托管的工作负载和动态存储卷，请参见备份和还原集群工作负载。
要备份和还原 vSphere with Tanzu 集群（包括主管集群及其创建的工作负载集群），请参见 VMware vSphere 8.0 文档中的备份和还原 vSphere with Tanzu。
注意
此功能处于不受支持的技术预览版状态；请参见 TKG 功能状态。
重新创建工作负载集群的管理集群后，对工作负载集群执行 Pinniped 身份验证不起作用。
设置 Velero
您可以使用 Velero（开源社区标准工具）备份和还原 TKG 独立管理集群基础架构和工作负载。
Velero 支持各种存储提供程序以存储其备份。Velero 还支持：
Tanzu Kubernetes Grid 订阅包括对 VMware 测试的、兼容的 Velero 发行版的支持，可从 Tanzu Kubernetes Grid 下载页面获取。
要备份和还原 TKG 集群，您需要：
- 在本地工作站上运行的 Velero CLI v1.9.5；请参见安装 Velero CLI。
- 具有备份保存位置的存储提供程序；请参见设置存储提供程序。
- 正在备份的集群上运行的 Velero 服务器：
- 工作负载集群上的 Velero 会备份其工作负载和动态存储，如下所述。
- 独立管理集群上的 Velero 可备份工作负载集群对象，如备份和还原管理和工作负载集群基础架构中所述。
完成上述必备条件后，还可以使用 Velero 在集群之间迁移工作负载。有关说明，请参见 Velero 文档中的集群迁移和资源筛选。
安装 Velero CLI
注意如果已安装 Velero CLI v1.8.1 或更低版本（随早期版本的 TKG 一起分发），则需要升级到 v1.9.5。较旧的 Velero 版本不能与 v1.9 及更高版本中使用的 CRD 一起使用。
要安装 Velero CLI v1.9.5，请执行以下操作：
- 转到 Tanzu Kubernetes Grid 下载页面，然后使用您的 VMware Customer Connect 凭据登录。
- 在产品下载下，单击转到下载 (Go to Downloads)。
- 滚动到 Velero 条目，然后下载适用于您的工作站操作系统的 Velero CLI
.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) 权限。 - 使用 Windows Search 搜索
env。 - 选择编辑系统环境变量 (Edit the system environment variables)，然后单击环境变量 (Environment Variables)按钮。
- 选择系统变量 (System variables)下的
Path，然后单击编辑 (Edit)。 - 单击新建 (New)以添加新行，然后输入
velero二进制文件的路径。
- 创建新的
-
设置存储提供程序
要备份 Tanzu Kubernetes Grid 工作负载集群内容，您需要以下存储位置：
- 集群中 Kubernetes 元数据的集群对象存储备份
- 集群使用的数据的卷快照
请参见 Velero 文档中的 备份存储位置和卷快照位置。Velero 支持各种存储提供程序，这些提供程序可以是：
- 联机云存储提供程序。
- 用于代理或气隙环境的内部部署对象存储服务，例如 MinIO。
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 的存储
在 vSphere 上，集群对象存储备份和卷快照将保存到同一存储位置。此位置必须是 Amazon Web Services (AWS) 或 S3 提供程序（如 MinIO）上与 S3 兼容的外部存储。
要为 vSphere 上的 Velero 设置存储，请参见适用于 v1.4.2 插件的 Vanilla Kubernetes 集群中适用于 vSphere 的 Velero 插件。
用于 AWS 的存储和 AWS 上的存储
要为 AWS 上的 Velero 设置存储，请按照适用于 AWS 存储库的 Velero 插件中的过程操作：
根据需要为每个插件设置 S3 存储。对象存储插件存储和检索集群对象备份，卷快照程序存储和检索数据卷。
用于 Azure 的存储和 Azure 上的存储
要为 Azure 上的 Velero 设置存储，请按照适用于 Azure 存储库的 Velero 插件中的过程操作：
根据需要为每个插件设置 S3 存储。对象存储插件存储和检索集群对象备份，卷快照程序存储和检索数据卷。
将 Velero 服务器部署到管理集群
要备份工作负载集群对象，请将 Velero v1.9.5 服务器安装到独立管理集群并验证安装。
Velero 安装选项
要安装 Velero，请使用以下选项运行 velero install：
--provider $PROVIDER：例如，aws--plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.5.3_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.3_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.1.0_vmware.1 - 无快照位置：要备份集群基础架构，请勿设置
--snapshot-location-config
验证 Velero 安装
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.24.10---vmware.1-tkg.1 v1.24.10+vmware.1-tkg.1 True True -
等待几分钟，直到备份的工作负载集群使用的所有 TKR 变得可用：
tanzu kubernetes-release get NAME VERSION COMPATIBLE ACTIVE UPDATES AVAILABLE v1.22.17---vmware.2-tkg.2 v1.22.17+vmware.2-tkg.2 True True v1.23.16---vmware.1-tkg.1 v1.23.16+vmware.1-tkg.1 True True v1.24.10---vmware.1-tkg.1 v1.24.10+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.24.10+vmware.1 <none> prod v1.24.10---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.24.10+vmware.1 <none> prod v1.24.10---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.24.10+vmware.1 <none> v1.24.10---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.24.10+vmware.1 tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt Ready <none> 114m v1.24.10+vmware.1 tkg-vc-antrea-wdsfx-2hkxp Ready control-plane 116m v1.24.10+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.24.10+vmware.1 <none> v1.24.10---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.24.10+vmware.1 wc-2cjn4-4zljs Ready control-plane 26h v1.24.10+vmware.1 wc-2cjn4-59v95 Ready control-plane 26h v1.24.10+vmware.1 wc-2cjn4-ncgxb Ready control-plane 25h v1.24.10+vmware.1 wc-md-0-nl928-5df8b9bfbd-nww2w Ready <none> 26h v1.24.10+vmware.1 wc-md-1-j4m55-589cfcd9d6-jxmvc Ready <none> 26h v1.24.10+vmware.1 wc-md-2-sd4ww-7b7db5dcbb-crwdv Ready <none> 26h v1.24.10+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.24.10+vmware.1 <none> v1.24.10---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} - 登录到 vSphere 或其他基础架构，然后手动移除虚拟机。
-
- 获取工作负载集群
