iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 15
0
DevOps

Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*系列 第 15

Day 15 - 先占節點 Preemptible Instance 實戰分享,先占虛擬機如何殺死你的 Pod,如何處置上篇

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

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

曬貓


先占虛擬機終止流程 (Preemption process)

子曰:未知生焉知死。但做工程師要反過來,考量最差情形,也就是要知道應用可能如何死去。不知道應用可能怎麼死,別說你知道應用活得好好的,大概想表達這麼意思。

這對先占虛擬機來說特別重要,一般應用面對的機器故障或是機器終止,在使用先占西你幾的狀況下,變成每日的必然,因此,需要對應用的終止情境,與終止流程有更精細的掌控。如同前幾篇所說的,先占虛擬機會被公有雲收回,但收回的時候不會突然機器就 ben 不見,會有一個固定的流程。

如果你的應用已經帶有可容錯的機制,能夠承受機器突然變不見,服務還好好的,仍然要花時間理解這邊的流程,藉此精算每天虛擬機的終止與替換:應用會有什麼反應,會產生多少衝擊,稍後可以量化服務的影響。例如

  • 應用重啟初始化時 cpu memory 突然拉高
  • 承受節點錯誤後的復原流程,需要消耗額外算力。例如需要從上個 checkpoint 接續做,需要去讀取資料造成 IO,或是資料需要做 rebalance ...等等

如果你的應用需要有 graceful shutdown 的機制,那你務必要細心理解這邊的步驟。並仔細安排安全下樁的步驟。又或是無法保證在先占虛擬機回收的作業時限內,完成優雅終止,需要考慮其他可能的實作解法。

這邊有幾個面向要注意

  1. GCP 如何終止先占節點
  2. GCP 移除節點對 GKE 、以及執行中應用的影響
  3. GKE 集群如何應對的節點失效
  4. GCP 自動調度補足新的先占節點
  5. GKE 集群如何應對節點補足

三個重點

  • 先占虛擬機終止對集群的影響
  • Pod 隨之終止對應用的影響,是否能夠優雅終止
  • 有沒有方法可以避免上面兩者的影響

劇透一下:有的,有一些招式可以處理。讓我們繼續看下去。

GCP 如何終止虛擬機

先占虛擬機的硬體終止步驟與一般隨選虛擬機相同,所以我們要先理解虛擬機的停止流程

這裡指的終止 (Stop) 是虛擬機生命週期 的 RUNNING -> instances.stop() -> STOPPING -> TERMINATED 的步驟。

  • instances.stop()
  • ACPI shutdown
  • OS 會進行 shutdown 流程,並嘗試執行各個服務的終止流程,以安全的終止服務。如果虛擬機有設定Shtudown Script 會在這步驟處理
  • 等待至少 90 秒,讓 OS 完成終止的流程
    • 逾時的終止流程,GCP 會直接強制終止,就算 shutdown script 還沒跑完
    • GCP 不保證終止時限的時間,官方建議不要寫重要的依賴腳本在終止時限內
  • 虛擬機變成 TERMINATED 狀態

GCP 如何終止先占虛擬機

與隨選虛擬機不同

  • 先占虛擬機的時間 30 秒
  • 搭配 GKE 使用 Managed Instance Group,終止的虛擬機會被刪除,Autoscaler 會啟動新的虛擬機

一樣先看先占虛擬機的說明文件:終止流程

  • 資料中心開始回收先占虛擬機,選中我們專案其中的一台先占虛擬機
  • Compute Engine 傳送 ACPI G2 Soft Off,這裡 OS 會試圖安全關變服務,也會執行 shutdown script,可以做簡短的優雅終止
  • 30秒後,ACPI G3 Mechanical off

但 30 秒能做什麼?只能快速的交代當前進度。如果應用需要花時間收尾,保存工作進度,可能會產生許多問題

  • GCP 不保證終止時限的時間,官方建議不要寫重要的依賴腳本在終止時限內
  • 在面對大量 IO 的工作,可能會導致者台虛擬機的大量應用一起進入優雅終止,先占虛擬機最後耗盡資源,來不及做完
  • 如果可能會超時,或是沒完成會有資料遺失風險,就不能在這個階段處理

依賴 shutdown script 做收尾是危險的,我們之後要想辦法處理這個不保證做完的優雅終止。

如果應用本身有容錯的框架,或是有容錯機制,我們這邊要額外做的工作就會少很多。例如許多程式框架提供自動重啟的功能,在外部保存 checkpoint,worker 只負責運算,終止信號一進來,也不用保存,直接拋棄未完成的工作進
度,留待繼起的 worker 從 checkpoint 接手。


明天待續,GCP 是如何選擇哪些機器應該要被回收的,以及我們應該如何面對這些限制


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

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

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

我的粉專,等你來留言


上一篇
Day 14 - 先占節點 Preemptible Instance 實戰分享,虛擬機資源評估,機器應該開多大台
下一篇
Day 16 - 先占節點 Preemptible Instance 實戰分享,先占虛擬機如何殺死你的 Pod,如何處置下篇
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30

尚未有邦友留言

立即登入留言