🥇werf への 3 方向マージ: Helm を「強力に」使用した Kubernetes へのデプロイメント

私たち（そして私たちだけではありません）が長い間待っていたことが起こりました：ワーフ、アプリケーションを構築して Kubernetes に配信するためのオープンソースユーティリティが、3 ウェイマージパッチを使用した変更の適用をサポートするようになりました。これに加えて、既存の K8s リソースを再構築せずに Helm リリースに採用することができます。

非常に短い場合は、 WERF_THREE_WAY_MERGE=enabled — 次のように「デプロイメント」を取得します kubectl apply"、既存の Helm 2 インストールとさらに互換性があります。

しかし、理論から始めましょう。3 ウェイマージパッチとは一体何なのか、人々はどのようにしてパッチを生成するアプローチを思いついたのか、そしてなぜ Kubernetes ベースのインフラストラクチャを使用した CI/CD プロセスにおいて重要なのでしょうか。その後、werf における 3-way-merge とは何か、デフォルトで使用されるモード、およびその管理方法を見てみましょう。

3-way マージパッチとは何ですか?

そこで、YAML マニフェストに記述されたリソースを Kubernetes にロールアウトするタスクから始めましょう。

リソースを操作するために、Kubernetes API は、作成、パッチ適用、置換、削除という基本操作を提供します。彼らの助けを借りて、クラスターへのリソースの便利な継続的なロールアウトを構築する必要があると想定されます。どうやって？

kubectl 命令型コマンド

Kubernetes でオブジェクトを管理する最初のアプローチは、kubectl 命令型コマンドを使用して、それらのオブジェクトを作成、変更、削除することです。簡単に言えば：

チーム kubectl run デプロイメントまたはジョブを実行できます。
```
kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE
```
チーム kubectl scale — レプリカの数を変更します。
```
kubectl scale --replicas=3 deployment/mysql
```
等

このアプローチは一見すると便利に見えるかもしれません。ただし、次のような問題があります。

それは難しい 自動化.
Как 構成を反映する Gitで？クラスターに起こった変更を確認するにはどうすればよいですか?
提供方法 再現性 再起動時の設定?
...

このアプローチが、アプリケーションとインフラストラクチャをコードとして保存すること (IaC、または GitOps より現代的なオプションとして、Kubernetes エコシステムで人気が高まっています)。したがって、これらのコマンドは kubectl でさらに開発されませんでした。

作成、取得、置換、削除の操作

プライマリー付き の作成 簡単です: マニフェストをオペレーションに送信します create kube API とリソースが作成されました。マニフェストの YAML 表現は Git に保存し、次のコマンドを使用して作成できます。 kubectl create -f manifest.yaml.

С 削除これも簡単です: 同じものを置き換えます manifest.yaml Git からチームへ kubectl delete -f manifest.yaml.

操作 replace リソースを再作成することなく、リソース構成を新しいものに完全に置き換えることができます。これは、リソースに変更を加える前に、次の操作で現在のバージョンをクエリすることが論理的であることを意味します。 getを変更し、操作で更新します。 replace。 kube APIサーバーが組み込まれています楽観的ロックそして手術後の場合は get オブジェクトが変更されてから操作が行われる replace 通らないだろう。

設定を Git に保存し、replace を使用して更新するには、次の操作を行う必要があります。 get、Git からの設定を受け取ったものとマージし、実行します replace。デフォルトでは、kubectl は次のコマンドのみを使用できます。 kubectl replace -f manifest.yamlどこ manifest.yaml — インストールする必要がある、すでに完全に準備された (この場合はマージされた) マニフェスト。ユーザーはマージマニフェストを実装する必要があることがわかりましたが、これは簡単な問題ではありません...

また、注目に値するのは、 manifest.yaml オブジェクトが Git に保存されている場合、オブジェクトを作成する必要があるのか更新する必要があるのかを事前に知ることはできません。これはユーザーソフトウェアによって実行する必要があります。

