Posts

我們以下幾個需求： 執行短期的 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，如果有別家雲平台有提供相同方案，請留言告訴我，我可能就會多開幾家不同的範例。

前言 這是原文完整版本。太長不讀 (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 程式。

這是原文翻譯的太長不讀 (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.

季中回顧 這一季開了很多新坑，卻來不及寫文章填上 完成的有 Terraform 的基礎與實務導入經驗 正在趕工的有 hashicorp vault，Gitops，與 tls。 其中 GitOps 已經有強者我朋友 Hwchiu 巨巨填坑了，我這邊就會偷懶跳過。友情連結 剩下的希望本季結束前能填完(掩面) 已填坑 從零開始導入 Terraform DevOps Taiwan Meetup iThome Cloud Summit 新坑，碼農正在耕田，挖坑自己跳 hashicorp vault install basic operation Sign & manage x509 certificate with pki secret engine 填坑中，文章尚未完成 aws

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.

2019 年度回顧

跟著 MIT 6.824 深入淺出分散式系統

https://en.bitcoin.it/wiki/Atomic_swap Algorithm 2 pay txs and 2 claim tx claim txs are singed at first, locked with time 2 pay txs are encrypted by x, affects only when x is reveal on the network Initialization A: random number x