k8s 是當前主流的容器編排服務，它主要解決「集群環境」下「容器化應用」的「管理問題」，主要包括如下幾方面：
?
? 容器集群管理

• 編排?
• 調度?
• 訪問?

? 基礎設施管理

• 計算資源?
• 網絡資源?
• 存儲資源?
  ?

k8s 的強大依賴於它良好的設計理念和抽象，吸引了越來越多的開發者投入到 k8s 社區，把 k8s 作為基礎設施運行服務的公司也逐步增多。
?
在設計理念方面，k8s 只有 APIServer 與 etcd (存儲) 通信，其他組件在內存中維護狀態，通過 APIServer 持久化數據。管理組件動作的觸發是 level-based 而非 edge-based，並根據資源「當前狀態」和「期望狀態」進行相應動作。k8s 采用分層設計，基於各類抽象接口、由不同的插件滿足不同的需求。

?

MySQL on k8s

?
應用的設計和開發不能脫離業務需求，對 MySQL 應用的需求如下：

1. 數據高可靠?
2. 服務高可用?
3. 易使用?
4. 易運維?
   ?
   為了實現上述需求，需要依靠 k8s 和應用兩方面協同工作，即開發基於 k8s 高可靠應用，既需要 k8s 相關的知識，也需要應用領域內的知識。
   ?
   下述將根據上述需求來分析相應的解決方案。

1.數據高可靠

數據的高可靠一般依賴於這幾方面：

• 冗余?
• 備份/恢復?
  ?
  我們使用 Percona XtraDB Cluster 作為 MySQL 集群方案，它是 multi-master 的 MySQL 架構，實例間基於 Galera Replication 技術實現數據的實時同步。這種集群方案可以避免 master-slave 架構的集群在主從切換時可能出現的數據丟失現象，進一步提升數據的可靠性。
  
  ?
  ?
  ?
  ??備份方面，我們使用 xtrabackup 作為備份/恢復方案，實現數據的熱備份，在備份期間不影響用戶對集群的正常訪問。
  ?
  提供「定時備份」的同時，我們也提供「手動備份」，以滿足業務對備份數據的需求。
  ?
  2.服務高可用
  ?
  這裏從「數據鏈路」和「控制鏈路」兩個角度來分析。
  ?
  「數據鏈路」是用戶訪問 MySQL 服務的鏈路，我們使用 3 主節點的 MySQL 集群方案，通過 TLB (七牛自研的四層負載均衡服務) 對用戶提供訪問入口。TLB 既實現了訪問層面對 MySQL 實例的負載均衡，又實現了對服務的健康檢測，自動摘除異常的節點，同時在節點恢復時自動加入該節點。如下圖：
  ?
  
  ??基於上述 MySQL 集群方案和 TLB，一個或兩個節點的異常不會影響用戶對 MySQL 集群的正常訪問，確保 MySQL 服務的高可用。
  ?
  「控制鏈路」是 MySQL 集群的管理鏈路，分為兩個層面：
• 全局控制管理?
• 每個 MySQL 集群的控制管理

全局控制管理主要負責「創建/刪除集群」「管理所有 MySQL 集群狀態」等，基於 Operator 的理念來實現。每個 MySQL 集群有一個控制器，負責該集群的「任務調度」「健康檢測」「故障自動處理」等。
?
這種拆解將每個集群的管理工作下放到每個集群中，降低了集群間控制鏈路的相互幹擾，同時又減輕了全局控制器的壓力。
如下圖：
?

??這裏簡單介紹下 Operator 的理念和實現。
?
Operator 是 CoreOS 公司提出的一個概念，用來創建、配置、管理復雜應用，由兩部分構成：
?

Resource

• 自定義資源?
• 為用戶提供一種簡單的方式描述對服務的期望?
  ?Controller
• 創建 Resource?
• 監聽 Resource 的變更，用來實現用戶對服務的期望?
  ?

工作流程如下圖所示：?
?

?
??即：

