戳藍字“CSDN云計算”關注我們哦！

前情回顧：《Kubernetes API 與 Operator：不為人知的開發者戰爭（上）》
2016 年秋天，原 CoreOS 公司的工程師鄧洪超像往常一樣，來到了同事位于福斯特城（Foster City）的公寓進行結對編程。每周四相約在這里結對，是這兩位工程師多年來約定俗成的慣例。

CoreOS 當年開發 etcd 所在的車庫
不過，與以往不同的是，相比于往常天馬行空般的頭腦風暴，這一次，這兩位工程師的腦子里正在琢磨著的，是一個非?！敖拥貧狻钡男№椖?。

我們知道，Kubernetes 項目實現“容器編排”的核心，在于一個叫做“控制器模式”的機制，即：通過對 etcd 里的 API 對象的變化進行監視（Watch），Kubernetes 項目就可以在一個叫做 Controller 的組件里對這些變化進行響應。而無論是 Pod 等應用對象，還是 iptables、存儲設備等服務對象，任何一個 API 對象發生變化，那么 Kubernetes 接下來需要執行的響應邏輯，就是對應的 Controller 里定義的編排動作。
所以，一個自然而然的想法就是，作為 Kubernetes 項目的用戶，我能不能自己編寫一個 Controller 來定義我所期望的編排動作呢？比如：當一個 Pod 對象被更新的時候，我的 Controller 可以在“原地”對 Pod 進行“重啟”，而不是像 Deployment 那樣必須先刪除 Pod，然后再創建 Pod。
這個想法，其實是很多應用開發者以及 PaaS 用戶的強烈需求，也是一直以來縈繞在 CoreOS 公司 CEO Alex Polvi 腦海里的一個念頭。而在一次簡單的內部討論提及之后，這個念頭很快就激發出了兩位工程師的技術靈感，成為了周四結對編程的新主題。
而這一次，他們決定把這個小項目，起名叫做：Operator。
所以顧名思義，Operator 這個項目最開始的初衷，是用來幫助開發者實現運維（Operate）能力的。但 Operator 的核心思想，卻并不是“替開發者做運維工作”，而是“讓開發者自己編寫運維工具”。更有意思的是，這個運維工具的編寫標準，或者說，編寫 Operator 代碼可以參考的模板，正是 Kubernetes 的“控制器模式（Controller Pattern）”。
前面已經說過， Kubernetes 的“控制器模式”，是圍繞著比如 Pod 這樣的 API 對象，在 Controller 通過響應它的增刪改查來定義對 Pod 的編排動作。
而 Operator 的設計思路，就是允許開發者在 Kubernetes 里添加一個新的 API 對象，用來描述一個分布式應用的集群。然后，在這個 API 對象的 Controller 里，開發者就可以定義對這個分布式應用集群的運維動作了。
舉個例子， 假設下面這個 YAML 文件定義的，是一個 3 節點 etcd 集群的描述：

apiVersion: "etcd.database.coreos.com/v1beta2"

kind: "EtcdCluster"

metadata:

?name: "example-etcd-cluster"

spec:

?size: 3

?version: "3.2.13"

有了這樣一個 etcdCluster 對象，那么開發者接下來要做的事情，就是編寫一個 etcdCluster Controller，使得當任何用戶提交這樣一個 YAML 文件給 Kubernetes 之后，我們自己編寫的 Controller 就會響應 etcdCluster “增加”事件，為用戶創建出 3 個節點的 etcd 集群出來。然后，它還會按照我們在 Controller 編寫的事件響應邏輯，自動的對這個集群的節點更新、刪除等事件做出處理，執行我定義的其他運維功能。像這樣一個 etcdCluster Controller，就是 etcd Operator 的核心組成部分了。
而作為 etcd 的開發者，CoreOS 的兩位工程師把對 etcd 集群的運維工作編寫成 Go 語言代碼，一點都不困難?？墒?#xff0c;要完成這個 Operator 真正困難在于：Kubernetes 只認識 Pod、Node、Service 等這些 Kubernetes 自己原生的 API 對象，它怎么可能認識開發者自己定義的這個 etcdCluster 對象呢？
在當時， Kubernetes 項目允許用戶自己添加 API 對象的插件能力，叫做 Third Party Resource，簡稱：TPR。
TPR 允許你提交一個 YAML 文件，來定義你想要的的新 API 對象的名字，比如：etcdCluster；也允許你定義這個對象允許的合法的屬性，比如：int 格式的 size 字段， string 格式的 version 字段。然后，你就可以提交一個具體的 etcdCluster 對象的描述文件給 Kubernetes，等待該對應的 Controller 進行處理。
而這個 Controller，就是 Operator 的主干代碼了。
所以接下來，CoreOS 的兩位工程師輕車熟路，在 Operator 里對 etcdCluster 對象的增、刪、改事件的響應位置，寫上了創建、刪除、更新 etcd 節點的操作邏輯。然后，調試運行，看著一個 etcd 集群按照 YAML 文件里的描述被創建起來。大功告成！
就這樣，在一個普通的周四下午，世界上第一個 Operator 誕生在了灣區的一所公寓當中。
而對于 CoreOS 的兩位工程師來說，編寫這個小工具的主要目的，就是借助 Kubernetes 的核心原理來自動化的管理 etcd 集群，更重要的是，不需要使用 Kubernetes 里自帶的 StatefulSet。
你可能已經知道，Kubernetes 里本身就內置了一個叫做 StatefulSet 的功能，是專門用來管理有狀態應用的。而 StatefulSet 的核心原理，其實是對分布式應用的兩種狀態進行了保持：

