gcp

先占虛擬機與 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 這些任務的核心需求，很簡單直接

先占虛擬機終止流程 (Preemption process) 子曰：未知生焉知死。但做工程師要反過來，考量最差情形，也就是要知道應用可能如何死去。不知道應用可能怎麼死，別說你知道應用活得好好的，大概想表達這麼意思。 這對先占虛擬機來說特別重要，一般應用面對的機器故障或是機器終止，在使用先占西你幾的狀況下，變成每日的必然，因此，需要對應用的終止情境，與終止流程有更精細的掌控。如同前幾篇所說的，先占虛擬機會被公有雲收回，但收回的時候不會突然機器就 ben 不見，會有一個固定的流程。 如果你的應用已經帶有可容錯的機制，能夠承受機器突然變不見，服務還好好的，仍然要花時間理解這邊的流程，藉此精算每天虛擬機的終止與替換：應用會有什麼反應，會產生多少衝擊，稍後可以量化服務的影響。例如 應用重啟初始化時 cpu memory 突然拉高 承受節點錯誤後的復原流程，需要消耗額外算力。例如需要從上個 checkpoint 接續做，需要去讀取資料造成 IO，或是資料需要做 rebalance …等等 如果你的應用需要有 graceful shutdown 的機制，那你務必要細心理解這邊的步驟。並仔細安排安全下樁的步驟。又或是無法保證在先占虛擬機回收的作業時限內，完成優雅終止，需要考慮其他可能的實作解法。 這邊有幾個面向要注意 GCP 如何終止先占節點 GCP 移除節點對 GKE 、以及執行中應用的影響 GKE 集群如何應對的節點失效 GCP 自動調度補足新的先占節點 GKE 集群如何應對節點補足 三個重點

我們以下幾個需求： 執行短期的 batch job 執行長期的 user-facing API server 執行長期的 stateful 資料庫、儲存庫 該不該在 Kubernetes 上面跑 database？ TL;DR ，如果你剛開始考慮這件事，通常的答案都是否定的 等等，我們這邊不是討論該不該上 Kuberentes ，而是該不該使用先占虛擬機吧。然而由於先占虛擬機節點的諸多限制，光憑先占虛擬機並不適合跑任何持久性的儲存庫。我們這邊仰賴 Kubernetes 的網路功能 (e.g. 服務發現)，與自動管理 (e.g. health check，HPA，auto-scaler)，基於先占虛擬機，建構高可用性的服務架構，來支撐高可用，且有狀態的的儲存庫。 應用是否適合部署到 Kubernetes 上，可以看這篇 Google Blog: To run or not to run a database on Kubernetes: What to consider，如果大家有興趣，再留言告訴我，我再進行中文翻譯。

前言 鐵人賽的第二部分，要帶來公有雲省錢系列文章。 架構的成本，很多時候會影響架構的設計與需求。公司的營運都需要在成本與需求之前平衡，成本其實是影響公司決策的重要因素。身為架構管理員，應該要試著量化並且進行成本管理，提出解決方案時，也需要思考如何幫公司開源節流。 一昧消減架構的成本也未必是最佳方案，帳面上消減的成本有時也會反映在其他地方，例如：使用比較便宜的解決方案，或是較低的算力，但卻造成維運需要花更多時間維護，造成隱性的人力成本消耗。用什麼替代方案 (trade-off) 省了這些錢。 Kubernetes 是一個很好的例子：例如：有人說「Kubernetes 可以省錢」，但也有人說「Kubernetes 產生的 Overhead 太重會虧錢」。 「要不要導入 Kubernetes 是一個好問題」。應該回歸基本的需求，了解需求是什麼。例如：Google 當初開發容器管理平台，是面對什麼樣的使用需求，最終開發出 Kubernetes，各位可以回顧前篇文章「Borg Omega and Kubernete，Kubernetes 的前日今生，與 Google 十餘年的容器化技術」，從 Google 的角度理解容器管理平台，反思自身團隊的實際需求。 這套解決方案是否真的適合團隊，解決方案帶來的效果到底是怎樣呢？希望看完這系列文章後，能幫助各位，從成本面思考這些重要的問題。 這篇使用 GCP 的原因，除了是我最熟悉的公有雲外，也是因為 GCP 提供的免費額度，讓我可以很輕鬆地作為社群文章的 Demo，如果有別家雲平台有提供相同方案，請留言告訴我，我可能就會多開幾家不同的範例。

2020 It邦幫忙鐵人賽 系列文章 這邊改了一些大綱，原本的內容還有一些 kubernetes 的設定，以及 GCP 相關服務的介紹。但既然我們的主題是把東西搬上 k8s 的踩雷旅程，那我們就繼續搬，繼續踩。剩下的時間大概會有四個題目。 Nginx Ingress (3) Deploy Nginx Ingress Controller Configure Nginx Ingress Cert-manager (3) Deploy cert-manager How cert-manager work Cert-manager complete workflow Kubernetes CRD & Operator-sdk (3) Introduction about custom resource Deployment & Usage Deployment & Usage 由於我比較熟悉 GCP / GKE 的服務，這篇的操作過程都會以 GCP 平台作為範例，不過操作過程大體上是跨平台通用的。

2020 It邦幫忙鐵人賽 系列文章 這邊改了一些大綱，原本的內容還有一些 kubernetes 的設定，以及 GCP 相關服務的介紹。但既然我們的主題是把東西搬上 k8s 的踩雷旅程，那我們就繼續搬，繼續踩。剩下的時間大概會有四個題目。 Nginx Ingress (3) Deploy Nginx Ingress Controller Configure Nginx Ingress Cert-manager (3) Deploy cert-manager How cert-manager work Cert-manager complete workflow Kubernetes CRD & Operator-sdk (3) Introduction about custom resource Deployment & Usage Deployment & Usage 由於我比較熟悉 GCP / GKE 的服務，這篇的操作過程都會以 GCP 平台作為範例，不過操作過程大體上是跨平台通用的。

2020 It邦幫忙鐵人賽 系列文章 Self-host ELK stack on GCP Secure ELK Stask 監測 Google Compute Engine 上服務的各項數據 監測 Google Kubernetes Engine 的各項數據 是否選擇 ELK 作為解決方案 使用 logstash pipeline 做數據前處理 Elasticsearch 日常維護：數據清理，效能調校，永久儲存 Debug ELK stack on GCP 作為範例的 ELK 的版本是當前的 stable release 7.