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

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: etcdbackup
  namespace: kube-system
spec:
  schedule: "0 0 * * *"   #每天備份數據
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            # Same image as in /etc/kubernetes/manifests/etcd.yaml
            image: k8s.gcr.io/etcd:3.3.10 #默認鏡像
            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" #打taints，為了使pod能夠容忍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. 傳進的參數為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/

1. 運行以下命令，以臨時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/"

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

2. 改回/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/
ETCDCTL_API=3 etcdctl snapshot restore etcdbk.db \
--data-dir=/var/lib/etcd \
--initial-advertise-peer-urls="https://192.168.14.138:2380" \
--initial-cluster="docker10=https://192.168.14.140:2380,docker8=https://192.168.14.138:2380,docker9=https://192.168.14.139:2380" \
--initial-cluster-token etcd-cluster \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
--endpoints="https://192.168.14.138:2379"  \
--name docker8

在lab2上執行：

cd /tmp/
ETCDCTL_API=3 etcdctl snapshot restore etcdbk.db \
--data-dir=/var/lib/etcd \
--initial-advertise-peer-urls="https://192.168.14.139:2380" \
--initial-cluster="docker10=https://192.168.14.140:2380,docker8=https://192.168.14.138:2380,docker9=https://192.168.14.139:2380" \
--initial-cluster-token etcd-cluster \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
--endpoints="https://192.168.14.139:2379"  \
--name docker9

在lab3上執行：

cd /tmp/
ETCDCTL_API=3 etcdctl snapshot restore etcdbk.db \
--data-dir=/var/lib/etcd \
--initial-advertise-peer-urls="https://192.168.14.140:2380" \
--initial-cluster="docker10=https://192.168.14.140:2380,docker8=https://192.168.14.138:2380,docker9=https://192.168.14.139:2380" \
--initial-cluster-token etcd-cluster \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
--key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
--endpoints="https://192.168.14.140:2379"  \
--name docker10

全部恢復完成后，三臺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
[root@docker8 manifests]# kubectl get pods -n kube-system 
NAME                               READY   STATUS      RESTARTS   AGE
backup                             0/1     Completed   0          3h21m
backup-1565740800-d86j9            0/1     Completed   0          2d9h
backup-1565827200-rz4lf            0/1     Completed   0          33h
backup-1565913600-vwbfd            0/1     Completed   0          9h
backup1                            0/1     Completed   0          3d2h
coredns-5c98db65d4-9jhw2           1/1     Running     40         3d3h
coredns-5c98db65d4-mfx68           1/1     Running     40         3d3h
etcd-docker10                      1/1     Running     0          5m34s
etcd-docker8                       1/1     Running     0          5m58s
etcd-docker9                       1/1     Running     0          5m54s
kube-apiserver-docker10            1/1     Running     0          5m37s
kube-apiserver-docker8             1/1     Running     1          5m59s
kube-apiserver-docker9             1/1     Running     0          5m55s
kube-controller-manager-docker10   1/1     Running     1          3d3h
kube-controller-manager-docker8    1/1     Running     1          3d3h
kube-controller-manager-docker9    1/1     Running     1          3d3h
kube-flannel-ds-amd64-7hkch        1/1     Running     0          3d3h
kube-flannel-ds-amd64-bnmdd        1/1     Running     0          3d3h
kube-flannel-ds-amd64-zvrvl        1/1     Running     0          3d3h
kube-proxy-gxfkl                   1/1     Running     0          3d3h
kube-proxy-x2tlp                   1/1     Running     0          3d3h
kube-proxy-xpgjf                   1/1     Running     0          3d3h
kube-scheduler-docker10            1/1     Running     1          3d3h
kube-scheduler-docker8             1/1     Running     2          3d3h
kube-scheduler-docker9             1/1     Running     0          3d3h

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

### 4.Etcd最后說明

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

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

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

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

### 5.參考鏈接

[阿里云上kubernetes的備份和恢復](https://yq.aliyun.com/articles/336781)

[kubeadm安裝etcd備份恢復](https://blog.51cto.com/ygqygq2/2176492)

[Kubernetes Master節點災備恢復操作指南](https://www.cnblogs.com/aguncn/p/9983603.html)

[etcd解析](https://jimmysong.io/kubernetes-handbook/concepts/etcd.html)