親歷者說：Kubernetes API 與 Operator，鮮爲人知的開發者戰爭

若是我問你，如何把一個 etcd 集羣部署在 Google Cloud 或者阿里雲上，你必定會不假思索的給出答案：固然是用 etcd Operator！

實際上，幾乎在一晚上之間，Kubernetes Operator 這個新生事物，就成了開發和部署分佈式應用的一項事實標準。時至今日，不管是 etcd、TiDB、Redis，仍是 Kafka、RocketMQ、Spark、TensorFlow，幾乎每個你能叫上名字來的分佈式項目，都由官方維護着各自的 Kubernetes Operator。而 Operator 官方庫裏，也一直維護着一個知名分佈式項目的 Operator 彙總。

github.com/operator-fr…

短短一年多時間，這個列表的長度已經增加了幾十倍。

並且更有意思的是，若是你仔細翻閱這個 Operator 列表，你就不難發現這樣一個有趣的事實：現今 Kubernetes Operator 的意義，恐怕已經遠遠超過了「分佈式應用部署」的這個原始的範疇，而已然成爲了容器化時代應用開發與發佈的一個全新途徑。因此，你纔會在這個列表裏看到，Android SDK 的開發者們，正在使用 Operator 「一鍵」生成和更新 Android 開發環境；而 Linux 系統工程師們，則在使用Operator 「一鍵」重現性能測試集羣。

若是說，Docker 鏡像的提出，完成了應用靜態描述的標準化。那麼 Kubernetes Operator 的出現，終於爲應用的動態描述提出了一套行之有效的實現規範。更爲重要的是，對於 TiDB、Kafka、RocketMQ 等分佈式應用的開發者來講，這些應用運行起來以後的動態描述，纔是對一個分佈式應用真正有意義的信息。

而在此以前，用戶若是要想將 TiDB、Kafka 這樣的分佈式應用很好的使用起來，就不得不去嘗試編寫一套複雜的管理腳本，甚至爲此學習大量與項目自己無關的運維知識。更爲麻煩的是，這些腳本、知識、和經驗，並無一個很好的辦法可以有效的沉澱下來。而任何一種技術的傳授，若是嚴重依賴於口口相傳而不是固化的代碼和邏輯的話，那麼它的維護成本和使用門檻，就能夠說是「災難級」的。

因此說，Kubernetes Operator 發佈之初最大的意義，就在於它將分佈式應用的使用門檻直接降到了最低。

那麼這個門檻具體有多低呢？

通常來講，不管這個分佈式應用項目有多複雜，只要它爲用戶提供了 Operator，那麼這個項目的使用就只須要兩條命令便可搞定，以 Kafka 爲例：

這兩條命令執行完成後，一個 Kafka 集羣運行所需的節點，以及它們所依賴的 ZooKeeper 節點，就會以容器的方式自動出如今你的 Kubernetes 集羣裏了。

不過，簡化運維和部署，其實只是 Operator 在用戶層面的表象。而在更底層的技術層面，Operator 最大的價值，在於它爲「容器究竟能不能管理有狀態應用」這個頗具爭議話題，畫上了一個優雅的句號。

要知道，在2014-2015年的時候，伴隨着 Docker 公司和 Docker 項目的走紅，整個雲計算生態幾乎都陷入了名爲「容器」的狂熱當中。然而，相比於 「容器化」浪潮的如火如荼，這個圈子卻始終對「有狀態應用」諱莫如深。

事實上，有狀態應用（好比， 前面提到的Kafka ）跟無狀態應用（好比，一個簡單的Jave Web網站）的不一樣之處，就在於前者對某些外部資源有着綁定性的依賴，好比遠程存儲，或者網絡設備，以及，有狀態應用的多個示例之間每每有着拓撲關係。這兩種設計，在軟件工程的世界裏能夠說再普通不過了，並且咱們幾乎能夠下這樣一個結論：全部的分佈式應用都是有狀態應用。

