首先說備份etcd快照數據很重要，因為如果機器斷電導致etcd突然中斷，它自身是無法恢復的。
之前出現了兩次這種情況，每次都是重置kubernetes，但現在部署的應用越來越多就比較麻煩了，所以不得不搞定通過快照備份來快速恢復。
https://blog.csdn.net/u013958257/article/details/106978416
首先參考的是這篇文章，所說明的問題是一樣的。
按照其所指備份方法成功備份后，恢復遇到了問題。
他是通過在kubernetes之外單獨安裝etcd，通過etcdctl恢復成功，我想的是通過etcd容器進行恢復，這樣就不用單獨安裝etcd了。
進入到etcd容器執行他說明的恢復命令時，提示/var/lib/etcd目錄已經存在。
那好再按照他的說明先將這個目錄重命名下，當執行重命名時mv命令時出現了錯誤，說是“Device or resource busy”.
現在就麻煩了，麻煩在哪呢？
由於我所有的操作都是在容器中執行的，而/var/lib/etcd是加載的外部主機的，所以不能刪除，而它的存在又會導致恢復操作不會成功，因為恢復需要一個空的目錄。
PS: 其實現在想來出現這個問題，是因為執行恢復命令時通過—data-dir選項指定了恢復目錄，如果不指定的話會存放到默認目錄/default.etcd/下，在恢復完成后可以將恢復結果復制到/var/lib/etcd下。之所以參考文章沒有問題，是因為他是在主機上操作，可以對/var/lib/etcd做任何操作。
在這種進退兩難的情況下，有找了另一篇關於etcd恢復的文章。
https://elastisys.com/backup-kubernetes-how-and-why/
它的思路和我一樣，也是通過容器恢復，而不是單據安裝etcd。
通過etcd鏡像重新創建一個容器，而是復用現有容器，並且將/var/lib/etcd也加載到容器內，但執行恢復操作時並沒有指定要恢復到的目錄，這樣恢復的數據就到了默認目錄/default.etcd/下，恢復完成后再通過mv命令把其下member目錄移動到/var/lib/etcd。
這樣主機的/var/lib/etcd目錄下也有了已經恢復完成的數據。
最后刪除kubernetes的etcd容器，它自動重建后果然數據都回來了。
但通過kubectl查看pod時發現有些是終止狀態，查看其日志發現都是相同的錯誤：“Authorization error (user=kube-apiserver-kubelet-client, verb=create, resource=nodes, subresource=proxy)”，開始以為是恢復數據導致連接apiserver的客戶端證書丟失，但通過查看/etc/kubernetes/pki目錄，發現證書都是存在的。
對比發現處於終止狀態的pod都在非主節點上，再查看節點狀態，發現除了主節點其它都是unreachable狀態，嘗試重啟其中一個非主節點后問題不再，就將剩余節點全部重啟，至此所有應用全部恢復正常 。
這里記錄的是解決問題的步驟，但通過兩邊參考文章的內容可以得出etcdctl恢復快照數據的操作純粹是一個本地操作，無需像第一篇文章一樣需要通過選項指定證書、地址及恢復目錄。指定了恢復目錄反而導致無法在現有容器中完成恢復。
PS: 不能在etcd容器中直接將/var/lib/etcd/下的member目錄刪除，因為etcd是基於其運行的，如果直接刪除會導致etcd進程中斷，從而導致kubernetes的etcd容器終止並重啟。