本文轉自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：
https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources
自定義資源定義（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服務器中對上述任何物件的更改，并確保匹配的部署和配置保持同步，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/694.html
標籤：其他