先占虛擬機終止流程 (Preemption process) 子曰：未知生焉知死。但做工程師要反過來，考量最差情形，也就是要知道應用可能如何死去。不知道應用可能怎麼死，別說你知道應用活得好好的，大概想表達這麼意思。 這對先占虛擬機來說特別重要，一般應用面對的機器故障或是機器終止，在使用先占西你幾的狀況下，變成每日的必然，因此，需要對應用的終止情境，與終止流程有更精細的掌控。如同前幾篇所說的，先占虛擬機會被公有雲收回，但收回的時候不會突然機器就 ben 不見，會有一個固定的流程。 如果你的應用已經帶有可容錯的機制，能夠承受機器突然變不見，服務還好好的，仍然要花時間理解這邊的流程，藉此精算每天虛擬機的終止與替換：應用會有什麼反應，會產生多少衝擊，稍後可以量化服務的影響。例如 應用重啟初始化時 cpu memory 突然拉高 承受節點錯誤後的復原流程，需要消耗額外算力。例如需要從上個 checkpoint 接續做，需要去讀取資料造成 IO，或是資料需要做 rebalance …等等 如果你的應用需要有 graceful shutdown 的機制，那你務必要細心理解這邊的步驟。並仔細安排安全下樁的步驟。又或是無法保證在先占虛擬機回收的作業時限內，完成優雅終止，需要考慮其他可能的實作解法。 這邊有幾個面向要注意 GCP 如何終止先占節點 GCP 移除節點對 GKE 、以及執行中應用的影響 GKE 集群如何應對的節點失效 GCP 自動調度補足新的先占節點 GKE 集群如何應對節點補足 三個重點 先占虛擬機終止對集群的影響 Pod 隨之終止對應用的影響，是否能夠優雅終止 有沒有方法可以避免上面兩者的影響 劇透一下：有的，有一些招式可以處理。讓我們繼續看下去。 GCP 如何終止虛擬機 先占虛擬機的硬體終止步驟與一般隨選虛擬機相同，所以我們要先理解虛擬機的停止流程 這裡指的終止 (Stop) 是虛擬機生命週期 的 RUNNING -> instances.stop() -> STOPPING -> TERMINATED 的步驟。 instances.stop() ACPI shutdown OS 會進行 shutdown 流程，並嘗試執行各個服務的終止流程，以安全的終止服務。如果虛擬機有設定Shtudown Script 會在這步驟處理 等待至少 90 秒，讓 OS 完成終止的流程 逾時的終止流程，GCP 會直接強制終止，就算 shutdown script 還沒跑完 GCP 不保證終止時限的時間，官方建議不要寫重要的依賴腳本在終止時限內 虛擬機變成 TERMINATED 狀態 GCP 如何終止先占虛擬機 與隨選虛擬機不同 ...

我們以下幾個需求： 執行短期的 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，如果大家有興趣，再留言告訴我，我再進行中文翻譯。 文中針對三個可能的方案做分析，以 MySQL 為例： Sass，GCP 的 Cloud SQL 最低的管理維運成本 自架 MySQL 在 GCP 的 VM 上，自行管理 自負完全的管理責任，包含可用性，備份 (backup)，以及容錯移轉 (failover) 自架 MySQL 在 Kubernetes 上 自負完全的管理責任 Kubernetes 的複雜抽象層，會加重維運工作的複雜程度 然而 RDBMS 的提供商，自家也提供 Operator ...

