Kubernetes 是一個「數據庫」嗎？

時間 2021-02-18

標籤 git github 數據庫編程性能優化網絡架構 less 運維編程語言欄目 SQL 简体版

原文原文鏈接

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

最近，Kubernetes 社區裏有一個關於「Kubernetes is the new database」的論述，引發了不少人的關注。固然，這個論述更確切的含義，指的是 Kubernetes 項目自己的工做原理相似於數據庫，而不是說你應該把 Kubernetes 當數據庫用。github

粗看起來，這個「Kubernetes 是一個數據庫」的論述仍是比較匪夷所思的。畢竟咱們日常所說的 Kubernetes 的工做原理，好比控制器模式、聲明式 API 等等，好像跟「數據庫」這個東西並無什麼直接關係。但實際上，這個論述背後卻有着其很是本質的含義。這裏的原因，得從 Kubernetes 項目裏一個最基礎的理論談起。數據庫

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

在咱們討論 Kubernetes 的時候，每每會提到這樣一個概念，叫作「聲明式應用管理」。實際上，這也是 Kubernetes 項目跟其餘全部基礎設施項目都不同的一個設計，是 Kubernetes 所獨有的一個能力，那麼，你有沒有思考過，聲明式應用管理在 Kubernetes 中具體的表現究竟是什麼呢？性能優化

1. 聲明式應用管理不只僅是「聲明式風格的 API」網絡

若是咱們回顧一下 Kubernetes 的核心工做原理，咱們其實就不難發現這樣一個事實：Kubernetes 裏面的絕大多數功能，不管是 kubelet 執行容器、kube-proxy 執行 iptables 規則，仍是 kube-scheduler 進行 Pod 調度，以及 Deployment 管理 ReplicaSet 的過程等等，其實從整體設計上都是在遵循着咱們常常強調過的「控制器」模式來進行的。即：用戶經過 YAML 文件等方式來表達他所想要的指望狀態也就是終態（不管是網絡、仍是存儲），而後 Kubernetes 的各類組件就會讓整個集羣的狀態跟用戶聲明的終態逼近，最終達成二者的徹底一致。這個實際狀態逐漸向指望狀態逼近的過程，就叫作 reconcile（調諧）。而一樣的原理，也正是 Operator 和自定義 Controller 的核心工做方式。架構

這種經過聲明式描述文件，以驅動控制器執行 reconcile 逼近兩個狀態的工做形態，正是聲明式應用管理最直觀的體現。須要注意的是，這個過程其實包括了兩層含義：less

聲明式描述的指望狀態。這個描述必須是嚴格意義上使用者想要的最終狀態，若是你在這個描述裏面填寫的是某個中間狀態，或者你但願動態的調整這個指望狀態，都會破壞這個聲明式語義的準確執行；
基於 reconcile 的狀態逼近過程。Reconcile 過程的存在，確保了系統狀態與終態保持一致的理論正確性。確切地說，Reconcile 過程不停的執行「檢查 -> Diff -> 執行」的循環，才使得系統可以始終對系統自己狀態與終態直接的差別並可以採起必要的行動。而相比之下，僅僅擁有聲明式的描述是不充分的。這個道理很容易理解，你第一次提交這個描述時系統達成了你想要的指望狀態，並不能表明、也不能保證一個小時後的狀況也是如此。不少人會搞混「聲明式應用管理」和「聲明式風格的 API」，其實就是對 Reconcile 必要性沒有正確的認識。

你也許會比較好奇，採用這種聲明式應用管理體系，對於 Kubernetes 來講有什麼好處呢？運維

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

實際上，聲明式應用管理體系背後的理論基礎，是一種叫作 Infrastructure as Data （IaD）的思想。這種思想認爲，基礎設施的管理不該該耦合於某種編程語言或者配置方式，而應該是純粹的、格式化的、系統可讀的數據，而且這些數據可以完整的表徵使用者所指望的系統狀態。

