Kubernetes クラスターを準備するのは簡単で便利ですか? アドオンオペレーターの発表

以下の シェルオペレーター 私たちは彼の兄を紹介します - アドオンオペレーター。 これは、アドオンと呼ばれるシステム コンポーネントを Kubernetes クラスターにインストールするために使用されるオープン ソース プロジェクトです。

そもそもなぜ追加があるのでしょうか？

Kubernetes が既製のオールインワン製品ではないことは周知の事実であり、「成人向け」クラスターを構築するにはさまざまな追加が必要になります。 Addon-operator は、これらのアドオンのインストール、構成、および最新の状態の維持を支援します。

クラスター内の追加コンポーネントの必要性については、以下で説明されています。 レポート 同僚 ドリューシャ。 つまり、現時点での Kubernetes の状況は、単純な「遊び心」インストールの場合は、そのままのコンポーネントで問題なく使用でき、開発者とテストの場合は Ingress を追加できますが、完全なインストールの場合は、 「本番環境の準備ができた」と言えますが、監視用のアドオン、ログ記録用のアドオン、Ingress と cert-manager を忘れずに、ノードのグループの選択、ネットワーク ポリシーの追加、シーズンなど、さまざまなアドオンを追加する必要があります。 sysctl とポッド オートスケーラー設定を使用して...

彼らとの協働の具体的な内容は何ですか？

実際に見てみるとわかるように、問題は XNUMX つのインストールに限定されません。 クラスターで快適に動作するには、アドオンを更新して無効にする (クラスターから削除する) 必要があり、運用クラスターにインストールする前にいくつかのアドオンをテストする必要があります。

では、ここでは Ansible で十分でしょうか? 多分。 しかし 一般に、本格的なアドオンは設定なしでは動作しません。。 これらの設定は、クラスターのバリアント (aws、gce、azure、bare-metal、do など) によって異なる場合があります。 一部の設定は事前に指定できず、クラスターから取得する必要があります。 また、クラスターは静的ではありません。設定によっては、変更を監視する必要があります。 そして、ここでは Ansible がすでに欠けています。クラスター内に存在するプログラムが必要です。 Kubernetes オペレーター。

職場で試してみた方 シェルオペレーター、アドオンのインストールと更新、および設定の監視のタスクは、次を使用して完全に解決できると言うでしょう。 フック シェルオペレーター用。 条件付きを実行するスクリプトを書くことができます kubectl apply たとえば、設定が保存される ConfigMap を監視します。 これはほぼ addon-operator で実装されているものです。

これは addon-operator でどのように構成されますか?

新しいソリューションを作成する際には、次の原則に基づいて作業を進めました。

• アドオン インストーラーはサポートする必要があります テンプレートと宣言型の構成。 私たちはアドオンをインストールする魔法のスクリプトを作成しません。 アドオン オペレーターは Helm を使用してアドオンをインストールします。 インストールするには、チャートを作成し、構成に使用される値を選択する必要があります。
• 設定できるのは、 インストール時に生成される、それらは可能です クラスターから取得または アップデートを受信する、クラスターリソースを監視します。 これらの操作はフックを使用して実装できます。
• 設定できるのは、 クラスターに格納する。 クラスターに設定を保存するには、ConfigMap/アドオン オペレーターが作成され、アドオン オペレーターはこの ConfigMap への変更を監視します。 Addon-operator は、単純な規則を使用してフックに設定へのアクセスを提供します。
• 追加は設定による。 設定が変更された場合、アドオン オペレーターは新しい値で Helm チャートをロールアウトします。 Helm チャート、その値、およびフックの組み合わせをモジュールと呼びます (詳細については以下を参照)。
• 演出。 魔法のリリース スクリプトはありません。 更新メカニズムは通常のアプリケーションと似ており、アドオンとアドオン オペレーターをイメージに収集し、タグ付けしてロールアウトします。
• 結果の制御。 Addon-operator は Prometheus のメトリクスを提供できます。

アドオン演算子のパディングとは何ですか?

追加とは、クラスターに新しい機能を追加するものすべてを指します。 たとえば、Ingress のインストールはアドオンの好例です。 これは、独自の CRD を持つ任意のオペレーターまたはコントローラー (prometheus-operator、cert-manager、kube-controller-manager など) にすることができます。 または、小規模だが使いやすいもの - たとえば、レジ​​ストリ シークレットを新しい名前空間にコピーするシークレット コピアや、新しいノードで sysctl パラメータを構成する sysctl チューナーなどです。

アドオンを実装するために、Addon-operator はいくつかの概念を提供します。

• ヘルムチャート Prometheus、Grafana、nginx-ingress など、さまざまなソフトウェアをクラスターにインストールするために使用されます。 必要なコンポーネントに Helm チャートがある場合、Addon-operator を使用してインストールするのは非常に簡単です。
• 価値観のストレージ。 通常、Helm チャートにはさまざまな設定があり、時間の経過とともに変更される可能性があります。 Addon-operator はこれらの設定の保存をサポートしており、新しい値で Helm チャートを再インストールするためにその変更を監視できます。
• フック アドオン オペレーターがイベントで実行し、値ストアにアクセスする実行可能ファイルです。 フックはクラスター内の変更を監視し、値ストア内の値を更新できます。 それらの。 フックを使用すると、起動時またはスケジュールに従ってクラスターから値を収集するディスカバリーを実行したり、クラスター内の変更に基づいてクラスターから値を収集する継続的なディスカバリーを実行したりできます。
• モジュール Helm チャート、値ストア、フックの組み合わせです。 モジュールは有効または無効にすることができます。 モジュールを無効にするということは、すべての Helm チャート リリースを削除することを意味します。 モジュールは、必要なすべてのモジュールが有効になっている場合、または検出でフック内に必要なパラメータが見つかった場合など、モジュール自体を動的に有効にすることができます。これは補助有効スクリプトを使用して行われます。
• グローバルフック。 これらは「独自の」フックであり、モジュールには含まれておらず、グローバル値ストアにアクセスでき、その値はモジュール内のすべてのフックで利用できます。

