RKE 集群备份和恢复
概述
v0.1.7 或以上版本可用
RKE 集群可以自动备份 etcd 节点的快照。在灾难场景下，您可以使用这些快照恢复集群。RKE 将快照保存本地/opt/rke/etcd-snapshots路径下。
v0.2.0 或以上版本可用
RKE 可将集群快照上传至 AWS S3 适配的后端机器。
说明：RKE v0.2.0 改变了存储集群状态的方式，所以pki.bundle.tar.gz不再是必须的文件。
备份集群
您可以手动创建集群备份，或为集群创建定时快照。
创建一次性快照
RKE v0.2.0 或以上的版本
打开命令行工具，输入rke etcd snapshot-save命令，运行后即可保存 cluster config 文件内每个 etcd 节点的快照。RKE 会将节点快照保存在/opt/rke/etcd-snapshots路径下。运行上述命令时，RKE 会创建一个用于备份快照的容器。完成备份后，RKE 会删除该容器。
- 首先，运行以下命令，在本地创建一个一次性快照：
rke etcd snapshot-save --config cluster.yml --name snapshot-name
结果： 创建了一个快照，保存在 /opt/rke/etcd-snapshots路径下。
- 然后，你可以进一步把上述快照文件保存到远端存储，以便灾难恢复。
创建定时快照
RKE v0.2.0 或以上的版本
您可以启用etcd-snapshot服务，使用相关的配置参数，开启定时备份 etcd 节点快照功能。
etcd-snapshot在etcd容器之外的服务容器中运行。默认设置下，etcd-snapshot服务会为每一个具有etcd角色的节点创建快照，然后将这些快照储存在本地的/opt/rke/etcd-snapshots路径下。
快照服务日志
运行已经启用etcd-snapshot的集群时，您可以在命令行工具中输入docker logs etcd-rolling-snapshots，查看etcd-rolling-snapshots日志，确认集群是否已开启定时快照功能。如果集群已经开启定时快照功能，输入该命令后，返回的消息包含了每个快照的创建时间、创建信息、名称和运行时间，与下方代码示例相似。
docker logs etcd-rolling-snapshots
time="2018-05-04T18:39:16Z" level=info msg="Initializing Rolling Backups" creation=1m0s retention=24h0m0s
time="2018-05-04T18:40:16Z" level=info msg="Created backup" name="2018-05-04T18:40:16Z_etcd" runtime=108.332814ms
time="2018-05-04T18:41:16Z" level=info msg="Created backup" name="2018-05-04T18:41:16Z_etcd" runtime=92.880112ms
time="2018-05-04T18:42:16Z" level=info msg="Created backup" name="2018-05-04T18:42:16Z_etcd" runtime=83.67642ms
time="2018-05-04T18:43:16Z" level=info msg="Created backup" name="2018-05-04T18:43:16Z_etcd" runtime=86.298499ms
Etcd-Snapshot 服务的可配置参数
创建定时快照时，可配置的主要参数如下表所示。
配置快照服务的 YAML 示例
services:
etcd:
backup_config:
interval_hours: 12 # 创建快照的间隔时间，单位是小时，12表示每12个小时创建一个快照
retention: 6 # 快照的存活时间，单位是小时
恢复集群
您可以使用 RKE 备份的集群快照恢复集群。
RKE v0.2.0 或以上的版本
如果您的 Kubernetes 集群发生了灾难，您可以使用rke etcd snapshot-restore来恢复您的 etcd。这个命令可以将 etcd 恢复到特定的快照，应该在遭受灾难的特定集群的 etcd 节点上运行。
当您运行该命令时，将执行以下操作。
- 同步快照。
- 跨 etcd 节点检查快照校验和，确保它们是相同的。
- 通过运行rke remove删除您当前的集群并清理旧数据。这将删除整个 Kubernetes 集群，而不仅仅是 etcd 集群。
- 从选择的快照重建 etcd 集群。
- 通过运行rke up创建一个新的集群。
- 重新启动集群系统 pod。
警告：在运行rke etcd snapshot-restore之前，您应该备份集群中的任何重要数据，因为该命令会删除您当前的 Kubernetes 集群，并用新的集群替换。
用于恢复 etcd 集群的快照可以存储在本地的/opt/rke/etcd-snapshots中，也可以存储在远端存储。
从本地快照恢复的示例
请运行以下命令，从本地快照中还原 etcd：
rke etcd snapshot-restore --config cluster.yml --name mysnapshot
假设快照位于/opt/rke/etcd-snapshots中。
注意：不需要pki.bundle.tar.gz文件，因为 RKE v0.2.0 改变了Kubernetes 集群状态的存储方式。
示例场景
示例场景使用的是部署在两个 AWS 节点上的 Kubernetes 集群：node1 和node2。我们会模拟node2失效的场景，创建一个新的节点node3并将node2的快照备份迁移到node3。节点的详细信息如下表所示：
RKE v0.2.0 或更新的版本
概述
使用 RKE v0.2.0 或更新的版本进行备份和恢复集群的操作指导，分为以下五个步骤：
- 备份集群
- 模拟节点 failure
- 新建 etcd 节点
- 使用备份恢复新建节点的数据
- 确认恢复后的集群处于正常状态
备份集群
运行以下命令，备份集群。
rke etcd snapshot-save --name snapshot.db --config cluster.yml
模拟节点失效的场景
运行以下命令，关闭node2，模拟节点失效的场景。运行命令后，node2的状态变更为不可用：
root@node2:~# poweroff
新建 etcd 节点
升级和恢复 etcd 节点之前，您需要将新建的节点添加到 Kubernetes 集群内，并为其分配etcd角色。请打开cluster.yml文件，将node2相关的参数变更为注释，然后添加新节点node3的参数，如下所示。
nodes:
- address: 10.0.0.1
hostname_override: node1
user: ubuntu
role:
- controlplane
- worker
# - address: 10.0.0.2
# hostname_override: node2
# user: ubuntu
# role:
# - etcd
- address: 10.0.0.3
hostname_override: node3
user: ubuntu
role:
- etcd
使用备份恢复新建节点的数据
先决条件：开始恢复节点前，请确保您的cluster.rkestate文件有效，因为该文件包含了集群所需的证书数据。
将新建的节点添加到cluster.yml中后，运行 rke etcd snapshot-restore命令，从备份中启动etcd：
rke etcd snapshot-restore --name snapshot.db --config cluster.yml
默认配置下，RKE 将快照保存在/opt/rke/etcd-snapshots路径。
说明：从 v0.2.0 开始，恢复集群所需的证书信息存储在cluster.rkestate中，所以pki.bundle.tar.gz不再是恢复集群时的必备文件。
确认恢复后的集群处于正常状态
rke etcd snapshot-restore命令触发了使用新的cluster.yml运行rke up命令。请运行kubectl get pods确认您的 Kubernetes 集群处于正常状态。如果状态正常，返回的信息应该与以下代码示例相似：
> kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-65899c769f-kcdpr 1/1 Running 0 17s
nginx-65899c769f-pc45c 1/1 Running 0 17s
nginx-65899c769f-qkhml 1/1 Running 0 17s
问题排查
从 RKEv0.1.9开始，不论恢复节点的结果是成功还是失败，rke-bundle-cert容器都会被移除，无法依据完成恢复节点的流程以后，rke-bundle-cert容器是否依然存在，来确认恢复节点成功或失败。您需要查看 RKE 的日志排查问题。
