主持人 > 博客 > 管理 > Kubernetes 的 Operator：如何運行有狀態應用程序

Kubernetes 的 Operator：如何運行有狀態應用程序

Kubernetes 中有狀態應用程式的問題

當涉及到無狀態（即無狀態）的情況時，應用程式和服務的配置、啟動和進一步擴展很容易。 不保存資料。 使用其標準 API 在 Kubernetes 中運行此類服務很方便，因為一切都是「開箱即用」的：根據標準配置，不涉及任何細節或魔法。

簡而言之，要在容器叢集中再啟動五個 PHP/Ruby/Python 後端副本，只需設定新伺服器 5 次並複製來源即可。 由於原始程式碼和初始化腳本都在映像中，因此擴展無狀態應用程式變得完全簡單。 正如容器和微服務架構的愛好者所熟知的那樣，困難始於 有狀態應用程式， IE。 具有資料持久性，例如資料庫和快取（MySQL、PostgreSQL、Redis、ElasticSearch、Cassandra...）。 這適用於獨立實現仲裁叢集的軟體（例如 Percona XtraDB 和 Cassandra），以及需要單獨管理實用程式的軟體（例如 Redis、MySQL、PostgreSQL...）。

困難的出現是因為原始程式碼和啟動服務已經不夠了——您需要執行更多步驟。 至少，複製資料和/或加入叢集。 更準確地說，這些服務需要了解如何正確擴展、更新和重新配置它們，而不會丟失資料或暫時不可用。 考慮到這些需求稱為「操作知識」。

CoreOS 操作員

為了「編程」操作知識，去年年底的CoreOS項目 引進 Kubernetes 平台的「一類新軟體」－Operators（源自英文“operation”，即“操作”）。

使用和擴充 Kubernetes 核心功能（包括 有狀態集，請參閱下面的差異）允許 DevOps 專家將操作知識新增至應用程式程式碼。

營運商的目的 — 為使用者提供一個 API，讓您可以管理 Kubernetes 叢集中的多個有狀態應用程式實體，而無需考慮幕後內容（哪些資料以及如何處理它們，仍需要執行哪些命令來維護叢集） ）。 事實上，Operator 旨在盡可能簡化叢集內應用程式的工作，自動執行先前必須手動解決的操作任務。

操作員如何工作

副本集 Kubernetes 可讓您指定所需的運行 pod 數量，控制器可確保維持其數量（透過建立和刪除 pod）。 Operator 以類似的方式運作，將一組操作知識新增至標準 Kubernetes 資源和控制器，讓您可以執行其他操作來支援所需數量的應用程式實體。

這與 有狀態集，專為需要叢集為其提供有狀態資源（例如資料儲存或靜態 IP）的應用程式而設計？ 對於此類應用，營運商可以使用 有狀態集 （反而 副本集）作為基礎，提供 額外的自動化：在崩潰時執行必要的操作、進行備份、更新配置等。

因此， 這一切是如何運作的？ 操作員是一個管理器守護進程，它：

  1. 訂閱 Kubernetes 中的事件 API；
  2. 從它接收有關係統的資料（關於其 副本集, 莢, 服務 等等。）;
  3. 接收有關的數據 第三方資源 （請參閱下面的範例）；
  4. 對外觀/變化做出反應 第三方資源 （例如，更改尺寸、更改版本等）；
  5. 對系統狀態的變化做出反應（關於它的 副本集, 莢, 服務 等等。）;
  6. 最重要的：
    1. 呼叫 Kubernetes API 來創建它需要的一切（同樣，它自己的 副本集, 莢, 服務……）、
    2. 執行一些魔法（為了簡化，您可以認為 Operator 進入 Pod 本身並呼叫命令，例如，加入叢集或在更新版本時升級資料格式）。

Kubernetes 的 Operator：如何運行有狀態應用程序
事實上，從圖中可以看出，只是在 Kubernetes 中加入了一個單獨的應用程式（一個常規的應用程式） 部署 с 複製集），稱為運算符。 它生活在一個普通的 Pod 中（通常只有一個），通常只負責它的 命名空間。 這個運營商應用程式實現了它的API——雖然不是直接的，但透過 第三方資源 在 Kubernetes 中。

因此，在我們創建之後 命名空間 運算符，我們可以添加它 第三方資源.

etcd 範例 （詳情請見下文）:

apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
  name: example-etcd-cluster
spec:
  size: 3
  version: 3.1.0

Elasticsearch 的範例：

apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
  name: example-es-cluster
spec:
  client-node-replicas: 3
  master-node-replicas: 2
  data-node-replicas: 3
  zones:
  - us-east-1c
  - us-east-1d
  - us-east-1e
  data-volume-size: 10Gi
  java-options: "-Xms1024m -Xmx1024m"
  snapshot:
    scheduler-enabled: true
    bucket-name: elasticsnapshots99
    cron-schedule: "@every 2m"
  storage:
    type: gp2
    storage-class-provisioner: kubernetes.io/aws-ebs

