如何在 Kubernetes 中為 TPR 整合 RollingUpdate 策略

有了 Kubernetes，可以輕鬆管理和擴展無狀態應用程式，例如網頁應用程式和 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 分片叢集是一種橫向擴展資料庫架構。基於雜湊演算法，該架構將資料分佈在叢集的所有分片中。分片對於用戶端完全透明：Proxy 能夠連接到叢集中的任何分片，並直接向正確的分片發出查詢。

| ----- | | | |

注意：每個分片對應一個 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

接下來，讓我們看看兩個主要功能：高可用性和 RollingUpdate 策略。

為了示範，我們將首先運行 sysbench 以在叢集上產生一些負載。在本範例中，QPS 指標由 MySQL 匯出產生，由 Prometheus 收集，並在 Grafana 中視覺化。

功能：高可用性

WQ-RDS 處理 MySQL 實例崩潰，同時防止資料遺失。

當終止 clustershard-c0 時，WQ-RDS 將偵測到 clustershard-c0 不可用，並在故障機器上更換 clustershard-c0，平均耗時約 35 秒。

同時實現零資料遺失。

功能：RollingUpdate 策略

MySQL 分片叢集不僅為我們帶來了強大的可擴展性，還帶來了一些維護複雜性。例如，當更新 MySQL 組態（如 innodb_buffer_pool_size）時，DBA 必須執行多個步驟

1. 應用變更時間。
2. 停用用戶端對資料庫 Proxy 的存取。
3. 開始滾動升級。

滾動升級需要按順序進行，並且是該過程中要求最高的步驟。在 MySQL 實例的先前更新正在運行並準備就緒之前，無法繼續滾動升級。

4. 驗證叢集。
5. 啟用用戶端對資料庫 Proxy 的存取。

滾動升級可能存在的問題包括

• 節點重新啟動
• MySQL 實例重新啟動
• 人為錯誤 相反，WQ-RDS 使 DBA 能夠自動執行滾動升級。

Kubernetes 中的 StatefulSet RollingUpdate

Kubernetes 1.7 包含一個主要功能，該功能為 StatefulSet 新增了自動更新，並支援一系列更新策略，包括滾動更新。

注意： 有關 StatefulSet RollingUpdate 的更多資訊，請參閱 Kubernetes 文件。

由於 TPR（目前為 CRD）不支援滾動升級策略，因此我們需要將 RollingUpdate 策略整合到 WQ-RDS 中。幸運的是，Kubernetes repo 是學習的寶庫。在實作過程中，有一些要分享的要點

• **MySQL 分片叢集已**變更：每個 StatefulSet 都有其對應的 ControllerRevision，它記錄所有修訂資料和順序（如 git）。每當 StatefulSet 同步時，StatefulSet Controller 將首先將其規格與最新的對應 ControllerRevision 資料進行比較（類似於 git diff）。如果發生變更，將產生新的 ControllerrRevision，並且修訂號將遞增 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 中的 Controller 修訂

修訂資訊儲存在 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 秒。

升級以單調遞減的方式進行

結論

RollingUpgrade 對資料庫管理員意義重大。它提供了一種更有效的方式來操作資料庫。

• ←上一篇
下一篇→