創(chuàng)新互聯(lián)成立與2013年，是專業(yè)互聯(lián)網(wǎng)技術服務公司，擁有項目成都做網(wǎng)站、成都網(wǎng)站設計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元昌吉做網(wǎng)站,已為上家服務,為昌吉各地企業(yè)和個人服務,聯(lián)系電話:028-86922220

作者 | 張磊，阿里云高級技術專家、CNCF 官方大使，CNCF 應用交付領域 co-chair，Kubernetes 項目資深維護者

最近，Kubernetes 社區(qū)里有一個關于“Kubernetes is the new database”的論述，引起了很多人的關注。當然，這個論述更確切的含義，指的是 Kubernetes 項目本身的工作原理類似于數(shù)據(jù)庫，而不是說你應該把 Kubernetes 當數(shù)據(jù)庫用。

粗看起來，這個 “Kubernetes 是一個數(shù)據(jù)庫” 的論述還是比較匪夷所思的。畢竟我們平常所說的 Kubernetes 的工作原理，比如控制器模式、聲明式 API 等等，好像跟“數(shù)據(jù)庫”這個東西并沒有什么直接關系。但實際上，這個論述背后卻有著其非常本質的含義。這里的緣由，得從 Kubernetes 項目里一個最基礎的理論談起。

Kubernetes 聲明式應用管理理論基礎

在我們討論 Kubernetes 的時候，往往會提到這樣一個概念，叫做“聲明式應用管理”。實際上，這也是 Kubernetes 項目跟其它所有基礎設施項目都不一樣的一個設計，是 Kubernetes 所獨有的一個能力，那么，你有沒有思考過，聲明式應用管理在 Kubernetes 中具體的表現(xiàn)到底是什么呢？

1. 聲明式應用管理不僅僅是“聲明式風格的 API”

如果我們回顧一下 Kubernetes 的核心工作原理，我們其實就不難發(fā)現(xiàn)這樣一個事實：Kubernetes 里面的絕大多數(shù)功能，無論是 kubelet 執(zhí)行容器、kube-proxy 執(zhí)行 iptables 規(guī)則，還是 kube-scheduler 進行 Pod 調度，以及 Deployment 管理 ReplicaSet 的過程等等，其實從總體設計上都是在遵循著我們經(jīng)常強調過的“控制器”模式來進行的。即：用戶通過 YAML 文件等方式來表達他所想要的期望狀態(tài)也就是終態(tài)（無論是網(wǎng)絡、還是存儲），然后 Kubernetes 的各種組件就會讓整個集群的狀態(tài)跟用戶聲明的終態(tài)逼近，最終達成兩者的完全一致。這個實際狀態(tài)逐漸向期望狀態(tài)逼近的過程，就叫做 reconcile（調諧）。而同樣的原理，也正是 Operator 和自定義 Controller 的核心工作方式。
這種通過聲明式描述文件，以驅動控制器執(zhí)行 reconcile 逼近兩個狀態(tài)的工作形態(tài)，正是聲明式應用管理最直觀的體現(xiàn)。需要注意的是，這個過程其實包括了兩層含義：

• 聲明式描述的期望狀態(tài)。這個描述必須是嚴格意義上使用者想要的最終狀態(tài)，如果你在這個描述里面填寫的是某個中間狀態(tài)，或者你希望動態(tài)的調整這個期望狀態(tài)，都會破壞這個聲明式語義的準確執(zhí)行；

• 基于 reconcile 的狀態(tài)逼近過程。Reconcile 過程的存在，確保了系統(tǒng)狀態(tài)與終態(tài)保持一致的理論正確性。確切地說，Reconcile 過程不停的執(zhí)行“檢查 -> Diff -> 執(zhí)行”的循環(huán)，才使得系統(tǒng)能夠始終對系統(tǒng)本身狀態(tài)與終態(tài)直接的差異并能夠采取必要的行動。而相比之下，僅僅擁有聲明式的描述是不充分的。這個道理很容易理解，你第一次提交這個描述時系統(tǒng)達成了你想要的期望狀態(tài)，并不能代表、也不能保證一個小時后的情況也是如此。很多人會搞混“聲明式應用管理”和“聲明式風格的 API” ，其實就是對 Reconcile 必要性沒有正確的認識。

你也許會比較好奇，采用這種聲明式應用管理體系，對于 Kubernetes 來說有什么好處呢？

2. 聲明式應用管理的本質：Infrastructure as Data

