本篇是一個 GKE 上面的使用經驗談，主要問題發生調整 StatefulSet 數量時(3->5)，發現新增出來的 Pod 都沒有辦法順利的被排程到節點上。
作者團隊遇到的錯誤訊息是

FailedScheduling 4m42s (x3 over 4m44s) default-scheduler 0/9 nodes are available: 3 pod has unbound immediate PersistentVolumeClaims, 6 node(s) didn’t match node selector.

根據上述訊息，可以觀察到兩個點
1) 3個 Pod 因為 PVC 的問題過不去
2) 6個節點沒有符合 node selector 的敘述

這個錯誤訊息讓團隊覺得很莫名，畢竟本來的 StatefulSet 運行的很好，只是改個 replica 的數量就出問題了。

經過調查與研究後發現， GKE 創造的 PV(PersistentVOlume)全部都綁定於 europe-west4-b 上，然而所有的 Pod 全部都綁定於 europe-west4-a 上。
Zone 的使用上沒有一致導致這個問題發生。
作者本來是期許 GKE 要可以更聰明的去處理這個問題，所有自動創立的 PV 應該要針對 Node Selector 有符合的 Zone 去設定，這樣才可以確保運行的 Pod 有對應的 PV 可以使用。

最後作者閱讀了相關文件，得到兩個結論
1. 根據官方文件，Regional persistent disk 只會針對同 regional 內的兩個 zone 去複製與同步 Disk，因此對於一個有 3個 zone 的 Region，是有機會存取到一個沒有該 Disk 的 Zone。
2. 根據 GKE 的文件，使用者最好維護自己的 StorageClass 物件，透過該物件去來 select 多個 zone，同時團隊也比較有能力針對多zone的情況去控管

https://faun.pub/a-story-about-gke-zonal-nodes-and-stateful-set-scaling-1e15acfe5523

今天這篇文章是個基礎介紹文，跟大家介紹一下 Kubernetes 裡面的 Job，不同於 Pod 這種屬於 daemon 的運算資源， Kubernetes 提供了 Job 以及 CronJob 這種一次性的運算資源。

Job 以及 CronJob 差異就是什麼時候該執行，Job 就如同其他資源一樣，創建到 Kubernetes 內後就會開始執行，而 CronJob 則是可以制定一個時間點，去定期反覆的執行

雖說 Job 是一次性的工作流程，但是對於 Kubernetes 來說，最小的工作資源就是 Pod，所有更高階的抽象資源都是基於 Pod 配上不同的 Controller 來完成。
Job 的設計也是如此，最終運行勢必是叫起一個 Pod 來幫忙運行，但是 Job 則會期望該 Pod 最後可以進入 Completed 的狀態。

什麼情況下我們可能會使用 Job 而非其他資源如 deployment/daemonset/statefulset ?
譬如說一個 AI 的模型訓練，一次物件的偵測 甚至是一些系統資源的檢查與清除，這類型的工作都可以考慮用 Job。而那些 Server 類型需要長時間存活的服務則應該使用其他高階類型的資源來部署。

原文算是非常清楚的介紹 Job 的使用，包含了諸如 backofflimit, parallelism, activedeadlineseconds 等參數的含義，並且也有透過實際的範例來展示怎麼使用。

如果對於 Job 這種物件不熟系的，可以參考一下原文來學習一下怎麼使用
https://levelup.gitconnected.com/understanding-jobs-in-kubernetes-541614ccd796

Kuberentes 支援的運算資源種類繁多，諸如 Pod, Job, ReplicaSet, DaemonSet, Deployment 以及 StatefulSet.
其中 StatefulSet 則是特別針對 stateful 應用程式所設計的，實際使用上會有些許小地方與 Deployment 用法不同，譬如
1. Storage 使用的是 Template 的概念，希望每個 StatefulSet Pod 可以綁定固定的 PV
2. 名稱採取流水號設計，相對於 Deployment -> ReplicaSet -> Pod 兩層亂數來說， StatefulSet 的名稱更加顯眼
3. StatefulSet 的 Pod 有網路存取唯一性，搭配 Headless Service，就可以使用固定一組的 DNS 名稱來存取固定 Pod(預設情況下，Pod 重啟 IP 就會不同，要做到固定一致需要不少修改)

今天這篇文章算是一個入門教學文，主要是跟大家探討什麼是 StatefulSet，以及於 Kubernetes 內該如何使用，使用上有什麼要注意的，以下幫大家節錄部分資訊

1. StatefulSet 的設計是安全優先，所以預設情況下刪除 StatefulSet 不會連帶刪除使用的 Volume
2. 使用 StatefulSet 的時候，要記得處理當 Pod 被停止，被刪除時，相關資料的寫入與同步
3. 預設情況下, StatefulSet 的創建與移除都是一個一個來，創建時由 0-N-1, 移除則反過來。
4. 對於多節點的 StatefulSet 來說，這些應用程式可能都會需要一些初始化的操作，甚至 leader-election 等相關算法。這意味者 Container(s) Running 不等於 Pod 以及準備好了。
5. 針對上述概念，使用者一定要仔細的去設定 liveness 以及 readiness，來確保
6. PostStart/PreStop 的用法與時機也要考慮進去，特別是 PreStop 用得好還可以減少使用端封包無故重送
7. 研究 disruption budgets 的用法，來確保你的 StatefulSet 運行得更安心
8. 針對特定的儲存空間使用權限問題，可以考慮使用 fsGroup 來修改，而不用自己寫一堆 shellScript 來做。當然要注意儲存空間檔案過多內容過大的情況，預設的 fsGroup 行為可以會導致你的 Pod 花太多時間來啟動

原文: https://itnext.io/stateful-applications-in-kubernetes-808a60bc109

想學習更多關於 Kubernetes 的實戰經驗與基礎設計，可參閱我的線上課程: https://technologynoteniu.github.io/awesome-notes/linux/network/