摘要：本文是我司黃東旭同學(xué)在上的演講實錄，主要分享了關(guān)于與整合的一些工作。同時也是特別喜歡開源，基本上做的所有東西都是開源，包括像這些項目。其實嚴格來說，他們只是做運維的創(chuàng)業(yè)公司。背后的系統(tǒng)的前身就是的。支持事務(wù)的前提之下還支持的。

本文是我司 CTO 黃東旭同學(xué)在 DTCC2017 上的《When TiDB Meets Kubernetes》演講實錄，主要分享了關(guān)于 TiDB 與 Kubernetes 整合的一些工作。文章較長，且干貨滿滿。

今天給大家?guī)淼姆窒硎顷P(guān)于 TiDB 與 Kubernetes 整合的一些工作。在講之前，想了解一下，在場的各位有聽說過 Kubernetes 的同學(xué)舉個手；聽說過 TiDB 的舉個手，非常好。因為我也是 DTCC 的常客了，前幾年來講的時候基本上沒有人聽說過 TiDB ，隨著這個項目越來越成熟，很欣慰，有一些社區(qū)的小伙伴已經(jīng)用起來了。

我先簡單介紹一下我自己。我是 PingCAP 的聯(lián)合創(chuàng)始人兼 CTO ，也是 TiDB 項目的碼農(nóng) ，之前一直也是在做 Infrastructure 和分布式系統(tǒng)相關(guān)的一些工作。同時也是特別喜歡開源，基本上做的所有東西都是開源，包括像 Codis 、TiDB 、 TiKV 這些項目。比較喜歡的編程語言有 GO 、Rust 、Python。

對于今天的話題，如果說在 40 分鐘之內(nèi)要去完整的介紹怎么做一個數(shù)據(jù)庫或者說怎么去做一個集成調(diào)度的系統(tǒng)，我覺得是不太可能的。

所以今天這個 Talk 我主要會分享 TiDB 作為一個分布式關(guān)系型數(shù)據(jù)庫與云整合的經(jīng)驗，以及我們遇到的一些問題，來幫大家在遇到相似的問題時提供一個解決思路。大家其實在存儲系統(tǒng)上可以把 TiDB 換成任何東西，然后對于在 Kubernetes 上的融合，我覺得都會有一些啟發(fā)的意義。

首先想強調(diào)的是，Cloud 才是未來?，F(xiàn)場做一個小調(diào)研：有在線上生產(chǎn)環(huán)境中，正使用 Kubernetes 或者 Mesos 這樣的容器化管理方案的同學(xué)嗎？好，一個兩個三個。

我相信，如果在三到五年以后，再去問這個問題，應(yīng)該是至少一半的同學(xué)會舉手。因為其實在可見的未來，數(shù)據(jù)量是一直在膨脹，業(yè)務(wù)會越來越復(fù)雜。包括現(xiàn)在很多微服務(wù)的這種思想，當(dāng)你的業(yè)務(wù)比較大的時候，會把整個服務(wù)拆成非常細的模塊，然后在眾多的模塊的拆分之下，怎么去高效的運維你的分布式集群，其實靠 SRE 或者運維人員手動去管理各個微服務(wù)或者說各個的系統(tǒng)，其實是不太現(xiàn)實的。

但是大家也都知道，對于這種無狀態(tài)的業(yè)務(wù)，比如像 Application 應(yīng)用層，其實它并不會真正的存儲數(shù)據(jù)，狀態(tài)一般都持久化到數(shù)據(jù)庫或者緩存中，所以它基本是無狀態(tài)的。所以其實一直以來大家在使用容器化遇到的第一個問題就是，有狀態(tài)的服務(wù)，特別是數(shù)據(jù)庫或者分布式存儲系統(tǒng)，怎么去運維。比如說我在 Docker 里面寫的數(shù)據(jù)，這個容器銷毀它直接就掛了，它其實是很難去做這種數(shù)據(jù)層面上的東西。