注：Infrastructure as Data 有時也被稱做 Configuration as Data，背後的意思是同樣的。

而這樣作的好處就在於，任什麼時候候我想對基礎設施作操做，最終都等價於對這些數據的「增、刪、改、查」。而更重要的是，我對這些數據進行「增、刪、改、查」的方式，與這個基礎設施自己是沒有任何關係的。因此說，我跟一個基礎設施交互的過程，不會被綁定在某種編程語言、某種遠程調用協議、或者某種 SDK 上。只要我可以生成對應格式的「數據」，我就可以「天馬行空」地使用任何我喜歡的方式來完成對基礎設施的操做。

這種好處具體體如今 Kubernetes 上，就是若是我想在 Kubernetes 上作任何操做，我只須要提交一個 YAML 文件，而後對這個 YAML 文件進行增刪改查便可。而不是必須使用 Kubernetes 項目的 Restful API 或者 SDK 。這個 YAML 文件裏的內容，其實就是 Kubernetes 這個 IaD 系統對應的 Data（數據）。

因此說，Kubernetes 從誕生起就把它的全部功能都定義成了所謂的「API 對象」，其實就是定義成了一份一份的 Data。這樣，Kubernetes 使用者就能夠經過對這些 Data 進行增刪改查來達成本身想要的目標，而不是被綁定在某種具體的語言或者 SDK 上。更重要的是，相比於專有的、命令式的 API 或者 SDK，以 YAML 爲載體的聲明式數據可以更簡單的完成對底層實現的屏蔽，從而更容易對接和集成現有的基礎設施能力，這其實也是 Kubernetes 生態可以以驚人的速度蓬勃發展到今天的一個祕密武器：IaD 思想帶來的聲明式 API 與控制器模式，讓整個社區更願意爲 Kubernetes 編寫插件和對接各類能力，而且這些插件和能力的通用性和可移植性也很是高，這是其它項目好比 Mesos 和 OpenStack 所可望不可即的。能夠說，IaD 正是 Kubernetes 可以達成「The Platform for Platform」這個目標的核心戰鬥力所在。

說到這裏，你們估計也就明白了：這種 IaD 設計中的 Data 具體表現出來，其實就是聲明式的 Kubernetes API 對象；而 Kubernetes 中的控制循環，則是確保系統自己可以始終跟這些 Data 所描述的狀態永遠保持一致。從這一點上來講，Kubernetes 本質上實際上是一個以數據（Data）來表達系統的設定值、經過控制器（Controller）的動做來讓系統維持在設定值的調諧系統。

等一下，這個「讓系統維持在設定值」的理論，聽起來好像有點耳熟？

實際上，Kubernetes 背後的這門基礎課，可能絕大多數工科背景的讀者都是學過的，它叫作《控制理論》。

是否是感受豁然開朗了呢？

在明白了 Kubernetes 的這個本質以後，咱們回過頭來再看本來一些比較難以理解的設定，可能會更容易體會到一些本質的東西。

好比，今天咱們在使用 Kubernetes 的時候之因此要寫那麼多 YAML 文件，實際上是由於咱們須要經過一種方式把 Data 提交給 Kubernetes 這個控制系統。而在這個過程當中，YAML 只是一種爲了讓人類可以格式化的編寫 Data 的一個載體。若是作一個類比，那麼 YAML 就像咱們小時候做業本里的「田字格」，而「田字格」裏寫的那些文字，纔是 Kubernetes 真正關心的 Data 和整個系統運轉的核心。

細心的讀者此時應該已經想到了，既然 Kubernetes 須要處理這些 Data，那麼 Data 自己不是也應該有一個固定的「格式」這樣 Kubernetes 才能解析它們呢？沒錯，這裏的格式在 Kubernetes 中就叫作 API 對象的 Schema。若是你常常編寫自定義 Controller 的話，可能就會對這個 Schema 的體感比較深入：CRD 就是一個專門用來定義 Schema 的一個特殊的 API 對象。

