浏览铁人赛众多优质文章时，也别忘了做好备份 etcd 基本功．

etcd 是 OpenShift平台的键值存储资料库（key-value store），可储存整个系统每个资源的状态，譬如配置，规格以及运行中的工作负载的状态。系统管理员应定期备份 etcd 数据，并最好备份到在 OpenShift 外部的安全位置。

本篇文章将介绍如何备份 OpenShift 4.5 的 etcd 数据。

确认 etcd Cluster 是健康的

方法一： ssh 到其中一个 master 节点并执行 etcdctl endpoint health 指令

$ ssh -i id_rsa core@masternode1
$ source /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd-common-tools
$ source /etc/kubernetes/static-pod-resources/etcd-certs/configmaps/etcd-scripts/etcd.env
$ etcdctl endpoint health
https://192.168.50.10:2379 is healthy: successfully committed proposal: took = 12.932144ms
https://192.168.50.11:2379 is healthy: successfully committed proposal: took = 14.816544ms
https://192.168.50.12:2379 is healthy: successfully committed proposal: took = 15.857068ms

方法二： 透过 oc 指令

$ oc get etcd -o=jsonpath='{range .items[0].status.conditions[?(@.type=="EtcdMembersAvailable")]}{.message}{"\n"}'
3 members are available

备份 etcd 数据。

在任何一个健康的 master 节点执行以下指令

＄ /usr/local/bin/cluster-backup.sh /var/home/core/backup/
512a3e830ede6af4472474ae1ab90ac7c5fb8c9e60b20b96bbb90a30f8c8a97c
etcdctl version: 3.3.18
API version: 3.3
found latest kube-apiserver-pod: /etc/kubernetes/static-pod-resources/kube-apiserver-pod-63
found latest kube-controller-manager-pod: /etc/kubernetes/static-pod-resources/kube-controller-manager-pod-39
found latest kube-scheduler-pod: /etc/kubernetes/static-pod-resources/kube-scheduler-pod-37
found latest etcd-pod: /etc/kubernetes/static-pod-resources/etcd-pod-21
Snapshot saved at /var/home/core/backup//snapshot_2020-10-13_062754.db
snapshot db and kube resources are successfully saved to /var/home/core/backup/

上面指令会产生两个档案在 /var/home/core/backup/ 资料夹

• snapshot_.db: etcd 的主要 snapshot.
• static_kuberesources_.tar.gz: 这个档案包含了 master 节点上 static Pods 的资讯。

执行完後只要将该这两个档案上传到 Nexus 或其他 OpenShift 外部的位置保存即可。

如何修复 failed 的 etcd 成员

etcd 可容忍一小部分成员故障来实现高可用性。 但是，为了改善 etcd 的整体运行状况，请立即更换发生故障的成员。如果多个成员失败，请“一个接一个”的替换它们，切勿同时替换所有故障的成员。替换失败的成员主要涉及两个步骤：删除失败的成员和添加新成员。

1. 取得故障成员的 ID :

etcdctl  member list -w table
+------------------+---------+-----------------+----------------------------+----------------------------+
|        ID        | STATUS  |      NAME       |         PEER ADDRS         |        CLIENT ADDRS        |
+------------------+---------+-----------------+----------------------------+----------------------------+
|  38cea7b2f31b828 | started | masternode1 | https://192.168.50.10:2380 | https://192.168.50.10:2379 |
|  e478d9c72b17c7f | started | masternode2 | https://192.168.50.11:2380 | https://192.168.50.11:2379 |
| c8a14199c8670745 | unreachable | masternode3 | https://192.168.50.12:2380 | https://192.168.50.12:2379 |
+------------------+---------+-----------------+----------------------------+----------------------------+

2. 移除故障成员:

etcdctl member remove c8a14199c8670745

3. 删除并重新创建 master 节点. 当新的 master 节点建立之後, etcd 会自动 scales up 。

4. 确定所有瘩 etcd Pods 状态都是 Running:

$ oc get pods -n openshift-etcd | grep etcd
etcd-masternode0                 3/3     Running     0          16d20h
etcd-masternode1                 3/3     Running     0          16d20h
etcd-masternode2                 3/3     Running     0          16d20h

Restore from snapshot

请参考官方文件 来透过之前备份的 snapshot 复原 etcd 到之前的状态。我就不赘述了。

注意: 这个步骤必须先移除其他 etcd 成员，确定只有一个主要的节点有正常的运行的 etcd 。 复原到之前的状态漏，再透过 etcd cluster Operator 将 etcd 扩充到剩余的 master 节点.

结论

如果有要对 master 节点做安全性更新而需要重新启动 VM，务必在那之前先做好备份，必且避免一次同时重新启动所有 master 节点。笔者就曾好几次因为底层的 infra 团队因为没有注意，而导致部分 etcd 成员上的资料不一致，笔者也不确定谁的资料才是最新的，只能选择从最近的备份 snapshot 紧急做 recovery。

参考资料

• https://medium.com/better-programming/a-closer-look-at-etcd-the-brain-of-a-kubernetes-cluster-788c8ea759a5
• https://docs.openshift.com/container-platform/4.5/backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.html