1. 註冊 CR (CustomResource) 資源?
2. 監聽 CR objects 的變更?
3. 用戶對該 CR 資源進行 CREATE/UPDATE/DELETE 操作?
4. 觸發相應的 handler 進行處理?
   ?
   我們根據實踐，對開發 Operator 做了如下抽象：
   ??
   
   ?
   CR 抽象為這樣的結構體：
   ??
   
   ?
   對 CR ADD/UPDATE/DELETE events 的操作，抽象為如下接口：
   ??
   ?
   ?
   在上述抽象的基礎上，七牛提供了一個簡單的 Operator 框架，透明化了創建 CR、監聽 CR events 等的操作，將開發 Operator 的工作變的更為簡單。?
   ?
   我們開發了 MySQL Operator 和 MySQL Data Operator，分別用來負責「創建/刪除集群」和「手動備份/恢復」工作。
   ?
   由於每個 MySQL 集群會有多種類型的任務邏輯，如「數據備份」「數據恢復」「健康檢測」「故障自動處理」等，這些邏輯的並發執行可能會引發異常，故需要任務調度器來協調任務的執行，Controller 起到的就是這方面的作用：
   ?
   
   ??
   通過 Controller 和各類 Worker，每個 MySQL 集群實現了自運維。
   ?
   在「健康檢測」方面，我們實現了兩種機制：
   ? 被動檢測?
   ? 主動檢測???
   「被動檢測」是每個 MySQL 實例向 Controller 匯報健康狀態，「主動檢測」是由 Controller 請求每個 MySQL 實例的健康狀態。這兩種機制相互補充，提升健康檢測的可靠度和及時性。
   ?
   對於健康檢測的數據，Controller 和 Operator 均會使用，如下圖所示：
   ??
   
   ?
   Controller 使用健康檢測數據是為了及時發現 MySQL 集群的異常，並做相應的故障處理，故需要準確、及時的健康狀態信息。它在內存中維護所有 MySQL 實例的狀態，根據「主動檢測」和「被動檢測」的結果更新實例狀態並做相應的處理。
   ?
   Operator 使用健康檢測數據是為了向外界反映 MySQL 集群的運行情況，並在 Controller 異常時介入到 MySQL 集群的故障處理中。
   ?
   在實踐中，由於健康檢測的頻率相對較高，會產生大量的健康狀態，若每個健康狀態都被持久化，那麽 Operator 和 APIServer 均會承受巨大的訪問壓力。由於這些健康狀態僅最新的數據有意義，故在 Controller 層面將待向 Operator 匯報的健康狀態插入到一個有限容量的 Queue 中，當 Queue 滿時，舊的健康狀態將被丟棄。
   ?
   當 Controller 檢測到 MySQL 集群異常時，將會進行故障自動處理。
   ?
   先定義故障處理原則：
   ? 不丟數據?
   ? 盡可能不影響可用性?
   ? 對於已知的、能夠處理的故障進行自動處理?
   ? 對於未知的、不能夠處理的故障不自動處理，人工介入???
   在故障處理中，有這些關鍵問題：?
   ? 故障類型有哪些?
   ? 如何及時檢測和感知故障?
   ? 當前是否出現了故障?
   ? 出現的故障是哪種故障類型?
   ? 如何進行處理???
   針對上述關鍵問題，我們定義了 3 種級別的集群狀態：
   ?

   Green
   ? 可以對外服務?
   ?運行節點數量符合預期?
   Yellow
   ?可以對外服務?
   ?運行節點數量不符合預期?
   Red
   ?不能對外服務?
   ?

同時針對每個 mysqld 節點，定義了如下狀態：
?

Green
? 節點在運行?
? 節點在 MySQL 集群中?
Yellow?
? 節點在運行?
? 節點不在 MySQL 集群中?
Red-clean?
? 節點優雅退出?
Red-unclean?
? 節點非優雅退出?
Unknown?
? 節點狀態不可知?
?

Controller 收集到所有 MySQL 節點狀態後，會根據這些節點的狀態推算 MySQL 集群的狀態。當檢測到 MySQL 集群狀態不是 Green 時，會觸發「故障處理」邏輯，該邏輯會根據已知的故障處理方案進行處理。若該故障類型未知，人工介入處理。整個流程如下圖：
?

