本文同步刊登於個人技術部落格,有興趣關注更多 Kubernetes、DevOps 相關資源的讀者,請務必追蹤從零開始的軟體工程師之旅,喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。
如果有技術問題也可透過粉絲專頁 討論,技術方面諮詢免錢、需要動手做另計 XD。
子曰:未知生焉知死。但做工程師要反過來,考量最差情形,也就是要知道應用可能如何死去。不知道應用可能怎麼死,別說你知道應用活得好好的,大概想表達這麼意思。
這對先占虛擬機來說特別重要,一般應用面對的機器故障或是機器終止,在使用先占西你幾的狀況下,變成每日的必然,因此,需要對應用的終止情境,與終止流程有更精細的掌控。如同前幾篇所說的,先占虛擬機會被公有雲收回,但收回的時候不會突然機器就 ben 不見,會有一個固定的流程。
如果你的應用已經帶有可容錯的機制,能夠承受機器突然變不見,服務還好好的,仍然要花時間理解這邊的流程,藉此精算每天虛擬機的終止與替換:應用會有什麼反應,會產生多少衝擊,稍後可以量化服務的影響。例如
如果你的應用需要有 graceful shutdown 的機制,那你務必要細心理解這邊的步驟。並仔細安排安全下樁的步驟。又或是無法保證在先占虛擬機回收的作業時限內,完成優雅終止,需要考慮其他可能的實作解法。
這邊有幾個面向要注意
三個重點
劇透一下:有的,有一些招式可以處理。讓我們繼續看下去。
先占虛擬機的硬體終止步驟與一般隨選虛擬機相同,所以我們要先理解虛擬機的停止流程
這裡指的終止 (Stop) 是虛擬機生命週期 的 RUNNING -> instances.stop() -> STOPPING -> TERMINATED 的步驟。
與隨選虛擬機不同
一樣先看先占虛擬機的說明文件:終止流程
但 30 秒能做什麼?只能快速的交代當前進度。如果應用需要花時間收尾,保存工作進度,可能會產生許多問題
依賴 shutdown script 做收尾是危險的,我們之後要想辦法處理這個不保證做完的優雅終止。
如果應用本身有容錯的框架,或是有容錯機制,我們這邊要額外做的工作就會少很多。例如許多程式框架提供自動重啟的功能,在外部保存 checkpoint,worker 只負責運算,終止信號一進來,也不用保存,直接拋棄未完成的工作進
度,留待繼起的 worker 從 checkpoint 接手。
明天待續,GCP 是如何選擇哪些機器應該要被回收的,以及我們應該如何面對這些限制
有寫過鐵人賽的都知道 30 篇真的很漫長,一篇文章幾千字,都要花好幾個小時。我去年後半,真的都會看讀者的留言跟按讚,取暖一波,才有動力繼續寫。留言的人多就會多寫,留言的人少就會少寫,各位覺得文章還看得下去,請務必來我粉專按讚留個言,不管是推推、鞭鞭、或是有想看的文章來許願,都十分歡迎。有你們的支持,我才有動力繼續寫。
請大家務必以實際行動支持好文章,不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD
當然,沒人留言我就會當作自己才是垃圾文 (自知之明XD),就會收一收回家嚕貓睡覺,掰掰~