好險！我差點重做整個K8S集群
沒有遇到故障的運維不是合格的運維，沒有處理故障的運維不是好運維。
做運維這么多年，每天依然提心吊膽，擔心突發故障，打破生活節奏。
可是，人算不如天算，大部分故障都來源于近乎合理的操作，這次也是一樣。
起因是要把幾百G的數據傳輸到阿里云的Nas，通過外網掛載的方式拷貝。按道理講這沒什么問題，不就幾百G的數據么，之前拷貝幾個T的數據都沒問題。
可偏偏不按道理講。
這幾百G的數據全是由大量的小文件組成，在拷貝的時候既要頻繁的占用本地磁盤IO，也要占用網絡IO，然后事情就發生了——服務器的負載直接干爆（原本8核的CPU，負載高達500多），而且服務器是老年機，配置很Low。這就導致該服務器直接處于死亡狀態，更可氣的是該服務器是K8S集群的master，Master宕機，其他節點失聯，集群處于崩潰中。
負載下不來，服務器無法操作。只有出絕招了——重啟服務器。
在提心吊膽中服務器終于是起來了。但是，新問題來了，Docker起不來，提示/var/lib/docker/overlays Input/Output error。
這特么不是盡給我惹事么，所幸的是只是這個目錄下的部分文件異常，整個文件系統并沒有損壞。
既然你起不來，那我就換一個目錄吧，我就在/etc/docker/daemon.json中重新更改了目錄：
Docker起來了，看似向好的方向發展了，可是Docker壓根用不了。
陷入了沉默，內心焦躁不安，如果不及時解決會影響整體的項目進度......
開始做最壞的打算——重做。隨機開始把未備份的數據進行備份 ，然后另一方面問谷歌大佬，看有沒有類似的問題，最后什么也沒找到。
沉入谷底，如果重做，我一晚上都不一定能做好，但是不重做，所有的工作都可能停滯。
為了靜下心，買了一盒泡面.....
其實問題的目標很明確了，修復好docker，一切都迎刃而解。
又重頭去梳理Docker的配置。發現Docker的啟動文件中有引入其他配置。
然后發現在docker-options.conf中有配置Docker的data-root，我就把其改了，把原來/etc/docker/daemon.json刪了。
神奇的事情發生，Docker能夠正常啟動，也沒有再報任何錯誤。
現在就開始啟動Etcd，為了保險起見，將原有的數據進行了備份，然后重新恢復故障前最近的Etcd備份文件。
Etcd順利起來了，然后apiserver、controller-manager等都起來了，整個集群開始正常運轉。
問題發生的出乎意料，問題解決的也出乎意料。
所以，平時在工作中：
1、做好備份
2、謹慎操作
3、冷靜分析
問題發生，總要找解決辦法，做好最壞的打算。在解決問題的過程中一定要冷靜，我有一陣子很急躁，導致沒有仔細去看配置，所以延緩了恢復時間。