?
??由於每種應用的故障場景和處理方案不同，這裏不再敘述具體的處理方法。
?
3.易使用
?
我們基於 Operator 的理念實現了高可靠的 MySQL 服務，為用戶定義了兩類資源，即 QiniuMySQL 和 QiniuMySQLData。前者描述用戶對 MySQL 集群的配置，後者描述手動備份/恢復數據的任務，這裏以 QiniuMySQL 為例。
?
用戶可通過如下簡單的 yaml 文件觸發創建 MySQL 集群的操作：
??
?
?
在集群創建好後，用戶可通過該 CR object 的 status 字段獲取集群狀態：
??

?
這裏再引入一個概念：Helm。?
?
Helm 是為 k8s 提供的包管理工具，通過將應用打包為 Chart，標準化了 k8s 應用的交付、部署和使用流程。
?
Chart 本質上是 k8s yaml 文件和參數文件的集合，這樣可以通過一個 Chart 文件進行應用的交付。Helm 通過操作 Chart，可一鍵部署、升級應用。
?
由於篇幅原因及 Helm 操作的通用性，這裏不再描述具體的使用過程。
?
4.易運維
?
除了上述實現的「健康檢測」「故障自動處理」以及通過 Helm 管理應用的交付、部署，在運維過程中還有如下問題需要考慮：
? 監控/告警?
? 日誌管理?
?
我們通過 prometheus + grafana 做監控/告警服務，服務將 metric 數據以 HTTP API 暴露給 prometheus，由 prometheus server 定時拉取。開發人員在 grafana 上將 prometheus 中的監控數據可視化，根據對監控圖表和應用的把握，在監控圖中設置告警線，由 grafana 實現告警。
?
這種先可視化監控後告警的方式，極大程度上增強了我們對應用運行特征的把握，明確需要關註的指標和告警線，降低無效告警的產生量。
?
在開發中，我們通過 gRPC 實現服務間的通信。在 gRPC 生態系統中，有個名為 go-grpc-prometheus 的開源項目，通過在服務中插入幾行簡單的代碼，就可以實現對 gRPC server 所有 rpc 請求的監控打點。
?
對於容器化服務，日誌管理包括「日誌收集」和「日誌滾動」兩方面維度。
?
我們將服務日誌打到 syslog 中，再通過某種手段將 syslog 日誌轉入到容器的 stdout/stderr 中，方便外部采用常規的方式進行日誌收集。同時，在 syslog 中配置了 logrotate 功能，自動進行日誌的滾動操作，避免日誌占滿容器磁盤空間引發服務異常。
?
為了提升開發效率，我們使用?https://github.com/phusion/baseimage-docker?作為基礎鏡像，其中內置了 syslog 和 lograte 服務，應用只關心把日誌打入 syslog 即可，不用關心日誌的收集和日誌滾動問題。
?

小結

?
通過上述描述，完整的 MySQL 應用架構如下：
?

?
??在開發基於 k8s 的高可靠 MySQL 應用過程中，隨著對 k8s 和 MySQL 理解的深入，我們不斷進行抽象，逐步將如下通用的邏輯和最佳實踐以模塊的方式實現：

• Operator 開發框架?
• 健康檢測服務?
• 故障自動處理服務?
• 任務調度服務?
• 配置管理服務?
• 監控服務?
• 日誌服務?
• etc.???
  隨著這些通用邏輯和最佳實踐的模塊化，在開發新的基於 k8s 的高可靠應用時，開發者可像「搭積木」一樣將與 k8s 相關的交互快速搭建起來，這樣的應用由於已經運用了最佳實踐，從一開始就具備高可靠的特性。同時，開發者可將註意力從 k8s 陡峭的學習曲線轉移到應用自身領域，從應用自身加強服務的可靠性。
  ?

牛人說

?
牛人說專欄致力於技術人思想的發現，其中包括技術實踐、技術幹貨、技術見解、成長心得，還有一切值得被發現的技術內容。我們希望集合最優秀的技術人，挖掘獨到、犀利、具有時代感的聲音。
?
?

如何基於 k8s 開發高可靠服務？容器雲牛人有話說