行く？ バッシュ！ シェル オペレーターの紹介 (KubeCon EU'2020 のレビューとビデオ レポート)

今年、欧州の主要な Kubernetes カンファレンスである KubeCon + CloudNativeCon Europe 2020 はバーチャルで開催されました。 しかし、このような形式の変更によって、長年計画していたレポート「Go?」の提供が妨げられることはありませんでした。 バッシュ！ オープンソース プロジェクトに特化した「シェル オペレーターの紹介」 シェルオペレーター.

この記事は講演に触発されて、Kubernetes のオペレーター作成プロセスを簡素化するアプローチを紹介し、シェル オペレーターを使用して最小限の労力で独自のオペレーターを作成する方法を示します。

導入 レポートのビデオ (英語で約 23 分、記事よりも明らかに有益です) とその主要な抜粋をテキスト形式で示します。 行く！

Flant では、あらゆるものを常に最適化し、自動化しています。 今日は別のエキサイティングなコンセプトについてお話します。 会う： クラウドネイティブのシェルスクリプト!

ただし、これすべてが発生するコンテキスト、つまり Kubernetes から始めましょう。

Kubernetes API とコントローラー

Kubernetes の API は、オブジェクトの種類ごとにディレクトリを備えた一種のファイル サーバーとして表すことができます。 このサーバー上のオブジェクト (リソース) は YAML ファイルで表されます。 さらに、サーバーには基本的な API があり、次の XNUMX つのことを実行できます。

• 受け取る リソースの種類と名前による。
• 変化する リソース (この場合、サーバーは「正しい」オブジェクトのみを保管します。間違って形成されたオブジェクトや他のディレクトリーを対象としたオブジェクトはすべて破棄されます)。
• フォローする リソースの場合 (この場合、ユーザーは現在の/更新されたバージョンをすぐに受け取ります)。

したがって、Kubernetes は XNUMX つの基本メソッドを備えた (YAML マニフェスト用の) 一種のファイル サーバーとして機能します (はい、実際には他にもメソッドがありますが、ここでは省略します)。

問題は、サーバーは情報しか保存できないことです。 それを機能させるために必要なのは コントローラ - Kubernetes の世界で XNUMX 番目に重要かつ基本的な概念。

コントローラーには主に 8 つのタイプがあります。 XNUMX つ目は、Kubernetes から情報を取得し、ネストされたロジックに従って処理し、KXNUMXs に返します。 XNUMX 番目のタイプは Kubernetes から情報を取得しますが、最初のタイプとは異なり、一部の外部リソースの状態を変更します。

Kubernetes でデプロイメントを作成するプロセスを詳しく見てみましょう。

• デプロイメントコントローラー (以下に含まれます) kube-controller-manager) デプロイメントに関する情報を受け取り、ReplicaSet を作成します。
• ReplicaSet はこの情報に基づいて XNUMX つのレプリカ (XNUMX つのポッド) を作成しますが、これらのポッドはまだスケジュールされていません。
• スケジューラはポッドをスケジュールし、ノード情報を YAML に追加します。
• Kubelet は外部リソース (Docker など) に変更を加えます。

次に、このシーケンス全体が逆の順序で繰り返されます。kubelet はコンテナーをチェックし、ポッドのステータスを計算して送り返します。 ReplicaSet コントローラーはステータスを受信し、レプリカ セットの状態を更新します。 同じことがデプロイメント コントローラーでも発生し、ユーザーは最終的に更新された (現在の) ステータスを取得します。

シェルオペレーター

Kubernetes はさまざまなコントローラーの共同作業に基づいていることがわかります (Kubernetes オペレーターもコントローラーです)。 最小限の労力で独自のオペレーターを作成するにはどうすればよいかという疑問が生じます。 ここで私たちが開発したものが役に立ちます シェルオペレーター。 これにより、システム管理者は使い慣れた方法を使用して独自のステートメントを作成できます。

簡単な例: シークレットのコピー

簡単な例を見てみましょう。