可是，在容器的世界裏，分佈式應用卻成了一個「異類」。咱們知道，容器的本質，其實就是一個被限制了「世界觀」的進程。在這種隔離和限制的大基調下，容器技術自己的「人格基因」，就是對外部世界（即：宿主機）的「視而不見」和「充耳不聞」。因此咱們常常說，容器的「狀態」必定是「易失」的。其實，容器對它的「小世界」以外的狀態和數據不聞不問，正是這種「隔離性」的主要體現。

但狀態「易失」並不能說是容器的缺陷：咱們既然對容器能夠重現完整的應用執行環境的「一致性」拍手稱讚，那就必然要對這種能力背後的限制瞭然於心。這種默契，也正是早期的 Docker 公司所向披靡的重要背景：在這個階段，相比於「容器化」的巨大吸引力，開發者是能夠暫時接受一部分應用不能運行在容器裏的。

而分佈式應用容器化的困境，其實就在於它成爲了這種「容器化」默契的「終極破壞者」。

一個應用自己能夠擁有多個可擴展的實例，這原本是容器化應用使人津津樂道的一個優點。可是一旦這些實例像分佈式應用這樣具備了拓撲關係，以及，這些實例自己不徹底等價的時候，容器化的解決方案就再次變得「醜陋」起來：這種狀況下，應用開發者們不只又要爲這些容器實例編寫一套難以維護的管理腳本，還必需要想辦法應對容器重啓後狀態丟失的難題。而這些容器狀態的維護，實際上每每須要打破容器的隔離性、讓容器對外部世界有所感知才能作到，這就使得容器化與有狀態，成爲了兩種徹底相悖的需求。

不過，從上面的敘述中相信你也應該已經察覺到，分佈式應用容器化的難點，並不在於容器自己有什麼重大缺陷，而在於咱們一直以來缺少一種對「狀態」的合理的抽象與描述，使得狀態能夠和容器進程自己解耦開來。這也就解釋了爲何，在 Kubernetes 這樣的外部編排框架逐漸成熟起了以後，業界才逐漸對有狀態應用管理開始有了比較清晰的理解和認識。

而咱們知道， Kubernetes 項目最具價值的理念，就是它圍繞 etcd 構建出來的一套「面向終態」編排體系，這套體系在開源社區裏，就是大名鼎鼎的「聲明式 API」。

「聲明式 API」的核心原理，就是當用戶向 Kubernetes 提交了一個 API 對象的描述以後，Kubernetes 會負責爲你保證整個集羣裏各項資源的狀態，都與你的 API 對象描述的需求相一致。更重要的是，這個保證是一項「無條件的」、「沒有期限」的承諾：對於每一個保存在 etcd 裏的 API 對象，Kubernetes 都經過啓動一種叫作「控制器模式」（Controller Pattern）的無限循環，不斷檢查，而後調諧，最後確保整個集羣的狀態與這個 API 對象的描述一致。

好比，你提交的 API 對象是一個應用，描述的是這個應用必須有三個實例，那麼不管接下來你的 API 對象發生任何「風吹草動」，控制器都會檢查一遍這個集羣裏是否是真的有三個應用實例在運行。而且，它會根據此次檢查的結果來決定，是否是須要對集羣作某些操做來完成此次「調諧」過程。固然，這裏控制器正是依靠 etcd 的 Watch API 來實現對 API 對象變化的感知的。在整個過程當中，你提交的 API 對象就是 Kubernetes 控制器眼中的「金科玉律」，是接下來控制器執行調諧邏輯要達到的惟一狀態。這就是咱們所說的「終態」的含義。

而 Operator 的設計，其實就是把這個「控制器」模式的思想，貫徹的更加完全。在 Operator 裏，你提交的 API 對象再也不是一個單體應用的描述，而是一個完整的分佈式應用集羣的描述。這裏的區別在於，整個分佈式應用集羣的狀態和定義，都成了Kubernetes 控制器須要保證的「終態」。好比，這個應用有幾個實例，實例間的關係如何處理，實例須要把數據存儲在哪裏，如何對實例數據進行備份和恢復，都是這個控制器須要根據 API 對象的變化進行處理的邏輯。