前言 鐵人賽的第二部分，要帶來公有雲省錢系列文章。 架構的成本，很多時候會影響架構的設計與需求。公司的營運都需要在成本與需求之前平衡，成本其實是影響公司決策的重要因素。身為架構管理員，應該要試著量化並且進行成本管理，提出解決方案時，也需要思考如何幫公司開源節流。 一昧消減架構的成本也未必是最佳方案，帳面上消減的成本有時也會反映在其他地方，例如：使用比較便宜的解決方案，或是較低的算力，但卻造成維運需要花更多時間維護，造成隱性的人力成本消耗。用什麼替代方案 (trade-off) 省了這些錢。 Kubernetes 是一個很好的例子：例如：有人說「Kubernetes 可以省錢」，但也有人說「Kubernetes 產生的 Overhead 太重會虧錢」。 「要不要導入 Kubernetes 是一個好問題」。應該回歸基本的需求，了解需求是什麼。例如：Google 當初開發容器管理平台，是面對什麼樣的使用需求，最終開發出 Kubernetes，各位可以回顧前篇文章「Borg Omega and Kubernete，Kubernetes 的前日今生，與 Google 十餘年的容器化技術」，從 Google 的角度理解容器管理平台，反思自身團隊的實際需求。 這套解決方案是否真的適合團隊，解決方案帶來的效果到底是怎樣呢？希望看完這系列文章後，能幫助各位，從成本面思考這些重要的問題。 這篇使用 GCP 的原因，除了是我最熟悉的公有雲外，也是因為 GCP 提供的免費額度，讓我可以很輕鬆地作為社群文章的 Demo，如果有別家雲平台有提供相同方案，請留言告訴我，我可能就會多開幾家不同的範例。 先占虛擬機 TL;DR 先占虛擬機為隨選虛擬機定價的 2-3 折，使用先占虛擬機可能可以節省 7 成的雲平台支出 先占虛擬機比起隨選虛擬機，外加有諸多限制，e.g. 最長壽命 24 hr、雲平台會主動終止先占虛擬機…等 配合使用自動水平擴展 (auto-scaler)，讓舊的先占虛擬機回收的同時，去購買新的先占虛擬機 配合可容錯 (fault-tolerent) 的分散式應用，讓應用可以無痛在虛擬機切換轉移，不影響服務 要讓應用可以容錯，需要做非常多事情 搭配 kubernetes ，自動化管理來簡化工作 配合正確的設定，可以穩定的執行有狀態的分散式資料庫或儲存庫 或是看 Google 官方 Blog：Cutting costs with Google Kubernetes Engine: using the cluster autoscaler and Preemptible VMs 預計內容 ...

前言 這是原文完整版本。太長不讀 (TL;DR) 請見Borg Omega and Kubernetes 前世今生摘要 原文：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/44843.pdf 摘要 在 container 技術夯起來前，Google 已經做了 container 十幾年，過程中發展出需三套容器管理系統。雖然每一代系統的開發需求不同，但每一代都深受上一代影響。這篇文章描述 Google 開發這些系統時，學到的經驗。 第一套 container management 系統是 Borg，為了管理 1. 長期執行的服務 2. 批次的短期工作 (batch job)，原本分別是由 Babysitter 與 Global Work Queue 兩套系統分開管理。後者的架構深刻影響 Borg，但 Global Work Queue 專注於 batch job。兩套系統都在 Linux control groups 之前。Borg 將上述兩種應用放在共享的機器上，來增加資源的使用率，以節省成本。這種共享基於支援 container 的 Linux Kernel (Google 也貢獻許多 Linux kernel container 程式碼)，提供更好的隔離 (isolation) 給延遲敏感的使用者服務 (latency-sentitive user-facing services)，以及消耗大量 cpu 的 batch 程式。 越來越多應用都在 Borg 上開發執行， Google 的應用與 infratructure 團隊開發許多工具與服務，形成 Borg 生態系。這些系統提供設定 (configure) 與更新 (update) 工作、預測資源需求、動態推送設定到執行中的工作、服務發現 (service discovery) 與負載均衡 (Load balancing)，等等功能。這些生態系的開發基於 Google 不同團隊的需求，產生一個不同起源 (heterogeneous)、只針對各別需求的 (ad-hoc) 一個堆不同系統，Borg 的使用者需要使用不同的程式語言與程序，來與這些系統互動。Borg 仍然是 Google 主要的容器管理系統，因為他規模 (scale) 巨大，功能多樣，而且極度堅固 (robustness)。 ...

