Operators for Kubernetes: ステートフル アプリケーションを実行する方法

Kubernetes のステートフル アプリケーションの問題

ステートレスとして分類されるケースに関しては、アプリケーションとサービスの構成、起動、およびさらなるスケーリングが簡単です。 データを保存せずに。 このようなサービスを Kubernetes で標準 API を使用して実行すると便利です。これは、詳細や魔法を必要とせずに、すべてが「すぐに」標準構成に従って実行されるためです。

簡単に言うと、コンテナーのクラスター内で PHP/Ruby/Python のバックエンドのコピーをさらに 5 つ起動するには、新しいサーバーを XNUMX 回セットアップしてソースをコピーするだけで済みます。 ソース コードと init スクリプトの両方がイメージ内にあるため、ステートレス アプリケーションのスケーリングは完全に初歩的なものになります。 コンテナーとマイクロサービス アーキテクチャのファンはよく知っているように、その難しさは次のようなことから始まります。 ステートフルなアプリ、つまりデータベースやキャッシュ (MySQL、PostgreSQL、Redis、ElasticSearch、Cassandra...) などのデータ永続性を備えています。 これは、クォーラム クラスターを個別に実装するソフトウェア (Percona XtraDB や Cassandra など) と、別個の管理ユーティリティを必要とするソフトウェア (Redis、MySQL、PostgreSQL など) の両方に当てはまります。

ソース コードとサービスの起動だけでは十分ではなくなり、さらにいくつかの手順を実行する必要があるため、問題が発生します。 少なくとも、データをコピーするか、クラスターに参加します。 より正確には、これらのサービスでは、データ損失や一時的な利用不能を発生させずにサービスを適切に拡張、更新、再構成する方法を理解する必要があります。 これらのニーズを考慮することを「運用知識」と呼びます。

CoreOS オペレーター

運用知識を「プログラム」するために、昨年末に CoreOS プロジェクトが 紹介された Kubernetes プラットフォームの「新しいクラスのソフトウェア」 - オペレーター (英語の「オペレーション」、つまり「オペレーション」に由来)。

Kubernetes のコア機能 (含む) を使用および拡張するオペレーター。 ステートフル セット、以下の違いを参照してください) DevOps スペシャリストが運用知識をアプリケーション コードに追加できるようになります。

オペレーターの目的 — Kubernetes クラスター内の複数のステートフル アプリケーション エンティティを管理できる API をユーザーに提供します。これにより、内部にあるもの (どのデータとその処理方法、クラスターを維持するためにどのコマンドを実行する必要があるかなど) を考慮する必要がなくなります。 ）。 実際、Operator はクラスター内のアプリケーションの作業を可能な限り簡素化し、以前は手動で解決する必要があった運用タスクの実行を自動化するように設計されています。

オペレーターの仕組み

レプリカセット Kubernetes では、実行中のポッドの必要な数を指定でき、コントローラーは (ポッドの作成と削除によって) その数が維持されるようにします。 Operator は同様の方法で動作し、一連の運用知識を標準の Kubernetes リソースとコントローラーに追加して、必要な数のアプリケーション エンティティをサポートするための追加のアクションを実行できるようにします。

これはとどう違うのですか ステートフル セット、クラスターがデータ ストレージや静的 IP などのステートフル リソースを提供する必要があるアプリケーション向けに設計されていますか? このようなアプリケーションの場合、オペレータは次を使用できます。 ステートフル セット （その代わり レプリカセット) を基礎として、提供 追加の自動化: クラッシュの場合に必要なアクションを実行し、バックアップを作成し、構成を更新します。

このように、 これはどのように機能するのでしょうか？ オペレーターは、以下を行うマネージャー デーモンです。

1. Kubernetes のイベント API をサブスクライブします。
2. システムに関するデータをそこから受け取ります（システムに関するデータ） レプリカセット, ポッド, サービス 等々。）;
3. ～に関するデータを受け取ります サードパーティのリソース (以下の例を参照);
4. 外観/変化に反応する サードパーティのリソース (たとえば、サイズの変更、バージョンの変更など);
5. システムの状態の変化に反応します（システムの状態について） レプリカセット, ポッド, サービス 等々。）;
6. 最も重要な：
   1. Kubernetes API を呼び出して、必要なものすべてを作成します (ここでも独自の レプリカセット, ポッド, サービス...）、
   2. いくつかの魔法を実行します (単純化するために、Operator がポッド自体に入り、クラスターに参加したり、バージョンを更新するときにデータ形式をアップグレードしたりするコマンドを呼び出すと考えることができます)。

実際、図からわかるように、別のアプリケーションが Kubernetes (通常のアプリケーション) に追加されるだけです。 展開 с レプリカセット)、これはオペレーターと呼ばれます。 それは通常のポッド（通常は XNUMX つだけ）の中に住んでおり、原則として、そのポッドに対してのみ責任を負います。 名前空間。 このオペレータ アプリケーションは、直接ではなく、API を介して 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 の開発中に得た主なパターンを定式化しました。 すべてのオペレーターは個別のもの (独自の特性とニーズを持つ特定のアプリケーション用に作成されたもの) であるという事実にもかかわらず、その作成は、次の要件を課す一種のフレームワークに基づいている必要があります。