これらの部分はどのように連携するのでしょうか? ドキュメントの写真を見てみましょう。

次の XNUMX つの作業シナリオがあります。

1. グローバル フックは、クラスター内のリソースが変更されたときなど、イベントによってトリガーされます。 このフックは変更を処理し、新しい値をグローバル値ストアに書き込みます。 アドオン オペレーターは、グローバル ストレージが変更されたことに気づき、すべてのモジュールを開始します。 各モジュールは、そのフックを使用して、有効にする必要があるかどうかを判断し、その値ストアを更新します。 モジュールが有効な場合、アドオン オペレーターは Helm チャートのインストールを開始します。 この場合、Helm チャートはモジュール ストレージとグローバル ストレージの値にアクセスできます。
2. XNUMX 番目のシナリオはより単純です。モジュール フックはイベントによってトリガーされ、モジュールの値ストア内の値を変更します。 アドオン オペレーターはこれに気づき、更新された値で Helm チャートを起動します。

追加は、XNUMX つの単一フック、または XNUMX つの Helm チャートとして実装できます。 複数の依存モジュールであっても - これは、クラスターにインストールされるコンポーネントの複雑さと、必要な構成の柔軟性のレベルによって異なります。 たとえば、リポジトリ (/ examples) sysctl-tuner アドオンがあります。これは、フックと Helm チャートを備えた単純なモジュールとして実装され、ConfigMap を編集して設定を追加できるようにする値ストアを使用します。

アップデートの配信

Addon-operator がインストールするコンポーネントの更新の整理について少し説明します。

クラスター内で Addon-operator を実行するには、次のものが必要です。 追加を加えてイメージを構築する フックおよび Helm チャート ファイルの形式で、バイナリ ファイルを追加します addon-operator フックに必要なものはすべて次のとおりです。 bash, kubectl, jq, python 等その後、このイメージを通常のアプリケーションとしてクラスターにロールアウトでき、おそらく XNUMX つまたは別のタグ付けスキームを編成する必要があるでしょう。 クラスターが少ない場合は、アプリケーションの場合と同じアプローチが適している可能性があります。つまり、新しいリリース、新しいバージョン、すべてのクラスターに移動して、ポッドのイメージを修正します。 ただし、多数のクラスターにロールアウトする場合は、チャネルからの自己更新の概念の方が私たちには適していました。

その方法は次のとおりです。

• チャネルは基本的に、任意の値に設定できる識別子です (例: dev/stage/ea/stable)。
• チャンネル名はイメージタグです。 更新をチャネルにロールアウトする必要がある場合、新しいイメージが組み立てられ、チャネル名がタグ付けされます。
• 新しいイメージがレジストリに表示されると、Addon-operator が再起動され、新しいイメージで起動されます。

に書かれているように、これはベストプラクティスではありません Kubernetes ドキュメント。 これを行うことはお勧めできませんが、ここで話しているのは 同じクラスター内に存在する通常のアプリケーション。 Addon-operator の場合、アプリケーションはクラスター全体に分散された多数のデプロイメントであり、自己更新は非常に役立ち、作業が容易になります。

チャンネルは助けになるし、 テスト中: 補助クラスターがある場合は、それをチャネルに構成できます。 stage チャネルにロールアウトする前に更新をロールインします ea и stable。 チャネル上にクラスターがある場合 ea エラーが発生した場合は、次のように切り替えることができます stableこのクラスターの問題は調査中です。 クラスターがアクティブ サポートから外されると、「凍結された」チャネルに切り替わります。たとえば、次のようになります。 freeze-2019-03-20.

フックと Helm チャートの更新に加えて、必要な場合があります。 アップデートとサードパーティコンポーネント。 たとえば、条件付きノード エクスポーターのバグに気づき、パッチを適用する方法も見つけたとします。 次に、PR を開いて、新しいリリースがすべてのクラスターを通過してイメージのバージョンが上がるのを待っています。 無限に待機しないようにするには、ノード エクスポーターを構築し、PR を受け入れる前にそれに切り替えることができます。

一般に、これは Addon-operator なしで実行できますが、Addon-operator を使用すると、node-exporter をインストールするためのモジュールが XNUMX つのリポジトリに表示され、イメージを構築するための Dockerfile をそこに保持できるため、すべての参加者にとって作業が容易になります。何が起こっているかを理解するプロセス...そして、クラスターが複数ある場合は、PR のテストと新しいバージョンのロールアウトの両方が簡単になります。

このコンポーネント更新の構成はうまく機能しますが、他の適切なスキームを実装することもできます。 この場合、Addon-operator は単純なバイナリ ファイルです。.

まとめ

Addon-operator に実装された原則により、通常のアプリケーションの開発プロセスと同様に、クラスター内でアドオンを作成、テスト、インストール、更新するための透過的なプロセスを構築できます。

モジュール形式 (Helm チャート + フック) の Addon-operator のアドオンを公開できます。 私たち Flant 社は、夏の間にそのような追加の形で開発内容を公開する予定です。 GitHub で開発に参加する (シェルオペレーター, アドオンオペレーター)、以下に基づいて独自の追加を行ってみてください。 例 и ドキュメンテーション、ハブレと私たちのニュースを待ちます YouTube チャンネル!

PS

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

• «Kubernetes の拡張と補足 (概要とビデオ レポート)";
• «シェル オペレーターの紹介: Kubernetes のオペレーターの作成がさらに簡単になりました'。

出所： habr.com