🥇シェルオペレーターの紹介: Kubernetes のオペレーターの作成がかつてないほど簡単になりました

すでに私たちのブログに次のような記事が掲載されています Kubernetes のオペレーター機能そしてどうやって簡単な演算子を自分で作成する。今回は、オペレーターの作成を非常に簡単なレベルに引き上げるオープンソースソリューションを皆さんに紹介したいと思います。チェックしてください。シェルオペレーター!

なぜですか？

シェルオペレーターの考え方は非常に単純です。Kubernetes オブジェクトからのイベントをサブスクライブし、これらのイベントを受信すると、外部プログラムを起動して、イベントに関する情報を提供します。

この必要性が生じたのは、クラスターの運用中に、本当に正しい方法で自動化したい小さなタスクが現れ始めたときです。これらの小さなタスクはすべて、単純な bash スクリプトを使用して解決されましたが、ご存知のとおり、演算子は Golang で作成する方が良いでしょう。明らかに、このような小さなタスクごとにオペレーターの本格的な開発に投資するのは効果的ではありません。

オペレーターが15分以内に対応

Kubernetes クラスターで何が自動化できるのか、またシェルオペレーターがどのように役立つのかの例を見てみましょう。例としては、Docker レジストリにアクセスするためのシークレットの複製が挙げられます。

プライベートレジストリのイメージを使用するポッドには、レジストリにアクセスするためのデータを含むシークレットへのリンクをマニフェストに含める必要があります。このシークレットは、ポッドを作成する前に各名前空間で作成する必要があります。これは手動で行うこともできますが、動的な環境をセットアップすると、2 つのアプリケーションの名前空間が膨大になります。そして、3〜XNUMXのアプリケーションもなければ...シークレットの数は非常に多くなります。シークレットについてもう XNUMX つ説明します。レジストリにアクセスするキーを時々変更したいと考えています。最終的に、 手動操作 解決策として まったく効果がない — シークレットの作成と更新を自動化する必要があります。

シンプルな自動化

N 秒ごとに実行され、名前空間にシークレットが存在するかどうかを確認し、シークレットが存在しない場合はシークレットが作成されるシェルスクリプトを作成しましょう。このソリューションの利点は、cron のシェルスクリプトのように見えることであり、古典的で誰にとってもわかりやすいアプローチです。欠点は、起動の合間に新しい名前空間が作成される可能性があり、しばらくの間シークレットなしのままになるため、ポッドの起動時にエラーが発生することです。

シェルオペレーターによる自動化

スクリプトが正しく動作するには、名前空間の追加時に従来の cron 起動を起動に置き換える必要があります。この場合、使用する前にシークレットを作成できます。シェル演算子を使用してこれを実装する方法を見てみましょう。

まず、スクリプトを見てみましょう。シェルオペレーター用語でのスクリプトはフックと呼ばれます。フラグを付けて実行するときのすべてのフック --config シェルオペレーターにそのバインディングについて通知します。どのようなイベントを開始するかについて。私たちの場合、使用します onKubernetesEvent:

#!/bin/bash
if [[ $1 == "--config" ]] ; then
cat <<EOF
{
"onKubernetesEvent": [
  { "kind": "namespace",
    "event":["add"]
  }
]}
EOF
fi

ここでは、イベントの追加に興味があることが説明されています(add) 型のオブジェクト namespace.

ここで、イベントの発生時に実行されるコードを追加する必要があります。

#!/bin/bash
if [[ $1 == "--config" ]] ; then
  # конфигурация
cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "namespace",
  "event":["add"]
}
]}
EOF
else
  # реакция:
  # узнать, какой namespace появился
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  # создать в нём нужный секрет
  kubectl create -n ${createdNamespace} -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  ...
data:
  ...
EOF
fi

素晴らしい！その結果、小さくて美しいスクリプトが完成しました。これを「復活」させるには、イメージを準備してクラスター内で起動するという XNUMX つの手順が残っています。

