行く？バッシュ！シェルオペレーターに会う（KubeCon EU'2020からのレポートのレビューとビデオ）

今年、ヨーロッパの主要なKubernetes会議であるKubeCon + CloudNativeCon Europe2020は仮想的なものでした。しかし、そのような形式の変更は、私たちが長い間計画されていた講演「Go？バッシュ！オープンソースのシェルオペレータープロジェクト専用の「シェルオペレーター」をご覧ください。



この記事は、講演に触発されて、Kubernetesの演算子を作成するプロセスを簡素化するアプローチを示し、最小限の労力でシェル演算子を使用して独自の演算子を作成する方法を示します。レポート（英語で約23分、記事よりもはるかに有益）とその主要な抜粋をテキスト形式でビデオに







提示します。行く！



Flantでは、常にすべてを最適化および自動化します。今日は別のエキサイティングなコンセプトについてお話します。ミートクラウドネイティブのシェルスクリプト！



ただし、これがすべて発生している状況、つまりKubernetesから始めましょう。

KubernetesAPIとコントローラー

KubernetesのAPIは、オブジェクトのタイプごとにディレクトリを持つ一種のファイルサーバーとして表すことができます。このサーバー上のオブジェクト（リソース）は、YAMLファイルで表されます。さらに、サーバーには3つのことを行うための基本的なAPIがあります。

• その種類と名前でリソースを取得します。
• リソースを変更します（この場合、サーバーは「正しい」オブジェクトのみを格納します。誤って形成された、または他のディレクトリを対象としたものはすべて破棄されます）。
• ( / ).

したがって、Kubernetesは、3つの基本的な方法（はい、実際には他にもありますが、ここでは省略します）を備えた一種のファイルサーバー（YAMLマニフェスト用）として機能します。







問題は、サーバーが保存できるのは情報だけであるということです。それを機能させるには、コントローラーが必要です。これは、Kubernetesの世界で2番目に重要で基本的な概念です。



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



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

• Deployment Controller（に含まれていますkube-controller-manager）は、Deploymentに関する情報を受け取り、ReplicaSetを作成します。
• ReplicaSetは、この情報に基づいて2つのレプリカ（2つのポッド）を作成しますが、これらのポッドはまだスケジュールされていません。
• スケジューラーはポッドをスケジュールし、ノード情報をYAMLに追加します。
• Kubeletsは、外部リソース（Dockerなど）に変更を加えます。

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

シェルオペレーター

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

簡単な例：秘密をコピーする

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



Kubernetesクラスターがあるとしましょう。defaultいくつかの秘密を持つ名前名がありますmysecret。さらに、クラスターには他の名前名があります。それらのいくつかには特定のラベルが貼られています。私たちの目標は、シークレットをラベル付きの名前空間にコピーすることです。



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



タスクが定式化されたので、シェルオペレーターを使用してタスクの実装を開始します。しかし、最初に、シェルオペレーター自体についていくつかの単語を言う価値があります。

シェルオペレーターのしくみ

Kubernetesの他のワークロードと同様に、シェルオペレーターはポッド内で実行されます。このポッドに/hooksは、ディレクトリ内の実行可能ファイルが含まれています。これらは、Bash、Python、Rubyなどのスクリプトにすることができます。これらの実行可能ファイルをフックと呼びます。







Shell-operatorは、Kubernetesイベントをサブスクライブし、必要なイベントに応答してこれらのフックを起動します。







シェルオペレーターは、どのフックをいつ実行するかをどのように知るのですか？重要なのは、各フックには2つのステージがあるということです。起動時に、シェルオペレーターは引数を使用してすべてのフックを実行--configします。これが構成段階です。その後、フックは通常の方法で起動されます-フックが接続されているイベントに応答します。後者の場合、フックはバインディングコンテキストを受け取ります）-JSON形式のデータ。これについては以下で詳しく説明します。

Bashでオペレーターを作成する

これで、実装の準備が整いました。これを行うには、2つの関数を作成する必要があります（ちなみに、Bashでのフックの作成を大幅に簡素化するshell_libライブラリをお勧めします）。

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

#!/bin/bash

source /shell_lib.sh

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

function __main__() {
  # THE LOGIC
}

hook::run "$@"

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

• 変更の秘密のソース。
• クラスタ内のすべての名前付け。これにより、ラベルがどの名前付けに添付されているかがわかります。
• シークレットをターゲットにして、すべてがソースシークレットと同期していることを確認します。

秘密の情報源を購読する

バインディング構成は彼にとって十分に単純です。名前名mysecretに名前を付けてSecretに関心があることを示します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

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







配列filterResultsが含まれています。hasLabelラベルが指定された名前名に添付されているかどうかを示すブール変数。セレクターkeepFullObjectsInMemory: falseは、完全なオブジェクトをメモリに保持する必要はないと言っています。

秘密の追跡-ターゲット

注釈のあるすべてのシークレットをサブスクライブします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。シークレットの作成時に最後のパラメーターがアノテーションに渡されました。これにより、シークレットのバージョンを比較して最新の状態に保つことができます。



