聊聊Kubernetes operator

Operator 在2016年就被引入社區了， CoreOS 推出它旨在簡化複雜有狀態應用管理。Operator是一個感知應用狀態的控制器，經過擴展 Kubernetes API 來自動建立、管理和配置應用實例。 Operator 基於 CRD （Custom Resource Definition）擴展資源對象，並經過控制器來保證應用處於預期狀態。
下面舉個例子，好比etcd operator經過下面的三個步驟模擬了管理etcd集羣的行爲：
一、經過 Kubernetes API 觀察集羣的當前狀態；
二、分析當前狀態與指望狀態的差異；
三、調用k8s API消除這些差異。

下面從不一樣的角度來聊聊Operator
一、operator與docker
咱們先聊一聊docker。docker有很是多的優勢，好比隔離、執行效率等等。可是在我看來，docker的核心價值，或者說顛覆性的成果就是設計了鏡像流程，提供標準化的交付方式。就從單個的應用實例來說，標準化、一致性的環境解決了應用的runtime的問題，將應用的部署、應用的依賴進行了統一的封裝。將應用的部署方式從手工做坊的部署方式帶入了標準化的工業時代。固然這也帶來了必定的磁盤額外損耗。可是在硬件飛速發展的今天，這點磁盤損耗幾乎不成問題。並且藉助於聯合文件系統和鏡像優化，磁盤的損耗問題幾乎不用考慮。
時至今日，愈來愈少的項目採用源碼進行部署。之前一個開源項目每每配上一篇冗長的安裝文檔，教你如何安裝、如何運行。如今，基本上活躍的開源項目都提供了基於容器的部署方式，你只須要拉下鏡像run一下就可使用。docker大大提高了交付的效率，下降了使用的門檻，有效避免了部署的故障。
operator跟docker是類似的，而其主要的交付對象從單個的應用實例，擴展到了多實例、分佈式的系統上。以往部署一個分佈式系統須要啓動多個容器，而後進行復雜的配置，而如今只要建立一個CRD。operator將自動進行分佈式系統中須要的各個資源的建立和部署。從這個角度上來講，operator的目標是實現分佈式系統的標準化交付。

二、operator與Helm
如今咱們通常意義上的編排，也就是orchestration，還有另外一種翻譯就是編配。在維基百科的定義爲描述複雜計算機系統、中間件（middleware）和業務的自動化的安排、協調和管理。根據我我的的經驗，總結編排的典型特徵主要包括服務的版本管理、服務的生命週期管理、多個資源多種資源的管理、參數化以及模板化。
最先接觸編排概念，是經過openstack的heat項目。openstack中從計算、存儲到網絡有不少的系統。而若是部署一個完整的應用虛擬機，須要多種資源的協同參與。heat項目就是爲此目標而生。其經過模板和參數對多種資源進行編排，實現了對一個完整服務的建立、部署、修改、刪除等生命週期管理。

在k8s中，也有許多編排項目，目前比較熱門的是包管理工具Helm。若是說docker是奠基的單實例的標準化交付，那麼Helm則是集羣化多實例、多資源的標準化交付。
operator的管理不只限於容器(pod)，也能夠是多個資源(好比svc域名等等)，從這個角度上來講，operator跟Helm同樣，也是具備編排的能力的。從編排角度來看，在初學者看來，Helm跟operator有很是多的共性，很難對二者的做用進行區分。Helm也能夠完成分佈式系統的部署。那麼operator跟Helm又有什麼樣的區別呢？Helm的側重點在於多種多個的資源管理，而對生命週期的管理主要包括建立更新和刪除。Helm經過命令驅動整個的生命週期。
而operator對於資源的管理則不只是建立和交付。因爲其能夠經過watch的方式獲取相關資源的變化事件，所以能夠實現高可用、可擴展、故障恢復等運維操做。所以operator對於生命週期的管理不只包括建立，故障恢復，高可用，升級，擴容縮容，異常處理，以及最終的清理等等。
那你說這些功能能不能用Helm來實現，其實我以爲有一部分功能應該也是能夠的。可是這裏面就涉及到一個問題，就是這些功能沒法在編排中直接實現，就須要經過腳本或者程序的方式固化到鏡像中。大量的運維代碼被腳本化。會致使維護這些腳本的複雜度提升，可讀性變差。除此以外，還有一個潛在的風險沒法解決的就是，當這些容器實例所有掛掉的時候，則徹底沒法自動恢復了，即便有備份數據。這時候最終還會依賴於人工的介入，仍然沒法達到自動化、智能化的目標。
operator則在實現自動化的同時實現了智能化。其主要的工做流程是根據當前的狀態，進行智能分析判斷，並最終進行建立、恢復、升級等操做。而位於容器中的腳本，由於缺少不少全局的信息，僅靠自身是沒法沒法達實現這些所有的功能的。而處於第三方視角的operator，則能夠解決這個問題。他能夠經過側面的觀察，獲取全部的資源的狀態和信息，而且跟預想/聲明的狀態進行比較。經過預置的分析流程進行判斷，從而進行相應的操做，並最終達到聲明狀態的一個目的。這樣全部的運維邏輯就從鏡像中抽取出來，集中到operator裏去。層次和邏輯也就更加清楚，容易維護，也更容易交付和傳承。
若是把Helm比做rpm，那麼operator就是systemd。rpm負責應用的安裝、刪除，而systemd則負責應用的啓動、重啓等等操做。固然兩者並非互斥的，目前operator一種比較便捷的部署方式就是經過Helm進行部署。

