如果我問你，如何把一個 etcd 集群部署在 Google Cloud 或者阿里雲上，你一定會不假思索的給出答案：當然是用 etcd Operator！
實際上，幾乎在一夜之間，Kubernetes Operator 這個新生事物，就成了開發和部署分佈式應用的一項事實標準。時至今日，無論是 etcd、TiDB、Redis，還是 Kafka、RocketMQ、Spark、TensorFlow，幾乎每一個你能叫上名字來的分佈式項目，都由官方維護著各自的 Kubernetes Operator。而 Operator 官方庫裡，也一直維護著一個知名分佈式項目的 Operator 彙總。
https://github.com/operator-framework/awesome-operators
短短一年多時間，這個列表的長度已經增長了幾十倍。
而且更有意思的是，如果你仔細翻閱這個 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 的頭條。有趣的是，這個帖子直到今天也仍然健在，甚至還在被更新，你可以點擊這個鏈接去感受一下當時的盛況。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” 。
閱讀更多 阿里云云棲號 的文章
