preemptible

Gcp Preemptible Instance Introduction
先占虛擬機,技術文件二三事 第一篇的內容大部份還是翻譯跟講解官方文件。後面幾篇才會有實際的需求與解決方案分析。 Google 先占虛擬機官方文件 使用不熟悉的產品前一定要好好看文件,才不會踩到雷的時候,發現人家就是這樣設計的,而且文件上寫得清清楚楚。以為是 bug 結果真的是 feature,雷到自己。先占虛擬機是用起來跟普通虛擬機沒什麼兩樣,但實際上超級多細節要注意,毛很多的產品,請務必要小心使用。 以下文章是筆者工作經驗,覺得好用、確實有幫助公司,來跟大家分享。礙於篇幅,這裡只能非常粗略地描述我們團隊思考過的問題,實際上的問題會複雜非常多。文章只是作個發想,並不足以支撐實際的業務,所以如果要考慮導入,還是要 多作功課,仔細查閱官方文件,理解服務的規格 深入分析自身的需求 基於上面兩者,量化分析 什麼是先占虛擬機器(Preemptible Instance) 先占虛擬機器,是資料中心的多餘算力,讀者可以想像是目前賣剩的機器,會依據資料中心的需求動態調整,例如 目前資料中心的算力需求低,可使用的先占虛擬機釋出量多,可能可以用更便宜的價格使用 目前資料中心算力需求高,資料中心會收回部分先占虛擬機的額度,轉化成隨選付費的虛擬機 (pay-as-you-go) 由於先占虛擬機會不定時(但可預期)地被資料中心收回,因此上頭執行的應用,需要可以承受機器的終止,適合有容錯機制 (fault-tolerant) 的應用,或是批次執行的工作也很適合。 先占機器的優缺點 除了有一般隨選虛擬機的特性,先占虛擬機還有以下特點 比一般的虛擬機器便宜非常多,這也是我們選用先占虛擬機優於一般虛擬機的唯一理由 先占虛擬機有以下限制,以維運的角度,這些都是需要考量的點。 GCP 不保證會有足夠的先占虛擬機 先占虛擬機不能直接轉換成普通虛擬機 資料中心觸發維護事件時(ex. 回收先占虛擬機),先占虛擬機不能設定自動重啟,而是會直接關閉 先占機器排除在 GCP 的服務等級協議 (SLA)之外 先占虛擬機不適用GCP 免費額度 費用粗估試算 至於便宜是多便宜呢?這邊先開幾個例子給各位一些概念。
Gcp Preemptible Instance Resource Calculation
關於資源評估 架構團隊提供虛擬機給應用,有個問題時常出現:應該分配多少資源給應用?例如:後端準備一個 API server,SRE 這邊要準備多少什麼規格的機器? 以往使用虛擬機直接部署應用時,會需要明確規劃各群虛擬機,各自需要執行的應用,如果沒有做資源的事前評估,有可能放上機器運行後就發生資源不足。 導入 Kubernetes 後,透過節點池 (Node Pool) 形成一個大型資源池,設定部署的政策後,讓 Kubernetes 自動調度應用: 每一個節點的資源夠大,使得應用虛擬機器上所佔的比例相對較小,也就是單一應用的調度不會影響節點的整體負載 如果節點太小,調度應用就會有些侷促,例如:一個 API server 均載時消耗 1 cpu 滿載時消耗 2 cpu。準備 3 cpu 的虛擬機,調度應用時幾乎是遷移整台虛擬機的負載 此外還有機會因為上篇提到的資源保留,造成調度失敗。如果準備 24 cpu 的機器,調度起來彈性就很大,對節點的性能衝擊也比較低 只需要估計整體的資源消耗率計算需求,配合自動擴展,動態器補足不足的資源 例如:估計總共需要 32 cpu ,準備 36 cpu 的虛擬機,當滿載時依據 cpu 壓力自動擴容到 48 cpu 希望整體資源的使用率夠高,當然預留太多的資源會造成浪費 要控管 Kubernetes 的資源使用量也可設定資源需求與資源限制,延伸閱讀。
Gcp Preemptible Instance Speficication
先占虛擬機終止流程 (Preemption process) 子曰:未知生焉知死。但做工程師要反過來,考量最差情形,也就是要知道應用可能如何死去。不知道應用可能怎麼死,別說你知道應用活得好好的,大概想表達這麼意思。 這對先占虛擬機來說特別重要,一般應用面對的機器故障或是機器終止,在使用先占西你幾的狀況下,變成每日的必然,因此,需要對應用的終止情境,與終止流程有更精細的掌控。如同前幾篇所說的,先占虛擬機會被公有雲收回,但收回的時候不會突然機器就 ben 不見,會有一個固定的流程。 如果你的應用已經帶有可容錯的機制,能夠承受機器突然變不見,服務還好好的,仍然要花時間理解這邊的流程,藉此精算每天虛擬機的終止與替換:應用會有什麼反應,會產生多少衝擊,稍後可以量化服務的影響。例如 應用重啟初始化時 cpu memory 突然拉高 承受節點錯誤後的復原流程,需要消耗額外算力。例如需要從上個 checkpoint 接續做,需要去讀取資料造成 IO,或是資料需要做 rebalance …等等 如果你的應用需要有 graceful shutdown 的機制,那你務必要細心理解這邊的步驟。並仔細安排安全下樁的步驟。又或是無法保證在先占虛擬機回收的作業時限內,完成優雅終止,需要考慮其他可能的實作解法。 這邊有幾個面向要注意 GCP 如何終止先占節點 GCP 移除節點對 GKE 、以及執行中應用的影響 GKE 集群如何應對的節點失效 GCP 自動調度補足新的先占節點 GKE 集群如何應對節點補足 三個重點
Gcp Preemptible Instance
前言 鐵人賽的第二部分,要帶來公有雲省錢系列文章。 架構的成本,很多時候會影響架構的設計與需求。公司的營運都需要在成本與需求之前平衡,成本其實是影響公司決策的重要因素。身為架構管理員,應該要試著量化並且進行成本管理,提出解決方案時,也需要思考如何幫公司開源節流。 一昧消減架構的成本也未必是最佳方案,帳面上消減的成本有時也會反映在其他地方,例如:使用比較便宜的解決方案,或是較低的算力,但卻造成維運需要花更多時間維護,造成隱性的人力成本消耗。用什麼替代方案 (trade-off) 省了這些錢。 Kubernetes 是一個很好的例子:例如:有人說「Kubernetes 可以省錢」,但也有人說「Kubernetes 產生的 Overhead 太重會虧錢」。 「要不要導入 Kubernetes 是一個好問題」。應該回歸基本的需求,了解需求是什麼。例如:Google 當初開發容器管理平台,是面對什麼樣的使用需求,最終開發出 Kubernetes,各位可以回顧前篇文章「Borg Omega and Kubernete,Kubernetes 的前日今生,與 Google 十餘年的容器化技術」,從 Google 的角度理解容器管理平台,反思自身團隊的實際需求。 這套解決方案是否真的適合團隊,解決方案帶來的效果到底是怎樣呢?希望看完這系列文章後,能幫助各位,從成本面思考這些重要的問題。 這篇使用 GCP 的原因,除了是我最熟悉的公有雲外,也是因為 GCP 提供的免費額度,讓我可以很輕鬆地作為社群文章的 Demo,如果有別家雲平台有提供相同方案,請留言告訴我,我可能就會多開幾家不同的範例。