從上述敘述中，你就應該可以明白， Operator 其實就是一段代碼，這段代碼 Watch 了 etcd 裏一個描述分佈式應用集羣的API 對象，而後這段代碼經過實現 Kubernetes 的控制器模式，來保證這個集羣始終跟用戶的定義徹底相同。而在這個過程當中，Operator 也有能力利用 Kubernetes 的存儲、網絡插件等外部資源，協同的爲應用狀態的保持提供幫助。

因此說，Operator 自己在實現上，實際上是在 Kubernetes 聲明式 API 基礎上的一種「微創新」。它合理的利用了 Kubernetes API 能夠添加自定義 API 類型的能力，而後又巧妙的經過 Kubernetes 原生的「控制器模式」，完成了一個面向分佈式應用終態的調諧過程。

而 Operator 自己在用法上，則是一個須要用戶大量編寫代碼的的開發者工具。 不過，這個編寫代碼的過程，並無像不少人當初料想的那樣致使 Operator 項目走向小衆，反而在短短三年的時間裏， Operator 就迅速成爲了容器化分佈式應用管理的事實標準。時至今日，Operator 項目的生態地位已經毋庸置疑。就在剛剛結束的2018年 KubeCon 北美峯會上，Operator 項目和大量的用戶案例一次又一次出如今聚光燈前，不斷的印證着這個小小的「微創新」對整個雲計算社區所產生的深遠影響。

不過，在 Operator 項目引人矚目的成長經歷背後，你是否考慮過這樣一個問題：

Kubernetes 項目一直以來，其實都內置着一個管理有狀態應用的能力叫做 StatefulSet。而若是你稍微瞭解 Kubernetes 項目的話就不難發現，Operator 和 StatefulSet，雖然在對應用狀態的抽象上有所不一樣，但它們的設計原理，幾乎是徹底一致的，即：這兩種機制的本質，都是圍繞Kubernetes API 對象的「終態」進行調諧的一個控制器（Controller）而已。

但是，爲何在一個開源社區裏，會同時存在這樣的兩個核心原理徹底一致、設計目標也幾乎相同的有狀態應用管理方案呢？做爲 CoreOS 公司後來廣爲人知的「左膀右臂」之一（即：etcd 和 Operator），Operator 項目可以在 Kubernetes 生態裏爭取到今天的位置，是否是也是 CoreOS 公司的開源戰略使然呢？

事實上，Operator 項目並無像不少人想象的那樣出生就含着金鑰匙。只不過，在當時的確沒有人能想到，當 CoreOS 的兩名工程師帶着一個業餘項目從一間平淡無奇的公寓走出後不久，一場圍繞着 Kubernetes API 生態、以爭奪「分佈式應用開發者」爲核心的的重量級角逐，就徐徐拉開了序幕。

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 集羣的描述：

有了這樣一個 etcdCluster 對象，那麼開發者接下來要作的事情，就是編寫一個 etcdCluster Controller，使得當任何用戶提交這樣一個 YAML 文件給 Kubernetes 以後，咱們本身編寫的 Controller 就會響應 etcdCluster 「增長」事件，爲用戶建立出 3 個節點的 etcd 集羣出來。而後，它還會按照咱們在 Controller 編寫的事件響應邏輯，自動的對這個集羣的節點更新、刪除等事件作出處理，執行我定義的其餘運維功能。像這樣一個 etcdCluster Controller，就是 etcd Operator 的核心組成部分了。

而做爲 etcd 的開發者，CoreOS 的兩位工程師把對 etcd 集羣的運維工做編寫成 Go 語言代碼，一點都不困難。但是，要完成這個 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 管理下的一部分。但是， 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 的頭條。有趣的是，這個帖子直到今天也仍然健在，甚至還在被更新，你能夠點擊這個連接去感覺一下當時的盛況。gist.github.com/philips/a97…

而伴隨着 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 的博客（coreos.com/blog/custom…），旨在指導用戶從 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」 。