敝公司前陣子有發現有機器的資源使用率特別的低在 GKE 上，再怎麼說這些用不到的資源也是白花花的銀子啊，所以我們就新增資源更低更便宜的 Node Pool ，再搭配使用 Cordon + Drain 或者手動刪除 Pod ，讓 Pod 重新長在新的 Node Pool 上，當然在 GKE 上直接刪除舊的 Node Pool 也可以達到一樣的效果，只是我們選用了更安全的做法。
上述的做法，其實就是將 Node 標記為不可調度，然後再讓 Pod 生長在預期的主機上，今天就來説說當機器遇到故障或者需要升級的時候，我們該怎麼安全的處理。
情境
如果 Worker Node 要做系統升級或者發現即將故障了，我們該怎麼安全的處置。
作法
1. 讓該節點停止調度
我們使用 cordon 先將目標節點打上不可調度，此時只會將 Node 狀態變成 SchedulingDisabled ，之後再創建的 Pod ，都不會再調度到該節點上，舊有的 Pod 不會受到影響，依然可以繼續提供服務。
kubectl cordon <node-name>
2. 驅逐在這節點的 Pod
接下來我們要將 Pod 從 Node 上驅逐，這邊有兩個做法。
第一種作法是直接將節點上的所有 Pod 驅逐，但是如果你的一個 Deployment 內的 Pod 都活在此節點上的話，你的服務是有機會中斷的。
kubectl drain <node-name> --force --ignore-daemonsets
第二種作法是手動的一個一個將 Pod 在節點上刪除，此做法較為安全。
kubectl delete pod <pod-name>
3. 恢復該節點的調度或者刪除節點
當你升級完畢你的節點後，你就可以將節點標記為可調度狀態。
kubectl uncordon <node-name>
當你的節點確定硬體異常的話，就直接刪除節點吧。
kubectl delete node <node-name>
注意事項
- 要驅逐的 Pod 的 replica 必須大於 1 ， 不然你的服務會有中斷發生。
- 要檢查一下 Pod 是否有特殊的策略，不然被驅逐後就有機會不會被調度成功。
- 建議配置 PodAntiffinity 策略，確保同一個 Deployment 內的 Pods 與被驅逐的 Pod 可以盡量調度到不同的節點上。
總結
在 production 上，如果沒有十足的信心，建議在將 Pod 轉移到新的 Node 的處理過程中，一個一個手動刪除 Pod 吧。
歡迎到我的 Facebook Alan 的筆記本 留言，順手給我個讚吧！你的讚將成為我持續更新的動力，感謝你的閱讀，讓我們一起學習成為更好的自己。