然后另外一方面就是數(shù)據(jù)庫的運維，不管是放在云上做還是 DBA 自己在物理機上做，一樣的痛苦，所以怎樣去設(shè)計一個面向云的環(huán)境下、或者說在分布式系統(tǒng)上去做數(shù)據(jù)庫。其實這也是在做 TiDB 的過程中我一直在想的。TiDB 這個項目一開始的設(shè)計就是：它一定會放在云上去運轉(zhuǎn)。

上圖是 Amazon 在它的云上選擇創(chuàng)建一個數(shù)據(jù)庫實例的一個界面，大家不用看具體的字是什么，只是給大家感受下：就是說我作為一個業(yè)務(wù)的開發(fā)，我要去存儲一個數(shù)據(jù)，啟用一個 PG 或者 MySQL 的數(shù)據(jù)庫，我還要去關(guān)心這么多個選項，或者說我一定要去關(guān)心我的這個物理機到底是什么樣的情況：磁盤有多大，什么機型，各式各樣的配置等。因為畢竟不是所有人都是專業(yè)的 DBA ，也不是所有人都是操作系統(tǒng)的專家，當(dāng)時看到這個頁面的時候，基本上業(yè)務(wù)開發(fā)可能是一臉懵逼的狀態(tài)。

現(xiàn)在所有人都跟你說，我的系統(tǒng)是一個分布式系統(tǒng)，在廣告里寫的非常漂亮?，F(xiàn)在哪一個數(shù)據(jù)庫說自己不是分布式的，那基本上只能是落后于時代。但是，大家有沒有想過，現(xiàn)在所有的這些分布式系統(tǒng)、分布式數(shù)據(jù)庫，運維起來都是非常痛苦，沒有辦法去很好的把它用好。

以 Hadoop 為例，現(xiàn)在 setup 一個 Hadoop 的集群竟然能成為一個生意，這個生意還讓兩個創(chuàng)業(yè)公司都上市了，一個是 Cloudera，一個是 Hortonworks。其實嚴格來說，他們只是做 Hadoop 運維的創(chuàng)業(yè)公司。然后還有無數(shù)的公司在做 Spark 的維護、Spark 的管理。各種各樣的數(shù)據(jù)庫運維公司，靠這個都過的非常好。

這個其實在我看來是非常不正常的，因為大家想，如果你去運維一兩臺機器那沒有問題，我寫一個腳本，輕輕松松的就可以搞定；然后三五十臺機器，也還行，招一個 OPs 或者說招一個 DBA ，還是可以人工的管理。

但是如果是在 100 臺、1000 臺甚至 10000 臺規(guī)模之上，機器的故障會是每天每夜無時無刻都發(fā)生的，網(wǎng)絡(luò)的抖動，磁盤 IO 的異常，一直都在發(fā)生，靠人是沒有辦法做的?？偟膩碚f就是，當(dāng)你去運維一個 single node 的系統(tǒng)時，基本上沒有什么難度；但是如果要去運維一個特別大的 P2P 的 distributed system，尤其是節(jié)點數(shù)特別多的時候，你的狀態(tài)和維護的成本就變得非常高。

之前我做過一個項目叫 Codis ，可能有很多同學(xué)聽說過，也可能很多同學(xué)已經(jīng)用在生產(chǎn)環(huán)境之中。還有另外一個不是我做的項目，就是官方的 Redis Cluster。當(dāng)時很多社區(qū)里面的 Redis Cluster 的粉絲一直噴我，說 Codis 的配置怎么這么復(fù)雜，一點都不好用，組件怎么這么多?，F(xiàn)在這個事情又在重演。

很多系統(tǒng)做成了 P2P 的模型了以后，組件很少部署很方便，但是真正在去運維它的時候，比如說要去做一個滾動升級或者我想清楚的知道整個集群的數(shù)據(jù)分布和各個組件的狀態(tài)，又或者說是我的分布式邏輯出了個bug，但是我的存儲層沒事，需要做個熱更新這個時候，p2p 系統(tǒng)的運維復(fù)雜度就凸顯了。Codis 它其實有一個 Proxy，一個存儲層，這兩層在邏輯上其實是分離的；但是 Redis Cluster ，每一個節(jié)點既是它的分布式調(diào)度模塊，同時又是它的數(shù)據(jù)存儲模塊，這時候整個系統(tǒng)架構(gòu)是混在一起的，對于運維的同學(xué)來說這就是一個惡夢。