三、operator與controller
operator能夠說是另一種controller。目前的controller manager集合的主要是基礎的、通用的資源概念，好比rs/deployment，而對於特定的應用或者服務（如etcdcluster，均可以認爲是一種資源），則放權給了第三方，也就是CRD。用戶能夠經過自定義的資源描述，以及自研的controller/operator進行接入。所以controller和operator的關係有點相似於標準庫和第三方庫的關係。
通常來講，對於不一樣的應用通常來講須要不一樣的operator進行處理。這時咱們再來想下，以replicaset controller爲例。rs的主要功能是保持副本數。當有pod因某種緣由掛掉/刪除，對於無狀態的應用來講，恢復的方式就是再增長對應的pod數量。那麼從這個角度來講，對於無狀態的應用來講，rs controller其實就是無狀態應用的operator。

operator的核心價值
咱們原先經常講devops，就是運維和開發的結合，提高開發交付的效率和質量。這也帶來了一個趨勢，就是運維和開發一體化。好比原來開發應用的人，經過docker鏡像的製做，將應用的部署啓動等固化在了dockerfile/鏡像中，分擔了運維的許多部署工做。可是實際上運維的工做內容和範圍其實很是廣，特別是如今的分佈式的系統，包括集羣化部署、高可用、故障恢復、系統升級等等工做。而這些是沒法僅用dockerfile/鏡像進行固化的。
operator提供了一種可能，或者說是提供了一個很好的框架，就是把運維的經驗沉澱爲代碼，實現運維的代碼化、自動化、智能化。以往的高可用、擴展收縮，以及故障恢復等等運維操做，都經過operator進行沉澱下來。從長期來看，將會推動dev、ops、devops的深度一體化。將運維經驗、應用的各類方案和功能經過代碼的方式進行固化和傳承，減小人爲故障的機率，提高整個運維的效率。
operator的許多理念並非如今纔有的。在yarn中的application manager，mesos中的framework，均可以尋找到operator的一些蛛絲馬跡。而之因此說operator將可能成爲docker以後的又一項重大變革，其另一個重要的因素就是operator是站在kubernetes的巨人肩膀上。
kubernetes強化了基礎資源的封裝，並保持了靈活性和可定製性。kubernetes從傳統的資源(cpu/mem)的交付，轉爲了pod/svc/pv/pvc等資源的交付，擴展了資源的概念，將域名、負載均衡、存儲等等必要或相關的概念也都進行了封裝。而operator這些公共的資源基礎上，將應用集羣也視爲了一種資源，能夠向用戶提供。而且藉助於k8s已有的工做機制和框架，從而更爲便捷靈活的實現。
operator的變革雖然重大，可是因爲分佈式應用主要限於工業生產領域，所以對通常的開發而言可能最終使用場景有限。所以我判斷從全局看，operator的最終影響力有限，但在許多分佈式應用的垂直領域，會產生巨大的影響。

最後使用operator的前提就是能夠實現容器化。即應用可使用容器來進行應用的自動化的部署。operator化不只僅是開發一個operator的程序，還須要結合鏡像的製做、交付、封裝等工做。仍然是須要大量的開發工做的。可是一旦成熟穩定，也會帶來巨大的運維收益和長期的效果。