• 分布式應用的拓撲狀態，或者說，節點之間的啟動順序；

• 分布式應用的存儲狀態，或者說，每個節點依賴的持久化數據。

可是，為了能夠實現上述兩種狀態的保持機制，StatefulSet 的設計就給應用開發者帶來了額外的束縛。
比如，etcd 集群各節點之間的拓撲關系，并不依賴于節點名字或者角色（比如 Master 或者 Slave）來確定，而是記錄在每個 etcd 節點的啟動參數當中。這使得 StatefulSet 通過“為節點分配有序的 DNS 名字”的拓撲保持方式，實際上沒有了用武之地，反而還得要求開發者在節點的啟動命令里添加大量的邏輯來生成正確的啟動命令，非常不優雅。類似的，對于存儲狀態來說，etcd 集群對數據的備份和恢復方法，也跟 StatefulSet 依賴的的遠程持久化數據卷方案并沒有太大關系。
不難看到， StatefulSet 其實比較適用于應用本身節點管理能力不完善的項目，比如 MySQL。而對于 etcd 這種已經借助 Raft 實現了自管理的分布式應用來說， StatefulSet 的使用方法和帶來的各種限制，其實是非常別扭的。
而帶著工程師特有的較真兒精神，鄧洪超和他的同事借助 Kubernetes 原生的擴展機制實現的，正是一個比 StatefulSet 更加靈活、能夠把控制權重新交還給開發者的分布式應用管理工具。他們把這個工具起名叫做 Operator，并在幾個月后的 KubeCon 上進行了一次 Demo ，推薦大家嘗試使用 Operator 來部署 etcd 集群。
沒有人能想到的是，這個當時還處于 PoC 狀態的小項目一經公布，就立刻激發起了整個社區的模仿和學習的熱潮。
很快，大量的應用開發者紛紛涌進 Kubernetes 社區，爭先恐后的宣布自己的分布式項目可以通過 Operator 運行起來。而敏銳的公有云提供商們很快看出了這其中的端倪：Operator 這個小框架，已然成為了分布式應用和有狀態應用“上云”的必經之路。Prometheus，Rook，伴隨著越來越多的、以往在容器里運行起來困難重重的應用，通過 Operator 走上了 Kubernetes 之后，Kubernetes 項目第一次出現在了開發者生態的核心位置。這個局面，已經遠遠超出了鄧洪超甚至 CoreOS 公司自己的預期。
更重要的是，不同于 StatefulSet 等 Kubernetes 原生的編排概念，Operator 依賴的 Kubernetes 能力，只有最核心的聲明式 API 與控制器模式；Operator 具體的實現邏輯，則編寫在自定義 Controller 的代碼中。這種設計給開發者賦予了極高的自由度，這在整個云計算和 PaaS 領域的發展過程中，都是非常罕見的。
此外，相比于 Helm、Docker Compose 等描述應用靜態關系的編排工具，Operator 定義的乃是應用運行起來后整個集群的動態邏輯。得益于 Kubernetes 項目良好的聲明式 API 的設計和開發者友好的 API 編程范式，Operator 在保證上述自由度的同時，又可以始終如一的展現出清晰的架構和設計邏輯，使得應用的開發者們，可以通過復制粘貼就快速搭建出一個 Operator 的框架，然后專注于填寫自己的業務邏輯。
在向來講究“用腳投票”的開發者生態當中，Operator 這樣一個編程友好、架構清晰、方便代碼復制粘貼的小工具，本身就已經具備了某些成功的特質。
然而，Operator 的意外走紅，并沒有讓 CoreOS 公司“一夜成名”，反而差點將這個初出茅廬的項目，扼殺在萌芽狀態。
在當時的 Kubernetes 社區里，跟應用開發者打交道并不是一個非常常見的事情。而 Operator 項目的誕生，卻把 Kubernetes 項目第一次拉近到了開發者的面前，這讓整個社區感覺了不適應。而作為 Kubernetes 項目 API 治理的負責人，Google 團隊對這種沖突的感受最為明顯。
對于 Google 團隊來說，Controller 以及控制器模式，應該是一個隱藏在 Kubernetes 內部實現里的核心機制，并不適合直接開放給開發者來使用。退一步說，即使開放出去，這個 Controller 的設計和用法，也應該按照 Kubernetes 現有的 API 層規范來進行，最好能成為 Kubernetes 內置 Controller Manager 管理下的一部分?？墒?#xff0c; Operator 卻把直接編寫 Controller 代碼的自由度完全交給了開發者，成為了一個游離于 Kubernetes Controller Manager 之外的外部組件。
帶著這個想法，社區里的很多團隊從 Operator 項目誕生一開始，就對它的設計和演進方向提出了質疑，甚至建議將 Operator 的名字修改為 Custom Kubernetes Controller。而無巧不成書，就在 Google 和 CoreOS 在 Controller 的話語權上爭執不下的時候， Kubernetes 項目的發起人之一 Brendan Burns 突然宣布加入了微軟，這讓 Google 團隊和 Operator 項目的關系一下子跌倒了冰點。
你可能會有些困惑：Brendan Burns 與 Kubernetes 的關系我是清楚的，但這跟 Operator 又有什么瓜葛嗎？
實際上，你可能很難想到，Brendan Burns 和他的團隊，才是 TPR （Third Party Resource）這個特性最初的發起人。
所以，幾乎在一夜之間，Operator 項目鏈路上的每一個環節，都與 Google 團隊完美的擦肩而過。眼睜睜的看著這個正冉冉升起的開發者工具突然就跟自己完全沒了關系，這個中滋味，確實不太好受。
于是，在 2017年初，Google 團隊和 RedHat 公司開始主動在社區推廣 UAS（User Aggregated APIServer），也就是后來 APIServer Aggregator 的雛形。APIServer Aggregator 的設計思路是允許用戶編寫一個自定義的 APIServer，在這里面添加自定義 API。然后，這個 APIServer 就可以跟 Kubernetes 原生的 APIServer 綁定部署在一起統一提供服務了。不難看到，這個設計與 Google 團隊認為自定義 API 必須在 Kubernetes 現有框架下進行管理的想法還是比較一致的。
緊接著，RedHat 和 Google 聯盟開始游說社區使用 UAS 機制取代 TPR，并且建議直接從 Kubernetes 項目里廢棄 TPR 這個功能。一時間，社區里謠言四起，不少已經通過 TPR 實現的項目，也開始轉而使用 UAS 來重構以求自保。 而 Operator 這個嚴重依賴于 TPR 的小項目，還沒來得及發展壯大，就被推向了關閉的邊緣。
面對幾乎要與社區背道而馳的困境，CoreOS 公司的 CTO Brandon Philips 做出了一個大膽的決定：讓社區里的所有開發者發聲，挽救 TPR 和 Operator。
2017 年 2月，Brandon Philips 在 GitHub 上開了一個帖子（Gist）， 號召所有使用 TPR 或者 Operator 項目的開發者在這里留下的自己的項目鏈接或者描述。這個帖子，迅速的成為了當年容器技術圈最熱門的事件之一，登上了 HackerNews 的頭條。有趣的是，這個帖子直到今天也仍然健在，甚至還在被更新，你可以點擊這個鏈接去感受一下當時的盛況。https://gist.github.com/philips/a97a143546c87b86b870a82a753db14c
而伴隨著 Kubernetes 項目的迅速崛起，短短一年時間不到，夾縫中求生存的 Operator 項目，開始對公有云市場產生了不可逆轉的影響，也逐步改變了開發者們對“云”以及云上應用開發模式的基本認知。甚至就連 Google Cloud 自己最大的客戶之一 Snapchat ，也成為了 Operator 項目的忠實用戶。在來自社區的巨大壓力下，在這個由成千上萬開發者們自發維護起來的 Operator 生態面前，Google 和 RedHat 公司最終選擇了反省和退讓。
有意思的是，這個退讓的結果，再一次為這次鬧劇增添了幾分戲劇性。
就在 Brandon Phillips 的開發者搜集帖發布了不到三個月后，RedHat 和 Google 公司的工程師突然在 Kubernetes 社區里宣布：TPR 即將被廢棄，取而代之的是一個名叫 CRD，Custom Resource Definition 的東西。
于是，開發者們開始憂心忡忡的按照文檔，將原本使用 TPR 的代碼都升級成 CRD。而就在這時，他們卻驚奇的發現，這兩種機制除了名字之外，好像并沒有任何不同。所謂的升級工作，其實就是將代碼里的 TPR 字樣全局替換成 CRD 而已。
難道，這只是虛驚一場？
其實，很少有人注意到，在 TPR 被替換成 CRD 之后，Brendan Burns 和微軟團隊就再也沒有出現在“自定義 API”這個至關重要的領域里了。而 CRD 現在的負責人，都是來自 Google 和 RedHat 的工程師。
在這次升級事件之后不久，CoreOS 公司在它的官方網站上發布了一篇叫做：TPR Is Dead! Kubernetes 1.7 Turns to CRD 的博客（https://coreos.com/blog/custom-resource-kubernetes-v17），旨在指導用戶從 TRP 升級成 CRD。不過，現在回頭再看一眼這篇文章，平淡無奇的講述背后，你能否感受到當年這場“開發者戰爭”的蛛絲馬跡呢？
其實，Operator 并不平坦的晉級之路，只是 Kubernetes API 生態風起云涌的冰山一角。幾乎在每個星期，甚至每一天，都有太多圍繞著 Kubernetes 開發者生態的角逐，在這個無比繁榮的社區背后，以不為人知的方式開始或者謝幕。
而這一切紛爭的根本原因卻無比直白。Kubernetes 項目，已經被廣泛認可為云計算時代應用開發者們的終端入口。這正是為何，無論是 Google、微軟，還是 CoreOS 以及 Heptio，所有這個生態里的大小玩家，都在不遺余力的在 Kubernetes API 層上捍衛著自己的話語權，以期在這個未來云時代的開發者入口上，爭取到自己的一席之地。

