閱讀筆記: 「kubectl delete 的行為跟 docker delete 完全不同」

標題: 「kubectl delete 的行為跟 docker delete 完全不同」
類別: kubernetes
連結: https://www.acritelli.com/blog/kubectl-delete-sigkill/

熟悉 Linux 系統的人想必都了解 Signal 的概念，特別是幾個常見的如 SIGTERM, SIGKILL 等，

作者的團隊嘗試透過 SIGKILL 的行為來驗證與測試團隊內部署的 Kuberentes Pod，特別是當遇到 ungraceful shutdown 的情境時這些 Pod 會如何運作。
團隊嘗試透過 kubectl delete 的方式來刪除這些 Pod，但是實驗過程中發現 –grace-period 這個參數的運作行為與團隊的預期行為不同。
kubectl delete 得說明文件中特別指出

      --grace-period=-1: Period of time in seconds given to the resource to terminate gracefully.
Ignored if negative. Set to 1 for immediate shutdown. Can only be set to 0 when --force is true
(force deletion).

作者看文這段文字說明後滿腦問號，提出兩個問題

1. grace-period 設定為 1 的 immediate shutdown 是直接送出 SIGKILL 嗎？ 還是說會有一秒的間隔時間才發送 SIGKILL?
2. grace-period 設定為 0 是代表沒有間隔，所以也是馬上送出 SIGKILL 嗎? 還是說其只是單純將資源從 k8s API 中移除而沒有等待而已？

作者認為文件沒有辦法解決這些問題，所以設計了一些實驗來測試

–grace-period=1 的實驗結果是

1. 送出 SIGTERM
2. 送出 SIGKILL

作者對於這個行為感到不解，認為 “immediate shutdown” 應該就是要馬上關閉呀，怎麼可以送 SIGTERM 給 Pod 讓 Pod 有機會可以優雅的結束一切？
因為對於這行為的認知不同導致作者團隊的測試行為沒有辦法順利完成。

接下來測試 –grace-period=0 & –force=true

文件中說明這樣設定會立刻將該資源從 API Server 內給刪除並且避開 graceful 的階段。
最後測試的結果是

1. 發送 SIGTERM
2. 等待 30 秒
3. 發送 SIGKILL

作者表示又糊塗了，沒想到設定 grace-period=0 竟然中間還有 30 秒的時間，這完全與預料的不同，更麻煩的是文件也沒有講得非常清楚到底什麼是正確的行為，
此外還提到 Docker 就支援真正的 immediate shutdown，直接送 SIGKILL。

另外作者發現 K8s GitHub 中的也有人提出類似的 issue，對於這些 graceful 的行為感到不解同時文件說明不夠精準。

這件事情很難說誰正確誰不正確，畢竟不同的系統架構下的設計方式與條件都不同，不過的確 K8s 的指令文件有時候是真的不是精準，需要仔細測試才可以理解到底運作行為為何

我目前於 Hiskio 平台上面有開設 Kubernetes 相關課程，歡迎有興趣的人參考並分享，裡面有我從底層到實戰中對於 Kubernetes 的各種想法

詳細可以參閱
線上課程詳細資訊: https://course.hwchiu.com/

另外，歡迎按讚加入我個人的粉絲專頁，裡面會定期分享各式各樣的文章，有的是翻譯文章，也有部分是原創文章，主要會聚焦於 CNCF 領域
https://www.facebook.com/technologynoteniu

如果有使用 Telegram 的也可以訂閱下列頻道來，裡面我會定期推播通知各類文章
https://t.me/technologynote

你的捐款將給予我文章成長的動力