系列目錄html
案例現場:node
測試環境集羣原本正常,忽然間歇性地出現服務不能正常訪問,過一下子刷新頁面又能夠正常訪問了.進入到服務所在的pod查看輸出日誌並無發現異常.使用kubectl get node
命令正好發現一個節點是NotReady
狀態git
爲了方便觀察,使用kubectl get node --watch
來觀測一段時間,發現k8s-node1
節點不斷的在Ready和NotReady狀態之間切換(使用kubectl get node -o wide能夠查看節點的ip信息).github
進入到出現問題的節點,使用命令journalctl -f -u kubelet
來查看kubelet的日誌信息,把錯誤日誌截出來一段搜索一下,發現問題和這個問題基本上是同樣的,發現這個問題的時間和github上issue提出的時間是在同一天,也沒有看到解決辦法.可是基本能肯定是由於集羣中k8s-node1上的kubernetes版本不一致形成的(從上面截圖上能夠看到,這個節點的版本是1.14.1其它的都是1.13.1,是怎麼升上來的不清楚,多是其它同事誤操做升級致使的)docker
搜索kubernetes NotReady
查看了一些解決經驗,不少都是重啓docker,重啓kubectl等,而後都解決不了問題.因而嘗試重置這個節點.bash
因爲這個節點上運行着服務,直接刪除掉節點會致使服務不可用.咱們首先使用kubectl drain
命令來驅逐這個節點上的全部podide
kubectl drain k8s-node1 --delete-local-data --force --ignore-daemonsets
以上命令中
--ignore-daemonsets
每每須要指定的,這是由於deamonset會忽略unschedulable
標籤(使用kubectl drain時會自動給節點打上不可調度標籤),所以deamonset控制器控制的pod被刪除後可能立刻又在此節點上啓動起來,這樣就會成爲死循環.所以這裏忽略daemonset.測試
實際在使用kubectl drain時候,命令行一直被阻塞,等了好久還在被阻塞.使用kubectl get pod命令查看pod狀態時.其中一個叫做
busybox
的pod一直處於Terminating
狀態. 使用kubectl delete pod busybox一樣沒法刪除它.這時候可使用命令kubectl delete pods busybox --grace-period=0 --force
來強制立刻刪除pod.命令行
這時候控制檯阻塞狀態結束.下面執行命令kubectl delete node k8s-node1
來刪除這個節點.而後咱們從新安裝kubelet,kubeadm和kubectl
日誌
若是是經過yum方式安裝的,能夠經過yum list installed|grep xxx
形式來找到已安裝的組件,而後刪除它們.刪除之後從新安裝.
這裏之因此要從新安裝是由於版本升級成了較爲新的版本,若是版本是同樣的,其它的不肯定因素致使節點不穩定,又找不到具體緣由,則能夠經過
kubeadm reset
來重置安裝.
重置命令並不會重置設置的iptables規則和IPVS若是想要重置iptables,則須要執行如下命令:
iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
若是想要重置IPVS,則須要執行如下命令:
ipvsadm -C
這裏我可以基本肯定是因爲版本不一致致使的,所以我並不重置iptables和IPVS,僅僅是重裝組件.
重置完成之後,咱們把刪除掉的k8s-node1節點使用kubeadm join
從新加入到集羣中
若是忘記了主節點初始化時候生成的加入token,能夠在主節點上執行
kubeadm token create --print-join-command
從新生成加入token,而後把生成的命令複製到要加入集羣的節點上執行.
從新加入集羣后,觀察了一段時間,一直是Ready狀態,感受終於穩定了,可是同事又反饋部署服務時出現如下錯誤
Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "5159f7918d520aee74c5a08c8707f34b61bcf1c340bfc444125331034e1f57f6" network for pod "test-58f4789cb7-7nlk8": NetworkPlugin cni failed to set up pod "test-58f4789cb7-7nlk8_default" network: failed to set bridge addr: "cni0" already has an IP address different from 10.244.4.1/24
幸虧有偉大的互聯網,經過搜索,找到如下解決方案
因爲此次啓動之後初次部署pod就失敗了,所以此節點上尚未運行的服務,咱們不須要執行kubectl drain
,能夠直接把這個節點刪除.而後執行如下命令
kubeadm reset systemctl stop kubelet systemctl stop docker rm -rf /var/lib/cni/ rm -rf /var/lib/kubelet/* rm -rf /etc/cni/ ifconfig cni0 down ifconfig flannel.1 down ifconfig docker0 down ip link delete cni0 ip link delete flannel.1 systemctl start docker
完了之後從新加入集羣.此次能夠正常工做了.