Kubernetes Operator基礎入門

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