YAML 工程師？不，你是數據庫工程師！

上述 Kubernetes 的 IaD 的本質，決定了它的工做原理其實更相似一個「數據庫」，而不像傳統意義上的分佈式系統。這個差別，也是致使 Kubernetes 學習成本比較陡峭的一個根本性緣由。

而從這個角度來說，Kubernetes 爲你暴露出來的各類 API 對象，實際上就是一張張預先定義好 Schema 的表（Table）。而咱們絞盡腦汁編寫出的那些 YAML 文件，其實就是對這些表中的數據（Data）進行的增刪改查（CURD）。而 YAML 這個工具自己，則比如 SQL 同樣是一個幫助你對數據庫中的數據進行操做的工具和載體。而惟一跟傳統數據庫不太同樣的是，Kubernetes 在拿到這些數據以後，並不以把這些數據持久化起來爲目的，而是但願經過這些數據來驅動 Controller 執行某些操做，從而將整個系統的狀態逐步調整爲跟數據中聲明的終態一致，這就回到咱們前面所說的「控制理論」部分了。

也正是因爲 Kubernetes 這樣整套體系都圍繞着「數據」這個一等公民運轉的設定，才使得「編寫和操做 YAML文件」成爲了 Kubernetes 工程師的幾乎惟一的平常工做。不過，在理解了本文今天介紹的 IaD 的思想以後，你其實大能夠把本身比做一個「數據庫工程師」了，並且這個 TItle 確實要比「YAML 工程師」更加貼切一些。

Kubernetes 項目的「視圖層」

正如前文所述，若是你從一個「數據庫」的角度從新審視 Kubernetes 設計的話，就不難發現 Kubernetes 的不少設計背後其實有着很是精妙的思想。好比：

數據模型 - Kubernetes 的各類 API 對象與 CRD 機制
數據攔截校驗和修改機制 - Kubernetes Admission Hook
數據驅動機制 - Kubernetes Controller/Operator
數據監聽變動與索引機制 - Kubernetes 的 Informer 機制
……

另一方面，隨着 Kubernetes 基礎設施愈來愈複雜，第三方插件與能力愈來愈多，社區的維護者們也發現 Kubernetes 這個「數據庫」內置的「數據表」不管從規模仍是複雜度上，都正在迎來爆炸式的增加。因此 Kubernetes 社區很早就在討論如何給 Kubernetes 設計出一個「數據視圖（View）」出來，即：

而這樣一個構建在 Kubernetes 內置 API 資源之上的「視圖層」給 Kubernetes 使用者帶來的好處，跟數據庫中的「視圖」是很是相似的，好比：

簡化和更改數據格式和表示

Kubernetes 的視圖層，須要可以給研發和運維暴露更簡潔的、通過抽象後的應用層 API 對象，而不是原始的基礎設施層 API 對象。而一個視圖層對象具體如何定義，自由度應該徹底在用戶手中，不須要拘束在底層 Kubernetes 內置對象的 Schema 上。

簡化複雜的數據操做（簡化 SQL ）

通過抽象後產生的視圖層對象，不只在 UI 上須要更加簡單，還須要能夠定義和管理很是複雜的底層 Kubernetes 資源拓撲，從而下降用戶管理 Kubernetes 應用的複雜度和心智負擔。

保護底層數據表

研發和運維直接操做的是視圖層對象，因此底層的 Kubernetes 原始對象是被保護起來的。這使得這些 Kubernetes 的原始對象能夠在用戶無感的狀況下進行任意變動和升級。

複用數據操做（複用 SQL）

因爲視圖層對象與底層基礎設施是徹底解耦的，因此一個經過視圖層聲明的應用或者運維能力能夠在任意 Kubernetes 集羣漂移，而沒必要擔憂這些集羣支持的能力是否是有差別。

視圖依然是表，支持標準的表操做

Kubernetes 的視圖層對象必須依然是標準的 Kubernetes 對象，這樣 Kubernetes 對 API 對象的全部操做和原語對，纔會對視圖層對象適用。咱們不能在 Kubernetes API 模型上引入額外的心智負擔。

