怎么基于k8s 進(jìn)行開發(fā)高可靠服務(wù)，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡(jiǎn)單易行的方法。

成都創(chuàng)新互聯(lián)公司堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：做網(wǎng)站、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的云陽(yáng)網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

MySQL on k8s

應(yīng)用的設(shè)計(jì)和開發(fā)不能脫離業(yè)務(wù)需求，對(duì) MySQL 應(yīng)用的需求如下：

1. 數(shù)據(jù)高可靠

2. 服務(wù)高可用

3. 易使用

4. 易運(yùn)維

為了實(shí)現(xiàn)上述需求，需要依靠 k8s 和應(yīng)用兩方面協(xié)同工作，即開發(fā)基于 k8s 高可靠應(yīng)用，既需要 k8s 相關(guān)的知識(shí)，也需要應(yīng)用領(lǐng)域內(nèi)的知識(shí)。

下述將根據(jù)上述需求來分析相應(yīng)的解決方案。

1.數(shù)據(jù)高可靠

數(shù)據(jù)的高可靠一般依賴于這幾方面： ? 冗余 ? 備份/恢復(fù)

我們使用 Percona XtraDB Cluster 作為 MySQL 集群方案，它是 multi-master 的 MySQL 架構(gòu)，實(shí)例間基于 Galera Replication 技術(shù)實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)同步。這種集群方案可以避免 master-slave 架構(gòu)的集群在主從切換時(shí)可能出現(xiàn)的數(shù)據(jù)丟失現(xiàn)象，進(jìn)一步提升數(shù)據(jù)的可靠性。

??備份方面，我們使用 xtrabackup 作為備份/恢復(fù)方案，實(shí)現(xiàn)數(shù)據(jù)的熱備份，在備份期間不影響用戶對(duì)集群的正常訪問。

提供「定時(shí)備份」的同時(shí)，我們也提供「手動(dòng)備份」，以滿足業(yè)務(wù)對(duì)備份數(shù)據(jù)的需求。

2.服務(wù)高可用

這里從「數(shù)據(jù)鏈路」和「控制鏈路」兩個(gè)角度來分析。

「數(shù)據(jù)鏈路」是用戶訪問 MySQL 服務(wù)的鏈路，我們使用 3 主節(jié)點(diǎn)的 MySQL 集群方案，通過 TLB (七牛自研的四層負(fù)載均衡服務(wù)) 對(duì)用戶提供訪問入口。TLB 既實(shí)現(xiàn)了訪問層面對(duì) MySQL 實(shí)例的負(fù)載均衡，又實(shí)現(xiàn)了對(duì)服務(wù)的健康檢測(cè)，自動(dòng)摘除異常的節(jié)點(diǎn)，同時(shí)在節(jié)點(diǎn)恢復(fù)時(shí)自動(dòng)加入該節(jié)點(diǎn)。如下圖：

??基于上述 MySQL 集群方案和 TLB，一個(gè)或兩個(gè)節(jié)點(diǎn)的異常不會(huì)影響用戶對(duì) MySQL 集群的正常訪問，確保 MySQL 服務(wù)的高可用。

「控制鏈路」是 MySQL 集群的管理鏈路，分為兩個(gè)層面： ? 全局控制管理 ? 每個(gè) MySQL 集群的控制管理 全局控制管理主要負(fù)責(zé)「創(chuàng)建/刪除集群」「管理所有 MySQL 集群狀態(tài)」等，基于 Operator 的理念來實(shí)現(xiàn)。每個(gè) MySQL 集群有一個(gè)控制器，負(fù)責(zé)該集群的「任務(wù)調(diào)度」「健康檢測(cè)」「故障自動(dòng)處理」等。

這種拆解將每個(gè)集群的管理工作下放到每個(gè)集群中，降低了集群間控制鏈路的相互干擾，同時(shí)又減輕了全局控制器的壓力。 如下圖：

??這里簡(jiǎn)單介紹下 Operator 的理念和實(shí)現(xiàn)。

