摘要：和簡(jiǎn)介作為一個(gè)開(kāi)源的分布式數(shù)據(jù)庫(kù)產(chǎn)品，具有多副本強(qiáng)一致性的同時(shí)能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對(duì)上層業(yè)務(wù)無(wú)感知。

TiDB Operator 是 TiDB 在 Kubernetes 平臺(tái)上的自動(dòng)化部署運(yùn)維工具。目前，TiDB Operator 已正式開(kāi)源（pingcap/tidb-operator）。借助 TiDB Operator，TiDB 可以無(wú)縫運(yùn)行在公有云廠商提供的 Kubernetes 平臺(tái)上，讓 TiDB 成為真正的 Cloud-Native 數(shù)據(jù)庫(kù)。

要了解 TiDB Operator，首先需要對(duì) TiDB 和 Kubernetes 有一定了解，相信長(zhǎng)期以來(lái)一直關(guān)注 TiDB 的同學(xué)可能對(duì) TiDB 已經(jīng)比較熟悉了。本文將首先簡(jiǎn)單介紹一下 TiDB 和 Kubernetes，聊一聊為什么我們要做 TiDB Operator，然后講講如何快速體驗(yàn) TiDB Operator，以及如何參與到 TiDB Operator 項(xiàng)目中來(lái)成為 Contributor。

TiDB 作為一個(gè)開(kāi)源的分布式數(shù)據(jù)庫(kù)產(chǎn)品，具有多副本強(qiáng)一致性的同時(shí)能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對(duì)上層業(yè)務(wù)無(wú)感知。TiDB 包括三大核心組件：TiDB/TiKV/PD。?

TiDB Server：主要負(fù)責(zé) SQL 的解析器和優(yōu)化器，它相當(dāng)于計(jì)算執(zhí)行層，同時(shí)也負(fù)責(zé)客戶端接入和交互。

TiKV Server：是一套分布式的 Key-Value 存儲(chǔ)引擎，它承擔(dān)整個(gè)數(shù)據(jù)庫(kù)的存儲(chǔ)層，數(shù)據(jù)的水平擴(kuò)展和多副本高可用特性都是在這一層實(shí)現(xiàn)。

PD Server：相當(dāng)于分布式數(shù)據(jù)庫(kù)的大腦，一方面負(fù)責(zé)收集和維護(hù)數(shù)據(jù)在各個(gè) TiKV 節(jié)點(diǎn)的分布情況，另一方面 PD 承擔(dān)調(diào)度器的角色，根據(jù)數(shù)據(jù)分布狀況以及各個(gè)存儲(chǔ)節(jié)點(diǎn)的負(fù)載來(lái)采取合適的調(diào)度策略，維持整個(gè)系統(tǒng)的平衡與穩(wěn)定。

上面的這三個(gè)組件，每個(gè)角色都是一個(gè)多節(jié)點(diǎn)組成的集群，所以最終 TiDB 的架構(gòu)看起來(lái)是這樣的。

Kubernetes 最早是作為一個(gè)純粹的容器編排系統(tǒng)而誕生的，用戶部署好 Kubernetes 集群之后，直接使用其內(nèi)置的各種功能部署應(yīng)用服務(wù)。?

由于這個(gè) PaaS 平臺(tái)使用起來(lái)非常便利，吸引了很多用戶，不同用戶也提出了各種不同的需求。有些特性需求 Kubernetes 直接在其核心代碼里面實(shí)現(xiàn)了，但是有些特性并不適合合并到主干分支。

為滿足這類需求，Kubernetes 開(kāi)放出一些 API 供用戶自己擴(kuò)展，實(shí)現(xiàn)自己的需求。當(dāng)前 Kubernetes 內(nèi)部的 API 變得越來(lái)越開(kāi)放，使其更像是一個(gè)跑在云上的操作系統(tǒng)。用戶可以把它當(dāng)作一套云的 SDK 或 Framework 來(lái)使用，而且可以很方便地開(kāi)發(fā)組件來(lái)擴(kuò)展?jié)M足自己的業(yè)務(wù)需求。對(duì)有狀態(tài)服務(wù)的支持就是一個(gè)很有代表性的例子。

第一，使用傳統(tǒng)的自動(dòng)化工具帶來(lái)了很高的部署和運(yùn)維成本。TiDB 的分層架構(gòu)對(duì)于分布式系統(tǒng)是比較常見(jiàn)的，各個(gè)組件都可以根據(jù)業(yè)務(wù)需求獨(dú)立水平伸縮，并且 TiKV 和 TiDB 都可以獨(dú)立使用。比如，在 TiKV 之上可以構(gòu)建兼容 Redis 協(xié)議的 KV 數(shù)據(jù)庫(kù)，而 TiDB 也可以對(duì)接 LevelDB 這樣的 KV 存儲(chǔ)引擎。