如果我想清楚的知道我的數(shù)據(jù)到底是在哪幾臺機器上，比如說這塊數(shù)據(jù)特別熱我想把它挪走，這時候像在 Redis Cluster 這種純 P2P 的系統(tǒng)里面是很難得到它的當(dāng)前狀態(tài)。所以這也是影響了我后來一系列的系統(tǒng)設(shè)計的想法，所以 operation 是一個非常困難的事情，在一個特別大的分布式系統(tǒng)里，是一個非常困難的事情。

因為你的服務(wù)和組件特別多，不同的組件，不同的模塊，然后再加上一個分布式系統(tǒng)里邊特別不穩(wěn)定的網(wǎng)絡(luò)狀態(tài)，使得各種各樣的異常情況，人是沒有辦法去掌控的。

還好，Google 是一個非常偉大的公司，像 TiDB 整個模型大家也知道是參考了Google Spanner／F1。Kubernetes 背后的系統(tǒng)的前身就是 Google 的 Borg。

Borg 其實是 Google 內(nèi)部一直在用著的大規(guī)模的集群調(diào)度器。Borg 這個單詞就是星際迷航里面的一個角色，相當(dāng)于它作為整個集群的一個大腦來去控制集群的業(yè)務(wù)的分布跟數(shù)據(jù)的均衡，所以 Google 給我們帶來了 Kubernetes 這個項目。

Kubernetes 主要的工作就是一個面向 Container 的集群管理的服務(wù)。它同時會去做服務(wù)編排，Auto deployment、 Auto scaling、Auto healing ，你的整個集群的這些服務(wù)的生命周期的管理，然后故障的轉(zhuǎn)移、擴容...你可以認為它是一個集群的操作系統(tǒng)。大家可能認為操作系統(tǒng)就是單機上的一個概念，但是如果放到一個大規(guī)模的分布式系統(tǒng)里面，你有無數(shù)的 CPU 資源，無數(shù)的內(nèi)存，無數(shù)的磁盤資源，怎么高效的去把你的服務(wù)在這些海量的資源上進行合理的分配，這個就是 Kubernetes 干的事情。

TiDB 大家也都非常熟悉了，我簡單介紹一下吧。

我們做 TiDB 的目標(biāo)就是，希望構(gòu)建一個完全彈性的，用戶不需要去知道數(shù)據(jù)的分布信息，也不需要去做手工的數(shù)據(jù)分片，可以把它當(dāng)做一個單機的數(shù)據(jù)庫、 MySQL 的數(shù)據(jù)庫在用，但是它背后是一個高度彈性和智能的分布式的數(shù)據(jù)庫。對業(yè)務(wù)層你不需要再去想分庫分表，也不需要再去想熱點的 balance 這種事情。它支持百分之百的 OLTP 的功能，可以支持跨行事務(wù)，像 MySQL 一樣：我開始一個 transaction，然后寫寫寫，最后 commit，全成功或者全失敗，沒有第三種可能 。支持事務(wù)的前提之下還支持 80% 的 OLAP 。

所以 TiDB 是非常適合去做這種一邊有實時寫入，一邊有復(fù)雜 Join 和實時分析的場景，它的 SQL 優(yōu)化器其實也有從 Spark SQL 里面學(xué)到了很多東西。

當(dāng)然對外的接口是完整的 MySQL 的接口，你可以直接用 MySQL 的客戶端就連上了。另外，背后它支持高可用。因為底層的復(fù)制協(xié)議并不是通過像這種主從模型去做數(shù)據(jù)冗余的，而是用 Raft，Raft 跟 multi-paxos 是比較接近的，都是基于選舉的算法。