1. インストールは単一の方法で行う必要があります 展開: kubectl create -f SOME_OPERATOR_URL/deployment.yaml - 追加のアクションは必要ありません。
2. Kubernetes に Operator をインストールする場合は、新しいサードパーティ タイプを作成する必要があります (サードパーティリソース)。 アプリケーション インスタンス (クラスター インスタンス) を起動し、さらにそれらを管理 (バージョンの更新、サイズ変更など) するために、ユーザーはこのタイプを使用します。
3. 可能な限り、Kubernetes に組み込まれているプリミティブを使用する必要があります。 サービス и レプリカセットよくテストされたわかりやすいコードを使用すること。
4. Operator の下位互換性と、ユーザー作成リソースの古いバージョンのサポートが必要です。
5. Operator が削除された場合でも、アプリケーション自体は変更せずに機能し続けるはずです。
6. ユーザーは、必要なアプリケーション バージョンを定義し、アプリケーション バージョンの更新を調整できる必要があります。 ソフトウェア更新の欠如は、運用上およびセキュリティ上の問題の一般的な原因となるため、オペレーターはこの問題についてユーザーを支援する必要があります。
7. オペレーターは、ポッド、構成、ネットワークの潜在的な障害を特定する Chaos Monkey などのツールを使用してテストする必要があります。

etcd オペレーター

オペレーターの実装例 - etcd オペレーター、 準備 このコンセプト発表当日。 etcd クラスターの構成は、クォーラムの維持、クラスターのメンバーシップの再構成、バックアップの作成などの必要性により、複雑になる場合があります。 たとえば、etcd クラスターを手動でスケーリングするとは、新しいクラスター メンバーの DNS 名を作成し、新しい etcd エンティティを開始し、新しいメンバーについてクラスターにアラートを送信する必要があることを意味します (etcdctl メンバーの追加）。 Operator の場合、ユーザーはクラスター サイズを変更するだけで済み、その他はすべて自動的に行われます。

また、etcd も CoreOS で作成されたため、その Operator が最初に表示されるのは非常に論理的です。 彼はどうやって働いているのですか？ 演算子ロジック etcd は XNUMX つの要素によって決まります。

1. 観察する。 オペレーターは、Kubernetes API を使用してクラスターの状態を監視します。
2. 分析。 現在のステータスと望ましいステータス (ユーザー構成で定義) との相違点を見つけます。
3. アクション。 etcd や Kubernetes サービス API を使用して、検出された差異を解決します。

このロジックを実装するために、Operator に関数が用意されています。 作成/破壊 (etcd クラスターメンバーの作成と削除) および リサイズ (クラスターメンバーの数の変化)。 その動作の正しさは、Netflix の Chaos Monkey に似せて作成されたユーティリティを使用してチェックされました。 etcd ポッドをランダムに強制終了します。

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 の現在のステータスはベータ版であり、実行するには Kubernetes 1.5.3 以降および etcd 3.0 以降が必要です。 ソース コードとドキュメント (使用説明書を含む) は、次の場所から入手できます。 GitHubの.

CoreOS からの別の実装例が作成されました - プロメテウスオペレーター, ただし、まだアルファ版です（予定されている機能がすべて実装されているわけではありません）。

現状と展望

Kubernetes Operator の発表から 5 か月が経過しました。 公式 CoreOS リポジトリで利用できる実装はまだ XNUMX つだけです (etcd と Prometheus 用)。 どちらもまだ安定バージョンに達していませんが、コミットは毎日観察されています。

開発者らは、「ユーザーが Postgres Operator、Cassandra Operator、または Redis Operator を Kubernetes クラスターにインストールし、現在のステートレス Web アプリケーションのレプリカをデプロイするのと同じくらい簡単に、これらのアプリケーションのスケーラブルなエンティティを操作できる未来」を構想しています。 初め サードパーティ開発者のオペレーター 本当に現れ始めました：

• エラスティックサーチオペレーター UPMC エンタープライズから。
• PostgreSQL オペレーター Crunchy Data より (2017 年 XNUMX 月下旬発表)。
• ルークオペレーター Ceph ベースの分散データ ストレージ システムの作者によるもの (Rook はアルファ版です)。
• オープンスタック オペレーター SAP CCloud から。

2017 年 XNUMX 月にブリュッセルで開催されたヨーロッパ最大のフリー ソフトウェア カンファレンス FOSDEM で、CoreOS の Josh Wood は、次のオペレーターを発表しました。 レポート (ビデオはリンクからご覧いただけます!)、これは、より広範なオープンソース コミュニティにおけるこの概念の人気の拡大に貢献するはずです。

PS 記事に興味をお持ちいただきありがとうございます。 ハブに登録する、DevOps および GNU/Linux システム管理に関する新しい資料やレシピを見逃さないように、定期的に公開していきます。

出所： habr.com