Preemptible

我們以下幾個需求： 執行短期的 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 預計內容 ...