這是原文翻譯的太長不讀 (TL;DR) 版本。完整翻譯請見Borg Omega and Kubernetes 前世今生浩文完整翻譯 原文：https://storage.googleapis.com/pub-tools-public-publication-data/pdf/44843.pdf 前言 Borg 以前就有應用管理系統，那時還沒有 Linux control group Borg 是第一套統一的 container-management system Borg 仍被大規模的使用，有許多功能而且非常堅固 Omega 繼承 Borg 上成功的設計，並希望改進 Borg 的生態系 Kubernetes 開源 透過 REST API 溝通 client 應用開發導向，著重於開發者的需求，希望能簡單的部署複雜的系統 Container Google 使用 Container 來提昇 utilization 把 batch jobs 跟預留資源的服務 (user-facing app) 放在一起，使用閒置時的資源跑 batch job 現代 container 的定義是 runtime-isolation 與 image Application-oriented infrastructure container 使用久了，不只滿足 utilization 的需求 資料中心從機器導向變成應用導向 Container 封裝環境，把機器與 OS 的依賴抽象化 應用不依賴 部署流程 runtime infrastrcture Container scope 在應用上，專注在應用管理而不是機器管理 Application environment cgroup, chroot, namespace 原本的目的是為了保護應用，不被其他應用影響 混合使用可以在應用與 OS 間產生抽象層，解耦 app 與 OS 提供完全相同的部署環境，避免切換環境(ex. dev, prod)時造成環境差異 進一步把 app 的依賴程式也打包 image container 對 OS 唯一的依賴只剩 Linux kernel system-call interface 大幅增加 app 調度的彈性 然而有些 interface 仍附著 OS 上，ex socket, /prod, ioctl calls 希望透過 Open Container Initiative，清楚定義 interface 與抽象 直接的好處，少數幾種 OS 與 OS Version 就可以跑所有應用，新版本也不影響 Container as the unit of management 資料中心的重心，從管理機器變成管理應用 提供彈性給 infrastructure team 提供統一的架構 收集統一的 metrics Container 統一的介面，讓 management system (ex. k8s) 可以提供 generic APIs REST API, HTTP, /healthz, exec… 統一的 health check 介面，更方便的終止與重啟 一致性 容器提供統一的資訊，ex. status, text message, … 管理平台提供統一設定 (ex. resource limits) ，並進行 logging 與 monitoring 提供更精細的功能 ex. graceful-termination cgroups 提供 app 的資源使用資訊，而不需要知道 app spec，因為 contaier 本身即是 app 提供更簡單，卻更精細且堅固的 logging 與 monitoring 應用導向的 monitoring ，而不是機器導向的 monitoring 可以收集跨 OS 的 app 狀態，進行整合分析，而不會有 OS 不同造成的雜訊 更容易對應用除錯 nested contaiers resource allocation (aka. alloc in Borg, Pod in Kubernetes) Orchestration is the beginning, not the end 原本 Borg 只是要把 workload 分配到共用的機器上，來改善 utilization 結果發現可以做更多事情，來幫助開發與部署 Naming, service discovery Application-aware load balancing Rollout tool Workflow tool Monitoring tool 成功的工具被留下 然而工具都需要各自的 API，副作用是增加部署的複雜度到 Borg 的生態系 Kubernetese 試圖降低複雜度 提供一致的 API ex. ObjectMetadata, Specification, Status Object metadata 是全域共通的 Spec 與 Status 根據 Object 有所不同，但是概念是一致的 Spec 描述 desired state of object Status 提供 read-only 的 current state of object Uniform API 有許多好處 降低學習成本 可以使用 generic 的工具讓所有 workflow 使用 統一使用者的開發流程與開發經驗 Kubernetes 本身模組化，可以使用延伸模組 ex. pod API 讓使用者使用，kubernetes 內部使用，外部自動化工具也使用 使用者可以自己增加 customized API 如何達到 Uniform API decoupling API 切分 API 關注的面向，變成不同 components API. ex. replication controller 確保 desired 數量的 Pod 存在 autoscaler 關注在需求與使用的預測，然後控制 replication controller API higher-level 服務都共用相同的 basic API 切分 API 而外的好處 有關聯但是用途不同的 API 的內容與使用方式十分相似. ex. ReplicationController: 控制長時間運行的 containers 與其複本 DeamonSet: 每個機器上都跑一個 container Job: 一次性執行完畢的 container Common design patterns ex. reconciliation controller loop 在 Borg, Omega, Kubernetes 中大量使用 需求(desired state) 觀察現況(current state) 執行動作，收斂需求與現況(reconcile) loop 由於狀態是基於實際觀測產生，reconciliation loop 非常堅固，可以承受相當的 failure Kubernetes 設計為一連串的為服務系統，以及許多小型的 control loop 對比大型的 centralized orchestration system Things to avoid Google 開發過程中，也發現許多不該做的事情 ...