Kubernetes

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. Like my page if you really like it :) 上面講解 Terraform 的基本操作流程，提供範本原始碼，以及一步一步導入的詳細步驟。各位應該都可以依照上面幾篇的說明，開始快樂的使用 Terraform 了。 而當使用 Terraform 的規模越來越大，管理的資料越來越多時，開始會出現一些問題，例如重複的 terraform code 越來越多，協同工作 review 不太容易，state 的內容管理與鎖管理，等等。這些問題可以透過一些工作流程的改進，或是導入新的小工具，來改善工作效率。 接下來筆者推薦幾個心得與工具，希望能提升使用 Terraform 的效率與產值 以下幾篇文章，適合已經使用過 terraform 一點時間，有經驗的團隊，並打算更大規模導入 terraform，正在尋求改善的方向。 心得 CI/CD 全自動化 State backend 選擇 最佳實踐 https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html 工具 Terraform Atlantis Terragrunt Terraform Backend 剛開始使用 terraform 的時候，大家的第一個範例應該都是 local backend 吧，就是直接在本地 terraform apply，在目前的工作目錄下產生 state 檔案。這個 state 檔案直接 cat 打開來看後，可以發現裡面一切都是明碼的。初學時筆者感覺所謂的 Terraform backend 只是一個存放中繼的 state 資料的 workspace，後來發現完全不是這麼回事，便立刻棄用了 local backend。 ...

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. Like my page if you really like it :) 上面講解 Terraform 的基本操作流程，提供範本原始碼，以及一步一步導入的詳細步驟。各位應該都可以依照上面幾篇的說明，開始快樂的使用 Terraform 了。 而當使用 Terraform 的規模越來越大，管理的資料越來越多時，開始會出現一些問題，例如重複的 terraform code 越來越多，協同工作 review 不太容易，state 的內容管理與鎖管理，等等。這些問題可以透過一些工作流程的改進，或是導入新的小工具，來改善工作效率。 接下來筆者推薦幾個心得與工具，希望能提升使用 Terraform 的效率與產值 以下幾篇文章，適合已經使用過 terraform 一點時間，有經驗的團隊，並打算更大規模導入 terraform，正在尋求改善的方向。 心得 CI/CD 全自動化 State backend 選擇 最佳實踐 https://www.terraform.io/docs/cloud/guides/recommended-practices/index.html 工具 Terraform Atlantis Terragrunt CI/CD 全自動化 當公司成功導入 terraform ，並且整合 Git-flow 的工作流程後，應該可以很明顯的感受到，整體的 infrastructure 產出穩定度有大幅提升，畢竟軟體工程中 code review 是穩定度的核心關鍵之一，而導入 terraform 與 infrastructure as code 讓 infrastructure 也能在合理的工作流程中被層層 review。 ...

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. Like my page if you really like it :) 上面講了很多 terraform 的操作範例，應該看到這裡，對於 terraform 基本上是什麼東西，應該有些概念了。然而這樣還不能算是學會 terraform，這種工具的東西一定要有實際操作過的經驗才算是學會。 可以直接參考 Terraform 官方的 Get-started 文件來操作學習，我這邊也提供一個 Git repository 讓大家上手，當作初次操作的框架。 提供做為範例的原始碼 這個 Github Repository 是我給社群演講所使用的範例，第一次使用的可以參考 https://github.com/chechiachang/terraform-playground tree ├── README.md ├── SOP.md ├── aws/ ├── azure/ └── gcp/ TL;DR 選擇使用的雲平台，這邊提供三家範例，例如我這邊使用 gcp，當然你就要準備 GCP 的帳號，並且下載有執行權限的用戶 credential json key 等等。 ...

先占虛擬機與 Kubernetes 在 GCP 使用先占虛擬機，會需要面對先占虛擬機的額外限制 資料中心會 (可預期或不可預期地) 終止先占虛擬機 先占虛擬機不能自動重啟，而是會被資料中心終止後回收 GCP 不保證有足夠的先占虛擬機 節點的終止會造成額外的維運成本，例如 管理多個節點，容忍先占虛擬機的移除，自動補充新的先占虛擬機 管理多個應用複本，節點終止時，維護整體應用的可用性 將移除節點上的應用，重新排程到其他可用節點 動態維護應用複本的服務發現 (Service Discovery) 與服務端點 (Endpoints) 意思是應用關閉重啟後，換了一個新 IP，還要能持續存取應用。舊的 IP 要主動失效 配合應用的健康檢查 (Health Check) 與可用檢查 (Readiness Check)，再分配網路流量 這些需求，必須要有自動化的管理工具，是不可能人工管理的，想像你手上使用 100 個先占節點，平均每天會有 10% - 15% 的先占節點被資料中心回收，維運需要 補足被移除的 15 個節點 計算被移除的應用，補足移除的應用數量 移除失效的應用端點，補上新的應用端點 持續監控應用狀態 … 沒有自動化管理工具，看了心已累 (貓爪掩面) 我們使用 Kubernetes 協助維運自動化，在 GCP 上我們使用 GKE，除了上述提到的容器應用管理自動化外，GKE 還額外整合先占虛擬機的使用 啟用先占虛擬機的節點池 (node-pool)，設定節點池的自動拓展，自動補足先占節點的數量 GKE 自動維護先占虛擬機的 labels 關於 GKE 的先占虛擬機的完整細節，請見GCP 官方文件。這份文件底下也提供了 GCP 官方建議的先占虛擬機最佳實踐 架構設計需要假設，部分或是全部的先占虛擬機都不可用的情形 Pod 不一定有時間能優雅終止 (graceful shutdown) 同時使用隨選虛擬機與先占虛擬機，以維持先占虛擬機不可用時，服務依然可用 注意節點替換時的 IP 變更 避免使用有狀態的 Pod 在先占虛擬機上 (這點稍後的文章，我們會試圖超越) 使用 node taint 來協助排程到先占虛擬機，與非先占虛擬機 總之，由於有容器自動化管理，我們才能輕易的使用先占虛擬機。 ...

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