使用 bmctl 备份和恢复集群

本页面介绍如何使用 bmctl 备份和恢复使用 Google Distributed Cloud 创建的集群。以下说明适用于 Google Distributed Cloud 支持的所有集群类型。

警告：使用备份文件来恢复集群是最后的选择。恢复过程会重置现有集群并覆盖集群信息。除非集群发生灾难性故障，否则我们不建议从备份文件进行恢复。请与 Cloud Customer Care 团队联系，请其帮助您确定最合适的行动方案。

bmctl 备份和恢复过程不包括永久性卷。本地卷预配工具 (LVP) 创建的任何卷都将保持不变。

如果您需要其他帮助，请与 Cloud Customer Care 联系。

备份集群

bmctl backup cluster 命令会将 etcd 存储区中的集群信息和指定集群的 PKI 证书添加到 tar 文件中。etcd 存储区是所有集群数据的 Kubernetes 后备存储区，包含管理集群状态需要的所有 Kubernetes 对象和自定义对象。PKI 证书用于通过 TLS 进行身份验证。此数据从集群的控制层面或高可用性 (HA) 部署的其中一个控制层面进行备份。

备份 tar 文件包含敏感凭据，包括您的服务账号密钥和 SSH 密钥。请将备份文件存储在安全的位置。为了防止意外的文件泄露，Google Distributed Cloud 备份进程仅使用内存中的文件。

定期备份集群，以确保快照数据相对最新。调整备份频率以反映集群重大更改的频率。

用于备份集群的 bmctl 版本必须与管理集群的版本匹配。

要备份集群，请执行以下操作：

1. 确保集群正常运行，凭据有效并且可通过 SSH 连接所有节点。

   备份过程的目的是捕获处于已知良好状态的集群，以便在发生灾难性故障时可以恢复操作。

   使用以下命令检查集群：

   bmctl check cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG
   

   请替换以下内容：

   • CLUSTER_NAME：您计划备份的集群的名称。
   • ADMIN_KUBEONFIG：管理员集群的 kubeconfig 文件的路径。

2. 运行以下命令以确保目标集群未处于协调状态：

   kubectl describe cluster CLUSTER_NAME -n CLUSTER_NAMESPACE --kubeconfig ADMIN_KUBEONFIG
   

   请替换以下内容：

   • CLUSTER_NAME：要备份的集群的名称。
   • CLUSTER_NAMESPACE：集群的命名空间。默认情况下，Google Distributed Cloud 的集群命名空间是以 cluster- 开头的集群名称。例如，如果您将集群命名为 test，则命名空间的名称类似于 cluster-test。
   • ADMIN_KUBEONFIG：管理员集群的 kubeconfig 文件的路径。

3. 在命令输出中的 Status 部分检查是否有类型为 Reconciling 的 Conditions。

   如以下示例所示，这些 Conditions 的 False 状态表示集群稳定并且可以进行备份。

   ...
   Status:
     ...
     Cluster State:  Running
     ...
     Control Plane Node Pool Status:
       ...
       Conditions:
         Last Transition Time:  2023-11-03T16:37:15Z
         Observed Generation:   1
         Reason:                ReconciliationCompleted
         Status:                False
         Type:                  Reconciling
     ...
   

4. 运行以下命令来备份集群：

   bmctl backup cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBEONFIG
   

   请替换以下内容：

   • CLUSTER_NAME：要备份的集群的名称。
   • ADMIN_KUBEONFIG：管理员集群 kubeconfig 文件的路径。

   默认情况下，备份 tar 文件保存到管理员工作站上的工作区目录（默认为 bmctl-workspace）。tar 文件名为 CLUSTER_NAME_backup_TIMESTAMP.tar.gz，其中 CLUSTER_NAME 是正在备份的集群的名称，TIMESTAMP 是备份的日期和时间。例如，如果集群名称为 testuser，则备份文件的名称类似于 testuser_backup_2006-01-02T150405Z0700.tar.gz。

   如需为备份文件指定其他名称和位置，请使用 --backup-file 标志。

备份文件会在一年后过期，并且集群恢复过程不会使用过期的备份文件。

恢复集群

通过备份恢复集群是最后的补救手段，应在集群发生灾难性故障并且无法以任何其他方式恢复服务时使用。例如，etcd 数据损坏或 etcd Pod 陷入崩溃循环。

注意 ：为了提高集群性能，Google Distributed Cloud 使用单独的 etcd 实例来存储 Event 对象。这些 Event 对象的存留时间 (TTL) 为一小时。集群恢复操作会创建一个新的空 etcd-events 实例，因此您会丢失现有的 Event 对象。但是，事件对象的丢失对集群操作没有影响。事件应被视为信息丰富的、尽力而为的补充数据。

备份 tar 文件包含敏感凭据，包括您的服务账号密钥和 SSH 密钥。为了防止文件意外泄露，Google Distributed Cloud 恢复过程仅使用内存中的文件。

用于恢复集群的 bmctl 版本必须与管理集群的版本匹配。

要恢复集群，请执行以下操作：

1. 确保备份时集群可用的所有节点机器正常运行且可访问。

2. 确保节点之间的 SSH 连接使用备份时所用的 SSH 密钥。

   这些 SSH 密钥会在恢复过程中恢复。

3. 确保备份时使用的服务账号密钥仍然有效。

   这些服务账号密钥会针对恢复的集群恢复。

4. 如需恢复管理员集群、混合集群或独立集群，请运行以下命令：

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE
   

   请替换以下内容：

   • CLUSTER_NAME：要恢复的集群的名称。
   • BACKUP_FILE：您使用的备份文件的路径和名称。

5. 如需恢复用户集群，请运行以下命令：

   bmctl restore cluster -c CLUSTER_NAME --backup-file BACKUP_FILE \
       --kubeconfig ADMIN_KUBEONFIG
   

   请替换以下内容：

   • CLUSTER_NAME：要恢复的集群的名称。
   • BACKUP_FILE：您使用的备份文件的路径和名称。
   • ADMIN_KUBEONFIG：管理员集群 kubeconfig 文件的路径。

在恢复过程结束时，系统会为恢复的集群生成新的 kubeconfig 文件。

问题排查

如果您在备份或恢复过程中遇到问题，以下部分可帮助您排查问题。

如果您需要其他帮助，请与 Google 支持团队联系。

在备份或恢复期间内存不足

在备份或恢复过程中，您可能会收到错误消息，不容易解释或不明确后续步骤。如果在其中运行 bmctl 命令的工作站没有大量 RAM，则内存可能不足以执行备份或恢复过程。

Google Distributed Cloud 1.13 及更高版本可以在备份命令中使用 --use-disk 参数。为了保留文件权限，此参数会修改文件的权限，因此需要运行命令的用户是根用户（或使用 sudo）。

在恢复过程中缺少对文件的权限

恢复任务成功后，删除引导可能会失败，并显示类似于以下示例的错误消息：

Error: failed to restore node config files: sftp: "Failure" (SSH_FX_FAILURE)

此错误可能意味着恢复所需的某些目录不可写入。

Google Distributed Cloud 1.14 及更高版本具有更清晰的错误消息，其中目录必须可写入。确保报告的目录可写入，并根据需要更新目录的权限。

备份中断恢复过程后，刷新 SSH 密钥

如果在执行备份后刷新 SSH 密钥，则恢复过程中与 SSH 相关的操作可能会失败。在这种情况下，新的 SSH 密钥会在恢复过程中失效。

如需解决此问题，您可以临时重新添加原始 SSH 密钥，然后执行恢复。恢复过程完成后，您可以轮替 SSH 密钥。