在遇到 MySQL 的擴展性問題的時候，大家過去只能一臉懵逼，然后反回來去拆庫拆表，或者去用 MyCat 或者依托 MySQL 的中間件去做 sharding 。其實這對于業(yè)務(wù)層來說，侵入性非常大，所以 TiDB 的初衷就是解決這個問題，但是它沒有用任何一行 MySQL 的代碼。

TiDB 其實也是由很多的組件組成，它并不是一個純粹的 P2P 系統(tǒng)，如果看這個架構(gòu)其實非常像 Codis 。

今天的主題是說我們怎么在 Kubernetes 上去做 cluster 的 setup、rolling update，怎么去解決 Kubernetes 對于本地磁盤存儲的綁定問題。

所以面臨著一個與大家之前在 Kubernetes 上去部署帶狀態(tài)的服務(wù)非常接近的問題。因為 TiDB 本身是一個帶狀態(tài)的數(shù)據(jù)庫，數(shù)據(jù)庫沒有狀態(tài)那不可能。Kubernetes 的調(diào)度其實是對這種 stateless applications 非常友好的，但是如果你是一個帶狀態(tài)的，比如像 MySQL、PG、TiDB，或者 Etcd、Zookeeper 等等，怎么去做？真正的困難并不是 Kubernetes 做不了，而是每一個不同的系統(tǒng)都有自己的數(shù)據(jù)分布模型，同時每一個不同的系統(tǒng)它的運維方式也不太一樣。所以作為 Kubernetes 的平臺來說，沒有辦法去針對每一個不同的存儲系統(tǒng)去設(shè)計一套自己的調(diào)度策略。這是 Kubernetes 沒有辦法去做的一個事情。

舉個例子，比如說你想去運維好一個 Redis Cluster ，那你必須得了解 Redis Cluster 一些原理，還有必須得去知道它怎么運維；如果你想要去運維 Codis ，你必須得知道 Codis 的一些原理方法才能把它運維好。但這些領(lǐng)域知識怎么去告訴 Kubernetes 說你幫我按照這個方法來去運維這個系統(tǒng)？

這時候有一個公司，叫做 CoreOS ，相信大家可能也都熟悉，就是 Etcd 背后的那個公司，也是我們 PingCAP 的好伙伴。CoreOS 也是社區(qū)里面最大的 Kubernetes 的運營的公司，他們引入了一個新的 Kubernetes 的組件，叫做 Operator 。Operator的意義在于它其實是相當(dāng)于使用了 Kubernetes 的 TPR（third party resources）的 API，去把你的系統(tǒng)運維的一些領(lǐng)域知識，封裝到 Operator 里面，然后把 Operator 這個模塊注入到 Kubernetes 上面，整個這些集群是通過 Operator 這個模塊來去做調(diào)度。

CoreOS 官方還提供了一個 Etcd 的 Operator 的實現(xiàn)。其實這思路也很簡單，就是說把這個集群的創(chuàng)建滾動更新，然后各種運維的一些領(lǐng)域知識放到這個 Operator 里面，然后在 Operator 里面去調(diào)用 Kubernetes 原生的 API，來做集群的管理，相當(dāng)于是 Kubernetes 的一個 Hook 。

一般來說一個 Operator 它其實有這樣一些對外暴露的接口或者是能力。它做的事情的就是：比如我想要讓 Kubernetes 去建立一個 TiDB 的集群，比如說 deployment；比如我加入新的物理節(jié)點以后，我要想對現(xiàn)有的這個集群做擴容，然后 rebalance；比如說我的集群的 TiDB 本身的這些 binary需要升級，我要去做業(yè)務(wù)透明的滾動更新，比如說我有 100 個節(jié)點，要在上面去做升級，不可能手動去做，這個其實都是封裝在我們的 Operator 里面，然后包括自動化的 backup 跟 restore 這些功能。

本質(zhì)上來說你可以認為 Operator 是一個 Kubernetes 的批處理方案。我剛才也簡單提到了一下，Kubernetes 可以作為一個集群的操作系統(tǒng)，但是這個操作系統(tǒng)總應(yīng)該能讓運維去寫腳本的，這個腳本就是 Operator 機制。