但是，這種多組件的分布式系統(tǒng)增加了手工部署和運(yùn)維的成本。一些傳統(tǒng)的自動(dòng)化部署和運(yùn)維工具如 Puppet/Chef/SaltStack/Ansible，由于缺乏全局狀態(tài)管理，不能及時(shí)對(duì)各種異常情況做自動(dòng)故障轉(zhuǎn)移，并且很難發(fā)揮分布式系統(tǒng)的彈性伸縮能力。其中有些還需要寫(xiě)大量的 DSL 甚至與 Shell 腳本一起混合使用，可移植性較差，維護(hù)成本比較高。

第二，在云時(shí)代，容器成為應(yīng)用分發(fā)部署的基本單位，而谷歌基于內(nèi)部使用數(shù)十年的容器編排系統(tǒng) Borg 經(jīng)驗(yàn)推出的開(kāi)源容器編排系統(tǒng) Kubernetes 成為當(dāng)前容器編排技術(shù)事實(shí)上的標(biāo)準(zhǔn)。如今各大云廠商都開(kāi)始提供托管的 Kubernetes 集群，部署在 Kubernetes 平臺(tái)的應(yīng)用可以不用綁定在特定云平臺(tái)，輕松實(shí)現(xiàn)在各種云平臺(tái)之間的遷移，其容器化打包和發(fā)布方式也解決了對(duì)操作系統(tǒng)環(huán)境的依賴。

Kubernetes 項(xiàng)目最早期只支持無(wú)狀態(tài)服務(wù)（Stateless Service）的管理。無(wú)狀態(tài)服務(wù)通過(guò) ReplicationController 定義多個(gè)副本，由 Kubernetes 調(diào)度器來(lái)決定在不同節(jié)點(diǎn)上啟動(dòng)多個(gè) Pod，實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。對(duì)于無(wú)狀態(tài)服務(wù)，多個(gè)副本對(duì)應(yīng)的 Pod 是等價(jià)的，所以在節(jié)點(diǎn)出現(xiàn)故障時(shí)，在新節(jié)點(diǎn)上啟動(dòng)一個(gè) Pod 與失效的 Pod 是等價(jià)的，不會(huì)涉及狀態(tài)遷移問(wèn)題，因而管理非常簡(jiǎn)單。?

但是對(duì)于有狀態(tài)服務(wù)（Stateful Service），由于需要將數(shù)據(jù)持久化到磁盤，使得不同 Pod 之間不能再認(rèn)為成等價(jià)，也就不能再像無(wú)狀態(tài)服務(wù)那樣隨意進(jìn)行調(diào)度遷移。

Kubernetes v1.3 版本提出 PetSet 的概念，用來(lái)管理有狀態(tài)服務(wù)并于 v1.5 將其更名為 StatefulSet。StatefulSet 明確定義一組 Pod 中每個(gè)的身份，啟動(dòng)和升級(jí)都按特定順序來(lái)操作。另外使用持久化卷存儲(chǔ)（PersistentVolume）來(lái)作為存儲(chǔ)數(shù)據(jù)的載體，當(dāng)節(jié)點(diǎn)失效 Pod 需要遷移時(shí)，對(duì)應(yīng)的 PV 也會(huì)重新掛載，而 PV 的底層依托于分布式文件系統(tǒng)，所以 Pod 仍然能訪問(wèn)到之前的數(shù)據(jù)。同時(shí) Pod 在發(fā)生遷移時(shí)，其網(wǎng)絡(luò)身份例如 IP 地址是會(huì)發(fā)生變化的，很多分布式系統(tǒng)不能接受這種情況。所以 StatefulSet 在遷移 Pod 時(shí)可以通過(guò)綁定域名的方式來(lái)保證 Pod 在集群中網(wǎng)絡(luò)身份不發(fā)生變化。

但是由于有狀態(tài)服務(wù)的特殊性，當(dāng)節(jié)點(diǎn)出現(xiàn)異常時(shí)，出于數(shù)據(jù)安全性考慮，Kubernetes 并不會(huì)像無(wú)狀態(tài)服務(wù)那樣自動(dòng)做故障轉(zhuǎn)移。盡管網(wǎng)絡(luò)存儲(chǔ)能掛載到不同的節(jié)點(diǎn)上供其上的 Pod 使用，但是如果出現(xiàn)節(jié)點(diǎn)故障時(shí)，簡(jiǎn)單粗暴地將網(wǎng)絡(luò) PV 掛載到其它節(jié)點(diǎn)上是比較危險(xiǎn)的。

Kubernetes 判斷節(jié)點(diǎn)故障是基于部署在每個(gè)節(jié)點(diǎn)上的 Kubelet 服務(wù)是否能正常上報(bào)節(jié)點(diǎn)狀態(tài)，Kubelet 能否正常工作與用戶應(yīng)用并沒(méi)有必然聯(lián)系，在一些特殊情況下，Kubelet 服務(wù)進(jìn)程可能無(wú)法正常啟動(dòng)，但是節(jié)點(diǎn)上的業(yè)務(wù)容器還在運(yùn)行，將 PV 再掛載到其它節(jié)點(diǎn)可能會(huì)出現(xiàn)雙寫(xiě)問(wèn)題。

