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 的資源使用量也可設定資源需求與資源限制,延伸閱讀。 估計得越準確,當然實際部署的資源掌握度就越高,然而筆者過去的經驗,團隊在交付源碼時未必就能夠做出有效的資源消耗評估,那有沒有什麼辦法可以幫助我們? 資源需求估估看 如果應用開發團隊,有先作應用的 profiling,然後 release candidate 版本有在 staging 上作壓力測試的話,維運團隊這邊應該就取得的數據,做部署前的資源評估。 應用在不同狀態或是工作階段,會消耗不同的資源 例如:運算密集的 batch job 可能會有 控制節點 (master node) 啟動後會佔有一定的資源,一般來說不會消耗太多,只是需要為控制節點優先保留資源 工作節點 (worker node) 啟動時會需要預留足夠的資源,接收工作後會逐漸增加資源使用,拉到滿載 例如:面向用戶的服務,可能會有 ...