フック付きの画像を準備する

スクリプトを見ると、コマンドが使用されていることがわかります。 kubectl и jq。これは、イメージにはフック、イベントを監視してフックを実行するシェルオペレーター、フックで使用されるコマンド (kubectl および jq) が必要であることを意味します。 Hub.docker.com には、shell-operator、kubectl、および jq がパッケージ化された既製のイメージがすでにあります。残っているのは簡単なフックを追加することだけです Dockerfile:

$ cat Dockerfile
FROM flant/shell-operator:v1.0.0-beta.1-alpine3.9
ADD namespace-hook.sh /hooks

$ docker build -t registry.example.com/my-operator:v1 . 
$ docker push registry.example.com/my-operator:v1

クラスター内で実行する

フックをもう一度見てみましょう。今度は、クラスター内でどのようなアクションを実行し、どのオブジェクトを使用して実行するかを書き留めます。

名前空間作成イベントをサブスクライブします。
起動された名前空間以外の名前空間にシークレットを作成します。

イメージが起動されるポッドには、これらのアクションを実行するためのアクセス許可が必要であることがわかりました。これは、独自の ServiceAccount を作成することで実行できます。権限は ClusterRole および ClusterRoleBinding の形式で行う必要があります。私たちはクラスター全体のオブジェクトに興味があります。

YAML での最終的な記述は次のようになります。

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitor-namespaces-acc

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: monitor-namespaces
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "watch", "list"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "create", "patch"]

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: monitor-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: monitor-namespaces
subjects:
  - kind: ServiceAccount
    name: monitor-namespaces-acc
    namespace: example-monitor-namespaces

組み立てられたイメージを単純なデプロイメントとして起動できます。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1
      serviceAccountName: monitor-namespaces-acc

便宜上、シェルオペレーターが起動され、作成されたマニフェストが適用される別の名前空間が作成されます。

$ kubectl create ns example-monitor-namespaces
$ kubectl -n example-monitor-namespaces apply -f rbac.yaml
$ kubectl -n example-monitor-namespaces apply -f deployment.yaml

これですべてです。シェルオペレーターが起動し、名前空間作成イベントをサブスクライブし、必要に応じてフックを実行します。

このように、 単純なシェルスクリプトが Kubernetes の実際のオペレーターに変わりました クラスターの一部として機能します。これらすべてを、Golang でオペレーターを開発する複雑なプロセスなしで行うことができます。

この件に関しては別の例があります...

その意味については、次の出版物のいずれかでさらに詳しく明らかにします。

フィルタリング

オブジェクトを追跡するのは良いことですが、多くの場合、オブジェクトに反応する必要があります。 いくつかのオブジェクトのプロパティを変更するたとえば、デプロイメント内のレプリカの数を変更したり、オブジェクトのラベルを変更したりする場合です。

イベントが到着すると、シェルオペレーターはオブジェクトの JSON マニフェストを受け取ります。この JSON で興味のあるプロパティを選択し、フックを実行できます。のみ彼らが変わるとき。このフィールドがあります jqFilterここで、JSON マニフェストに適用される jq 式を指定する必要があります。

たとえば、Deployment オブジェクトのラベルの変更に対応するには、フィールドをフィルターする必要があります。 labels 野原の外へ metadata。構成は次のようになります。

cat <<EOF
{
"onKubernetesEvent": [
{ "kind": "deployment",
  "event":["update"],
  "jqFilter": ".metadata.labels"
}
]}
EOF

この jqFilter 式は、Deployment の長い JSON マニフェストをラベル付きの短い JSON に変換します。

shell-operator は、この短い JSON が変更された場合にのみフックを実行し、他のプロパティへの変更は無視されます。

フック起動コンテキスト

フック構成を使用すると、イベントに対して複数のオプションを指定できます。たとえば、Kubernetes からのイベントに対して 2 つのオプションと 2 つのスケジュールを指定できます。

