本文同步刊登於個人技術部落格，有興趣關注更多 Kubernetes、DevOps 相關資源的讀者，請務必追蹤從零開始的軟體工程師之旅，喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論，技術方面諮詢免錢、需要動手做另計 XD。

Preemption selection

除了 24 小時的壽命限制會終止虛擬機，資料中心的事件也會觸發主動的虛擬機回收，由 GCP 主動觸發的回收機制機率很低，會根據每>日每個區域 (zone) 的狀態而定。這裡描述資料中心啟動的臨時回收。

GCP 不會把所你手上的 preemptible 機器都收走，而是依照一定的規則，選擇一個比例撤換的機器。

先看文件敘述

• Compute Engine 會避免從單一客戶移除太多先占虛擬機
• 優先移除新的虛擬機，偏向保留舊的虛擬機 (但最多仍活不過 24hr)
• 開啟後馬上被移除的先占虛擬機不計費
• 機器尺寸較小的機器，可用性較高。例如：16 cpu 的先占虛擬機，比 128 cpu 的先占虛擬機容易取得

GCP 每天平均會移除一個專案中 5% - 15% 的虛擬機，從用戶的角度我們需要預期至少這個程度的回收。不過這個比例，GCP 也不給予任何保證。以筆者經驗，只能說絕大部分的時候，都不會擔心超過這個比例的回收，但是還是要做
好最壞的打算，如果臨時無法取得足夠的先占虛擬機，要有方法暫時補足隨選虛擬機。

GKE

使用先占虛擬機會違反 Kubernetes 的設計

• Pod grace period 會被忽略
• Pod disreuption budget，不會被遵守 (可能會超過)

對應用的影響

GCP 觸發的 Preemptible process，對應用的影響

• involuntary disruptions，GCP 送 ACPI G2 Soft Off
• OS 終止服務，包含執行 Kubernetes 的 container runtime
• 容器內的應用會收到 SIGTERM，啟動 graceful shutdown
  • Kubernetes 提供的 Graceful-shutdown 可能會跑不完
  • 實務上只是中斷當前工作

https://cloud.google.com/solutions/scope-and-size-kubernetes-engine-clusters

大量節點同時回收

由於 GCP 並不保證收回的機器的數量，同時回收的機器量大，還是會衝擊到服務。例如：一次收回 15% 的算力，當然服務還是會受到衝擊。當然這樣事件的機率並不高，但我們仍是需要為此打算。這邊有幾個做法

• 預留更多的算力
• 使用 regional cluster，在多個 zone 上分配先占虛擬機
• 我們自行控制，提前主動回收虛擬機

預留更多資源

這點很直觀，由於使用了更加便宜的機器，我們可以用同樣的成本，開更多的機器。

退一步說，使用打三折的先占虛擬機，然後開原本兩倍的機器數量

• 總成本是 0.3 * 2 = 0.6 倍
• 同時間可用資源是 2 倍

由於先占節點回收的單位是一個一個虛擬機

• 安排合適的機器尺寸
• 尺寸較小的先占虛擬機，可用性較高。意思是零碎的先占虛擬機容易取得

但當然也不能都開太小的機器，這會嚴重影響應用的分配。至於具體需要開多大，可以根據預計在機器上運行的應用，做綜合考量，例如有以下影用需要執行：

• app A: 1 cpu 5 replica
• app B: 3 cpu 5 replica
• app C: 5 cpu 5 replica

總共至少 45 cpu ，預期機器負載8 成的話，需要總共 45 / 0.8 = 56 cpu。也許可以考慮

• 8 cpu * 7 先占虛擬機
• 4 cpu * 14

也舉幾個極端不可行的例子

• 56 cpu * 1
  • 這樣的虛擬機回收時的影響範圍 (blast radius) 就是 100% 服務
• 1 cpu * 56
  • 機器太瑣碎，可能超出 Qouta (節點數量，IP 數量...)
  • 應用會更分散，節點間的內部網路流量會增加
  • 前幾篇提到的 reserved resource 比例高，會影響應用的部署

如果希望更保險，可以再補上隨選虛擬機混合搭配，例如

• 8 cpu * 7
  • 5 先占虛擬機 2 隨選虛擬機
• 4 cpu * 14
  • 10 先占虛擬機 4 隨選虛擬機

虛擬機區域

虛擬機的回收觸發，也是會依據服務的區域 (zone) 回收。意思是節點回收不會同時觸發 asia-east1 中所有 zone 的節點回收，一般來說時間是錯開的 (不過GCP 也不保證這點 XD)。為了維持 GKE 的可用性，我們都會開多個 node-pool 在多個區域下。

總之避免把機器都放在同個區域中。

自行控制的虛擬機汰換

簡單來說我們在 24 hr 期限之前，先分批自盡 XD，打散個各個虛擬機的 24 小時限制。

使用這個有趣的工具 estafette-gke-preemptible-killer，自動汰換先占虛擬機，讓整個繼起虛擬機都分散在 24 小時間。

estafette-gke-preemptible-killer ，使用上簡單，大家自己看著辦 XD。如果大家有興趣，留言的人多的話，我再另外開一篇細講。

小結

為了使用先占虛擬機，我們要多做以下幾件事

• 為應用設計可容錯分散式架構，例如應用可以同時執行一樣的 API server 3 個 replica
• 分散 Pod 到合適的機器上，例如設置 PodAntiAffinity
• 設定合適的虛擬機大小，合適的分散應用
• 使用 estafette-gke-preemptible-killer，自動汰換先占虛擬機
• 不依賴應用的 Graceful-shutdown 流程

有寫過鐵人賽的都知道 30 篇真的很漫長，一篇文章幾千字，都要花好幾個小時。我去年後半，真的都會看讀者的留言跟按讚，取暖一波，才有動力繼續寫。留言的人多就會多寫，留言的人少就會少寫，各位覺得文章還看得下去，請務必來我粉專按讚留個言，不管是推推、鞭鞭、或是有想看的文章來許願，都十分歡迎。有你們的支持，我才有動力繼續寫。

請大家務必以實際行動支持好文章，不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD

當然，沒人留言我就會當作自己才是垃圾文 (自知之明XD)，就會收一收回家嚕貓睡覺，掰掰~

我的粉專，等你來留言