TiDB Operator，讓 TiDB 成爲真正的 Cloud-Native 數據庫

TiDB Operator 是 TiDB 在 Kubernetes 平臺上的自動化部署運維工具。目前，TiDB Operator 已正式開源（pingcap/tidb-operator）。藉助 TiDB Operator，TiDB 能夠無縫運行在公有云廠商提供的 Kubernetes 平臺上，讓 TiDB 成爲真正的 Cloud-Native 數據庫。

要了解 TiDB Operator，首先須要對 TiDB 和 Kubernetes 有必定了解，相信長期以來一直關注 TiDB 的同窗可能對 TiDB 已經比較熟悉了。本文將首先簡單介紹一下 TiDB 和 Kubernetes，聊一聊爲何咱們要作 TiDB Operator，而後講講如何快速體驗 TiDB Operator，以及如何參與到 TiDB Operator 項目中來成爲 Contributor。

TiDB 和 Kubernetes 簡介

TiDB 做爲一個開源的分佈式數據庫產品，具備多副本強一致性的同時可以根據業務需求很是方便的進行彈性伸縮，而且擴縮容期間對上層業務無感知。TiDB 包括三大核心組件：TiDB/TiKV/PD。

• TiDB Server：主要負責 SQL 的解析器和優化器，它至關於計算執行層，同時也負責客戶端接入和交互。

• TiKV Server：是一套分佈式的 Key-Value 存儲引擎，它承擔整個數據庫的存儲層，數據的水平擴展和多副本高可用特性都是在這一層實現。

• PD Server：至關於分佈式數據庫的大腦，一方面負責收集和維護數據在各個 TiKV 節點的分佈狀況，另外一方面 PD 承擔調度器的角色，根據數據分佈情況以及各個存儲節點的負載來採起合適的調度策略，維持整個系統的平衡與穩定。

上面的這三個組件，每一個角色都是一個多節點組成的集羣，因此最終 TiDB 的架構看起來是這樣的。

Kubernetes 最先是做爲一個純粹的容器編排系統而誕生的，用戶部署好 Kubernetes 集羣以後，直接使用其內置的各類功能部署應用服務。

因爲這個 PaaS 平臺使用起來很是便利，吸引了不少用戶，不一樣用戶也提出了各類不一樣的需求。有些特性需求 Kubernetes 直接在其核心代碼裏面實現了，可是有些特性並不適合合併到主幹分支。

爲知足這類需求，Kubernetes 開放出一些 API 供用戶本身擴展，實現本身的需求。當前 Kubernetes 內部的 API 變得愈來愈開放，使其更像是一個跑在雲上的操做系統。用戶能夠把它看成一套雲的 SDK 或 Framework 來使用，並且能夠很方便地開發組件來擴展知足本身的業務需求。對有狀態服務的支持就是一個頗有表明性的例子。

爲何咱們要作 TiDB Operator

第一，使用傳統的自動化工具帶來了很高的部署和運維成本。TiDB 的分層架構對於分佈式系統是比較常見的，各個組件均可以根據業務需求獨立水平伸縮，而且 TiKV 和 TiDB 均可以獨立使用。好比，在 TiKV 之上能夠構建兼容 Redis 協議的 KV 數據庫，而 TiDB 也能夠對接 LevelDB 這樣的 KV 存儲引擎。

可是，這種多組件的分佈式系統增長了手工部署和運維的成本。一些傳統的自動化部署和運維工具如 Puppet/Chef/SaltStack/Ansible，因爲缺少全局狀態管理，不能及時對各類異常狀況作自動故障轉移，而且很難發揮分佈式系統的彈性伸縮能力。其中有些還須要寫大量的 DSL 甚至與 Shell 腳本一塊兒混合使用，可移植性較差，維護成本比較高。

第二，在雲時代，容器成爲應用分發部署的基本單位，而谷歌基於內部使用數十年的容器編排系統 Borg 經驗推出的開源容器編排系統 Kubernetes 成爲當前容器編排技術事實上的標準。現在各大雲廠商都開始提供託管的 Kubernetes 集羣，部署在 Kubernetes 平臺的應用能夠不用綁定在特定雲平臺，輕鬆實如今各類雲平臺之間的遷移，其容器化打包和發佈方式也解決了對操做系統環境的依賴。

Kubernetes 項目最先期只支持無狀態服務（Stateless Service）的管理。無狀態服務經過 ReplicationController 定義多個副本，由 Kubernetes 調度器來決定在不一樣節點上啓動多個 Pod，實現負載均衡和故障轉移。對於無狀態服務，多個副本對應的 Pod 是等價的，因此在節點出現故障時，在新節點上啓動一個 Pod 與失效的 Pod 是等價的，不會涉及狀態遷移問題，於是管理很是簡單。

可是對於有狀態服務（Stateful Service），因爲須要將數據持久化到磁盤，使得不一樣 Pod 之間不能再認爲成等價，也就不能再像無狀態服務那樣隨意進行調度遷移。

