本文轉自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服務器中對上述任何對象的更改，並確保匹配的部署和配置保持同步。