Operator 是 CoreOS 公司提出的一個(gè)概念，用來創(chuàng)建、配置、管理復(fù)雜應(yīng)用，由兩部分構(gòu)成：   Resource ? 自定義資源 ? 為用戶提供一種簡(jiǎn)單的方式描述對(duì)服務(wù)的期望  Controller ? 創(chuàng)建 Resource ? 監(jiān)聽 Resource 的變更，用來實(shí)現(xiàn)用戶對(duì)服務(wù)的期望

工作流程如下圖所示：

??即：

1. 注冊(cè) CR (CustomResource) 資源

2. 監(jiān)聽 CR objects 的變更

3. 用戶對(duì)該 CR 資源進(jìn)行 CREATE/UPDATE/DELETE 操作

4. 觸發(fā)相應(yīng)的 handler 進(jìn)行處理

我們根據(jù)實(shí)踐，對(duì)開發(fā) Operator 做了如下抽象：??

CR抽象為這樣的結(jié)構(gòu)體：??

對(duì) CR ADD/UPDATE/DELETE events 的操作，抽象為如下接口：??

在上述抽象的基礎(chǔ)上，七牛提供了一個(gè)簡(jiǎn)單的 Operator 框架，透明化了創(chuàng)建 CR、監(jiān)聽 CR events 等的操作，將開發(fā) Operator 的工作變的更為簡(jiǎn)單。

我們開發(fā)了 MySQL Operator 和 MySQL Data Operator，分別用來負(fù)責(zé)「創(chuàng)建/刪除集群」和「手動(dòng)備份/恢復(fù)」工作。

由于每個(gè) MySQL 集群會(huì)有多種類型的任務(wù)邏輯，如「數(shù)據(jù)備份」「數(shù)據(jù)恢復(fù)」「健康檢測(cè)」「故障自動(dòng)處理」等，這些邏輯的并發(fā)執(zhí)行可能會(huì)引發(fā)異常，故需要任務(wù)調(diào)度器來協(xié)調(diào)任務(wù)的執(zhí)行，Controller 起到的就是這方面的作用： ?

通過 Controller 和各類 Worker，每個(gè) MySQL 集群實(shí)現(xiàn)了自運(yùn)維。

在「健康檢測(cè)」方面，我們實(shí)現(xiàn)了兩種機(jī)制： ? 被動(dòng)檢測(cè) ? 主動(dòng)檢測(cè) 「被動(dòng)檢測(cè)」是每個(gè) MySQL 實(shí)例向 Controller 匯報(bào)健康狀態(tài)，「主動(dòng)檢測(cè)」是由 Controller 請(qǐng)求每個(gè) MySQL 實(shí)例的健康狀態(tài)。這兩種機(jī)制相互補(bǔ)充，提升健康檢測(cè)的可靠度和及時(shí)性。

對(duì)于健康檢測(cè)的數(shù)據(jù)，Controller 和 Operator 均會(huì)使用，如下圖所示： ??

Controller 使用健康檢測(cè)數(shù)據(jù)是為了及時(shí)發(fā)現(xiàn) MySQL 集群的異常，并做相應(yīng)的故障處理，故需要準(zhǔn)確、及時(shí)的健康狀態(tài)信息。它在內(nèi)存中維護(hù)所有 MySQL 實(shí)例的狀態(tài)，根據(jù)「主動(dòng)檢測(cè)」和「被動(dòng)檢測(cè)」的結(jié)果更新實(shí)例狀態(tài)并做相應(yīng)的處理。

Operator 使用健康檢測(cè)數(shù)據(jù)是為了向外界反映 MySQL 集群的運(yùn)行情況，并在 Controller 異常時(shí)介入到 MySQL 集群的故障處理中。

在實(shí)踐中，由于健康檢測(cè)的頻率相對(duì)較高，會(huì)產(chǎn)生大量的健康狀態(tài)，若每個(gè)健康狀態(tài)都被持久化，那么 Operator 和 APIServer 均會(huì)承受巨大的訪問壓力。由于這些健康狀態(tài)僅最新的數(shù)據(jù)有意義，故在 Controller 層面將待向 Operator 匯報(bào)的健康狀態(tài)插入到一個(gè)有限容量的 Queue 中，當(dāng) Queue 滿時(shí)，舊的健康狀態(tài)將被丟棄。