為了在 Kubernetes 上部署和管理 TiDB 這種有狀態(tài)的服務(wù)，我們需要擴(kuò)展 StatefulSet 的功能。TiDB Operator 正是基于 Kubernetes 內(nèi)置的 StatefulSet 開(kāi)發(fā)的 TiDB 集群管理和運(yùn)維工具。

Kubernetes 直到 v1.7 才試驗(yàn)性引入本地 PV，在這之前只有網(wǎng)絡(luò) PV，TiKV 自身在存儲(chǔ)數(shù)據(jù)時(shí)就是多副本的，網(wǎng)絡(luò) PV 的多副本會(huì)增加數(shù)據(jù)冗余，降低 TiDB 的性能。在這之前我們基于 Kubernetes 內(nèi)置的 hostPath volume 實(shí)現(xiàn)了本地 PV 滿足 TiKV 對(duì)磁盤 IO 的要求。官方本地 PV 方案直到最近的 Kubernetes v1.10 才相對(duì)穩(wěn)定地支持調(diào)度功能，滿足用戶對(duì)本地 PV 的需求。為了降低用戶的使用和管理成本并且擁抱 Kubernetes 開(kāi)源社區(qū)，我們又重新基于官方的本地 PV 方案實(shí)現(xiàn)了對(duì)數(shù)據(jù)的管理。

Operator 本質(zhì)上是 Kubernetes 的控制器（Controller），其核心思想是用戶給定一個(gè) Spec 描述文件，Controller 根據(jù) Spec 的變化，在 Kubernetes 集群中創(chuàng)建對(duì)應(yīng)資源，并且不斷調(diào)整資源使其狀態(tài)滿足用戶預(yù)期的 Spec。

上圖是 TiDB Operator 工作流程原理圖，其中 TidbCluster 是通過(guò) CRD（Custom Resource Definition）擴(kuò)展的內(nèi)置資源類型：

用戶通過(guò) Helm 往 Kubernetes API Server 創(chuàng)建或更新 TidbCluster 對(duì)象。

TiDB Operator 通過(guò) watch API Server 中的 TidbCluster 對(duì)象創(chuàng)建更新或刪除，維護(hù) PD/TiKV/TiDB StatefulSet, Service 和 Deployment 對(duì)象更新。

Kubernetes 根據(jù) StatefulSet, Service 和 Deployment 對(duì)象創(chuàng)建更新或刪除對(duì)應(yīng)的容器和服務(wù)。

在第 2 步中，TiDB Operator 在更新 StatefulSet 等對(duì)象時(shí)會(huì)參考 PD API 給出的集群狀態(tài)來(lái)做出 TiDB 集群的運(yùn)維處理。通過(guò) TiDB Operator 和 Kubernetes 的動(dòng)態(tài)調(diào)度處理，創(chuàng)建出符合用戶預(yù)期的 TiDB 集群。

TiDB Operator 需要運(yùn)行在 Kubernetes v1.10 及以上版本。TiDB Operator 和 TiDB 集群的部署和管理是通過(guò) Kubernetes 平臺(tái)上的包管理工具 Helm 實(shí)現(xiàn)的。運(yùn)行 TiDB Operator 前請(qǐng)確保 Helm 已經(jīng)正確安裝在 Kubernetes 集群里。?

如果沒(méi)有 Kubernetes 集群，可以通過(guò) TiDB Operator 提供的腳本快速在本地啟動(dòng)一個(gè)多節(jié)點(diǎn)的 Kubernetes 集群：

git clone https://github.com/pingcap/tidb-operator
cd tidb-operator
NUM_NODES=3    # the default node number is 2
KUBE_REPO_PREFIX=uhub.ucloud.cn/pingcap manifests/local-dind/dind-cluster-v1.10.sh up

等 Kubernetes 集群準(zhǔn)備好，就可以通過(guò) Helm 和 Kubectl 安裝部署 TiDB Operator 和 TiDB 集群了。

安裝 TiDB Operator

kubectl apply -f manifests/crd.yaml
helm install charts/tidb-operator --name=tidb-operator --namespace=tidb-    admin

部署 TiDB 集群

helm install charts/tidb-cluster --name=demo-tidb --namespace=tidb --set clusterName=demo

集群默認(rèn)使用 local-storage 作為 PD 和 TiKV 的數(shù)據(jù)存儲(chǔ)，如果想使用其它持久化存儲(chǔ)，需要修改 charts/tidb-cluster/values.yaml 里面的 storageClassName。

TiDB Operator 讓 TiDB 成為真正意義上的 Cloud-Native 數(shù)據(jù)庫(kù)，開(kāi)源只是一個(gè)起點(diǎn)，需要 TiDB 社區(qū)和 Kubernetes 社區(qū)的共同參與。?

大家在使用過(guò)程發(fā)現(xiàn) bug 或缺失什么功能，都可以直接在 GitHub 上面提 issue 或 PR，一起參與討論。要想成為 Contributor 具體可以參考 這個(gè)文檔。

作者: 鄧栓