對營運商的要求

CoreOS 制定了工程師在 Operator 工作時獲得的主要模式。 儘管所有 Operator 都是獨立的（為具有自身特徵和需求的特定應用程式創建），但它們的創建必須基於強加以下要求的框架：

  1. 安裝必須透過單一 部署: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - 且不需要額外的操作。
  2. 在 Kubernetes 中安裝 Operator 時，必須建立新的第三方類型 （第三方資源）。 為了啟動應用程式實例（叢集實例）並進一步管理它們（更新版本、調整大小等），使用者將使用此類型。
  3. 只要有可能，您應該使用 Kubernetes 內建的原語，例如 服務 и 副本集使用經過充分測試且易於理解的程式碼。
  4. 需要 Operator 向後相容並支援舊版本的使用者建立的資源。
  5. 如果 Operator 被刪除，應用程式本身應該繼續運行而無需更改。
  6. 用戶應該能夠定義所需的應用程式版本並協調應用程式版本更新。 缺乏軟體更新是操作和安全問題的常見根源，因此營運商必須在這方面協助使用者。
  7. 操作員應該使用 Chaos Monkey 等工具進行測試，該工具可以識別 Pod、配置和網路中的潛在故障。

etcd 操作員

算子實作範例 - etcd 操作員， 準備好了 在這個概念宣布的當天。 由於需要維護仲裁、需要重新配置叢集成員資格、建立備份等，etcd 叢集配置可能很複雜。 例如，手動擴展 etcd 叢集表示您需要為新叢集成員建立 DNS 名稱，啟動新的 etcd 實體，並向叢集發出有關新成員的警報（etcdctl 成員添加）。 對於 Operator，使用者只需要更改叢集大小 - 其他一切都會自動發生。

由於 etcd 也是在 CoreOS 中創建的，因此看到它的 Operator 首先出現是很合乎邏輯的。 他如何工作？ etcd 運算符邏輯 由三個部分決定：

  1. 觀察。 操作員使用 Kubernetes API 監控叢集的狀態。
  2. 分析。 尋找目前狀態與所需狀態（由使用者配置定義）之間的差異。
  3. 行動。 使用 etcd 和/或 Kubernetes 服務 API 解決偵測到的差異。

Kubernetes 的 Operator：如何運行有狀態應用程序

為了實現這個邏輯，Operator 中準備了函數 創建/銷毀 （建立和刪除etcd叢集成員）和 調整大小 （集群成員數量的變化）。 使用類似於 Netflix 的 Chaos Monkey 創建的實用程式來檢查其操作的正確性，即隨機殺死 etcd pod。

為了充分運行 etcd，Operator 提供了附加功能： 備份 （自動且對使用者不可見的備份副本建立 - 在配置中足以確定製作備份副本的頻率以及儲存的數量 - 以及隨後從中還原資料）和 升級 （無需停機即可更新 etcd 安裝）。

與操作員一起工作是什麼樣的？

$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
etcd-cluster-0000                1/1       Running   0          23s
etcd-cluster-0001                1/1       Running   0          16s
etcd-cluster-0002                1/1       Running   0          8s
etcd-cluster-backup-tool-rhygq   1/1       Running   0          18s

etcd Operator 目前狀態是 beta 版本，需要 Kubernetes 1.5.3+ 和 etcd 3.0+ 才能運作。 原始碼和文件（包括使用說明）可在以下位置取得： GitHub上.

CoreOS 的另一個範例實作已經建立 - 普羅米修斯操作員，但仍處於 alpha 版本（並非所有計劃的功能都已實現）。

現狀與前景

自 Kubernetes Operator 宣布以來已經過了 5 個月。 官方 CoreOS 儲存庫中仍然只有兩種實作（用於 etcd 和 Prometheus）。 兩者都尚未達到穩定版本，但每天都會觀察到提交。

開發人員設想“未來，用戶在其 Kubernetes 叢集上安裝 Postgres Operators、Cassandra Operators 或 Redis Operators，並像今天部署無狀態 Web 應用程式的副本一樣輕鬆地使用這些應用程式的可擴展實體。” 第一的 來自第三方開發人員的營運商 真正開始出現：

在 2017 年 XNUMX 月於布魯塞爾舉行的歐洲最大自由軟體會議 FOSDEM 上，來自 CoreOS 的 Josh Wood 宣布了 Operators 報告 （連結上有影片！），這應該有助於這個概念在更廣泛的開源社群中的流行。

聚苯乙烯 感謝您對本文的興趣！ 訂閱我們的中心，以免錯過有關 DevOps 和 GNU/Linux 系統管理的新資料和秘訣 - 我們將定期發布它們！

來源： www.habr.com

添加評論