本文轉自Rancher Labs
你是否曾經想過SRE團隊是如何有效地成功管理複雜的應用？在Kubernetes生態系統中，Kubernetes Operator可以給你答案。在本文中，我們將研究Operator是什麼以及它們如何工作。
Kubernetes Operator這一概念是由CoreOS的工程師於2016年提出的，這是一種原生的方式來構建和驅動Kubernetes叢集上的每一個應用，它需要特定領域的知識。它提供了一種一致的方法，通過與Kubernetes API的緊密合作，自動處理所有應用操作過程，而不需要任何人工干預。換句話說，Operator是一種包裝、執行和管理Kubernetes應用的方式。
Kubernetes Operator模式遵循Kubernetes的核心原則之一：控制理論（control theory）。在機器人和自動化領域，它是一種持續執行動態系統的機制。它依賴於一種快速調整工作負載需求的能力，進而能夠儘可能準確地適應現有資源。其目標是開發一個具有必要邏輯的控制模型，以幫助應用程式或系統保持穩定。在Kubernetes世界中，這部分由controller處理。
在迴圈中，Controller是個特殊的軟體，它可以對叢集的變化做出響應，並執行適應動作。第一個Kubernetes controller是一個kube-controller-manager。它被認為是所有Operator的前身，Operator是後來建立的。
什麼是Controller Loop？
簡單來說，Controller Loop是Controller動作的基礎。想象一下，有一個非終止的程式（在Kubernetes中稱為和解迴圈）在不斷地發生，如下圖所示：
這個過程至少觀察一個Kubernetes物件，該物件包含有關所需狀態的資訊。比如：
-
Deployment
-
Services
-
Secrets
-
Ingress
-
Config Maps
這些物件由JSON或YAML中的manifest組成的配置檔案定義。然後controller根據內建邏輯，通過Kubernetes API進行持續調整，模仿所需狀態，直到當前狀態變成所需狀態。
通過這種方式，Kubernetes通過處理不斷的更改來處理Cloud Native系統的動態性質。為達到預期狀態而執行的修改例項包括：
-
注意到節點當機時，要求更換新的節點。
-
檢查是否需要複製pods。
-
如果需要，建立一個新的負載均衡器。
Kubernetes Operator如何工作？
Operator是一個特定應用程式的controller，它擴充套件了一個Kubernetes API，替代運維工程師或SRE工程師來建立、配置和管理複雜的應用程式。在Kubernetes官方文件中對此有以下描述：
Operator是Kubernetes的軟體擴充，它利用自定義資源來管理應用程式及其元件。Operator遵循Kubernetes的原則，尤其遵循control loop。
到目前為止，你已經瞭解Operator會利用觀察Kubernetes物件的controller。這些controller有點不同，因為它們正在追蹤自定義物件，通常稱為自定義資源（CR）。CR是Kubernetes API的擴充套件，它提供了一個可以儲存和檢索結構化資料的地方——你的應用程式的期望狀態。整個操作原理如下圖所示：
Operator會持續跟蹤與特定型別的自定義資源相關的叢集事件。可以跟蹤的關於這些自定義資源的事件型別有：
-
Add
-
Update
-
Delete
當Operator接收任何資訊時，它將採取行動將Kubernetes叢集或外部系統調整到所需的狀態，作為其在自定義controller中的和解迴圈（reconciliation loop）的一部分。
如何新增一個自定義資源
自定義資源通過新增對你的應用有幫助的新型物件來擴充套件Kubernetes功能。Kubernetes提供了兩種向叢集新增自定義資源的方法：
通過API Aggregation新增，這是一種高階方法，需要你建立自己的API伺服器，但你有更多的控制許可權。
通過自定義資源定義（CRD）新增，一種不需要複雜程式設計知識就可以建立的簡單方式，作為Kubernetes API伺服器的擴充套件。
這兩種方案滿足了不同使用者的需求，他們可以在靈活性和易用性之間進行選擇。Kubernetes社群對兩者進行了比較，將幫助你決定哪種方法適合你，但目前最受歡迎的選項是CRD：
自定義資源定義（CRD）
自定義資源定義（CRD）的出現已經有一段時間了，第一個主要的API規範是與Kubernetes 1.16.0一起釋出的。下面的manifest介紹了一個例子：
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
name: application.stable.example.com
spec:
group: stable.example.com
version: v1
scope: Namespaced
names:
plural: application
singular: applications
kind: Application
shortNames:
- app
這個CRD可以讓你建立一個名為“Application”的CR（我們將會在下一個部分使用它）。前兩行定義了apiVersion和你要建立的物件種類。
Metadata描述了資源名稱，但這裡最重要的部分是“spec”欄位。它讓你可以指定組、版本以及可見性範圍——名稱空間或叢集範圍。
然後，你可以用多種格式定義名稱，並建立一個方便的縮寫，讓你執行命令kubectl get app來獲取現有的CR。
自定義資源
以上CRD可以讓你建立以下自定義資源的manifest。
apiVersion: stable.example.com/v1
kind: Application
metadata:
name: application-config
spec:
image: container-registry-image:v1.0.0
domain: teamx.yoursaas.io
plan: premium
如你所見，在這裡包含了執行特定情況下的應用程式所需的所有必要資訊。這個自定義資源將被我們的Operator觀察到——準確地說，是被Operator的自定義controller觀察到。根據controller中的內建邏輯，將模仿所需的狀態。它可以為我們的應用程式建立部署、服務和必要的ConfigMaps。執行它，並在特定的域上通過 ingress 暴露它。這只是一個簡單的用例，但你可以根據自己的需求對它進行任何設計。
Operator還可以配置在Kubernetes之外的資源。你可以在不離開Kubernetes平臺的情況下控制外部路由器的配置或在雲中建立資料庫。
Kubernetes Operators：案例研究
為了對Kubernetes Operator有一個整體清晰的認識，我們來看看Prometheus Operator，它是最早也是最流行的Operator之一。它簡化了Prometheus、Alertmanager以及相關監控元件的部署和配置。
Prometheus Operator的核心功能是監控Kubernetes API伺服器上指定物件的變化，並確保當前的Prometheus部署與這些物件相匹配。Operator作用於以下自定義資源定義（CRD）：
-
Prometheus：定義了所需Prometheus部署
-
Alertmanager：定義了所需的Alertmanager部署
-
ServiceMonitor：它宣告性地指定了應該如何監控Kubernetes服務的組。Operator會根據API伺服器中物件的當前狀態自動生成Prometheus scrape配置。
-
PodMonitor：宣告性地指定了應如何監控一組 pod。Operator 會根據 API 伺服器中物件的當前狀態自動生成 Prometheus scrape 配置。
-
PrometheusRule：定義了一組所需的 Prometheus 告警和/或記錄規則。Operator會生成一個規則檔案，可供 Prometheus 例項使用。
Prometheus Operator會自動檢測Kubernetes API伺服器中對上述任何物件的更改，並確保匹配的部署和配置保持同步。