このように構成されたフックは、実行時に上記の3つのバインディングコンテキストを受け取ります。それらをクラスターの一種のスナップショットと考えてください。







このすべての情報に基づいて、基本的なアルゴリズムを開発できます。すべての名前名を繰り返し、次のことを行います。

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

例を使用して、リポジトリのBashにアルゴリズムの実装をダウンロードできます。



これにより、35行のYAML構成とほぼ同じ量のBashコードを使用して、単純なKubernetesコントローラーを作成できました。シェルオペレーターの仕事は、それらをつなぎ合わせることです。



ただし、秘密をコピーすることは、ユーティリティのアプリケーションの唯一の領域ではありません。彼の能力を示すために、さらにいくつかの例を示します。

例1：ConfigMapに変更を加える

3ポッドの展開を見てみましょう。ポッドはConfigMapを使用していくつかの構成を保存します。ポッドが起動されたとき、ConfigMapはある状態でした（v.1と呼びましょう）。したがって、すべてのポッドはこの特定のバージョンのConfigMapを使用します。



ここで、ConfigMapが変更されたとします（v.2）。ただし、ポッドは古いバージョンのConfigMap（v.1）を使用します。ポッドを







新しいConfigMap（v.2）に移行するにはどうすればよいですか？答えは簡単です。テンプレートを使用してください。templateデプロイメント構成セクションにチェックサム注釈を追加しましょう：







その結果、このチェックサムはすべてのポッドに登録され、展開の場合と同じになります。これで、ConfigMapが変更されたときにアノテーションを更新する必要があります。この場合、シェルオペレーターが便利です。あなたがする必要があるのは、ConfigMapにサブスクライブしてチェックサムを更新するフックをプログラムすることです。



ユーザーがConfigMapに変更を加えると、シェルオペレーターはそれらに気づき、チェックサムを再計算します。次に、Kubernetesの魔法が作用します。オーケストレーターはポッドを殺し、新しいポッドを作成し、ポッドがになるのを待っReadyて、次のポッドに移動します。その結果、Deploymentは同期され、新しいバージョンのConfigMapに移行されます。

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

ご存知のように、Kubernetesではカスタムタイプ（種類）のオブジェクトを作成できます。たとえば、kindを作成できますMysqlDatabase。このタイプに2つのメタデータパラメータがあるとしましょう：nameとnamespace.

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

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

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

ご存知のように、pingを使用するのがネットワークを監視する最も簡単な方法です。この例では、シェル演算子を使用してこのような監視を実装する方法を示します。



まず、ノードにサブスクライブする必要があります。シェルオペレーターには、各ノードの名前と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に送信します。Shell-operatorは、メトリックをPrometheusにエクスポートして、環境変数で指定されたパスに従って配置されたファイルに保存できます$METRICS_PATH。



これは、クラスター内の単純なネットワーク監視のためのオペレーターを実行する方法です。

キューメカニズム

この記事は、シェル演算子に組み込まれている別の重要なメカニズムについて説明しないと不完全です。クラスター内のイベントに応答してフックを実行するとします。

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

幸い、シェルオペレーターにはキューイングメカニズムが組み込まれています。すべてのイベントはキューに入れられ、順番に処理されます。



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



また、これらのイベントを1つの大きなイベントに組み合わせることができます。groupバインディング構成のパラメーターがこれを担当します。







キュー/フックとそれらのさまざまな組み合わせをいくつでも作成できます。たとえば、1つのキューが2つのフックで機能することも、その逆も可能です。







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

結論

シェルオペレーターとは何かについて話し、Kubernetesオペレーターをすばやく簡単に作成するためにどのように使用できるかを示し、その使用例をいくつか示しました。



シェルオペレーターに関する詳細情報、およびそれを使用するためのクイックガイドは、GitHubの対応するリポジトリで入手できます。ご不明な点がございましたら、お気軽にお問い合わせください。特別なテレグラムグループ（ロシア語）またはこのフォーラム（英語）で話し合うことができます。



そして、あなたがそれを好きなら、私たちは常にGitHubの新しい問題/ PR /スターに喜んでいます、ところで、あなたは他の興味深いプロジェクトを見つけることができます。その中で、シェルオペレーターの兄であるアドオンオペレーターを強調する価値があります..。このユーティリティは、Helmチャートを使用してアドオンをインストールし、更新を配信してさまざまなチャートパラメータ/値を監視し、チャートのインストールプロセスを制御し、クラスタ内のイベントに応じてそれらを変更することもできます。

ビデオとスライド

パフォーマンスのビデオ（〜23分）：





レポートの提示：

PS

私たちのブログも読んでください：

• "シェル演算子を使用したKubernetes演算子の簡単な作成：1年でのプロジェクトの進捗状況";
• 「シェルオペレーターの紹介：Kubernetesのオペレーターの作成が簡単になりました」;
• 「Kubernetesクラスターを準備するのは簡単で便利ですか？アドオンオペレーターを発表します ";
• 「Kubernetesの拡張と補完」（レポートのレビューとビデオ）。