Gcp Preemptible Instance Kubernetes
先占虛擬機與 Kubernetes
在 GCP 使用先占虛擬機，會需要面對先占虛擬機的額外限制
- 資料中心會 (可預期或不可預期地) 終止先占虛擬機
- 先占虛擬機不能自動重啟，而是會被資料中心終止後回收
- GCP 不保證有足夠的先占虛擬機
節點的終止會造成額外的維運成本，例如
- 管理多個節點，容忍先占虛擬機的移除，自動補充新的先占虛擬機
- 管理多個應用複本，節點終止時，維護整體應用的可用性
- 將移除節點上的應用，重新排程到其他可用節點
- 動態維護應用複本的服務發現 (Service Discovery) 與服務端點 (Endpoints)
- 意思是應用關閉重啟後，換了一個新 IP，還要能持續存取應用。舊的 IP 要主動失效
- 配合應用的健康檢查 (Health Check) 與可用檢查 (Readiness Check)，再分配網路流量
這些需求，必須要有自動化的管理工具，是不可能人工管理的，想像你手上使用 100 個先占節點，平均每天會有 10% - 15% 的先占節點被資料中心回收，維運需要
- 補足被移除的 15 個節點
- 計算被移除的應用，補足移除的應用數量
- 移除失效的應用端點，補上新的應用端點
- 持續監控應用狀態
- …
沒有自動化管理工具，看了心已累 (貓爪掩面)
我們使用 Kubernetes 協助維運自動化，在 GCP 上我們使用 GKE，除了上述提到的容器應用管理自動化外，GKE 還額外整合先占虛擬機的使用
- 啟用先占虛擬機的節點池 (node-pool)，設定節點池的自動拓展，自動補足先占節點的數量
- GKE 自動維護先占虛擬機的 labels
關於 GKE 的先占虛擬機的完整細節，請見GCP 官方文件。這份文件底下也提供了 GCP 官方建議的先占虛擬機最佳實踐
- 架構設計需要假設，部分或是全部的先占虛擬機都不可用的情形
- Pod 不一定有時間能優雅終止 (graceful shutdown)
- 同時使用隨選虛擬機與先占虛擬機，以維持先占虛擬機不可用時，服務依然可用
- 注意節點替換時的 IP 變更
- 避免使用有狀態的 Pod 在先占虛擬機上 (這點稍後的文章，我們會試圖超越)
- 使用 node taint 來協助排程到先占虛擬機，與非先占虛擬機
總之，由於有容器自動化管理，我們才能輕易的使用先占虛擬機。
GKE
然而，決定使用 GKE 後，就有許多關於成本的事情需要討論
- 每個 GKE 集群管理費用 $0.1/hr = $72/hr
這個費用是固定收費，只要開一個集群，不論集群的節點數量。所以在節點多、算力大的集群裡，這個費用會被稀釋，但在節點少的集群裡比例會被放大。
然後 GKE 還是會有一些自己的毛，俗話說有一好沒兩好，我們使用它的好處同時，也要注意許多眉眉角角。再來爬文件。如同最前面宣導，用產品就要乖乖把文件看完，不過這裡先針對與先占虛擬機相關的議題
Allocatable Resource
在網路上看到這篇好文 GKE 上的可使用的資源 Allocatable Resource。啥意思呢？難道還有不能使用的資源嗎？
沒錯，GKE 會保留一定的機器資源 (e.g. cpu, memory, disk)，來維持節點的管理元件，例如 container runtime (e.g. Docker)、kubelet、cAdvisor。
也就是說，就算我們跟 GCP 購買了算力，有一個比例的資源我們是使用不到的。細節請見 理解 GKE 集群架構。這會影響我們單一節點的規格，我們也需要一並計算，能實際使用的資源 (allocatable resource)。
Allocatable = Capacity - Reserved - Eviction Threshold
- Capacity，是機器上實際裝載的資源，例如 n1-standard-4 提供 4 cpu 15 Gb memory
- Reserved，公有雲代管集群，預保留的資源
- Eviction Threshold：Kubernetes 設定的 kubelet 驅逐門檻
驅逐門檻 (Eviction threshold)
Kubelet 會主動監測節點上的資源使用狀況，當節點發生資源不足的狀況時，kubelet 會主動終止某些 Pod 的運行，並回收節點的資源，來避免整個節點資源不足導致的系統不穩定。被終止的 Pod 可以再次排程到其他資源足夠的節點上。細節請見 官方文件 Scheduling and Eviction
在 Kubernetes 上，我們可以進一步設定驅逐門檻，當節點的可用資源低於驅逐的門檻，kubelet 會觸發 Pod 驅逐機制
GKE 上每個節點會額外保留 100 MiB 的記憶體，作為驅逐門檻，意思是當節點耗盡資源，導致剩餘記憶體低於 100 MiB 的時候，會直接觸發 GKE 的 Pod Eviction，終止並回收部分的 Pod。換句話說，這 100 MiB 是不能被使用的資源。細節請見官方文件
集群保留資源精算
資源的定義，使用雲平台的一般費用大多來自此
- cpu
- memory
- storage
然後是這個表，注意保留的資源是累進級距
255 MiB of memory for machines with less than 1 GB of memory 25% of the first 4GB of memory 20% of the next 4GB of memory (up to 8GB) 10% of the next 8GB of memory (up to 16GB) 6% of the next 112GB of memory (up to 128GB) 2% of any memory above 128GB
值計上能夠用到的資源，底下 GCP 也整理好了，例如 n1-standard-4 實際使用的是 memory 12.3/15，cpu 3.92/4。
在維持合理的使用率下，開啟大的機器，可以降低被保留的資源比例，依照筆者公司過去經驗，GKE 起跳就是 n1-standard-4 或是以上規格，如果低於這個規格，可調度的資源比例真的太低，應該重新考慮一下這個解決方案是否合乎成本。
但究竟什麼規格的機器適合我們的需求，說實在完全要看執行的應用而定。