Kubernetes クラスターがあるとします。 名前空間があります default 秘密を持って mysecret。 さらに、クラスター内には他の名前空間もあります。 それらの中には、特定のラベルが付けられているものもあります。 私たちの目標は、Secret をラベル付きの名前空間にコピーすることです。

新しい名前空間がクラスター内に出現し、それらの一部にこのラベルが付いている可能性があるため、タスクは複雑になります。 一方、ラベルを削除する場合は、Secret も削除する必要があります。 これに加えて、Secret 自体も変更される可能性があります。この場合、新しい Secret をラベル付きのすべての名前空間にコピーする必要があります。 Secret が名前空間で誤って削除された場合、当社のオペレーターは直ちにそれを復元する必要があります。

タスクが定式化されたので、シェル オペレーターを使用して実装を開始します。 しかし、その前に、シェル オペレーター自体について少し述べておく価値があります。

シェルオペレーターの仕組み

Kubernetes の他のワークロードと同様に、shell-operator は独自のポッドで実行されます。 このポッド内のディレクトリ内 /hooks 実行可能ファイルが保存されます。 これらは、Bash、Python、Ruby などのスクリプトにすることができます。 このような実行可能ファイルをフックと呼びます (フック).

シェルオペレーターは Kubernetes イベントをサブスクライブし、必要なイベントに応答してこれらのフックを実行します。

シェルオペレーターはどのフックをいつ実行するかをどのようにして知るのでしょうか? ポイントは、すべてのフックが XNUMX 段階あることです。 起動中、シェルオペレーターは引数を指定してすべてのフックを実行します。 --config これは構成段階です。 その後、フックは通常の方法で、フックが接続されているイベントに応じて起動されます。 後者の場合、フックはバインディング コンテキスト (バインディングコンテキスト) - JSON 形式のデータ。これについては以下で詳しく説明します。

Bash で演算子を作成する

これで実装の準備が整いました。 これを行うには、XNUMX つの関数を記述する必要があります (ちなみに、 図書館 シェルライブラリこれにより、Bash でのフックの作成が大幅に簡素化されます)。

• XNUMX つ目は構成段階で必要です。これはバインディング コンテキストを表示します。
• XNUMX 番目にはフックのメイン ロジックが含まれています。

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

次のステップは、必要なオブジェクトを決定することです。 私たちの場合、以下を追跡する必要があります。

• 変更のソースシークレット。
• クラスター内のすべての名前空間。どの名前空間にラベルが付いているかがわかります。
• ターゲット シークレットを使用して、それらがすべてソース シークレットと同期していることを確認します。

秘密のソースを購読する

そのバインド設定は非常に簡単です。 Secret に興味があることを名前で示します mysecret 名前空間内 default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

その結果、ソースシークレットが変更されるとフックがトリガーされます(src_secret) し、次のバインディング コンテキストを受け取ります。

ご覧のとおり、名前とオブジェクト全体が含まれています。

名前空間を追跡する

次に、名前空間をサブスクライブする必要があります。 これを行うには、次のバインディング構成を指定します。

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

ご覧のとおり、構成に次の名前の新しいフィールドが表示されています。 jqフィルター。 その名の通り、 jqFilter 不要な情報をすべて除外し、関心のあるフィールドを含む新しい JSON オブジェクトを作成します。 同様の構成のフックは、次のバインディング コンテキストを受け取ります。

配列が含まれています filterResults クラスター内の名前空間ごとに。 ブール変数 hasLabel ラベルが指定された名前空間にアタッチされているかどうかを示します。 セレクタ keepFullObjectsInMemory: false 完全なオブジェクトをメモリ内に保持する必要がないことを示します。

ターゲットシークレットの追跡

