本文同步刊登於個人技術部落格，有興趣關注更多 Kubernetes、DevOps 相關資源的讀者，請務必追蹤從零開始的軟體工程師之旅，喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論，技術方面諮詢免錢、需要動手做另計 XD。

上篇，我們開始探討以下幾個需求：

• 執行短期的 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

• Oracle 自家提供的 MySQL Operator
• CrunchyData 也有提供的 Postgres Operator

你就想，所以這些人是想怎樣，RDBMS 放 Kubernetes 上到底是行不行 XD。Google 的文章說明：如果應用本身並不符合 Kubernetes 的工作流程 (Pod life-cycle)，可以透過上述的 Operator 來自動化許多維運的作業，降低維運的困難。

然而 DB 有千百種，除了 RDBMS 以外，還有另外一批 Database 天生就具有分散式的架構，這些儲存庫部署到 Kubernetes 上，並不會太痛苦 (還是要付出一定的成本XD)，但是卻可以得益於 Kubernetes 的諸多功能。

底下我們先根據分散式的儲存庫做概觀描述，本系列文的最後，會根據時間狀況，做實例分享：Cassandra 或是 CockroachDB。提供各位一點發想，並根據需求去選擇需要的儲存庫

「行不行要問你自己了施主，技術上都可以，維運上要看看你的團隊有沒有那個屁股吃這份藥 XD」

Distributed Database

底下非常粗淺的簡介分散式儲存庫的概念，提供一個基準點，幫助接下來討論是否可以使用先占虛擬機。這邊要強調，儲存庫的類型千百種，底層的各種實作差異都非常大，底下的模型是基於 cassandra 但不會走太多細節。 cassandra 的規格有機會再細聊。

當後端應用已經順利水平拓展之後，整體服務的效能瓶頸往往都壓在後端 DB 上。這些不同的 DB 面向不同的需求，當需求符合時，可以考慮使用這些解決方法。

這邊要強調，不是放棄現有的 RDBMS ，完全移轉到新的資料庫，這樣的成本太高，也沒有必要性。更好的做法，是搭配既有的關聯性資料庫，將不是核心業務的資料處理抽出，移轉到合適的資料庫上。讓不同需求的資料儲存到更合>適的儲存庫，是這段話要強調的重點，關連式資料庫也不是唯一選擇。

分散式的資料庫有以下特徵

• 分散式節點集群 (Cluster)：資料庫是多個節點共存，而非 single master, multiple slaves 的架構
  • 配合共識算法 (consensus algorithm) 溝通節點之間的資訊
• 無單點錯誤 (Single-point failure)：e.g. 不會因為 master 錯誤導致整個服務失效
• 高可用(High Availitility：可以承受集群中一定數量虛擬機故障，服務仍然可用
• 資料 sharding 到不同節點上
• 複本 (replica)
  • 節點複本 (node replicas)：多個節點提供服務，提供流量的帶寬與可用性
  • 資料複本 (data replicas)：在多個節點上儲存資料，提供資料的備份，同時也提供讀取帶寬與可用性

從以上特徵來說，使用此架構的服務可以承受先占虛擬機的不定時終止，或許可以使用。

實務上有非常多需要注意，需要依據各自服務的性質，各自處理。常見的問題舉例如下：

• 應用可以容錯 (fault-tolerent)，然而錯誤發生後，會需要消耗復原成本，例如重啟後需要花時間初始化，或是在多節點上進行 data rebalance。
• 可以承受突然的錯誤，使用先占虛擬機，變成每日固定會承受必然的錯誤。這裡犧牲了部分算力，甚至造成隱性的維護成本，最後是否符合節省成本的需求。

都是需要仔細了解解決方案，並且分析需求，來評估是否有合乎成本。

GKE

以上分析了三種常見需求例子：從 batch job，user-facing service，與 distributed database。

明天會實際搬出 GKE 與 GCP Preemptible Instance 的技術規格，與大家實際討論。

有寫過鐵人賽的都知道 30 篇真的很漫長，一篇文章幾千字，都要花好幾個小時。我去年後半，真的都會看讀者的留言跟按讚，取暖一波，才有動力繼續寫。留言的人多就會多寫，留言的人少就會少寫，各位覺得文章還看得下去，請務必來我粉專按讚留個言，不管是推推、鞭鞭、或是有想看的文章來許願，都十分歡迎。有你們的支持，我才有動力繼續寫。

請大家務必以實際行動支持好文章，不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD

當然，沒人留言我就會當作自己才是垃圾文 (自知之明XD)，就會收一收回家嚕貓睡覺，掰掰~

我的粉專，等你來留言