Kubernetes 中最基本的運作單元是 Pod，基於 Pod 之上則有各種不同作用的高階抽象層，譬如 DaemonSet, Job, Deployment 等。
使用 Kubernetes 來部署應用程式時，遲早都要面臨資源使用的問題，到底每個 Pod 要使用多少的 CPU/Memory，同時如果是 Deployment 時到底要設定多少個 replica 來符合應用程式的需求。

Kubernetes 提供了 HPA 的方式來水平擴展 Pod 的數量，透過 HPA 的幫助， Pod 的數量可以根據當前的使用情況而自動改變。前述提到除了數量外， CPU 與 Memory 的設定也是一個煩惱的議題，因此就有一個名為 VPA (Vertical Pod Autoscaler) 的專案來處理這個情況，根據當前 Pod 的運行情況來調整 CPU/Memory 的設定(Request/Limit)。

這個專案並非 Kubernetes 的內建資源，必須要額外安裝相關的 CRD 與 Controller 來使用
今天這篇文章針對 VPA 的專案進行詳細的介紹，包括如何安裝，基本架構介紹， VPA 的概念以及使用上的限制都有詳細介紹。

特別要注意的是 VPA 與 HPA 不能同時針對一個 Pod 使用，否則會出現不可預期的行為。這部分也可以理解，畢竟兩個專案並沒有良好的整合，因此兩個 Controller 都會互相一直調整 Pod 行為時，可能會導致不預期的結果。

對於 VPA 這種調整 CPU/Memory (Request/Limut) 專案有興趣的人不仿參考下列文章
https://medium.com/infrastructure-adventures/vertical-pod-autoscaler-deep-dive-limitations-and-real-world-examples-9195f8422724

關鍵字: GKE, conntrack, HAProxy
影響: 網路重度服務遇見大量錯誤

今天這個案例的重點非常簡單，Kubernetes(GKE) 會根據每個節點上面的記憶體大小去設定相關的 conntrack_max 的數值。因此對於一個小記憶體的節點上運行一個有網路重度的服務，非常容易踩到 conntrack_max 的上限最後導致連線 reset 以及 timeout.

conntrack 是 Linux Kernel 非常重要的網路功能，透過 conntrack (connection tracking) 可以實現非常多的功能，kernel 會去追蹤與監控系統上看到的所有連線，每個連線都包含兩個方向的封包。

根據作者的測試，於 GKE 觀察的結果是大概每 MB 可提升5條 connection的上限。
團隊的應用程式是一個類似於 proxy 的角色，這個應用程式大概每秒要處理一萬個以上的 rquest，而這個現象是當團隊針對整個架構進行一番改正後，開始注意到有網路連線出現問題。

針對這個問題作者提出了幾個解決思路
1. 針對網路連線非常重度的應用程式，將其給配置到比較強力效能的機器人，才可以獲得更高數值的 conntrack_max
2. 透過 init-container/daemonset 等方式，手動執行 sysctl 去修改節點上的 conntrack_max
3. 透過 Prometheus 去監控系統上目前所有節點 conntrack 使用的數量，藉此提醒團隊這個數值也很重要，需要監控
4. 1.15 以後的 kubernetes 有一些小的修復可以幫忙移除一些不合法的 conntrack，勁量讓 conntrack pool 留給有用的連線

https://deploy.live/blog/kubernetes-networking-problems-due-to-the-conntrack/

今天這篇文章是個基礎介紹文，跟大家介紹一下 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