Kubernetes etcd灾备与节点问题处理
前言：
k8s集群的灾备与恢复基于etcd的灾备与恢复，etcd的数据默认会存放在命令的工作目录（即master的/var/lib/etcd/）中，数据所在的目录，会被分为两个文件夹snap与wal：
- snap: 存放快照数据,etcd防止WAL文件过多而设置的快照，存储etcd数据状态。
- wal: 存放预写式日志,最大的作用是记录了整个数据变化的全部历程。在etcd中，所有数据的修改在提交前，都要先写入到WAL中。
单节点etcd数据备份和恢复基于数据文件的备份，Kubeadm的默认安装时，将etcd的数据以文件形式存储在宿主机的/var/lib/etcd/目录，将此目录下的文件定期备份起来，etcd的数据出现问题，需要恢复时，直接将文件还原到此目录下，新库加载文件，就实现了单节点的etcd数据库的重建。
一、etcd的备份：
在做etcd单点备份之前，需要注意两个问题：
- 如果etcd容器正在启动，是不能覆盖的，这时只需要将etcd的manifest文件[/etc/kubernetes/manifests/etcd.yaml]里的etcd版本号更改一下，然后用docker stop命令停止etcd容器，就不会自动重启了。数据还原后，将etcd版本再回到正确的版本，kubelet服务就会自动将etcd容器重启起来。
- etcd 目前最新的版本的 v3.1.1，但它的 API 有 v3 和 v2 之分，使用 v3 备份数据时存在 v2 的数据则不影响恢复，若使用 v2 备份数据时存在 v3 的数据则恢复失败。（简单的来说就是不能用低版本数据备份恢复在高版本服务器上
查看API版本的方法：
docker exec -it <容器id> sh
etcdctl --version
etcdctl version: 3.0.4
API version: 2
备份实例：
cp /var/lib/etcd/ <backup file>
恢复实例：
cp etcd /var/lib/ (master节点/var/lib/etcd与etcd容器的/varlib/etcd为映射关系)
修改/etc/kubernetes/manifests/etcd.yaml中image项（随便修改一个数字，稍后要改回来）
使用docker ps | grep -v pause | grep etcd 命令查看etcd容器，etcd容器消失后将image项改回来
稍等片刻kubelet就会将etcd服务启动
使用docker ps | grep -v pause | grep etcd 命令便可查看到新etcd容器
二、kubernetes生产环境灾备场景：
生产环境中的k8s集群可能出现的问题分以下两种情况：
- node节点出现问题
- master节点出现问题
这两种情况的解决办法如下：
node节点问题：
node节点出现问题一般不会影响到集群的对外服务，处理node节点崩溃相对比较简单，只需创建一个新节点并将其添加到集群中。加入集群步骤如下：（附：如果需要将老node加入新的cluser，则需要在node上执行kubeadm reset后，再重新加入）
生成token
kubeadm token create
查看ca的hash编码
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
然后加入集群
kubeadm join 192.168.10.11:6443 --token yhns57.4s3y2yll21ew8mta \
--discovery-token-ca-cert-hash sha256:ce07a7f5b259961884c55e3ff8784b1eda6f8b5931e6fa2ab0b30b6a4234c09a
重新加入集群以后，master就会根据负载均衡策略，把负载高的节点上的pod调度到该新node，重新达到平衡
master节点问题：
k8s集群在master节点发生故障时，不会影响已有的pod运行和服务开放，所以对服务没有影响，master节点的重建需要etcd数据库的重建和master与k8s集群的重置，找到合适的机会重置master即可。
重置master节点需要备份文件，需要备份的文件有：
etcd数据库备份：
/etc/kubernetes/目录下的所有文件(证书，manifest文件)
- admin.conf
- controller-manager.conf
- kubelet.conf
- manifests
- pki
- scheduler.conf
用户主目录下.kube/config文件(kubectl连接认证)
/var/lib/kubelet/目录下所有文件(plugins容器连接认证)
- config.yaml
- device-plugins
- pki
- plugins
- pod-resources
- cpu_manager_state
- kubeadm-flags.env
- plugin-containers
- plugins_registry
- pods
修复步骤：
重置master
kubeadm reset iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X 恢复etcd数据 将之前备份的/etc/kubernetes/与/var/lib/kubelet/目录下的文件依次还原。 tar -zxvf <back file> -C /etc/kubernetes/ tar -zxvf <back file> -C /var/lib/kubelet/ 删除/etc/kubernetes/manifest/目录下的所有文件 rm -rf /etc/kubernetes/manifest/* 初始化集群 kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --kubernetes-version v1.13.3 \ --image-repository registry.aliyuncs.com/google_containers \ --ignore-preflight-errors=DirAvailable--var-lib-etcd 创建.kube目录与config文件 mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
新机器使用备份重建master：
1.安装好与之前备份版本相同的master.
2.关闭kublet服务（10250端口）.
3.根据备份恢复/etc/kubernetes/与/var/lib/kubelet/和/var/lib/etcd目录
4.开启kubelet服务，kubelet服务就会将容器启动。
5.检验集群回复情况。
三、当集群不可用：
如果是整个集群的崩溃的话，需要做的工作就是重建集群，当然,服务肯定会中断，恢复的方法是重建master并恢复etcd数据库，新建node节点并加入该master集群，新的pod就会自动建立，因为我们用的是etcd单点，且是低版本v2API，所以恢复etcd数据库还是比较简单的（十分钟），这样决定服务中断时间的就是master和node的重建。数据损失取决于etcd备份的时间差。
参考链接：
https://blog.csdn.net/weixin_43046724/article/details/103504800