而在完成了對收 CoreOS 的收購之后，RedHat 終于在這一領域拿到了可以跟 Google 和微軟一較高低的關鍵位置。2018年，RedHat 不失時機的發布了 Operator Framework，希望通過 Operator 周邊工具和生態的進一步完善，把 Operator 確立成為分布式應用開發與管理的關鍵依賴。而伴隨著 Operator 越來越多的介入到應用開發和部署流程之后， Kubernetes API 一定會繼續向上演進，進一步影響開發者的認知和編程習慣。這，已經成為了云計算生態繼續發展下去的必然趨勢。
而作為這個趨勢堅定不移的貫徹者，無論是 Istio，還是 Knative，都在用同樣的經歷告訴我們這樣的道理：只有構建在 Kubernetes 這個云時代基礎設施事實標準上的開發者工具，才有可能成為下一個開發者領域的 “Operator” 。

推薦閱讀

• 關于云原生，這是最詳細的技術知識

• 用“AI”給吳秀波測面相，發現……

• 程序員一畢業就年薪 110 萬竟然是靠……

• 程序員鎖死服務器失蹤，公司解散 600 萬項目徹底黃了！

• 史上最全新媒體運營工具（121種）

• 一年省下1000億? 原來零售玩的是悶聲發大財
  

• Spark+Alluxio性能調優十大技巧
  

• 從云計算到AI：NetApp的數據網絡轉型之道
  

1.微信群：

添加小編微信：color_ld，備注“進群+姓名+公司職位”即可，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！

2.征稿：

投稿郵箱：liudan@csdn.net；微信號：color_ld。請備注投稿+姓名+公司職位。

喜歡就點擊“好看”吧！

總結

以上是生活随笔為你收集整理的Kubernetes API 与 Operator：不为人知的开发者战争的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。