實際上，聲明式應用管理體系背后的理論基礎，是一種叫做 Infrastructure as Data （IaD）的思想。這種思想認為，基礎設施的管理不應該耦合于某種編程語言或者配置方式，而應該是純粹的、格式化的、系統(tǒng)可讀的數(shù)據(jù)，并且這些數(shù)據(jù)能夠完整的表征使用者所期望的系統(tǒng)狀態(tài)。
注：Infrastructure as Data  有時也被稱作 Configuration as Data，背后的意思是一樣的。
而這樣做的好處就在于，任何時候我想對基礎設施做操作，最終都等價于對這些數(shù)據(jù)的“增、刪、改、查”。而更重要的是，我對這些數(shù)據(jù)進行“增、刪、改、查”的方式，與這個基礎設施本身是沒有任何關系的。所以說，我跟一個基礎設施交互的過程，不會被綁定在某種編程語言、某種遠程調用協(xié)議、或者某種 SDK 上。只要我能夠生成對應格式的“數(shù)據(jù)”，我就能夠“天馬行空”地使用任何我喜歡的方式來完成對基礎設施的操作。
這種好處具體體現(xiàn)在 Kubernetes 上，就是如果我想在 Kubernetes 上做任何操作，我只需要提交一個 YAML 文件，然后對這個 YAML 文件進行增刪改查即可。而不是必須使用 Kubernetes 項目的 Restful API 或者 SDK 。這個 YAML 文件里的內(nèi)容，其實就是 Kubernetes 這個 IaD 系統(tǒng)對應的 Data（數(shù)據(jù)）。
所以說，Kubernetes 從誕生起就把它的所有功能都定義成了所謂的“API 對象”，其實就是定義成了一份一份的 Data。這樣，Kubernetes 使用者就可以通過對這些 Data 進行增刪改查來達成自己想要的目標，而不是被綁定在某種具體的語言或者 SDK 上。
更重要的是，相比于專有的、命令式的 API 或者 SDK，以 YAML 為載體的聲明式數(shù)據(jù)能夠更簡單的完成對底層實現(xiàn)的屏蔽，從而更容易對接和集成現(xiàn)有的基礎設施能力，這其實也是 Kubernetes 生態(tài)能夠以驚人的速度蓬勃發(fā)展到今天的一個秘密武器：IaD 思想帶來的聲明式 API 與控制器模式，讓整個社區(qū)更愿意為 Kubernetes 編寫插件和對接各種能力，并且這些插件和能力的通用性和可移植性也非常高，這是其它項目比如 Mesos 和 OpenStack 所望塵莫及的。
可以說，IaD 正是 Kubernetes 能夠達成 “The Platform for Platform” 這個目標的核心戰(zhàn)斗力所在。 說到這里，大家估計也就明白了：這種 IaD 設計中的 Data 具體表現(xiàn)出來，其實就是聲明式的 Kubernetes API 對象；而 Kubernetes 中的控制循環(huán)，則是確保系統(tǒng)本身能夠始終跟這些 Data 所描述的狀態(tài)永遠保持一致。從這一點上來說，Kubernetes 本質上其實是一個以數(shù)據(jù)（Data）來表達系統(tǒng)的設定值、通過控制器（Controller）的動作來讓系統(tǒng)維持在設定值的調諧系統(tǒng)。
等一下，這個“讓系統(tǒng)維持在設定值”的理論，聽起來好像有點耳熟？
實際上，Kubernetes 背后的這門基礎課，可能絕大多數(shù)工科背景的讀者都是學過的，它叫做《控制理論》。

 是不是感覺豁然開朗了呢？
在明白了 Kubernetes 的這個本質之后，我們回過頭來再看原本一些比較難以理解的設定，可能會更容易體會到一些本質的東西。
比如，今天我們在使用 Kubernetes 的時候之所以要寫那么多 YAML 文件，其實是因為我們需要通過一種方式把 Data 提交給 Kubernetes 這個控制系統(tǒng)。而在這個過程中，YAML 只是一種為了讓人類能夠格式化的編寫 Data 的一個載體。如果做一個類比，那么 YAML 就像我們小時候作業(yè)本里的“田字格”，而“田字格”里寫的那些文字，才是 Kubernetes 真正關心的 Data 和整個系統(tǒng)運轉的核心。
細心的讀者此時應該已經(jīng)想到了，既然 Kubernetes 需要處理這些 Data，那么 Data 本身不是也應該有一個固定的“格式”這樣 Kubernetes 才能解析它們呢？沒錯，這里的格式在 Kubernetes 中就叫做 API 對象的 Schema。如果你經(jīng)常編寫自定義 Controller 的話，可能就會對這個 Schema 的體感比較深刻：CRD 就是一個專門用來定義 Schema 的一個特殊的 API 對象。

YAML 工程師？不，你是數(shù)據(jù)庫工程師！