給 Kubernetes 設置視圖層的想法雖然最終沒有在 Kubernetes 上游落地，可是卻成爲了社區中大多數大規模玩家的主流作法。好比 Pinterest 就在 Kubernetes 之上設計了一個 PInterestService 的 CRD 來描述和定義 Pinterest 的應用，這個 CRD 其實就是一個視圖層對象。但這個作法對於絕大多數企業來講，仍是太過簡陋了。要知道，數據的「視圖」並不僅是數據的簡單抽象和翻譯，在真正的生產環境中要大規模使用視圖層，至少須要解決幾個關鍵問題：

如何定義和管理視圖層對象與底層 K8s 對象之間的映射關係？注意這裏毫不是簡單的一對一映射，一個視圖層對象可能會對應多個 K8s 對象。
如何對「運維能力」進行建模和抽象？一個真正的應用，毫不只是簡單的 Deployment 或者 Operator，它必定是待運行程序與相應的運維能力的有機組合（好比一個容器化應用和它的水平擴展策略）。這些運維能力如何經過在應用定義裏體現出來？全定義成 annotation 可行嗎？
如何管理運維能力同待運行程序之間的綁定關係？如何將這個綁定關係映射成底層 K8s 當中真正的執行關係？
如何經過視圖層對象標準化的定義雲資源，好比一個阿里雲的 RDS 實例？
……

上述這些問題，正是 Kubernetes 上游最終沒能將「視圖層」落地的重要緣由之一，同時也是諸如 Open Application Model （OAM）這樣的 Kubernetes 應用層開源項目主要的關注點。須要指出的是，僅靠一個 OAM 這樣一個「規範」是依然不足以解決上述全部問題的，Kubernetes 視圖層的創建，必須藉助標準的視圖層依賴庫在實現層予以保證，才能真正在 Kubernetes 中享受到「數據視圖」帶來的優點和便捷。目前社區中比較強大的 Kubernetes 視圖層依賴庫，是來自 Crossplane 團隊的 oam-kubernetes-runtime：https://github.com/crossplane/oam-kubernetes-runtime。

總結

Kubernetes 這個以 IaD 爲核心的、相似「數據庫」設計，正是這個社區繁榮發展背後的重要理論基礎。然而，IaD 的思想自己也是一把雙刃劍，它催生出來的蓬勃發展的社區的另外一面，是無數個「各自爲政」的 Controller/Operator，以及一個經過這些 Controller 拼裝出來的、複雜度極高的 Kubernetes 集羣。這樣的一個生產級別複雜度的 Kubernetes 集羣，距離一個真正受研發和運維喜好的雲原生應用管理平臺，差距可謂十萬八千里。

在過去的 5 年裏，Kubernetes 項目的巨大成功，其實是基礎設施能力（好比網絡、存儲、容器）在聲明式 API 下逐步標準化和統一化的一個過程，而隨着 OAM 等 Kubernetes 應用層技術的逐步普及，咱們已經看見一個標準化應用層生態正在付出水面。愈來愈多的團隊正在嘗試經過更加用戶友好的數據視圖層，對最終用戶暴露出喜聞樂見的 API，同時對基礎設施工程師提供出更增強大的橫向連通與模塊化的平臺能力。

與此同時，Kubernetes 這個「數據庫」其餘欠缺的部分，也必定會愈來愈多的在社區涌現出來。好比今天正在迅速成熟的 Open Policy Agent（OPA）項目，能夠認爲是「數據攔截校驗和修改機制」這一層的不斷進化結果。再好比阿里巴巴內部在「萬節點」集羣中推動的管控鏈路性能調優工做，其理論基礎和實踐，跟今天的數據庫性能優化，更是有殊途同歸之妙的。

若是你有任何關於 IaD 系統想法，很是歡迎釘釘掃碼加羣同咱們交流！