アノテーションが指定されたすべての Secret をサブスクライブします managed-secret: "yes" (これらが私たちの目標です dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

この場合 jqFilter 名前空間とパラメータを除くすべての情報をフィルタリングします。 resourceVersion。 最後のパラメータは、シークレットの作成時にアノテーションに渡されました。これにより、シークレットのバージョンを比較し、最新の状態に保つことができます。

このように構成されたフックは、実行されると、上で説明した XNUMX つのバインディング コンテキストを受け取ります。 これらは一種のスナップショットと考えることができます (スナップショット） 集まる。

これらすべての情報に基づいて、基本的なアルゴリズムを開発できます。 すべての名前空間を反復処理し、次のことを行います。

• 場合 hasLabel 事項 true 現在の名前空間の場合:
  • グローバル シークレットとローカル シークレットを比較します。
    • それらが同じである場合、何も行われません。
    • 異なる場合 - 実行します kubectl replace または create;
• 場合 hasLabel 事項 false 現在の名前空間の場合:
  • Secret が指定された名前空間に存在しないことを確認します。
    • ローカル シークレットが存在する場合は、次を使用して削除します。 kubectl delete;
    • ローカル シークレットが検出されない場合は、何も行われません。

Bash でのアルゴリズムの実装 弊社でダウンロードできます 例のあるリポジトリ.

このようにして、35 行の YAML 構成とほぼ同量の Bash コードを使用して、シンプルな Kubernetes コントローラーを作成することができました。 シェルオペレーターの仕事は、それらをリンクすることです。

ただし、このユーティリティの適用範囲はシークレットのコピーだけではありません。 彼の能力を示す例をさらにいくつか挙げます。

例 1: ConfigMap に変更を加える

1 つのポッドで構成されるデプロイメントを見てみましょう。 ポッドは ConfigMap を使用して一部の構成を保存します。 ポッドが起動されたとき、ConfigMap は特定の状態 (v.XNUMX と呼びます) にありました。 したがって、すべてのポッドはこの特定のバージョンの ConfigMap を使用します。

ここで、ConfigMap が変更されたと仮定します (v.2)。 ただし、ポッドは以前のバージョンの ConfigMap (v.1) を使用します。

新しい ConfigMap (v.2) に切り替えるにはどうすればよいですか? 答えは簡単です。テンプレートを使用するのです。 セクションにチェックサムの注釈を追加しましょう template 展開構成:

その結果、このチェックサムはすべての Pod に登録され、Deployment のチェックサムと同じになります。 これで、ConfigMap が変更されたときに注釈を更新するだけで済みます。 この場合、シェル演算子が役に立ちます。 必要なのはプログラムすることだけです ConfigMap をサブスクライブし、チェックサムを更新するフック.

ユーザーが ConfigMap に変更を加えると、シェルオペレーターがそれに気づき、チェックサムを再計算します。 その後、Kubernetes の魔法が機能します。オーケストレーターはポッドを強制終了し、新しいポッドを作成し、ポッドがポッドになるのを待ちます。 Ready、次へ進みます。 その結果、Deployment は同期され、ConfigMap の新しいバージョンに切り替わります。

例 2: カスタム リソース定義の操作

ご存知のとおり、Kubernetes ではカスタム タイプのオブジェクトを作成できます。 たとえば、種類を作成できます MysqlDatabase。 この型に XNUMX つのメタデータ パラメーターがあるとします。 name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

MySQL データベースを作成できる、さまざまな名前空間を持つ Kubernetes クラスターがあります。 この場合、shell-operator を使用してリソースを追跡できます。 MysqlDatabase、それらを MySQL サーバーに接続し、クラスターの望ましい状態と観察された状態を同期します。

例 3: クラスターネットワークの監視

ご存知のとおり、ping の使用はネットワークを監視する最も簡単な方法です。 この例では、shell-operator を使用してそのような監視を実装する方法を示します。

まず最初に、ノードをサブスクライブする必要があります。 シェル オペレーターには、各ノードの名前と IP アドレスが必要です。 彼らの助けを借りて、彼はこれらのノードに ping を送信します。

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

パラメーター executeHookOnEvent: [] フックがイベントに応答して (つまり、ノードの変更、追加、削除に応答して) 実行されないようにします。 しかし、彼は、 走ります (そしてノードのリストを更新します) 予定 - フィールドの規定に従って毎分 schedule.

ここで疑問が生じます。パケット損失などの問題について、どのように正確に知ることができるのでしょうか? コードを見てみましょう:

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

ノードのリストを反復処理し、ノードの名前と IP アドレスを取得し、ping を実行して、結果を Prometheus に送信します。 シェルオペレーターはメトリクスを Prometheus にエクスポートできます、環境変数で指定されたパスに従って配置されたファイルに保存します。 $METRICS_PATH.

このような クラスター内の単純なネットワーク監視用のオペレーターを作成できます。

キューイングメカニズム

シェル オペレーターに組み込まれている別の重要なメカニズムについて説明しなければ、この記事は不完全になります。 クラスター内のイベントに応答して、ある種のフックが実行されると想像してください。

• 同時にクラスター内で何かが発生した場合はどうなりますか? もう一つ イベント？
• シェルオペレーターはフックの別のインスタンスを実行しますか?
• たとえば、クラスター内で一度に XNUMX つのイベントが発生した場合はどうなるでしょうか?
• シェルオペレーターはそれらを並行して処理しますか?
• メモリやCPUなどの消費リソースはどうなるでしょうか?

幸いなことに、shell-operator にはキューイング メカニズムが組み込まれています。 すべてのイベントはキューに入れられ、順番に処理されます。

これを例を挙げて説明しましょう。 フックが XNUMX つあるとします。 最初のイベントは最初のフックに進みます。 処理が完了すると、キューは前に進みます。 次の XNUMX つのイベントは XNUMX 番目のフックにリダイレクトされ、キューから削除され、「バンドル」としてキューに入ります。 あれは フックはイベントの配列を受け取ります — より正確には、バインディング コンテキストの配列です。

これらも イベントを XNUMX つの大きなイベントにまとめることができる。 パラメータがこれを担当します group バインディング構成内。

任意の数のキュー/フックとそれらのさまざまな組み合わせを作成できます。 たとえば、XNUMX つのキューが XNUMX つのフックで機能することも、その逆も同様です。

必要なのは、それに応じてフィールドを設定することだけです queue バインディング構成内。 キュー名が指定されていない場合、フックはデフォルトのキューで実行されます (default）。 このキューイング メカニズムにより、フックを使用する際のリソース管理の問題をすべて完全に解決できます。

まとめ

シェル オペレーターとは何かを説明し、それを使用して Kubernetes オペレーターを迅速かつ簡単に作成する方法を示し、その使用例をいくつか示しました。

シェル オペレーターの詳細情報とその使用方法に関する簡単なチュートリアルは、対応するドキュメントで参照できます。 GitHub 上のリポジトリ。 ご質問がございましたら、お気軽にお問い合わせください。特別なセッションでご相談いただけます。 電報グループ （ロシア語で）または このフォーラム （英語）

気に入っていただけましたら、GitHub で新しい号/PR/スターをいつでも喜んで拝見させていただきます。ところで、他の号も見つけることができます。 興味深いプロジェクト。 その中でも注目すべきは アドオンオペレーター、シェルオペレーターの兄です。。 このユーティリティは、Helm チャートを使用してアドオンをインストールし、更新を配信してさまざまなチャートのパラメーター/値を監視し、チャートのインストール プロセスを制御し、クラスター内のイベントに応じてチャートを変更することもできます。

ビデオとスライド

パフォーマンスのビデオ (約 23 分):

報告書のプレゼンテーション:

PS

私たちのブログもお読みください:

• «Shell-Operator を使用した Kubernetes オペレーターの簡単な作成: 年間のプロジェクトの進捗状況";
• «シェル オペレーターの紹介: Kubernetes のオペレーターの作成がさらに簡単になりました";
• «Kubernetes クラスターを準備するのは簡単で便利ですか? アドオンオペレーターの発表";
• «Kubernetes の拡張と補完」（レビューとビデオレポート）.

出所： habr.com