合計： 継続的な展開を構築できるか 作成、置換、削除のみを使用して、インフラストラクチャ構成がコードおよび便利な CI/CD とともに確実に Git に保存されるようにしますか?

原則として、私たちは次のことを行うことができます... マージ操作を実装する必要があります マニフェストと次のようなバインディング:

クラスター内のオブジェクトの存在を確認します。
初期リソース作成を実行します。
更新または削除します。

アップデートの際はご注意ください リソースが変更された可能性があります 前回から get オプティミスティックロックのケースを自動的に処理し、更新を繰り返し試行します。

しかし、kube-apiserver がリソースを更新する別の方法、つまりオペレーションを提供しているのに、なぜ車輪の再発明をする必要があるのでしょうか。 patch、これにより、説明されている問題の一部がユーザーから解放されますか?

パッチ

さて、パッチの話に入ります。

パッチは、Kubernetes の既存のオブジェクトに変更を適用する主な方法です。手術 patch それはこのように動作します：

kube-apiserver ユーザーは JSON 形式でパッチを送信し、オブジェクトを指定する必要があります。
そして、apiserver 自体がオブジェクトの現在の状態を処理し、それを必要な形式にします。

この場合、楽観的ロックは必要ありません。この操作は置換よりも宣言的ですが、最初は逆に見えるかもしれません。

したがって：

操作を使用して create Git のマニフェストに従ってオブジェクトを作成します。
経由 delete — オブジェクトが不要になった場合は削除します。
経由 patch — オブジェクトを変更して、Git で記述された形式にします。

ただし、これを行うには、 正しいパッチ!

Helm 2 でのパッチの仕組み: 双方向マージ

初めてリリースをインストールするときに、Helm が操作を実行します。 create チャートリソースの場合。

各リソースの Helm リリースを更新する場合:

前のチャートのリソースバージョンと現在のチャートバージョンの間のパッチを考慮します。
このパッチを適用します。

このパッチをパッチと呼びます 双方向マージパッチ、その作成には 2 つのマニフェストが関係しているためです。

以前のリリースのリソースマニフェスト、
現在のリソースからのリソースマニフェスト。

操作を削除する場合 delete kube では、以前のリリースでは宣言されたが、現在のリリースでは宣言されていないリソースに対して apiserver が呼び出されます。

2 方向のマージパッチのアプローチには問題があります。 クラスター内のリソースの実際の状態および Git のマニフェストと同期していません.

例による問題の図解

Git では、チャートにはフィールドが含まれるマニフェストが保存されます。 image 導入に関する事項 ubuntu:18.04.
ユーザー経由 kubectl edit このフィールドの値を次のように変更しました ubuntu:19.04.
Helm チャートを再デプロイする場合 パッチは生成されません、フィールドなので image 以前のバージョンのリリースと現在のチャートでは同じです。
再配備後 image 遺体 ubuntu:19.04、チャートには次のように書かれていますが、 ubuntu:18.04.

非同期が発生し、宣言性が失われました。

同期リソースとは何ですか?

一般的に言えばフル実行中のクラスター内のリソースマニフェストと Git からのマニフェストの間で一致を取得することは不可能です。実際のマニフェストには、一部のコントローラーによってリソースに動的に追加および削除されるサービスの注釈/ラベル、追加のコンテナー、およびその他のデータが存在する可能性があるためです。このデータを Git に保存することはできませんし、保存したくありません。ただし、Git で明示的に指定したフィールドには、ロールアウト時に適切な値が設定されるようにする必要があります。

それは非常に一般的であることがわかりました 同期リソースルール: リソースをロールアウトするときに、Git のマニフェストで明示的に指定されている (または、以前のバージョンで指定され、現在は削除されている) フィールドのみを変更または削除できます。

双方向マージパッチ

中心思想双方向マージパッチ: 実行中のクラスターからのマニフェストの現在のバージョンを考慮して、Git からのマニフェストの最後に適用されたバージョンと Git からのマニフェストのターゲットバージョンとの間にパッチを生成します。結果として得られるパッチは、同期リソースルールに準拠する必要があります。