當(dāng) Controller 檢測(cè)到 MySQL 集群異常時(shí)，將會(huì)進(jìn)行故障自動(dòng)處理。

先定義故障處理原則： ? 不丟數(shù)據(jù) ? 盡可能不影響可用性 ? 對(duì)于已知的、能夠處理的故障進(jìn)行自動(dòng)處理 ? 對(duì)于未知的、不能夠處理的故障不自動(dòng)處理，人工介入 在故障處理中，有這些關(guān)鍵問題： ? 故障類型有哪些 ? 如何及時(shí)檢測(cè)和感知故障 ? 當(dāng)前是否出現(xiàn)了故障 ? 出現(xiàn)的故障是哪種故障類型 ? 如何進(jìn)行處理 針對(duì)上述關(guān)鍵問題，我們定義了 3 種級(jí)別的集群狀態(tài)：

Green ? 可以對(duì)外服務(wù) ? 運(yùn)行節(jié)點(diǎn)數(shù)量符合預(yù)期 Yellow ? 可以對(duì)外服務(wù) ? 運(yùn)行節(jié)點(diǎn)數(shù)量不符合預(yù)期 Red ? 不能對(duì)外服務(wù)

同時(shí)針對(duì)每個(gè) mysqld 節(jié)點(diǎn)，定義了如下狀態(tài)：

Green ? 節(jié)點(diǎn)在運(yùn)行 ? 節(jié)點(diǎn)在 MySQL 集群中 Yellow ? 節(jié)點(diǎn)在運(yùn)行 ? 節(jié)點(diǎn)不在 MySQL 集群中 Red-clean ? 節(jié)點(diǎn)優(yōu)雅退出 Red-unclean ? 節(jié)點(diǎn)非優(yōu)雅退出 Unknown ? 節(jié)點(diǎn)狀態(tài)不可知

Controller 收集到所有 MySQL 節(jié)點(diǎn)狀態(tài)后，會(huì)根據(jù)這些節(jié)點(diǎn)的狀態(tài)推算 MySQL 集群的狀態(tài)。當(dāng)檢測(cè)到 MySQL 集群狀態(tài)不是 Green 時(shí)，會(huì)觸發(fā)「故障處理」邏輯，該邏輯會(huì)根據(jù)已知的故障處理方案進(jìn)行處理。若該故障類型未知，人工介入處理。整個(gè)流程如下圖：

??由于每種應(yīng)用的故障場(chǎng)景和處理方案不同，這里不再敘述具體的處理方法。

3.易使用

我們基于 Operator 的理念實(shí)現(xiàn)了高可靠的 MySQL 服務(wù)，為用戶定義了兩類資源，即 QiniuMySQL 和 QiniuMySQLData。前者描述用戶對(duì) MySQL 集群的配置，后者描述手動(dòng)備份/恢復(fù)數(shù)據(jù)的任務(wù)，這里以 QiniuMySQL 為例。

用戶可通過如下簡(jiǎn)單的 yaml 文件觸發(fā)創(chuàng)建 MySQL 集群的操作：

在集群創(chuàng)建好后，用戶可通過該 CR object 的 status 字段獲取集群狀態(tài)：??

這里再引入一個(gè)概念：Helm。

Helm 是為 k8s 提供的包管理工具，通過將應(yīng)用打包為 Chart，標(biāo)準(zhǔn)化了 k8s 應(yīng)用的交付、部署和使用流程。

Chart 本質(zhì)上是 k8s yaml 文件和參數(shù)文件的集合，這樣可以通過一個(gè) Chart 文件進(jìn)行應(yīng)用的交付。Helm 通過操作 Chart，可一鍵部署、升級(jí)應(yīng)用。

