中午睡覺, 夢到一羣母蜘蛛圍攻我, 我卻不能動, 苦苦掙扎在音樂聲中驚醒
醒來後, 繼續工作, 突然發現服務器磁盤佔用100%, 操作巨卡, 一臉問號
是不是之前部署的istio的鏡像無法下載, 導致的, 我忘記了刪除部署
然後將istio全部刪除, 集羣還是卡, 節點丟失
最後重啓了各個節點的kubelet, 集羣正常了
但是呢, 很多掛載pv的POD一直create狀態, 然後describe一下, 發現pvc無法掛載
這種情況一般是pvc被其他哥們強佔, 所以按照經驗是這種路子, 然後分析了, 發現沒有活着的哥們強佔他
想起之前的情況:
不知什麼原因, 和ROOK掛載後出現POD迷失的情況, 也就是無法刪除並且留在了node上, 重啓kubelet, 查看allkube可以看到沒了
但是呢, 目標node一直報錯
Jul 5 00:17:28 localhost kubelet: E0705 00:17:28.138366 938 kubelet_volumes.go:128] Orphaned pod "94d9dcc1-7ee6-11e8-95bf-000c29ab3f28" found, but volume paths are still present on disk : There were a total of 1 errors similar to this. Turn up verbosity to see them.
解決方式: cd /var/lib/kubelet/pods 刪除報錯對應的文件夾, 刪除不了只能先重啓機器
那麼是什麼原因造成POD迷失的呢, 是由於kubelet不正常被kill了
POD迷失後, k8s會自動部署該POD新的實例, 而迷失的POD還持有原PVC的掛載, 因此如果PVC的策略是RWO, 那麼新的實例無法掛載
這個時候得尋找這個迷失POD的節點
需要查看kubelet的日誌, 找到出現上述錯誤的節點kubelet, 按照上述操作乾死
乾死後新的實例也是無法起來的, 使用k8s將新實例乾死, 這時候又是坑中坑, 一直是Terminating狀態, 無法乾死
這個時候, 查看這個新實例的node, 到node上重啓kublet即可乾死它, 最好確認下該node的kubelet日誌
重新部署該POD, 還是起不來, 報錯無法掛載pvc
一看ceph監控嚇一跳
查看osd的日誌
這裏osd保證集羣健康的方式是osd之間互相的heat, 按照這個ip找到了集羣中的osd實例, 發現真的無法ping通
直接ping該ods實例所在node的docker0端口, 發現仍然無法ping通, 排除了osd容器的問題, 是node的網絡問題
最後搞笑的發現是ping其他節點的這臺主機網絡有問題, 最後發現是3臺master的網絡出了問題, 有點麻煩!!!
分析後, 類似網絡覆蓋分裂, master之間可以通, 而node之間也可以通, 但master和node之間無法通行
查看master的ip a
flanneld的overlay有2個網段!!! 蛋疼蛋疼 (這裏後面在細細記錄了~)
首先想到是重啓master的flanneld和docker, 一臺一臺來, 否則導致docker, flanneld, etcd互相依賴起不來, 集羣GG
無效
重啓node的flaneld和docker
無效
重啓node的kubelet
無效
崩潰~~
重啓master的flanneld, docker, kubelet, kube-proxy
無效
萬般無奈, 不如直接重啓master, 幹你媽的
重啓後flanneld的overlay只有1個子網段了
ping之後發現OK了~
隨之按此方法依次重啓另外兩臺master, 最後發現還有幾臺node, 也重啓下解決
最後ceph集羣全部正常
重新嘗試部署新實例
部署成功, 並且成功加載pvc, 數據沒丟, 只是丟了一段剛剛宕機時間的監控數據
一臉驚歎~