本文档简述了Kubernetes主节点灾备恢复的相关步骤,供在发生k8s master崩溃时操作。
就算是在k8s里部署了etcd群集, 主节点控制组件的高可用节点,灾备恢复也是必须要实现的操作,才能形成完备的企业级服务方案。
K8s集群在master节点发生故障时,并不会影响已有的pod运行和服务开放,所以对服务是没有影响的。故而我们可以在发生故障之后,挑选合适的时间窗口进行维护和恢复,可以对外部客户造成最低的影响。
严格来讲,通过kubeadm安装的k8s主节点包括两大类的灾备恢复,etcd数据存储恢复和主节点控制组件恢复(包括但不限于kube-apiserver,kube-controller-manager,kube-scheduler,flannel,coreDns,dashboard)。
所以本文档也会相应的分成两个章节来进行描述。
之前的文档是全手工操作,而此次升级版,参考了国外比较正规的作法,形成了每天自动备份的机制。主要参考URL:
一,Etcd数据备份及恢复
etcd的数据默认会存放在我们的命令工作目录中,我们发现数据所在的目录,会被分为两个文件夹中:
- snap: 存放快照数据,etcd防止WAL文件过多而设置的快照,存储etcd数据状态。
- wal: 存放预写式日志,最大的作用是记录了整个数据变化的全部历程。在etcd中,所有数据的修改在提交前,都要先写入到WAL中。
A,单节点etcd数据备份
此方案备份etcd的数据时,为了部署方便和兼容,使用了k8s安装时本身的images作为运行容器(k8s.gcr.io/etcd-amd64:3.1.12)。使用以下yaml文件,运行在k8s的master上,即每天备份etcd的数据了。
etcd-backup.yaml
apiVersion: batch/v1beta1kind: CronJobmetadata: name: backup namespace: kube-systemspec: # activeDeadlineSeconds: 100 schedule: "0 0 * * *" jobTemplate: spec: template: spec: containers: - name: backup # Same image as in /etc/kubernetes/manifests/etcd.yaml image: k8s.gcr.io/etcd-amd64:3.1.12 env: - name: ETCDCTL_API value: "3" command: ["/bin/sh"] args: ["-c", "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 /backup/etcd-snapshot-$(date +%Y-%m-%d_%H:%M:%S_%Z).db"] volumeMounts: - mountPath: /etc/kubernetes/pki/etcd name: etcd-certs readOnly: true - mountPath: /backup name: backup restartPolicy: OnFailure nodeSelector: node-role.kubernetes.io/master: "" tolerations: - key: "node-role.kubernetes.io/master" effect: "NoSchedule" hostNetwork: true volumes: - name: etcd-certs hostPath: path: /etc/kubernetes/pki/etcd type: DirectoryOrCreate - name: backup hostPath: path: /tmp/etcd_backup/ type: DirectoryOrCreate
从上面的yaml文件中,我们可以看到其实现思路:
1, 定义为CronJob,这个pod每天凌晨会自动运行(schedule: "0 0 * * *")。
2, 此pod是运行在master上的(nodeSelector + tolerations 实现)。
3, 挂载了master机器上的/tmp/etcd_backup/作为备份目录,这个目录生产环境最好挂载或及时cp到其它机器,防止机器本身的意外情况。
4, 传进的参数为ETCDCTL_API版本3的命令进行备份。
Args参数中的"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 /backup/etcd-snapshot-$(date +%Y-%m-%d_%H:%M:%S_%Z).db"即为备份命令。它按照时间的格式命名etcd的备份数据。
B,单节点etcd数据恢复
如果已有备份数据,在只有etcd数据损坏的下,可根据以下步骤进行恢复。
1, 将/etc/kubernetes/manifests/ kube-apiserver.yaml文件里的镜像版本更改,停止kube-api server服务。
2, 将/etc/kubernetes/manifests/ etcd.yaml文件里的镜像版本更改,停止etcd server服务。
3, 运行如下命令,将损坏的数据文件移至其它地方。
mv /var/lib/etcd/* /tmp/
4, 运行以下命令,以临时docker运行的方式,将数据从备份里恢复到/var/lib/etcd/。
docker run --rm \
-v '/tmp:/backup' \
-v '/var/lib/etcd:/var/lib/etcd' \
--env ETCDCTL_API=3 \
'k8s.gcr.io/etcd-amd64:3.1.12' \
/bin/sh -c "etcdctl snapshot restore '/backup/etcd-snapshot-xxx_UTC.db' ; mv /default.etcd/member/ /var/lib/etcd/"
[上面的命令中,假定我们已将待还原数据放置于/tmp/目录下]
5, 改回/etc/kubernetes/manifests/kube-apiserver.yaml文件里的镜像版本,恢复etcd server服务。
6, 改回/etc/kubernetes/manifests/etcd.yaml文件里的镜像版本,恢复kube-api server服务。
二,Master节点控制组件的备份及恢复
一般来说,如果master节点需要备份恢复,那除了误操作和删除,很可能就是整个机器已出现了故障,故而可能需要同时进行etcd数据的恢复。
而在恢复时,有个前提条件,就是在待恢复的机器上,机器名称和ip地址需要与崩溃前的主节点配置完成一样,因为这个配置是写进了etcd数据存储当中的。
A,主节点数据备份
主节点数据的备份包括三个部分:
1,/etc/kubernetes/目录下的所有文件(证书,manifest文件)
2,用户主目录下.kube/config文件(kubectl连接认证)
3,/var/lib/kubelet/目录下所有文件(plugins容器连接认证)
[最好这一步,也作成cronjob的yaml,每天自动运行]
k8s-master-backup.yaml
apiVersion: batch/v1beta1kind: CronJobmetadata: name: k8s-master-backup namespace: kube-systemspec: # activeDeadlineSeconds: 100 schedule: "5 0 * * *" jobTemplate: spec: template: spec: containers: - name: k8s-master-backup image: 3rd_part/alpine:alpine-3.8_glibc-2.28 command: ["/bin/sh"] args: ["-c", "tar -zcvf /backup/k8s-master-$(ifconfig eth0 | grep 'inet addr:' | awk '{print $2}' | cut -c 6-)-$(date +%Y-%m-%d_%H:%M:%S_%Z).tar.gz /kubernetes /kubelet"] volumeMounts: - mountPath: /backup name: backup - mountPath: /kubernetes name: kubernetes - mountPath: /kubelet name: kubelet restartPolicy: OnFailure nodeSelector: node-role.kubernetes.io/master: "" tolerations: - key: "node-role.kubernetes.io/master" effect: "NoSchedule" hostNetwork: true volumes: - name: backup hostPath: path: /tmp/k8s_master_backup/ type: DirectoryOrCreate - name: kubernetes hostPath: path: /etc/kubernetes/ type: DirectoryOrCreate - name: kubelet hostPath: path: /var/lib/kubelet/ type: DirectoryOrCreate
代码解释:
1, 通过hostPath方式挂载了/etc/kubernetes目录
2, 以hostPath方式挂载了/var/lib/kubelet目录
3, 以hostNetwork: true方式运行,能读取主机IP地址。
4, 以nodeSelector方式,运行于k8s master节点。
5, Backup目录默认挂载于宿主机/tmp/k8s_master_backup/,也需要及时保持到其它机器。
B,主节点组件恢复
主节点组件的恢复可按以下步骤进行:
1,按之前的安装脚本进行全新安装(kubeadm reset,iptables –X…)
2,恢复etcd数据(参见第一章节操作)。
3,将之前备份的两个目录依次还原(.kube/config文件不用还原,根据第4步的提示,还需要先删除/etc/kubernetes/manifest/目录下的文件,及/var/lib/kubelet/pki/目录下的文件)。
4,运行如下命令,重新安装k8s master节点,并使用以前认证和数据。
kubeadm init \
--pod-network-cidr=10.244.0.0/16 \
--kubernetes-version=${K8S_VERSION} \
--feature-gates=CoreDNS=true \
--ignore-preflight-errors=DirAvailable--var-lib-etcd
5,一杯咖啡,稍等片刻,待所有组件启动成功后,根据输出提示,运行如下两条命令,将新的config文件cp到指定位置,进行验证。
mkdir -p $HOME/.kube
cp -f /etc/kubernetes/admin.conf $HOME/.kube/config