其實它的原理很簡單，就是它注入到 Kubernetes 里面，會實時不停的去觀察集群的狀態(tài)，去 Hook Kubernetes 的一些集群的狀態(tài)，一些 API，然后得到整個集群的狀態(tài)。把一些分析的東西放在 Operator 里面，它可能會有一些地方被觸發(fā)，比如說我該擴容了或者我該去做 Failover ，然后去反饋。

然后 TiDB 的 Operator 目前來說有這么幾個功能：創(chuàng)建集群、滾動更新、Scale out， Failover、Backup/Restore。

因為其實今天的這個話題是說怎么去跟云做結(jié)合。我們現(xiàn)在在跟一些公有云的提供方在做合作。但是不可能說每一個公有云都自己去接入它的資源管理的 API，因為每個公有云可能都用的是不一樣的 API database，所以我們相當(dāng)于做的一個方案就是說，不管你是公有云也好還是私有云也好，你給我一堆物理的機器，然后在這一堆物理的機器上面去部署 Kubernetes ，在這個 Kubernetes 上面，我相當(dāng)于把我的 TiDB Operator 給放進去，當(dāng)某個公有云客戶要它去創(chuàng)建一個集群的時候，會通知 Operator 去創(chuàng)建，比如說劃出一些機器，去做物理隔離。

這在私有云里邊也是一個比較常見的場景了。用戶他其實想要去做這種業(yè)務(wù)之間的租戶隔離，TiDB Operator 是做一個比較簡單的物理隔離。

但是做這個 Operator 最難的一個部分其實剛才也簡單講了一下，就是存儲的問題。如果大家關(guān)注 Kubernetes 社區(qū)的話，一般都會注意到 persistend local storage 的這個方案一直在社區(qū)里邊扯皮和吵架。現(xiàn)在大家認為 Kubernetes 本地的磁盤是沒法用的，或者說沒有辦法直接當(dāng)做一個資源來使用的。

上圖是放在 Kubernetes 的 issues 里面的一個問題，就是 persistent local storage ，這個看上去非常不可思議，這么簡單的功能為什么一直到現(xiàn)在沒有支持。

我個人感覺 Google 之所以遲遲不去做這個功能，它背后有一個原因可能是在 Google 內(nèi)部，它的網(wǎng)絡(luò)存儲是非常強的，它有自己非常好的網(wǎng)絡(luò)設(shè)備。你在同一個數(shù)據(jù)中心里，去換一塊網(wǎng)絡(luò)盤，它的這個 latency 基本上很多業(yè)務(wù)可以接受的，所以這樣的話，持久化存儲的問題基本上是靠網(wǎng)絡(luò)的磁盤來解決。

想像你跑一個 MySQL 的業(yè)務(wù)，MySQL 的業(yè)務(wù)本身它寫入的磁盤并不是你的物理機的本地盤，而是一塊網(wǎng)絡(luò)盤，這個網(wǎng)絡(luò)盤我能給你保證它的 IOPS 跟 latency 都是非常好的狀態(tài)，這個時候你的業(yè)務(wù)掛掉了，我再重新啟一個容器把這個網(wǎng)絡(luò)盤再掛到那個 pod 的后邊，這時候你的業(yè)務(wù)是幾乎無感知的。這也是 Google 比較推崇的使用存儲的一個模式，所以這就是 Kubernetes 背后的那個 persistent volumes 的這個方案。

它現(xiàn)在是有這個方案的，但是對于像我們這樣的分布式數(shù)據(jù)庫或者說對這種本地磁盤有特別強要求的（ TiDB 底層的存儲引擎對單機的 SSD 做了非常多的優(yōu)化），并沒有辦法去容忍我底下寫入的一個磁盤是網(wǎng)絡(luò)盤。因為本身比如說 TiDB 這一層，已經(jīng)做了三個副本，甚至五個副本的復(fù)制，但是在底下網(wǎng)絡(luò)盤又要去做這個復(fù)制其實是沒有太多必要的，所以 Google 一直遲遲沒有推 Local Storage Resource。如果在 Google Cloud 上它能更好的去賣它的云盤，或者說對于這些公有云廠商來說，這是更友好的。

