kubernetest master 節點恢復災備恢復操作指南

本文基本轉載別人文章，文末會標明出處。

1. 基本說明

? 本文檔簡述了Kubernetes主節點災備恢復的相關步驟，供在發生k8s master崩潰時操作。k8s里部署了etcd群集, 主節點控制組件的高可用節點，災備恢復也是必須要實現的操作，才能形成完備的企業級服務方案。K8s集群在master節點發生故障時，并不會影響已有的pod運行和服務開放，所以對服務是沒有影響的。故而我們可以在發生故障之后，挑選合適的時間窗口進行維護和恢復，可以對外部客戶造成最低的影響。

? 文檔參考了國外比較正規的作法，形成了每天自動備份的機制。主要參考URL：Backup and Restore a Kubernetes Master with Kubeadm

2. Etcd基本概念

? Etcd使用的是raft一致性算法來實現的，是一款分布式的一致性KV存儲，主要用于共享配置和服務發現。關于raft一致性算法請參考該動畫演示。

? 關于Etcd的原理解析請參考Etcd 架構與實現解析。

? etcdctl的V3版本與V2版本使用命令有所不同，etcd2和etcd3是不兼容的。使用etcdctlv3的版本時，需設置環境變量ETCDCTL_API=3。kubernetes默認是使用V3版本。

?

3. Etcd數據備份及恢復

etcd的數據默認會存放在我們的命令工作目錄中，我們發現數據所在的目錄，會被分為兩個文件夾中：

• snap: 存放快照數據,etcd防止WAL文件過多而設置的快照，存儲etcd數據狀態。
• wal: 存放預寫式日志,最大的作用是記錄了整個數據變化的全部歷程。在etcd中，所有數據的修改在提交前，都要先寫入到WAL中。

3.1 單節點etcd數據備份

? 我們使用的是v1.14.3版本，為了部署方便和兼容，使用了k8s安裝時本身的images作為運行容器(k8s.gcr.io/etcd:3.3.10)。使用以下yaml文件，運行在k8s的master上，即每天備份etcd的數據了。

? 首先查看集群中etcd的信息，順便通過提取etcd pod中的，作為我們執行命令的參考。

kubectl get pods -n kube-system kubectl describe pods -n kube-system etcd-docker1 找出liveness中的命令 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

編寫etcd-backup.yaml

apiVersion: batch/v1beta1 kind: CronJob #cronjob方式 metadata:name: etcdbackupnamespace: kube-system spec:schedule: "0 0 * * *" #每天備份數據jobTemplate:spec:template:spec:containers:- name: backup# Same image as in /etc/kubernetes/manifests/etcd.yamlimage: k8s.gcr.io/etcd:3.3.10 #默認鏡像env:- name: ETCDCTL_APIvalue: "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-certsreadOnly: true- mountPath: /backup #證書備份位置映射進來name: backuprestartPolicy: OnFailurenodeSelector:node-role.kubernetes.io/master: "" #節點選擇為主節點tolerations:- key: "node-role.kubernetes.io/master" #打taints，為了使pod能夠容忍mastereffect: "NoSchedule"hostNetwork: truevolumes:- name: etcd-certshostPath:path: /etc/kubernetes/pki/etcd #掛載主機證書文件位置type: DirectoryOrCreate- name: backuphostPath:path: /tmp/etcd_backup/ #備份文件位置type: DirectoryOrCreate

? 從上面的yaml文件中，我們可以看到其實現思路：

定義為CronJob，這個pod每天凌晨會自動運行(schedule: "0 0 *")。

此pod是運行在master上的(nodeSelector + tolerations 實現)。

掛載了master機器上的/tmp/etcd_backup/作為備份目錄，這個目錄生產環境最好掛載或及時cp到其它機器，防止機器本身的意外情況。

傳進的參數為ETCDCTLAPI版本3的命令進行備份。Args參數中的$(date +%Y-%m-%d%H:%M:%S_%Z).db"即為備份命令。它按照時間的格式命名etcd的備份數據。

3.2 單節點etcd數據恢復

