备份和恢复集群

Version 1.7 (unsupported)

• 版本 1.28（最新）
• 版本 1.16
• 版本 1.15
• 较低版本（不受支持）

本页面介绍如何备份和恢复使用 Anthos clusters on Bare Metal 创建的集群。以下说明适用于 Anthos clusters on Bare Metal 支持的所有集群类型。

警告：使用备份文件来恢复 etcd 数据是最后的选择。除非集群完全损坏，否则我们不建议从备份文件进行恢复。请与 Google 支持团队联系，请其帮助您确定最合适的行动方案。

备份集群

备份过程包括两个部分。首先，通过 etcd 存储区创建快照。然后，相关的 PKI 证书会保存到一个 tar 文件中。etcd 存储区是所有集群数据的 Kubernetes 后备存储区，包含管理集群状态需要的所有 Kubernetes 对象和自定义对象。PKI 证书用于通过 TLS 进行身份验证。此数据从集群的控制层面或高可用性 (HA) 集群的其中一个控制层面进行备份。

我们建议您定期备份集群，以确保快照数据相对最新。备份频率取决于集群进行重大更改的频率。

创建 etcd 存储区的快照

在 Anthos clusters on Bare Metal 中，kube-system 命名空间中名为 etcd-CONTROL_PLANE_NAME 的 pod 会运行该控制层面的 etcd。要备份集群的 etcd 存储区，请从管理员工作站执行以下步骤：

1. 使用 kubectl get po 标识 etcd pod。

   kubectl --kubeconfig CLUSTER_KUBECONFIG get po -n kube-system \
       -l 'component=etcd,tier=control-plane'
   

   响应内容包括 etcd pod 名称及其状态。

2. 使用 kubectl describe pod 查看在 etcd Pod 中运行的容器（包括 etcd 容器）。

   kubectl --kubeconfig CLUSTER_KUBECONFIG describe pod ETCD_POD_NAME -n kube-system
   

3. 在 etcd 容器中运行 Bash shell：

   kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
       ETCD_POD_NAME --container etcd --namespace kube-system \
       -- bin/sh
   

4. 在 etcd 容器内的 shell 中，使用 etcdctl（API 的第 3 版）保存 etcd 存储区的快照 snapshot.db。

   ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt \
       --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
       --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
       snapshot save snapshotDATESTAMP.db
   

   将 DATESTAMP 替换为当前日期，以防止覆盖任何后续快照。

5. 从容器中的 shell 退出，然后运行以下命令将快照文件复制到管理员工作站。

   kubectl --kubeconfig CLUSTER_KUBECONFIG cp \
       kube-system/ETCD_POD_NAME:snapshot.db \
       --container etcd snapshot.db
   

6. 请将快照文件存储在集群外部且不依赖于集群操作的位置。

将 PKI 证书归档

要备份的证书位于控制层面的 /etc/kubernetes/pki 目录中。如果控制层面完全停止运行，将需要使用 PIK 证书和 etcd 存储区 snapshot.db 文件来恢复集群。以下步骤将创建一个包含 PKI 证书的 tar 文件。

1. 使用 ssh 以根用户身份连接到集群的控制层面。

   ssh root@CONTROL_PLANE_NAME
   

2. 在控制层面中，创建一个包含 /etc/kubernetes/pki 目录内容的 certs_backup.tar.gz 文件。

   tar -czvf certs_backup.tar.gz -C /etc/kubernetes/pki .
   

   在控制层面内创建 tar 文件会保留所有证书文件权限。

3. 退出控制层面，然后从工作站中将包含证书的 tar 文件复制到工作站中的首选位置。

   sudo scp root@CONTROL_PLANE_NAME:certs_backup.tar.gz BACKUP_PATH
   

恢复集群

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

集群恢复过程包括两个部分。首先，在控制层面上恢复 PKI 证书。然后，恢复 etcd 存储区数据。

恢复 PKI 证书

假设您已按照归档 PKI 证书中的说明设置了 PKI 证书，则以下步骤介绍了如何将证书从 tar 文件恢复到控制层面。

1. 将 PKI 证书 tar 文件 certs_backup.tar.gz 从工作站复制到集群控制层面。

   sudo scp -r BACKUP_PATH/certs_backup.tar.gz root@CONTROL_PLANE_NAME:~/
   

2. 使用 ssh 以根用户身份连接到集群的控制层面。

   ssh root@CONTROL_PLANE_NAME
   