上述 Kubernetes 的 IaD 的本質，決定了它的工作原理其實更類似一個“數(shù)據(jù)庫”，而不像傳統(tǒng)意義上的分布式系統(tǒng)。這個差異，也是導致 Kubernetes 學習成本比較陡峭的一個根本性原因。
而從這個角度來講，Kubernetes 為你暴露出來的各種 API 對象，實際上就是一張張預先定義好 Schema 的表（Table）。而我們絞盡腦汁編寫出的那些 YAML 文件，其實就是對這些表中的數(shù)據(jù)（Data）進行的增刪改查（CURD）。而 YAML 這個工具本身，則好比 SQL 一樣是一個幫助你對數(shù)據(jù)庫中的數(shù)據(jù)進行操作的工具和載體。而唯一跟傳統(tǒng)數(shù)據(jù)庫不太一樣的是，Kubernetes 在拿到這些數(shù)據(jù)之后，并不以把這些數(shù)據(jù)持久化起來為目的，而是希望通過這些數(shù)據(jù)來驅動 Controller 執(zhí)行某些操作，從而將整個系統(tǒng)的狀態(tài)逐步調整為跟數(shù)據(jù)中聲明的終態(tài)一致，這就回到我們前面所說的“控制理論”部分了。
也正是由于  Kubernetes 這樣整套體系都圍繞著“數(shù)據(jù)”這個一等公民運轉的設定，才使得“編寫和操作 YAML文件”成為了 Kubernetes 工程師的幾乎唯一的日常工作。不過，在理解了本文今天介紹的 IaD 的思想之后，你其實大可以把自己比作一個“數(shù)據(jù)庫工程師”了，而且這個 TItle 確實要比“YAML 工程師”更加貼切一些。

Kubernetes 項目的“視圖層”

正如前文所述，如果你從一個“數(shù)據(jù)庫”的角度重新審視 Kubernetes 設計的話，就不難發(fā)現(xiàn) Kubernetes 的很多設計背后其實有著非常精妙的思想。比如：

• 數(shù)據(jù)模型 -  Kubernetes 的各種 API 對象與 CRD 機制
• 數(shù)據(jù)攔截校驗和修改機制 - Kubernetes Admission Hook
• 數(shù)據(jù)驅動機制 - Kubernetes Controller/Operator
• 數(shù)據(jù)監(jiān)聽變更與索引機制 - Kubernetes 的 Informer 機制
• ……

另外一方面，隨著 Kubernetes 基礎設施越來越復雜，第三方插件與能力越來越多，社區(qū)的維護者們也發(fā)現(xiàn) Kubernetes 這個“數(shù)據(jù)庫”內(nèi)置的“數(shù)據(jù)表”無論從規(guī)模還是復雜度上，都正在迎來爆炸式的增長。所以  Kubernetes 社區(qū)很早就在討論如何給 Kubernetes  設計出一個“數(shù)據(jù)視圖（View）”出來，即：

而這樣一個構建在 Kubernetes 內(nèi)置 API 資源之上的“視圖層”給 Kubernetes 使用者帶來的好處，跟數(shù)據(jù)庫中的“視圖”是非常類似的，比如：

1. 簡化和更改數(shù)據(jù)格式和表示

Kubernetes 的視圖層，需要能夠給研發(fā)和運維暴露更簡潔的、經(jīng)過抽象后的應用層 API 對象，而不是原始的基礎設施層 API 對象。而一個視圖層對象具體如何定義，自由度應該完全在用戶手中，不需要拘束在底層 Kubernetes 內(nèi)置對象的 Schema 上。

2. 簡化復雜的數(shù)據(jù)操作（簡化 SQL ）

經(jīng)過抽象后產(chǎn)生的視圖層對象，不僅在 UI 上需要更加簡單，還需要可以定義和管理非常復雜的底層 Kubernetes 資源拓撲，從而降低用戶管理 Kubernetes 應用的復雜度和心智負擔。

3. 保護底層數(shù)據(jù)表

研發(fā)和運維直接操作的是視圖層對象，所以底層的 Kubernetes 原始對象是被保護起來的。這使得這些 Kubernetes 的原始對象可以在用戶無感的情況下進行任意變更和升級。

4. 復用數(shù)據(jù)操作（復用 SQL）

由于視圖層對象與底層基礎設施是完全解耦的，所以一個通過視圖層聲明的應用或者運維能力可以在任意 Kubernetes 集群漂移，而不必擔心這些集群支持的能力是不是有差異。

5. 視圖依然是表，支持標準的表操作