Kubernetes v1.3 版本提出 PetSet 的概念，用來管理有狀態服務並於 v1.5 將其改名爲 StatefulSet。StatefulSet 明肯定義一組 Pod 中每一個的身份，啓動和升級都按特定順序來操做。另外使用持久化卷存儲（PersistentVolume）來做爲存儲數據的載體，當節點失效 Pod 須要遷移時，對應的 PV 也會從新掛載，而 PV 的底層依託於分佈式文件系統，因此 Pod 仍然能訪問到以前的數據。同時 Pod 在發生遷移時，其網絡身份例如 IP 地址是會發生變化的，不少分佈式系統不能接受這種狀況。因此 StatefulSet 在遷移 Pod 時能夠經過綁定域名的方式來保證 Pod 在集羣中網絡身份不發生變化。

可是因爲有狀態服務的特殊性，當節點出現異常時，出於數據安全性考慮，Kubernetes 並不會像無狀態服務那樣自動作故障轉移。儘管網絡存儲能掛載到不一樣的節點上供其上的 Pod 使用，可是若是出現節點故障時，簡單粗暴地將網絡 PV 掛載到其它節點上是比較危險的。

Kubernetes 判斷節點故障是基於部署在每一個節點上的 Kubelet 服務是否能正常上報節點狀態，Kubelet 可否正常工做與用戶應用並無必然聯繫，在一些特殊狀況下，Kubelet 服務進程可能沒法正常啓動，可是節點上的業務容器還在運行，將 PV 再掛載到其它節點可能會出現雙寫問題。

爲了在 Kubernetes 上部署和管理 TiDB 這種有狀態的服務，咱們須要擴展 StatefulSet 的功能。TiDB Operator 正是基於 Kubernetes 內置的 StatefulSet 開發的 TiDB 集羣管理和運維工具。

Kubernetes 直到 v1.7 才試驗性引入本地 PV，在這以前只有網絡 PV，TiKV 自身在存儲數據時就是多副本的，網絡 PV 的多副本會增長數據冗餘，下降 TiDB 的性能。在這以前咱們基於 Kubernetes 內置的 hostPath volume 實現了本地 PV 知足 TiKV 對磁盤 IO 的要求。官方本地 PV 方案直到最近的 Kubernetes v1.10 才相對穩定地支持調度功能，知足用戶對本地 PV 的需求。爲了下降用戶的使用和管理成本而且擁抱 Kubernetes 開源社區，咱們又從新基於官方的本地 PV 方案實現了對數據的管理。

TiDB Operator 原理解析

Operator 本質上是 Kubernetes 的控制器（Controller），其核心思想是用戶給定一個 Spec 描述文件，Controller 根據 Spec 的變化，在 Kubernetes 集羣中建立對應資源，而且不斷調整資源使其狀態知足用戶預期的 Spec。

上圖是 TiDB Operator 工做流程原理圖，其中 TidbCluster 是經過 CRD（Custom Resource Definition）擴展的內置資源類型：

1. 用戶經過 Helm 往 Kubernetes API Server 建立或更新 TidbCluster 對象。

2. TiDB Operator 經過 watch API Server 中的 TidbCluster 對象建立更新或刪除，維護 PD/TiKV/TiDB StatefulSet, Service 和 Deployment 對象更新。

3. Kubernetes 根據 StatefulSet, Service 和 Deployment 對象建立更新或刪除對應的容器和服務。

在第 2 步中，TiDB Operator 在更新 StatefulSet 等對象時會參考 PD API 給出的集羣狀態來作出 TiDB 集羣的運維處理。經過 TiDB Operator 和 Kubernetes 的動態調度處理，建立出符合用戶預期的 TiDB 集羣。

快速體驗 TiDB Operator

TiDB Operator 須要運行在 Kubernetes v1.10 及以上版本。TiDB Operator 和 TiDB 集羣的部署和管理是經過 Kubernetes 平臺上的包管理工具 Helm 實現的。運行 TiDB Operator 前請確保 Helm 已經正確安裝在 Kubernetes 集羣裏。

若是沒有 Kubernetes 集羣，能夠經過 TiDB Operator 提供的腳本快速在本地啓動一個多節點的 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 集羣準備好，就能夠經過 Helm 和 Kubectl 安裝部署 TiDB Operator 和 TiDB 集羣了。

1. 安裝 TiDB Operator

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

2. 部署 TiDB 集羣

   helm install charts/tidb-cluster --name=demo-tidb --namespace=tidb --set clusterName=demo
   複製代碼

集羣默認使用 local-storage 做爲 PD 和 TiKV 的數據存儲，若是想使用其它持久化存儲，須要修改 charts/tidb-cluster/values.yaml 裏面的 storageClassName。

參與 TiDB Operator

TiDB Operator 讓 TiDB 成爲真正意義上的 Cloud-Native 數據庫，開源只是一個起點，須要 TiDB 社區和 Kubernetes 社區的共同參與。

你們在使用過程發現 bug 或缺失什麼功能，均可以直接在 GitHub 上面提 issue 或 PR，一塊兒參與討論。要想成爲 Contributor 具體能夠參考 這個文檔。

做者：鄧栓