當(dāng)然它也不是沒做，它是要在 1.9 里面才會去做這個支持，但以 Kubernetes社區(qū)的迭代速度，我估計 1.9 可能還要等個兩三年，所以這是完全不能忍的一個狀態(tài)。那既然我們又需要這個本地磁盤的支持，但是官方又沒有，那該怎么辦呢？這時我們就發(fā)揮主觀能動性了。

我們給 Kubernetes 做了一個 patch。這個 patch 也是通過 Kubernetes resource 的方案去做的一個本地磁盤資源的管理模塊，這個怎么做的呢？也比較簡單。這部分內(nèi)容就比較干了，需要大家對 Kubernetes 整個架構(gòu)有一點點了解。

第一步，先會去創(chuàng)建一個 Kubernetes 的 Configuration map，我們稱之為 TiDB 的 storage ，就是針對 storage 的物理資源寫在配置的文件里邊。比如說機器的 IP，它的不同盤對應(yīng)的文件夾在哪兒，相當(dāng)于是一個配置階段的東西。

第二步，創(chuàng)建一個利用 Kubernetes 的 Third Party Resources（TPR） 的 API，去創(chuàng)建一個叫 tidb-volume 的第三方資源，然后這個資源去剛才 Configuration map 里面去讀它去注冊的那些物理磁盤分布的狀態(tài)資源，相當(dāng)于 TPR 會把那個配置里面的磁盤資源 load 出來，變成在 Kubernetes 里的一個第三方 resource，這個對象大概是這樣一個狀態(tài)。

第三步，我們在這邊會去寫一個 controller，我們寫這個 controller 是干嘛呢？叫 volume-controller 。比如說我們的一個磁盤的資源分配給了一個 pod，然后這個 pod 現(xiàn)在在占用著這個資源，我需要有一個 controller 的模塊來標(biāo)記這個資源的使用情況，不能說我新的業(yè)務(wù)在起來的時候，我把資源分配給了兩個正在用的業(yè)務(wù)，這是不行的。這里的對應(yīng)關(guān)系其實是由 volume controller 去維護的。然后另外一方面它還實時的監(jiān)盯著剛才 Configuration map 里面的物理資源，我可以動態(tài)的添加物理的磁盤資源的一些狀態(tài)。

第四步，剛才我們說到 opreator 其實是一個運維的工具，去做創(chuàng)建集群還有滾動升級，相當(dāng)于總的入口。在這里面在去創(chuàng)建集群，在啟動進程的時候，把剛才我們創(chuàng)建的本地磁盤資源啟動實例綁定在一起，讓它能夠成功的創(chuàng)建這個資源。

第五步，就是創(chuàng)建一個 DaemonSet。DaemonSet 在 Kubernetes 里就是在每一個物理節(jié)點上每一個長度的進程，這個進程是用來去維護磁盤上資源的使用狀況。比如說一個 TiKV 的節(jié)點下線了，這個物理的磁盤資源就要被回收。回收了以后你要去做刪除數(shù)據(jù)、清空數(shù)據(jù)的操作，或者這個物理機就宕機了，你需要有一個東西來去通知 controllor 把這個資源給下線掉，這個是 DaemonSet 在干的事情。

這一整套加起來就是相當(dāng)于只通過 Third Party Resources 來嵌入 Kubernetes，整體來說在旁路卻實現(xiàn)了一種本地的 local 磁盤的管理方案。

因為這個代碼其實還蠻多的，現(xiàn)在還沒有辦法直接 push 回 Kubernetes 社區(qū)。雖然現(xiàn)在這還是一個 private 的項目，但是在后續(xù)把代碼整理以后我們還是會開源出來。所以這其實也是為大家以后在 Kubernetes 去調(diào)度這種單雙向服務(wù)的方案，提供了一套可行的路，至少我們用這個還挺爽的。

然后，想稍微展望一下未來的數(shù)據(jù)庫應(yīng)該是什么樣的。

