Kubernetes 將改變資料庫的管理方式

當技術決策人考慮在 Kubernetes 上部署資料庫時，面臨的第一個問題就是：“Kubernetes 有應對有狀態服務的能力嗎?”多年來的答案都是“不建議”，而且理由充分。畢竟，Kubernetes 最初的設計便是用於處理無狀態服務的容器編排。如今，有狀態服務的相關技術已經相當成熟，是時候重新考慮在 Kubernetes 上執行資料庫了。

實現資料庫容器化，還需要從三個重要的技術角度來考慮：

1、Kubernetes 本身的技術成熟度

2、Kubernetes 處理有狀態服務的能力

3、容器中執行資料庫的可用性和效能

Kubernetes 技術有多成熟?

雖然評估任何一項技術的成熟度都不是一個簡單的過程，但還是可以依靠一些資料來推證的。

Kubernetes[1] 是 CNCF 基金會[2]的畢業專案，目前該技術很流行，且有很多的專案參與者。據 CNCF 2020 年的雲原生調查報告[3] 顯示，“91% 使用容器技術的受訪者使用 Kubernetes，其中 83% 是在生產環境中使用。”

自 2017 年 11 月以來，知名分析公司 Thoughtworks[4] 一直將 Kubernetes 作為必須採用的技術之一，並解釋說，“在將容器部署到叢集中時，它已成為我們大多數客戶的預設解決方案。”

圖片來自 CNCF

Kubernetes 處理有狀態服務的能力如何?

Kubernetes 的有狀態功能經常受到質疑，第一代有狀態技術 Persistent Set(簡稱“PetSet”)也(部分)受到了指責。這個特性被棄用後，取而代之的是 Kubernetes 有狀態技術：StatefulSets[5]。2018 年 GA 版本釋出，如今為無數的 Kubernetes 容器提供持久、非短暫儲存的解決方案，同時也為 Vitess[6] 或其他雲原生資料庫提供了在 Kubernetes 中部署的可能性。

最值得注意的是，StatefulSets 將 PersistentVolumes(PV)裝載到容器中。這些 PV 通常由 Kubernetes 節點外部的儲存提供，可以是網路或軟體定義的儲存解決方案，如 OpenEBS。本質上，Kubernetes 和雲上使用的儲存與 AWS 上使用的 EBS 卷或 GCP 上使用的持久磁碟相同。

Kubernetes 上執行資料庫的效能如何?

無疑，Kubernetes 上執行資料庫效能會受到影響。容器被錯誤地視為“輕量級虛擬機器”它們是相當輕量的抽象層，包裹著 Linux 核心提供的檔案系統、程式和網路空間。如果只使用短暫的容器儲存資料，可能會有一些開銷。但如果使用外部 PV 儲存，開銷可以忽略不計。

那麼容器的臨時性不會影響高可用性嗎?由於容器只是對程式的“包裝”，它們的生命週期與程式的生命週期有關。換句話說，容器將和其中執行的資料庫程式一樣穩定。

Kubernetes 徹底改變了資料庫的執行方式

在 Kubernetes 上執行資料庫有明顯的優勢：部署簡單，整個堆疊由同一個編排工具管理，自動修復，以及自動重新部署失敗的容器，從而提高可用性。例如，如果執行資料庫的其中一個節點出現故障，Kubernetes 將自動進行自我修復，重新安排另一個節點上的工作負載。透過與資料庫管理軟體的合作，它可以選擇一個在以前存在的複製副本上執行的新資料庫主節點，並將新節點重新初始化為一個新的複製副本，這一切都是自動的。但還有其他更重要的原因讓你想在 Kubernetes 中執行資料庫。

大多數公司希望將資料庫作為 DBaaS(資料庫即服務)進行操作。自我配置自愈資料庫，包括備份和監視。雖然這是功能大多數雲廠商也提供，但透過使用 Kubernetes 自己動手可以節省大量成本，並提供額外的功能，如多雲和雲可移植性。

這些功能可以透過 Kubernetes Operator[7] 來提供。Operator 是 Kubernetes 的特定於應用程式的擴充套件，它對部署和操作自動化進行編碼，同時向使用者公開簡單的介面。高階的資料庫 Operator 帶來了以下好處：

·這是一種用於部署和更新的宣告性方法，使其對 GitOps 100% 友好，非常適合任何使用 CI/CD 的公司。操作員定義的 CRD(自定義資源定義)是高階物件，通常作為簡單的 YAML 檔案介面，允許以簡單的方式部署和管理複雜的資料庫架構。

·“Day-2 Operation”[8] 自動化：部署、高可用性、備份和監控;修復、清理、重新編制索引等。操作員可以將這些操作編碼到 CRD、YAML 檔案中，以便自動執行這些操作。

·將資料庫功能外部化到第三方、知名的 Kubernetes 元件，如 Envoy Proxy;Prometheus 和 Grafana 負責監控;或 Cert Manager 用於 SSL 證書管理。資料庫 Operator 可以依賴這些元件來分離部分資料庫功能，減少使用者操作難度，因為它更熟悉更易獲得更高階的功能。正如 Goldman Sachs、Zalando 和 Flipkart 等領先公司所表現的那樣，在 Kubernetes 上執行資料庫不僅是未來，也是現在。與任何技術一樣，在部署生產工作負載之前，應該進行仔細和客觀的評估。

在 Kubernetes 2021 調查報告[9] 中發現，90% 的公司認為 Kubernetes 已經準備好了應對有狀態的工作負載。這些受訪企業中的絕大多數(70%)在生產中執行有狀態的工作負載，其中資料庫排在首位。75% 的受訪企業生產率提升兩倍甚至更高!

鑑於以上的資料和優勢，企業應該去考慮一下。在 Kubernetes 上執行資料是全面協調基礎設施的最新前沿，我相信這一轉變將為企業帶來可觀的價值。

原文：

引用參考:

Kubernetes：

CNCF 基金會：

雲原生調查報告：

Thoughtworks：

StatefulSets：

Vitess：

Kubernetes Operator：

Day-2 Operation：https://jimmysong.io/blog/what-is-day-2-operation/

Kubernetes 2021 調查報告：