ターゲットバージョンに追加される新しいフィールドはパッチを使用して追加されます。
最後に適用されたバージョンに以前に存在し、ターゲットバージョンに存在しないフィールドは、パッチを使用してリセットされます。
マニフェストのターゲットバージョンと異なるオブジェクトの現在のバージョンのフィールドは、パッチを使用して更新されます。

この原理に基づいてパッチが生成されます。 kubectl apply:

マニフェストの最後に適用されたバージョンはオブジェクト自体のアノテーションに保存されます。
target - 指定された YAML ファイルから取得されます。
現在のものは実行中のクラスターからのものです。

理論を整理したので、次は werf で何をしたかを説明します。

werf への変更の適用

以前、werf は、Helm 2 と同様に、双方向マージパッチを使用していました。

修復パッチ

新しいタイプのパッチ - 3-way-merge - に切り替えるための最初のステップとして、いわゆる 修復パッチ.

デプロイ時には、標準の 2-way マージパッチが使用されますが、werf はさらに、リソースの実際の状態と Git に書き込まれた内容を同期するパッチを生成します (そのようなパッチは、上で説明したのと同じ同期リソースルールを使用して作成されます)。。

非同期が発生した場合、デプロイメントの最後に、ユーザーは対応するメッセージを含む警告と、リソースを同期された形式にするために適用する必要があるパッチを受け取ります。このパッチは特別なアノテーションにも記録されています werf.io/repair-patch。ユーザーの手によるものと想定されます。 彼自身 はこのパッチを適用しますが、werf はそれをまったく適用しません。

修復パッチの生成は、3 方向マージの原則に基づいてパッチの作成を実際にテストできるようにする一時的な手段ですが、これらのパッチが自動的に適用されるわけではありません。現時点では、この動作モードはデフォルトで有効になっています。

新しいリリース専用の 3-way-merge パッチ

1 年 2019 月 XNUMX 日より、werf のベータ版とアルファ版が開始されます デフォルトで 本格的な 3-way マージパッチを使用して、werf を通じて展開される新しい Helm リリースにのみ変更を適用します。既存のリリースでは、引き続き双方向のマージ + パッチの修復アプローチが使用されます。

この動作モードは、設定によって明示的に有効にすることができます。 WERF_THREE_WAY_MERGE_MODE=onlyNewReleases 今

注意: この機能はいくつかのリリースにわたって werf に登場しました: アルファチャネルではバージョンで準備が整いました v1.0.5-alpha.19、そしてベータチャンネルでは - v1.0.4-ベータ.20.

すべてのリリースの 3-way マージパッチ

15 年 2019 月 3 日以降、werf のベータ版とアルファ版では、すべてのリリースに変更を適用するために、デフォルトで完全な XNUMX-way マージパッチが使用され始めます。

この動作モードは、設定によって明示的に有効にすることができます。 WERF_THREE_WAY_MERGE_MODE=enabled 今

リソースの自動スケーリングをどうするか?

Kubernetes の自動スケーリングには、HPA (水平) と VPA (垂直) の 2 種類があります。

水平方向ではレプリカの数が自動的に選択され、垂直方向ではリソースの数が選択されます。レプリカの数とリソース要件は両方ともリソースマニフェストで指定されます (リソースマニフェストを参照)。 spec.replicas または spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и 他人).

問題: ユーザーがリソースまたはレプリカに特定の値を指定するようにチャート内のリソースを構成し、このリソースに対してオートスケーラーが有効になっている場合、各デプロイメントで werf がこれらの値をチャートマニフェストに書き込まれた値にリセットします。。

この問題には XNUMX つの解決策があります。まず、チャートマニフェストで自動スケール値を明示的に指定しないことが最善です。このオプションが何らかの理由で適切でない場合 (たとえば、チャート内の初期リソース制限とレプリカの数を設定するのが便利なため)、werf は次の注釈を提供します。

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

このようなアノテーションが存在する場合、werf は各デプロイメントで対応する値をリセットせず、リソースが最初に作成されたときにのみ設定します。