在我看來，未來的數(shù)據(jù)庫不會再需要 DBA ，或者說未來你在寫業(yè)務(wù)的時候，并不需要去關(guān)心底下數(shù)據(jù)該去怎么分片，怎么去 sharding，一切都應(yīng)該是在后面的云服務(wù)本身或者基礎(chǔ)設(shè)施去提供的。所有的東西都應(yīng)該是 self-driving，相當(dāng)于自動駕駛。就像在未來大家覺得自動駕駛應(yīng)該是一個方向，在基礎(chǔ)軟件里我覺得也是越來越多的自動化導(dǎo)致大家對運維的依賴變得越來越輕。但是在很多的極端的情況下，circuit-breaker（斷路器）還是要有的。比如說我的業(yè)務(wù)產(chǎn)品現(xiàn)在突然出現(xiàn)了一個特別熱的熱點，我需要業(yè)務(wù)這邊去緊急的做手動的數(shù)據(jù)切分、移動，把負載手動的均衡出來，所以手動模式還是仍然要有的。類似于你自動駕駛的汽車，突然來一個人加塞，大家還是非常希望能保證自己的安全，那就必須得有一個手動的模式。

第二點是 database as a service ，前面也說到了，serverless 可能會在 database 里面，有一種新的形態(tài)的數(shù)據(jù)的數(shù)據(jù)庫。大家如果關(guān)注數(shù)據(jù)庫領(lǐng)域的話，最近出了一個新的數(shù)據(jù)庫叫 FaunaDB 。FaunaDB 非常有意思，它其實是跟公有云綁定在一起對外提供服務(wù)的，你看不見它實際的進程和部署，也看不見它物理的進程在什么地方，整個數(shù)據(jù)庫對外的展現(xiàn)形式就是你去買我的服務(wù)，我給你多少的 QPS。比如說你買一萬個 QPS，這個服務(wù)就能保證一萬個 QPS，你買十萬就是十萬，按這個價格來去付費，至于你的容量全都是在背后隱藏著，所有業(yè)務(wù)的開發(fā)者實際上是看不見。

第三點就是 Local storage isn’t necessary。為什么 Google 它一直沒有在 Kubernetes 里面去做 Local storage，其實仔細想一下也是有道理的，就是說隨著未來硬件的發(fā)展，當(dāng)網(wǎng)絡(luò)社會的速度和分布跟你的磁盤的存儲差不多的時候，那它到底是不是網(wǎng)絡(luò)的，已經(jīng)對業(yè)務(wù)層沒有什么意義了，所以這可能是一個未來的趨勢。

這條是一個比較極端的路，就是把整個磁盤放到網(wǎng)絡(luò)上，用網(wǎng)絡(luò)盤。還有另外一條反向的特別極端的路，也是我現(xiàn)在正在嘗試的一個東西，就是更加去對硬件做定制。比如說我現(xiàn)在嘗試把一些 TiDB 的數(shù)據(jù)庫的一些邏輯放到 FPGA 上面，或者是放在 SSD 的控制芯片里面，這其實是更深的定制，在未來我覺得兩者可能會融合。就是說我雖然可能是掛了一個網(wǎng)絡(luò)盤，但是對于數(shù)據(jù)庫來說我有了這個計算邏輯可能直接的去操作硬件，而不需要去例如通過標(biāo)準的 POSIX API 來轉(zhuǎn)換內(nèi)核走 本地 IO 的接口。

總結(jié)一下，分布式系統(tǒng)的運維特別的痛苦，然后 Kubernetes 是一個未來集群調(diào)度必然的趨勢，但是在存儲層它現(xiàn)在還沒有太多的好辦法。目前來說我們在做的一個事情就是 Operator，把整個存儲層的運維的領(lǐng)域知識放在 Operator 里邊，然后讓 Kubernetes 能去調(diào)度我們的東西。這個有點像 DCOS 的 batch script。

TiDB-Operator，其實是把運維干的事情，全都通過 Operator 的形式來封裝在程序里邊，然后自動的去運維。

Local Storage 的問題我們是解決了。雖然 Kubernetes 沒有辦法去提供這個能力，但是我們暫時解決了。