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/
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解析