回覆列表
  • 1 # cnBeta

    今日,RedHat 攜手微軟、Google Cloud、亞馬遜 AWS,共同推出了名叫 OperatorHub.io 的集中式儲存庫,以方便 Kubernetes 社群查詢和分享資源。

    2016 年的時候,伴隨著 CoreOS 的推出,Operators 提供了一種打包、部署和管理 Kubernetes 應用程式的方法。遺憾的是,到目前為止,使用者都很難找到相關的資源。

    【Operators 是一套 Kubernetes 應用程式框架】

    有鑑於此,紅帽才下定決心,與科技巨頭聯手推出

    OperatorHub.io

    平臺。除了羅列各種註冊資源,該儲存庫還可輕鬆納入各種高標準的開發框架。

    紅帽社群發展總監 Diane Mueller 在一篇部落格文章中寫到:

    我們正在與 AWS、Google Cloud、微軟合作推出 OperatorHub.io,其旨在成為一個查詢支援 Operators 服務的公共註冊機構。

    登記在列的一個好處,就是那裡的所有內容都符合相關標準,能夠展示 Operators 叢集的生命週期、管理維護、和良好的文件記錄。

    此外,Mueller 提到了該公司的一個重要目標,即降低訪問 Kubernetes 應用程式的門檻。

    我們相信,透過允許應用開發者在 Kubernetes 環境中提供靈活的雲服務,此舉將在降低門檻方面發揮關鍵作用。

    我們希望 OperatorHub.io 的引入,能夠客戶更輕鬆地找到提供其所需支援的服務。

    OperatorHub.io 的推出,為圍繞 Operators 的使用者社群和組織提供了一個便捷的集中式儲存庫。

    我們期待看到 OperatorHub.io 的繼續成長,和推動 Kubernetes 社群的延伸。

  • 2 # 運維老男孩

    是否想知道站點可靠性工程(SRE)團隊如何有效地管理複雜的應用程式?在Kubernetes生態系統中,只有一個答案:Kubernetes Operator!在本文中,我們將研究它們是什麼以及它們如何工作。

    Kubernetes Operator概念是由CoreOS的工程師於2016年提出的,它是在Kubernetes叢集上構建和驅動每個應用程式的高階原生方法,需要特定領域的知識。透過與Kubernetes API的密切合作,它提供了一種一致的方法來自動處理所有應用程式操作流程,而無需任何人工響應。換句話說,Operator是打包,執行和管理Kubernetes應用程式的一種方式。

    Kubernetes Operator模式的行為遵循核心Kubernetes原理之一:控制理論。在機器人技術和自動化中,它是一種連續執行動態系統的機制。它依賴於一種能力,即儘可能準確地根據可用資源快速調整工作負載需求。目的是開發具有必要邏輯的控制模型,以幫助應用程式或系統保持穩定。在Kubernetes世界中,該部分由控制器處理。控制器是一種特殊的軟體,可以在迴圈中響應更改並在叢集中執行調整操作。第一個Kubernetes控制器是kube-controller-manager。它被視為所有Operator的始祖。

    什麼是控制迴圈?

    簡而言之,控制器迴圈是控制器動作的基礎。想象一下,一個非終止過程(在Kubernetes中稱為reconciliation 迴圈)反覆發生,如下圖所示:

    該過程觀察至少一個Kubernetes物件,該物件包含有關所需狀態的資訊。諸如...的物件

    DeploymentsServicesSecretsIngressConfig Maps

    …由配置檔案定義,這些配置檔案由JSON或YAML的清單組成。然後,控制器根據內建邏輯透過Kubernetes API進行連續調整,以模仿所需狀態,直到當前狀態變為所需狀態。

    這樣,Kubernetes透過處理不斷的變化來應對Cloud Native系統的動態特性。為達到預期狀態而執行的修改示例包括:

    注意節點何時出現故障並需要新的節點。檢查是否需要複製Pod。如果需要,請建立一個新的負載均衡器。

    Kubernetes Operator如何工作?

    Operator是特定於應用程式的控制器。它擴充套件了Kubernetes API以代表人員(操作工程師或站點可靠性工程師)建立,配置和管理複雜的應用程式。讓我們看看Kubernetes文件對此有何評論。Operator是Kubernetes的軟體擴充套件,它利用自定義資源來管理應用程式及其元件。Operator遵循Kubernetes原則,尤其是控制迴路。

    到目前為止,您知道Operator利用了觀察Kubernetes物件的控制器。這些控制器有點不同,因為它們跟蹤的是自定義物件,通常稱為自定義資源(CR)。 CR是Kubernetes API的擴充套件,它提供了一個可以儲存和檢索結構化資料(應用程式的期望狀態)的地方。下圖顯示了整個操作原理。

    Operator連續跟蹤與特定型別的定製資源有關的叢集事件。可以跟蹤的這些自定義資源上的事件型別為:

    AddUpdateDelete

    當Operator接收到任何資訊時,它將採取行動將Kubernetes叢集或外部系統調整為所需狀態,作為其自定義控制器中reconciliation 迴圈的一部分。

    如何增加一個Custom Resource

    自定義資源透過新增對你的應用程式有幫助的新物件,擴充套件了Kubernetes的功能。 Kubernetes提供了兩種向叢集新增自定義資源的方法:

    透過API聚合,這是一種高階方法,需要您構建自己的API伺服器,但可以為您提供更多控制權透過自定義資源定義(CRD),這是一種無需任何程式設計知識即可建立的簡單方法,是對原始Kubernetes API伺服器的擴充套件。

    這兩個選項可滿足不同使用者的需求,他們可以在靈活性和易用性之間進行選擇。 Kubernetes社群建立了一個比較,可以幫助您確定適合您的方法,但是最受歡迎的選擇是CRD。

    Custom Resource Definitions

    自定義資源定義已經存在了很長一段時間。 Kubernetes 1.16.0釋出了第一個主要的API規範。以下清單提供了一個示例:

    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。前兩行定義要建立的物件型別CustomResourceDefinition的apiVersion apiextensions.k8s.io/v1beta1。元資料描述了資源的名稱,但最重要的地方是“ spec”欄位。它使您可以指定組和版本以及可見性範圍(名稱空間或叢集範圍)。之後,您可以使用多種格式定義名稱並建立一個方便的簡稱,該名稱使您可以執行命令kubectl get app來獲取現有的CR。

    Custom Resource

    上面的CRD允許您建立以下自定義資源清單。

    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的自定義控制器來觀察。根據控制器中的內建邏輯,必要的動作將模仿所需的狀態。它可以為我們的應用程式建立一個Deployment,Service和必要的ConfigMap。執行它並透過特定域上的入口公開它。這只是用例的一個例子,但是它可以完成設計的任何事情。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抓取配置。PodMonitor, 以宣告方式指定應如何監視一組Pod。Operator根據API伺服器中物件的當前狀態自動生成Prometheus抓取配置。PrometheusRule, 它定義了一組所需的Prometheus警報和/或記錄規則。Operator生成一個規則檔案,Prometheus例項可以使用該檔案。

    Prometheus Operator自動檢測Kubernetes API伺服器中對上述任何物件的更改,並確保匹配的部署和配置保持同步。

  • 中秋節和大豐收的關聯?
  • DNF玩家讓朋友幫升級防具,朋友故意升一件首飾,少升一件防具,你有何看法?