我們知道,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 裏,開發者就可以定義對這個分散式應用集羣的運維動作了。