本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
如何在 Kubernetes 中為 TPR 整合 RollingUpdate 策略
使用 Kubernetes,可以輕鬆管理和擴充套件無狀態應用程式,如 Web 應用和 API 服務。迄今為止,所有關於 Kubernetes 的討論幾乎都圍繞著微服務和無狀態應用程式。
隨著基於容器的微服務架構的普及,部署和管理關係型資料庫管理系統 (RDBMS) 的需求越來越強烈。RDBMS 需要有經驗的資料庫特定知識才能正確地擴充套件、升級和重新配置,同時防止資料丟失或不可用。
例如,MySQL(最流行的開源 RDBMS)需要將資料儲存在持久且專屬於每個 MySQL 資料庫儲存的檔案中。每個 MySQL 資料庫都需要獨立區分;另一個更復雜的情況是在叢集中,需要將叢集中的一個 MySQL 資料庫區分為不同的角色,例如主庫、從庫或分片。在機器故障時替換資料庫節點,實現高可用性和零資料丟失也很困難。
利用強大的 Kubernetes API 擴充套件機制,我們可以將 RDBMS 領域知識編碼到名為 WQ-RDS 的軟體中,它像內建資源一樣執行在 Kubernetes 之上。
WQ-RDS 利用 Kubernetes 原生資源和控制器,提供了一系列企業級功能,並帶來了顯著可靠的方式來自動化耗時的操作任務,如資料庫設定、補丁備份和設定高可用叢集。WQ-RDS 支援主流版本的 Oracle 和 MySQL(相容 MariaDB)。
讓我們演示如何管理 MySQL 分片叢集。
MySQL 分片叢集
MySQL 分片叢集是一種橫向擴充套件的資料庫架構。基於雜湊演算法,該架構將資料分佈在叢集的所有分片中。分片對客戶端完全透明:代理能夠連線到叢集中的任何分片,並直接向正確的碎片發出查詢。
| ----- |
| |
|
注意:每個分片對應一個 MySQL 例項。目前,WQ-RDS 最多支援 64 個分片。
|
所有分片均使用 Kubernetes Statefulset、Services、Storage Class、configmap、secrets 和 MySQL 構建。WQ-RDS 管理分片叢集的整個生命週期。分片叢集的優點顯而易見:
- 橫向擴充套件每秒查詢次數 (QPS) 和每秒事務次數 (TPS)
- 橫向擴充套件儲存容量:透過將資料分佈到多個節點來獲得更多儲存空間
建立 MySQL 分片叢集
讓我們建立一個包含 8 個分片的 Kubernetes 叢集。
kubectl create -f mysqlshardingcluster.yaml
接下來,建立一個包含 8 個分片的 MySQL 分片叢集。
- TPR:MysqlCluster 和 MysqlDatabase
[root@k8s-master ~]# kubectl get mysqlcluster
NAME KIND
clustershard-c MysqlCluster.v1.mysql.orain.com
從 clustershard-c0 到 clustershard-c7 的 MysqlDatabase 屬於 MysqlCluster clustershard-c。
[root@k8s-master ~]# kubectl get mysqldatabase
NAME KIND
clustershard-c0 MysqlDatabase.v1.mysql.orain.com
clustershard-c1 MysqlDatabase.v1.mysql.orain.com
clustershard-c2 MysqlDatabase.v1.mysql.orain.com
clustershard-c3 MysqlDatabase.v1.mysql.orain.com
clustershard-c4 MysqlDatabase.v1.mysql.orain.com
clustershard-c5 MysqlDatabase.v1.mysql.orain.com
clustershard-c6 MysqlDatabase.v1.mysql.orain.com
clustershard-c7 MysqlDatabase.v1.mysql.orain.com
接下來,我們看看兩個主要功能:高可用性和滾動更新策略。
為了演示,我們首先執行 sysbench 在叢集上生成一些負載。在這個例子中,QPS 指標由 MySQL 匯出生成,由 Prometheus 收集,並在 Grafana 中視覺化。
功能:高可用性
WQ-RDS 處理 MySQL 例項崩潰,同時保護資料不丟失。
當殺死 clustershard-c0 時,WQ-RDS 將檢測到 clustershard-c0 不可用,並在故障機器上替換 clustershard-c0,平均耗時約 35 秒。
同時實現零資料丟失。
功能:滾動更新策略
MySQL 分片叢集不僅帶來了強大的可擴充套件性,也帶來了一定程度的維護複雜性。例如,當更新 MySQL 配置(如 innodb_buffer_pool_size)時,DBA 必須執行許多步驟:
1. 應用更改時間。
2. 停用客戶端訪問資料庫代理。
3. 開始滾動升級。
滾動升級需要按順序進行,是過程中最嚴苛的步驟。在之前的 MySQL 例項更新執行並準備就緒之前,不能繼續滾動升級。
4. 驗證叢集。
5. 啟用客戶端訪問資料庫代理。
滾動升級可能出現的問題包括:
- 節點重啟
- MySQL 例項重啟
- 人為錯誤 相反,WQ-RDS 使 DBA 能夠自動執行滾動升級。
Kubernetes 中的 StatefulSet 滾動更新
Kubernetes 1.7 包含一個主要功能,為 StatefulSet 添加了自動化更新,並支援一系列更新策略,包括滾動更新。
注意: 有關 StatefulSet 滾動更新 的更多資訊,請參閱 Kubernetes 文件。
由於 TPR(目前為 CRD)不支援滾動升級策略,我們需要將滾動更新策略整合到 WQ-RDS 中。幸運的是,Kubernetes 倉庫 是一個學習的寶庫。在實現過程中,有一些點值得分享:
**MySQL 分片叢集已**更改:每個 StatefulSet 都有其對應的 ControllerRevision,記錄所有修訂資料和順序(如 git)。每當 StatefulSet 同步時,StatefulSet Controller 將首先將其 spec 與最新的對應 ControllerRevision 資料進行比較(類似於 git diff)。如果發生更改,將生成一個新的 ControllerRevision,修訂號將增加 1。WQ-RDS 借鑑了這一過程,MySQL 分片叢集物件將記錄 ControllerRevision 中的所有修訂和順序。
**如何初始化 MySQL 分片叢集以滿足請求的**副本:Statefulset 支援兩種 Pod 管理策略:Parallel 和 OrderedReady。由於 MySQL 分片叢集的初始過程不需要有序建立,我們使用 Parallel 策略來加速叢集的初始化。
**如何執行滾動**升級:Statefulset 以嚴格遞減的順序重新建立 Pod。不同之處在於,WQ-RDS 更新分片而不是重新建立它們,如下圖所示:
滾動更新何時結束:Kubernetes 明確發出終止訊號。當一個集合的所有 Pod 都已更新到 updateRevision 時,滾動更新完成。狀態的 currentRevision 設定為 updateRevision,其 updateRevision 設定為空字串。狀態的 currentReplicas 設定為 updateReplicas,其 updateReplicas 設定為 0。
WQ-RDS 中的控制器修訂
修訂資訊儲存在 MysqlCluster.Status 中,與 Statefulset.Status 沒有區別。
root@k8s-master ~]# kubectl get mysqlcluster -o yaml clustershard-c
apiVersion: v1
items:
\- apiVersion: mysql.orain.com/v1
kind: MysqlCluster
metadata:
creationTimestamp: 2017-10-20T08:19:41Z
labels:
AppName: clustershard-crm
Createdby: orain.com
DBType: MySQL
name: clustershard-c
namespace: default
resourceVersion: "415852"
uid: 6bb089bb-b56f-11e7-ae02-525400e717a6
spec:
dbresourcespec:
limitedcpu: 1200m
limitedmemory: 400Mi
requestcpu: 1000m
requestmemory: 400Mi
status:
currentReplicas: 8
currentRevision: clustershard-c-648d878965
replicas: 8
updateRevision: clustershard-c-648d878965
kind: List
示例:執行滾動升級
最後,我們現在可以更新“clustershard-c”,將配置“innodb_buffer_pool_size”從 6GB 更新到 7GB 並重啟。
此過程需要 480 秒。
升級呈單調遞減趨勢
結論
滾動升級對資料庫管理員來說意義重大。它提供了一種更有效的資料庫操作方式。