3. 从控制层面中，将 tar 文件的内容提取到 /etc/kubernetes/pki 目录。

   tar -xzvf certs_backup.tar.gz -C /etc/kubernetes/pki/
   

4. 退出控制层面。

恢复 etcd 存储区

恢复 etcd 存储区时，具体过程取决于集群是否以高可用性 (HA) 模式运行，以及如果是，是否保留了仲裁。根据给定的集群故障场景，按照相应的指南恢复 etcd 存储区：

• 如果故障集群未以高可用性模式运行，则按照以下步骤在控制层面上恢复 etcd 存储区。

• 如果集群以高可用性模式运行，并且保留了仲裁，则不执行任何操作。只要保留了仲裁，则无需恢复故障集群。

• 如果集群以高可用性模式运行，并且配额丢失，则重复上述步骤，以使每个失败成员恢复 etcd 存储空间。

如需从工作站中移除和恢复故障集群的控制层面的 etcd 存储区，请按以下步骤操作：

1. 在控制层面的根目录中创建 /backup 目录。

   ssh root@CONTROL_PLANE_NAME "mkdir /backup"
   

   此步骤并非严格要求，但我们建议执行。以下步骤假定您已创建 /backup 目录。

2. 将 etcd 快照文件 snapshot.db 从工作站复制到集群控制层面上的 backup 目录。

   sudo scp snapshot.db root@CONTROL_PLANE_NAME:/backup
   

3. 使用 SSH 连接到控制层面节点：

   ssh root@CONTROL_PLANE_NAME
   

4. 将 etcd 和 kube-apiserver 静态 Pod 的清单文件从 /etc/kubernetes/manifests 目录移至 /backup 目录，停止这些 Pod。

   sudo mv /etc/kubernetes/manifests/etcd.yaml /backup/etcd.yaml
   sudo mv /etc/kubernetes/manifests/kube-apiserver.yaml /backup/kube-apiserver.yaml
   

5. 移除 etcd 数据目录。

   rm -rf /var/lib/etcd/
   

6. 使用 docker 运行 etcdctl 快照恢复。

   sudo docker run --rm -t \
       -v /var/lib:/var/lib \
       -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd \
       -v /backup:/backup \
       --env ETCDCTL_API=3 \
       k8s.gcr.io/etcd:3.2.24 etcdctl \
       --cacert=/etc/kubernetes/pki/etcd/ca.crt \
       --cert=/etc/kubernetes/pki/etcd/server.crt \
       --key=/etc/kubernetes/pki/etcd/server.key \
       --data-dir=/var/lib/etcd \
       --name=CONTROL_PLANE_NAME \
       --initial-advertise-peer-urls=https://CONTROL_PLANE_IP:2380 \
       --initial-cluster=CONTROL_PLANE_NAME=https://CONTROL_PLANE_IP:2380 \
       snapshot restore /backup/snapshot.db
   

   您可以在移动到 /backup 目录的 etcd.yaml 清单文件中找到 --name、--initial-advertise-peer-urls 和 --initial-cluster 条目。

7. 确保重新创建了 /var/lib/etcd，并在 /var/lib/etcd/member 中创建了一个新成员。

8. 将 etcd 和 kube-apiserver 清单移回 /manifests 目录，以便静态 Pod 可以重启。

   sudo mv /backup/etcd.yaml /etc/kubernetes/manifests/etcd.yaml
   sudo mv /backup/kube-apiserver.yaml /etc/kubernetes/manifests/kube-apiserver.yaml
   

9. 在 etcd 容器中运行 Bash shell：

   kubectl --kubeconfig CLUSTER_KUBECONFIG exec -it \
       ETCD_POD_NAME --container etcd --namespace kube-system \
       -- bin/sh
   

10. 使用 etcdctl 确认添加的成员正常运行。

    ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt  \
        --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
        --cacert=/etc/kubernetes/pki/etcd/ca.crt \
        --endpoints=CONTROL_PLANE_IP:2379 \
        endpoint health
    

    如果您要恢复多个失败的成员，请在恢复所有失败的成员后，在“--endpoints”字段中恢复所有恢复成员的控制层面 IP 地址。

    例如：

    ETCDCTL_API=3 etcdctl --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt  \
        --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
        --cacert=/etc/kubernetes/pki/etcd/ca.crt \
        --endpoints=10.200.0.3:2379,10.200.0.4:2379,10.200.0.5:2379 \
        endpoint health
    

    如果每个端点都正常运行，您的集群应该在正常运行。