鐵人賽2020

This article is part of 從零開始的 Infrastructu as Code: Terraform Get-started examples / SOP on Github Introducation to Terraform Iac: Speaker transcript Presentation Check my website chechia.net for other blog. Follow my page to get notification.

This article is part of 從零開始的 Infrastructu as Code: Terraform Get-started examples / SOP on Github Introducation to Terraform Iac: Speaker transcript Presentation Check my website chechia.net for other blog. Follow my page to get notification.

This article is part of 從零開始的 Infrastructu as Code: Terraform Get-started examples / SOP on Github Introducation to Terraform Iac: Speaker transcript Presentation Check my website chechia.net for other blog. Follow my page to get notification.

This article is part of 從零開始的 Infrastructu as Code: Terraform Get-started examples / SOP on Github Introducation to Terraform Iac: Speaker transcript Presentation Check my website chechia.net for other blog. Follow my page to get notification.

This article is part of 從零開始的 Infrastructu as Code: Terraform Get-started examples / SOP on Github Introducation to Terraform Iac: Speaker transcript Presentation Check my website chechia.net for other blog. Follow my page to get notification.

This article is part of 從零開始的 Infrastructu as Code: Terraform Get-started examples / SOP on Github Introducation to Terraform Iac: Speaker transcript Presentation Check my website chechia.net for other blog. Follow my page to get notification.

先占虛擬機與 Kubernetes 在 GCP 使用先占虛擬機，會需要面對先占虛擬機的額外限制 資料中心會 (可預期或不可預期地) 終止先占虛擬機 先占虛擬機不能自動重啟，而是會被資料中心終止後回收 GCP 不保證有足夠的先占虛擬機 節點的終止會造成額外的維運成本，例如 管理多個節點，容忍先占虛擬機的移除，自動補充新的先占虛擬機 管理多個應用複本，節點終止時，維護整體應用的可用性 將移除節點上的應用，重新排程到其他可用節點 動態維護應用複本的服務發現 (Service Discovery) 與服務端點 (Endpoints) 意思是應用關閉重啟後，換了一個新 IP，還要能持續存取應用。舊的 IP 要主動失效 配合應用的健康檢查 (Health Check) 與可用檢查 (Readiness Check)，再分配網路流量 這些需求，必須要有自動化的管理工具，是不可能人工管理的，想像你手上使用 100 個先占節點，平均每天會有 10% - 15% 的先占節點被資料中心回收，維運需要

先占虛擬機，技術文件二三事 第一篇的內容大部份還是翻譯跟講解官方文件。後面幾篇才會有實際的需求與解決方案分析。 Google 先占虛擬機官方文件 使用不熟悉的產品前一定要好好看文件，才不會踩到雷的時候，發現人家就是這樣設計的，而且文件上寫得清清楚楚。以為是 bug 結果真的是 feature，雷到自己。先占虛擬機是用起來跟普通虛擬機沒什麼兩樣，但實際上超級多細節要注意，毛很多的產品，請務必要小心使用。 以下文章是筆者工作經驗，覺得好用、確實有幫助公司，來跟大家分享。礙於篇幅，這裡只能非常粗略地描述我們團隊思考過的問題，實際上的問題會複雜非常多。文章只是作個發想，並不足以支撐實際的業務，所以如果要考慮導入，還是要 多作功課，仔細查閱官方文件，理解服務的規格 深入分析自身的需求 基於上面兩者，量化分析 什麼是先占虛擬機器(Preemptible Instance) 先占虛擬機器，是資料中心的多餘算力，讀者可以想像是目前賣剩的機器，會依據資料中心的需求動態調整，例如 目前資料中心的算力需求低，可使用的先占虛擬機釋出量多，可能可以用更便宜的價格使用 目前資料中心算力需求高，資料中心會收回部分先占虛擬機的額度，轉化成隨選付費的虛擬機 (pay-as-you-go) 由於先占虛擬機會不定時（但可預期）地被資料中心收回，因此上頭執行的應用，需要可以承受機器的終止，適合有容錯機制 (fault-tolerant) 的應用，或是批次執行的工作也很適合。 先占機器的優缺點 除了有一般隨選虛擬機的特性，先占虛擬機還有以下特點 比一般的虛擬機器便宜非常多，這也是我們選用先占虛擬機優於一般虛擬機的唯一理由 先占虛擬機有以下限制，以維運的角度，這些都是需要考量的點。 GCP 不保證會有足夠的先占虛擬機 先占虛擬機不能直接轉換成普通虛擬機 資料中心觸發維護事件時(ex. 回收先占虛擬機)，先占虛擬機不能設定自動重啟，而是會直接關閉 先占機器排除在 GCP 的服務等級協議 (SLA)之外 先占虛擬機不適用GCP 免費額度 費用粗估試算 至於便宜是多便宜呢？這邊先開幾個例子給各位一些概念。

關於資源評估 架構團隊提供虛擬機給應用，有個問題時常出現：應該分配多少資源給應用？例如：後端準備一個 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 的資源使用量也可設定資源需求與資源限制，延伸閱讀。

需求規劃 使用先占節點比起使用一般隨選虛擬機，會多出許多技術困難需要克服，只有節省下的成本大於整體技術成本時，我們才會選用先占節點。因此這邊要進行成本精算，重新調整的架構下，實際到底能省多少錢。務必使用 Google Cloud Pricing Calculator 精算成本。 另外，雖然先占虛擬機會有很多額外的限制與技術困難，但實務上還是要對比實際的需求，有些限制與需求是衝突的，有些限制則完全不會影響我們的需求。前者當然會帶給我們較高的導入難度，後者可能會非常輕鬆。 這邊想給大家的概念是，務必先明確需求，再討論技術。這點很重要，技術的適用與否，不是由個人的喜好決定，唯一的判斷標準，是能不能有效率的滿足需求。 所以這邊先定義我們以下幾個需求： 執行短期的 batch job 執行長期的 user-facing API server 執行長期的 stateful 資料庫、儲存庫 Batch Job 常見的範例，例如 使用網路爬蟲 (crawler) 去抓取許多網站的所有內容 使用 GPU 進行機器學習的 Model Training 大數據計算 MapReduce 這些任務的核心需求，很簡單直接