{"onKubernetesEvent":[
  {"name":"OnCreatePod",
  "kind": "pod",
  "event":["add"]
  },
  {"name":"OnModifiedNamespace",
  "kind": "namespace",
  "event":["update"],
  "jqFilter": ".metadata.labels"
  }
],
"schedule": [
{ "name":"every 10 min",
  "crontab":"* */10 * * * *"
}, {"name":"on Mondays at 12:10",
"crontab": "* 10 12 * * 1"
]}

少し余談: はい、シェルオペレーターはサポートしています crontab スタイルのスクリプトを実行する。詳細については、以下を参照してください。ドキュメンテーション.

フックが起動された理由を区別するために、シェルオペレーターは一時ファイルを作成し、そのファイルへのパスを変数でフックに渡します。 BINDING_CONTEXT_TYPE。ファイルには、フックを実行する理由の JSON 記述が含まれています。たとえば、10 分ごとに次の内容のフックが実行されます。

[{ "binding": "every 10 min"}]

...月曜日はこんな感じで始まります。

[{ "binding": "every 10 min"}, { "binding": "on Mondays at 12:10"}]

のために onKubernetesEvent さらに多くの JSON トリガーが存在することになります。オブジェクトの説明が含まれています。

[
 {
 "binding": "onCreatePod",
 "resourceEvent": "add",
 "resourceKind": "pod",
 "resourceName": "foo",
 "resourceNamespace": "bar"
 }
]

フィールドの内容はその名前から理解でき、詳細については次を参照してください。ドキュメンテーション。フィールドからリソース名を取得する例 resourceName jq の使用は、シークレットを複製するフックですでに示されています。

jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH

他のフィールドも同様の方法で取得できます。

次は何ですか？

プロジェクトリポジトリ内で、 /examples ディレクトリ、クラスター上で実行する準備ができているフックの例があります。独自のフックを作成するときは、それをベースとして使用できます。

Prometheus を使用したメトリクスの収集がサポートされています。利用可能なメトリクスについてはセクションで説明されています。メトリクス.

ご想像のとおり、シェルオペレーターは Go で書かれており、オープンソースライセンス (Apache 2.0) に基づいて配布されています。開発支援に感謝いたします GitHub 上のプロジェクト:、スター、問題、プルリクエスト。

秘密のベールを取り除き、シェルオペレーターがいることもお知らせします。 小さい Kubernetes クラスターにインストールされているアドオンを最新の状態に保ち、さまざまな自動アクションを実行できるシステムの一部です。このシステムについて詳しく読む言った文字通り、月曜日にサンクトペテルブルクで開催される HighLoad++ 2019 で、このレポートのビデオとトランスクリプトを間もなく公開する予定です。

私たちは、このシステムの残りの部分、つまりアドオンオペレーターとフックとモジュールのコレクションを公開する計画があります。ちなみに、addon-operatorはすでに githubで入手可能、ただし、そのドキュメントはまだ作成中です。モジュール集のリリースは夏を予定しています。

乞うご期待！

PS

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

出所： habr.com

シェルオペレーターの紹介: Kubernetes のオペレーターの作成がさらに簡単になりました

なぜですか？

オペレーターが15分以内に対応

シンプルな自動化

シェルオペレーターによる自動化

フック付きの画像を準備する

クラスター内で実行する

フィルタリング

フック起動コンテキスト

次は何ですか？

PS

コメントを追加します返信をキャンセル

シェル オペレーターの紹介: Kubernetes のオペレーターの作成がさらに簡単になりました

なぜですか？

オペレーターが15分以内に対応

シンプルな自動化

シェルオペレーターによる自動化

フック付きの画像を準備する

クラスター内で実行する

フィルタリング

フック起動コンテキスト

次は何ですか？

PS

コメントを追加します 返信をキャンセル

シェルオペレーターの紹介: Kubernetes のオペレーターの作成がさらに簡単になりました

コメントを追加します返信をキャンセル