容器叢集管理
- 編排
- 排程
- 訪問 基礎設施管理
- 計算資源
- 網路資源
- 儲存資源 k8s 的強大依賴於它良好的設計理念和抽象，吸引了越來越多的開發者投入到 k8s 社群，把 k8s 作為基礎設施執行服務的公司也逐步增多。
在設計理念方面，k8s 只有 APIServer 與 etcd (儲存) 通訊，其他元件在記憶體中維護狀態，通過 APIServer 持久化資料。管理元件動作的觸發是 level-based 而非 edge-based，並根據資源「當前狀態」和「期望狀態」進行相應動作。k8s 採用分層設計，基於各類抽象介面、由不同的外掛滿足不同的需求。
在抽象方面，不同的 workload 服務於不同的應用，如針對無狀態應用的 Deployment、針對有狀態應用的 StatefulSet 等。在訪問管理方面，Service 解耦了叢集內部服務訪問方和提供者，Ingress 提供了叢集外部到叢集內部的訪問管理。
k8s 雖然有良好的設計理念和抽象，但陡峭的學習曲線和不完善的開發資料極大增加了應用開發的難度。
本次分享將基於筆者的開發實踐，以 MySQL on k8s 為例，描述如何基於 k8s 開發高可靠應用，儘可能抽象出最佳實踐，降低基於 k8s 開發高可靠應用的成本。
MySQL on k8s
應用的設計和開發不能脫離業務需求，對 MySQL 應用的需求如下：
- 資料高可靠
- 服務高可用
- 易使用
- 易運維
為了實現上述需求，需要依靠 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 的變更，用來實現使用者對服務的期望
工作流程如下圖所示：
即：
- 註冊 CR (CustomResource) 資源
- 監聽 CR objects 的變更
- 使用者對該 CR 資源進行 CREATE/UPDATE/DELETE 操作
- 觸發相應的 handler 進行處理
我們根據實踐，對開發 Operator 做了如下抽象：
在上述抽象的基礎上，七牛提供了一個簡單的 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 陡峭的學習曲線轉移到應用自身領域，從應用自身加強服務的可靠性。
牛人說
牛人說專欄致力於技術人思想的發現，其中包括技術實踐、技術乾貨、技術見解、成長心得，還有一切值得被發現的技術內容。我們希望集合最優秀的技術人，挖掘獨到、犀利、具有時代感的聲音。