? 如果已有備份數據，在只有etcd數據損壞的下，恢復備份如下。主要考慮的順序：停止kube-apiserver，停止ETCD，恢復數據，啟動ETCD，啟動kube-apiserver。

1.將/etc/kubernetes/manifests/ kube-apiserver.yaml文件里的鏡像版本更改，停止kube-api server服務。

2.將/etc/kubernetes/manifests/ etcd.yaml文件里的鏡像版本更改，停止etcd server服務。

3.運行如下命令，將損壞的數據文件移至其它地方。

mv /var/lib/etcd/\* /tmp/

運行以下命令，以臨時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:3.3.10' \ /bin/sh -c "etcdctl snapshot restore '/backup/etcd-snapshot-xxx_UTC.db' ; mv /default.etcd/member/ /var/lib/etcd/"

改回/etc/kubernetes/manifests/kube-apiserver.yaml文件里的鏡像版本，恢復etcd server服務。

改回/etc/kubernetes/manifests/etcd.yaml文件里的鏡像版本，恢復kube-api server服務。

3.3 集群etcd節點控制組件備份

一般來說，如果master節點需要備份恢復，那除了誤操作和刪除，很可能就是整個機器已出現了故障，故而可能需要同時進行etcd數據的恢復。

而在恢復時，有個前提條件，機器名稱和ip地址需要與崩潰前的主節點配置完成一樣，因為這個配置是寫進了etcd數據存儲當中的。

因為高可用集群中的etcd的文件是一樣的，所以我們備份一份文件即可。

具體備份方法參考3.1

3.4 etcd節點控制組件的恢復

首先需要分別停掉三臺Master機器的kube-apiserver，確保kube-apiserver已經停止了。

mv /etc/kubernetes/manifests /etc/kubernetes/manifests.bak docker ps|grep k8s_ # 查看etcd、api是否up，等待全部停止 mv /var/lib/etcd /var/lib/etcd.bak

etcd集群用同一份snapshot恢復。

# 準備恢復文件 cd /tmp tar -jxvf /data/backup/kubernetes/2018-09-18-k8s-snapshot.tar.bz rsync -avz 2018-09-18-k8s-snapshot.db 192.168.105.93:/tmp/ rsync -avz 2018-09-18-k8s-snapshot.db 192.168.105.94:/tmp/

在lab1上執行：

cd /tmp/ export ETCDCTL_API=3 etcdctl snapshot restore 2018-09-18-k8s-snapshot.db \--endpoints=192.168.105.92:2379 \--name=lab1 \--cert=/etc/kubernetes/pki/etcd/server.crt \--key=/etc/kubernetes/pki/etcd/server.key \--cacert=/etc/kubernetes/pki/etcd/ca.crt \--initial-advertise-peer-urls=https://192.168.105.92:2380 \--initial-cluster-token=etcd-cluster-0 \--initial-cluster=lab1=https://192.168.105.92:2380,lab2=https://192.168.105.93:2380,lab3=https://192.168.105.94:2380 \--data-dir=/var/lib/etcd

在lab2上執行：

cd /tmp/ export ETCDCTL_API=3 etcdctl snapshot restore 2018-09-18-k8s-snapshot.db \--endpoints=192.168.105.93:2379 \--name=lab2 \--cert=/etc/kubernetes/pki/etcd/server.crt \--key=/etc/kubernetes/pki/etcd/server.key \--cacert=/etc/kubernetes/pki/etcd/ca.crt \--initial-advertise-peer-urls=https://192.168.105.93:2380 \--initial-cluster-token=etcd-cluster-0 \--initial-cluster=lab1=https://192.168.105.92:2380,lab2=https://192.168.105.93:2380,lab3=https://192.168.105.94:2380 \--data-dir=/var/lib/etcd

在lab3上執行：

cd /tmp/ export ETCDCTL_API=3 etcdctl snapshot restore 2018-09-18-k8s-snapshot.db \--endpoints=192.168.105.94:2379 \--name=lab3 \--cert=/etc/kubernetes/pki/etcd/server.crt \--key=/etc/kubernetes/pki/etcd/server.key \--cacert=/etc/kubernetes/pki/etcd/ca.crt \--initial-advertise-peer-urls=https://192.168.105.94:2380 \--initial-cluster-token=etcd-cluster-0 \--initial-cluster=lab1=https://192.168.105.92:2380,lab2=https://192.168.105.93:2380,lab3=https://192.168.105.94:2380 \--data-dir=/var/lib/etcd