詳細については、プロジェクトのドキュメントを参照してください。 HPA и VPA.

3-way-merge パッチの使用を禁止する

ユーザーは現在、環境変数を使用して werf での新しいパッチの使用を禁止できます。 WERF_THREE_WAY_MERGE_MODE=disabled。ただし、開始 1 年 2020 月 XNUMX 日以降、この禁止は適用されなくなります。 また、3-way-merge パッチのみを使用できます。

werf でのリソースの採用

3-way マージパッチで変更を適用する方法を習得したことで、クラスター内に存在するリソースを Helm リリースに採用するなどの機能をすぐに実装できるようになりました。

Helm 2 には問題があります。クラスター内に既に存在するチャートマニフェストにリソースを追加するには、このリソースを最初から再作成する必要があります (「Helm XNUMX」を参照)。 #6031, #3275）。私たちは、既存のリソースのリリースを受け入れるように werf に教えました。これを行うには、実行中のクラスターから現在のバージョンのリソースにアノテーションをインストールする必要があります (たとえば、 kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

ここでリソースをチャートに記述する必要があり、次回 werf が適切な名前のリリースをデプロイするときに、既存のリソースがこのリリースに受け入れられ、その制御下に残ります。さらに、リソースの解放を受け入れるプロセスで、werf は、同じ 3 ウェイマージパッチと同期されたリソースルールを使用して、実行中のクラスターからのリソースの現在の状態をチャートで説明されている状態にします。

注意：設定 WERF_THREE_WAY_MERGE_MODE リソースの採用には影響しません。採用の場合は、常に 3-way マージパッチが使用されます。

詳細 - でドキュメンテーション.

結論と今後の計画

この記事を読んだ後、3-way マージパッチとは何か、そしてなぜそのパッチが導入されたのかがより明確になったことを願っています。 werf プロジェクトの開発の実際的な観点から見ると、その実装は Helm のような展開を改善するための新たな一歩でした。これで、Helm 2 の使用時によく発生する構成の同期に関する問題を忘れることができます。同時に、既にダウンロードされた Kubernetes リソースを採用するという新しい便利な機能が Helm リリースに追加されました。

Helm のようなデプロイメントには、Go テンプレートの使用などの問題や課題がまだいくつかありますが、これらについては引き続き取り組んでいきます。

リソースの更新方法と採用に関する情報は、次の場所にもあります。このドキュメントページ.

ヘルム3

特筆に値する解放されたつい先日、Helm の新しいメジャーバージョン v3 がリリースされました。これも 3-way-merge パッチを使用し、Tiller を削除しました。 Helm の新しいバージョンには次のものが必要ですマイグレーション既存のインストールを削除して、新しいリリースのストレージ形式に変換します。

Werf 側では、現在 Tiller の使用を廃止し、3-way-merge に切り替えて追加しました。はるかに、既存の Helm 2 インストールとの互換性を維持しながら (移行スクリプトを実行する必要はありません)。したがって、werf が Helm 3 に切り替わるまで、werf ユーザーは Helm 3 に比べて Helm 2 の主な利点を失うことはありません (werf にもそれらがあります)。

ただし、werf から Helm 3 コードベースへの切り替えは避けられず、近い将来に行われる予定です。おそらく、これは werf 1.1 または werf 1.2 になります (現時点では、werf のメインバージョンは 1.0 です。werf バージョン管理デバイスの詳細については、「werf バージョン管理デバイス」を参照してください)。ここで）。この間、Helm 3 は安定する時間がかかります。

PS

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

werf のイノベーションに関する一連のメモ:
«werf - Kubernetes の CI / CD 用ツール (概要とビデオレポート)";
«werf と GitLab CI を使用して同じタイプのマイクロサービスを構築してデプロイする";
«Helm 3 の紹介'。

出所： habr.com

werf への 3 方向マージ: Helm を「強力に」使用した Kubernetes へのデプロイメント

3-way マージ パッチとは何ですか?