由于篇幅原因及 Helm 操作的通用性，這里不再描述具體的使用過程。

4.易運(yùn)維

除了上述實(shí)現(xiàn)的「健康檢測(cè)」「故障自動(dòng)處理」以及通過 Helm 管理應(yīng)用的交付、部署，在運(yùn)維過程中還有如下問題需要考慮： ? 監(jiān)控/告警 ? 日志管理

我們通過 prometheus + grafana 做監(jiān)控/告警服務(wù)，服務(wù)將 metric 數(shù)據(jù)以 HTTP API 暴露給 prometheus，由 prometheus server 定時(shí)拉取。開發(fā)人員在 grafana 上將 prometheus 中的監(jiān)控?cái)?shù)據(jù)可視化，根據(jù)對(duì)監(jiān)控圖表和應(yīng)用的把握，在監(jiān)控圖中設(shè)置告警線，由 grafana 實(shí)現(xiàn)告警。

這種先可視化監(jiān)控后告警的方式，極大程度上增強(qiáng)了我們對(duì)應(yīng)用運(yùn)行特征的把握，明確需要關(guān)注的指標(biāo)和告警線，降低無效告警的產(chǎn)生量。

在開發(fā)中，我們通過 gRPC 實(shí)現(xiàn)服務(wù)間的通信。在 gRPC 生態(tài)系統(tǒng)中，有個(gè)名為 go-grpc-prometheus 的開源項(xiàng)目，通過在服務(wù)中插入幾行簡(jiǎn)單的代碼，就可以實(shí)現(xiàn)對(duì) gRPC server 所有 rpc 請(qǐng)求的監(jiān)控打點(diǎn)。

對(duì)于容器化服務(wù)，日志管理包括「日志收集」和「日志滾動(dòng)」兩方面維度。

我們將服務(wù)日志打到 syslog 中，再通過某種手段將 syslog 日志轉(zhuǎn)入到容器的 stdout/stderr 中，方便外部采用常規(guī)的方式進(jìn)行日志收集。同時(shí)，在 syslog 中配置了 logrotate 功能，自動(dòng)進(jìn)行日志的滾動(dòng)操作，避免日志占滿容器磁盤空間引發(fā)服務(wù)異常。

為了提升開發(fā)效率，我們使用 https://github.com/phusion/baseimage-docker 作為基礎(chǔ)鏡像，其中內(nèi)置了 syslog 和 lograte 服務(wù)，應(yīng)用只關(guān)心把日志打入 syslog 即可，不用關(guān)心日志的收集和日志滾動(dòng)問題。

小結(jié)

通過上述描述，完整的 MySQL 應(yīng)用架構(gòu)如下：

在開發(fā)基于 k8s 的高可靠 MySQL 應(yīng)用過程中，隨著對(duì) k8s 和 MySQL 理解的深入，我們不斷進(jìn)行抽象，逐步將如下通用的邏輯和最佳實(shí)踐以模塊的方式實(shí)現(xiàn)： ? Operator 開發(fā)框架 ? 健康檢測(cè)服務(wù) ? 故障自動(dòng)處理服務(wù) ? 任務(wù)調(diào)度服務(wù) ? 配置管理服務(wù) ? 監(jiān)控服務(wù) ? 日志服務(wù) ? etc.

隨著這些通用邏輯和最佳實(shí)踐的模塊化，在開發(fā)新的基于 k8s 的高可靠應(yīng)用時(shí)，開發(fā)者可像「搭積木」一樣將與 k8s 相關(guān)的交互快速搭建起來，這樣的應(yīng)用由于已經(jīng)運(yùn)用了最佳實(shí)踐，從一開始就具備高可靠的特性。同時(shí)，開發(fā)者可將注意力從 k8s 陡峭的學(xué)習(xí)曲線轉(zhuǎn)移到應(yīng)用自身領(lǐng)域，從應(yīng)用自身加強(qiáng)服務(wù)的可靠性。

關(guān)于怎么基于k8s 進(jìn)行開發(fā)高可靠服務(wù)問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。