全部恢復完成后，三臺Master機器恢復manifests。

mv /etc/kubernetes/manifests.bak /etc/kubernetes/manifests

最后確認：

# 再次查看key [root@lab1 kubernetes]# etcdctl get / --prefix --keys-only --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key --cacert=/etc/kubernetes/pki/etcd/ca.crt registry/apiextensions.k8s.io/customresourcedefinitions/apprepositories.kubeapps.com/registry/apiregistration.k8s.io/apiservices/v1./registry/apiregistration.k8s.io/apiservices/v1.apps/registry/apiregistration.k8s.io/apiservices/v1.authentication.k8s.io........此處省略.......... [root@lab1 kubernetes]# kubectl get pod -n kube-system NAME READY STATUS RESTARTS AGE coredns-777d78ff6f-m5chm 1/1 Running 1 18h coredns-777d78ff6f-xm7q8 1/1 Running 1 18h dashboard-kubernetes-dashboard-7cfc6c7bf5-hr96q 1/1 Running 0 13h dashboard-kubernetes-dashboard-7cfc6c7bf5-x9p7j 1/1 Running 0 13h etcd-lab1 1/1 Running 0 18h etcd-lab2 1/1 Running 0 1m etcd-lab3 1/1 Running 0 18h kube-apiserver-lab1 1/1 Running 0 18h kube-apiserver-lab2 1/1 Running 0 1m kube-apiserver-lab3 1/1 Running 0 18h kube-controller-manager-lab1 1/1 Running 0 18h kube-controller-manager-lab2 1/1 Running 0 1m kube-controller-manager-lab3 1/1 Running 0 18h kube-flannel-ds-7w6rl 1/1 Running 2 18h kube-flannel-ds-b9pkf 1/1 Running 2 18h kube-flannel-ds-fck8t 1/1 Running 1 18h kube-flannel-ds-kklxs 1/1 Running 1 18h kube-flannel-ds-lxxx9 1/1 Running 2 18h kube-flannel-ds-q7lpg 1/1 Running 1 18h kube-flannel-ds-tlqqn 1/1 Running 1 18h kube-proxy-85j7g 1/1 Running 1 18h kube-proxy-gdvkk 1/1 Running 1 18h kube-proxy-jw5gh 1/1 Running 1 18h kube-proxy-pgfxf 1/1 Running 1 18h kube-proxy-qx62g 1/1 Running 1 18h kube-proxy-rlbdb 1/1 Running 1 18h kube-proxy-whhcv 1/1 Running 1 18h kube-scheduler-lab1 1/1 Running 0 18h kube-scheduler-lab2 1/1 Running 0 1m kube-scheduler-lab3 1/1 Running 0 18h kubernetes-dashboard-754f4d5f69-7npk5 1/1 Running 0 13h kubernetes-dashboard-754f4d5f69-whtg9 1/1 Running 0 13h tiller-deploy-98f7f7564-59hcs 1/1 Running 0 13h

進相應的安裝程序確認，數據全部正常。

4.Etcd最后說明

? 1.本文是綜合了很多篇文章，整理而成，最后會放參考鏈接！

? 2.單點etcd數據恢復的驗證沒有問題，但是恢復命令可以優化

? 3.集群etcd恢復沒有問題，因為集群中存在--initial-cluster-token=etcd-cluster-0所以沒有寫，是可以恢復的。

? 4.時間有限，有空繼續優化編輯。mark下！

5.參考鏈接

阿里云上kubernetes的備份和恢復

kubeadm安裝etcd備份恢復

Kubernetes Master節點災備恢復操作指南

etcd解析

轉載于:https://blog.51cto.com/9406836/2409012

總結

以上是生活随笔為你收集整理的kubernetest master 节点恢复灾备恢复操作指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。