本文档介绍了如何备份和恢复已启用高级集群的 Google Distributed Cloud 1.32 版及更高版本的管理员集群和用户集群。备份和恢复功能在 1.32 版中处于预览版阶段,在 1.33 版及更高版本中处于正式版阶段。
gkectl
备份和恢复过程不包括永久性卷。本地卷预配工具 (LVP) 创建的任何卷都将保持不变。
备份集群
gkectl backup cluster
命令会将 etcd 存储区中的集群信息和指定集群的 PKI 证书添加到 tar 文件中。etcd 存储区是所有集群数据的 Kubernetes 后备存储区,包含管理集群状态需要的所有 Kubernetes 对象和自定义对象。PKI 证书用于通过传输层安全协议 (TLS) 进行身份验证。此数据从集群的控制平面或高可用性 (HA) 部署的其中一个控制平面进行备份。
备份 tar 文件包含敏感凭据,包括您的服务账号密钥和 SSH 密钥。请将备份文件存储在安全的位置。为防止意外泄露文件,备份过程仅使用内存中的文件。
定期备份集群,以确保快照数据相对最新。调整备份频率以反映集群重大更改的频率。
在开始之前,请确保集群正常运行,凭据有效并且可通过 SSH 连接所有节点。备份过程的目的是捕获处于已知良好状态的集群,以便在发生灾难性故障时可以恢复操作。
要备份集群,请执行以下操作:
运行以下命令以检查集群:
gkectl diagnose cluster --cluster-name CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
替换以下内容:
CLUSTER_NAME:您计划备份的集群的名称。
ADMIN_KUBECONFIG:管理员集群的 kubeconfig 文件的路径。
运行适用的命令来备份集群:
管理员集群
gkectl backup admin --kubeconfig ADMIN_KUBECONFIG
用户集群
gkectl backup cluster --cluster-name CLUSTER_NAME \ --kubeconfig ADMIN_KUBECONFIG
默认情况下,备份 tar 文件会保存到管理员工作站上的 gkectl-workspace/backups
目录。tar 文件名为 CLUSTER_NAME_backup_TIMESTAMP.tar.gz
,其中 CLUSTER_NAME
是正在备份的集群的名称,TIMESTAMP
是备份的日期和时间。例如,如果集群名称为 testuser
,则备份文件的名称类似于 testuser_backup_2025-08-23T150405Z0700.tar.gz
。
(可选)您可以使用 --backup-file
标志为备份文件指定其他名称和位置,例如:
gkectl backup cluster testuser \
--kubeconfig admin-cluster/kubeconfig \
--backup-file cluster-backups/testuser-backup-aug-23-2025.tar.gz
备份文件会在一年后过期,并且集群恢复过程不会使用过期的备份文件。
备份到 vSphere
如需配置备份,以便将管理员集群和用户集群的备份文件上传到 vSphere,同时将其保存在管理员工作站上,请执行以下操作:
将 clusterBackup.datastore 字段添加到管理员集群配置文件:
clusterBackup: datastore: DATASTORE
将
DATASTORE
替换为要存储备份的数据存储区。数据存储区必须与管理员集群位于同一数据中心。备份位于指定数据存储区的anthos/CLUSTER_NAME/backup
目录中。更新管理员集群:
gkectl update admin --kubeconfig ADMIN_KUBECONFIG \ --config ADMIN_CONFIG
替换以下内容:
ADMIN_KUBECONFIG
:管理员集群的 kubeconfig 文件的路径。ADMIN_CONFIG
:管理员集群配置文件的路径。
默认情况下,gkectl backup
命令会将 vSphere 中最近的三个备份文件保存下来,并删除较旧的备份文件。如果您想保留旧的备份文件,请添加 --keep-all-backups
标志(此标志在版本 1.32.100 及更高版本中提供)。
恢复集群
通过备份恢复集群是最后的补救手段,应在集群发生灾难性故障并且无法以任何其他方式恢复服务时使用。例如,etcd 数据损坏或 etcd pod 陷入崩溃循环。
仅当所有三个控制平面节点都出现故障时,才使用 gkectl restore
命令。
如果只有一个节点发生故障,并且管理员集群配置文件中的
autoRepair.enabled
设置为true
,则系统会自动修复发生故障的节点。如果未配置autoRepair.enabled
,请将其添加到管理员集群配置文件中,然后运行gkectl update admin
。更新后,系统会自动重新创建节点。如果两个控制平面节点都已失败,请参阅本页面上的恢复法定人数部分。
备份 tar 文件包含敏感凭据,包括您的服务账号密钥和 SSH 密钥。为防止意外泄露文件,Google Distributed Cloud 恢复过程仅使用内存中的文件。
在恢复集群之前,请确保满足以下条件:
- 备份时集群可用的所有控制平面节点机器正常运行且可访问。
- 节点之间的 SSH 连接使用备份时所用的 SSH 密钥。这些 SSH 密钥会在恢复过程中恢复。
- 备份时使用的服务账号密钥仍然有效。这些服务账号密钥会针对恢复的集群恢复。
要恢复集群,请执行以下操作:
运行适用的命令以恢复集群:
管理员集群
gkectl restore admin --backup-file BACKUP_FILE \ --config ADMIN_CONFIG
替换以下内容:
BACKUP_FILE
:您使用的备份文件的路径和名称。ADMIN_CONFIG
:管理员集群配置文件的路径。
用户集群
gkectl restore cluster --cluster-name CLUSTER_NAME \ --backup-file BACKUP_FILE \ --kubeconfig ADMIN_KUBECONFIG
替换以下内容:
CLUSTER_NAME
:要恢复的集群的名称。BACKUP_FILE
:您使用的备份文件的路径和名称。ADMIN_KUBECONFIG
:管理员集群 kubeconfig 文件的路径。
在恢复过程结束时,系统会在工作区目录
gkectl-workspace
中为恢复的集群生成新的 kubeconfig 文件。恢复完成后,运行以下命令以验证恢复是否成功:
gkectl diagnose cluster --cluster-name CLUSTER_NAME \ --kubeconfig GENERATED_KUBECONFIG
将
GENERATED_KUBECONFIG
替换为生成的 kubeconfig 文件。
恢复仲裁
如果集群中有两个控制平面节点发生故障,您可以使用 gkectl restore
命令来恢复法定人数。恢复仲裁时,您需要向 gkectl restore
命令指定正在运行的控制平面节点的 IP 地址,而不是指定备份文件。
在运行命令之前,请确保满足以下条件:
- 只有一个控制平面节点在运行。
- 可以使用 SSH 密钥访问正常运行的控制平面节点。如需了解详情,请参阅使用 SSH 连接到集群节点。
如需恢复仲裁,请运行适用于您的集群类型的命令:
管理员集群
gkectl restore admin --kubeconfig ADMIN_KUBECONFIG \
--config ADMIN_CONFIG \
--control-plane-node WORKING_NODE_IP \
--ssh-key ADMIN_SSH_KEY_PATH
替换以下内容:
ADMIN_KUBECONFIG
:管理员集群的 kubeconfig 文件的路径。ADMIN_CONFIG
:管理员集群配置文件的路径。WORKING_NODE_IP
:正在运行的控制平面节点的 IP 地址。ADMIN_SSH_KEY_PATH
:管理员集群 SSH 密钥路径。
用户集群
gkectl restore cluster --cluster-name CLUSTER_NAME \
--kubeconfig ADMIN_KUBECONFIG \
--control-plane-node WORKING_NODE_IP \
--ssh-key USER_SSH_KEY_PATH
替换以下内容:
CLUSTER_NAME
:要恢复的集群的名称。ADMIN_KUBECONFIG
:管理员集群 kubeconfig 文件的路径。WORKING_NODE_IP
:正在运行的控制平面节点的 IP 地址。USER_SSH_KEY_PATH
:用户集群 SSH 密钥路径。
问题排查
如果您在备份或恢复过程中遇到问题,以下部分可帮助您排查问题。
如果您需要其他帮助,请与 Cloud Customer Care 团队联系。
在备份或恢复期间内存不足
如果您运行 gkectl
命令的工作站没有大量 RAM,则内存可能不足以执行备份或恢复过程。如果需要,请使用备份命令中的 --use-disk
参数创建并使用临时暂存磁盘来处理备份或恢复操作。为了保留文件权限,此参数会修改文件的权限,因此需要您以根用户身份运行命令(或使用 sudo
)。
在备份后刷新 SSH 密钥会中断恢复过程
如果在执行备份后刷新 SSH 密钥,则恢复过程中与 SSH 相关的操作可能会失败。在这种情况下,新的 SSH 密钥会在恢复过程中失效。如需解决此问题,您可以临时重新添加原始 SSH 密钥,然后执行恢复。恢复过程完成后,您可以轮替 SSH 密钥。