Proactive Node

終於要介紹第一個 Kubernetes Pattern!

實務上，我們經常用 HPA 讓 Critical workload 根據負載自動擴展 Pod，並搭配 Cluster Autoscaler 之類的工具擴展 Node，這一切聽起來很完美，但是如果你的集群本來就很大，因為 api-server 以及 ectd 平時的負載就大了，如果要加入一個 Node 的時間會比較久，還要更新 Node 的網路拓樸，所以 Node 註冊的時間會拉長到需要好幾分鐘，甚至十來分鐘。這時候如果服務負載過大而資源不夠，會造成 Node Resource Pressure，Kubernetes 會開始回收一些 Pod 讓資源給更重要的 Pod，如果服務分級沒有做好，災難就發生了。

為了避免這個問題，我們介紹一個 Kubernetes Pattern: Proactive Node。

Proactive Node

Kubernetes 註冊 Node 需要花時間，可能會跟不上服務負載的變化。

因此，佈署 low priority pod，讓 Cluster Autoscaler 擴展一個 Proactive Node 給 low priority pod 使用，並為關鍵服務打上 high priority，當關鍵服務負載過大，就會發生 Preemption，Preemption 會優先搶佔 low priority pod，因為 low priority pod 佈署在 Proactive Node，因此，Proactive Node 就會讓給關鍵服務使用。

我們接下來的文章會用 Kubernetes scheduler simulator 操作一次這個 Pattern 。

What is Priority and Preemption?

假設我們有兩個服務，一個是跟 Critical User Journey 有關的關鍵服務，另一個就是產報表的報表服務。關鍵服務有簽 SLA，報表服務就是公司內部使用而已，而他們都佈署在同一個 Kubernetes 當中。

很明顯，我們可以比較這兩個服務對業務的重要性，關鍵服務比報表服務還要重要，所以我們希望這個重要性可以呈現在 Pod 上。

因此，我們有了 Priority 來表示這個服務的重要性。

Priority 是位於會在 Scheduling Cycle 中的 Filter 發現沒有任何 Feasible Node 的時候，會進入 PostFilter 並發動 Preemption 這個行為，Preemption 會一一輪詢所有 Node，計算有沒有 Low Priority Pod，如果有 Low Priority Pod，會被 Scheduler 標記成犧牲者候選，如果釋出犧牲者資源後，High Priority Pod 可以佈署，Preemption 就會 evict 犧牲者。

所以 Priority and Preemption 是主要作用於排程的設定，我們稍微提到兩個很常跟 Priority 有關的設定。

QoS

QoS 會根據 pod.spec 的資源對 Pod 做分類，值得注意的是：QoS 會影響 kubelet eviction 的行為，但是 Priority 優先於 QoS。

PodDisruptionBudget
Preemption 會尊重 PDB，會盡量在不違反 PDB，如果有兩個 Pod，一個有 PDB 保護，另一個沒有 PDB 保護，Preemption 會優先選擇犧牲沒有 PDB 保護的 Pod。

但是如果需要犧牲 PDB 保護的 Pod 才可以佈署，Preemption 依然會犧牲 PDB 保護的 Pod，所以只是尊重 PDB 策略。

關於 PodDisruptionBudget 以及 QoS，我打算寫一篇講 **Eviction **，到時候再深入介紹，尤其是 QoS 要講到 CFS，不過，我來得及說 CFS 嗎?