Kubernetes 的視圖層對象必須依然是標準的 Kubernetes 對象，這樣 Kubernetes 對 API 對象的所有操作和原語對，才會對視圖層對象適用。我們不能在 Kubernetes API 模型上引入額外的心智負擔。 給 Kubernetes 設置視圖層的想法雖然最終沒有在 Kubernetes 上游落地，但是卻成為了社區(qū)中大多數(shù)大規(guī)模玩家的主流做法。比如 Pinterest 就在 Kubernetes 之上設計了一個 PInterestService 的 CRD 來描述和定義 Pinterest 的應用，這個 CRD 其實就是一個視圖層對象。但這個做法對于絕大多數(shù)企業(yè)來說，還是太過簡陋了。要知道，數(shù)據(jù)的“視圖”并不只是數(shù)據(jù)的簡單抽象和翻譯，在真正的生產(chǎn)環(huán)境中要大規(guī)模使用視圖層，至少需要解決幾個關鍵問題：

1. 如何定義和管理視圖層對象與底層 K8s 對象之間的映射關系？注意這里絕不是簡單的一對一映射，一個視圖層對象可能會對應多個 K8s 對象；
2. 如何對“運維能力”進行建模和抽象？一個真正的應用，絕不只是簡單的 Deployment 或者 Operator，它一定是待運行程序與相應的運維能力的有機組合（比如一個容器化應用和它的水平擴展策略）。這些運維能力如何通過在應用定義里體現(xiàn)出來？全定義成 annotation 可行嗎？
3. 如何管理運維能力同待運行程序之間的綁定關系？如何將這個綁定關系映射成底層 K8s 當中真正的執(zhí)行關系？
4. 如何通過視圖層對象標準化的定義云資源，比如一個阿里云的 RDS 實例？
5. ……

 上述這些問題，正是 Kubernetes 上游最終沒能將“視圖層”落地的重要原因之一，同時也是諸如  Open Application Model （OAM）這樣的 Kubernetes 應用層開源項目主要的關注點。需要指出的是，僅靠一個 OAM 這樣一個“規(guī)范”是依然不足以解決上述所有問題的，Kubernetes 視圖層的建立，必須借助標準的視圖層依賴庫在實現(xiàn)層予以保證，才能真正在 Kubernetes 中享受到“數(shù)據(jù)視圖”帶來的優(yōu)勢和便捷。目前社區(qū)中比較強大的 Kubernetes 視圖層依賴庫，是來自 阿里 團隊的 oam-kubernetes-runtime。
Open Application Model （OAM） 項目地址：https://github.com/oam-dev/spec
oam-kubernetes-runtime 項目地址：https://github.com/crossplane/oam-kubernetes-runtime

總結

Kubernetes 這個以 IaD 為核心的、類似“數(shù)據(jù)庫”設計，正是這個社區(qū)繁榮發(fā)展背后的重要理論基礎。然而，IaD 的思想本身也是一把雙刃劍，它催生出來的蓬勃發(fā)展的社區(qū)的另一面，是無數(shù)個“各自為政”的 Controller/Operator，以及一個通過這些 Controller 拼裝出來的、復雜度極高的 Kubernetes 集群。這樣的一個生產(chǎn)級別復雜度的 Kubernetes 集群，距離一個真正受研發(fā)和運維喜愛的云原生應用管理平臺，差距可謂十萬八千里。 在過去的 5 年里，Kubernetes 項目的巨大成功，實際上是基礎設施能力（比如網(wǎng)絡、存儲、容器）在聲明式 API 下逐步標準化和統(tǒng)一化的一個過程，而隨著 OAM 等 Kubernetes 應用層技術的逐步普及，我們已經(jīng)看見一個標準化應用層生態(tài)正在付出水面。越來越多的團隊正在嘗試通過更加用戶友好的數(shù)據(jù)視圖層，對最終用戶暴露出喜聞樂見的 API，同時對基礎設施工程師提供出更加強大的橫向連通與模塊化的平臺能力。 與此同時，Kubernetes 這個“數(shù)據(jù)庫”其他欠缺的部分，也一定會越來越多的在社區(qū)涌現(xiàn)出來。比如今天正在迅速成熟的 Open Policy Agent（OPA）項目，可以認為是“數(shù)據(jù)攔截校驗和修改機制”這一層的不斷進化結果。再比如阿里巴巴內(nèi)部在“萬節(jié)點”集群中推進的管控鏈路性能調優(yōu)工作，其理論基礎和實踐，跟今天的數(shù)據(jù)庫性能優(yōu)化，更是有異曲同工之妙的。 如果你有任何關于 IaD 系統(tǒng)想法，非常歡迎釘釘掃碼加群同我們交流！

本文題目：CNCF官方大使張磊：Kubernetes是一個“數(shù)據(jù)庫”嗎？-創(chuàng)新互聯(lián)
瀏覽路徑：http://weahome.cn/article/heshs.html