Helm デバイスとその落とし穴

タイフォン貨物輸送機のコンセプト、アントン・スワンポール

私の名前はドミトリー・スグロボフ、リロイ・マーリンの開発者です。 この記事では、Helm が必要な理由、Helm によって Kubernetes の操作がどのように簡素化されるか、第 XNUMX バージョンの変更点、および Helm を使用してダウンタイムなしで運用環境のアプリケーションを更新する方法について説明します。

これはカンファレンスでの講演をもとにまとめたものです @Kubernetes カンファレンス by Mail.ru クラウド ソリューション — 読みたくない場合は、ビデオをご覧ください。

本番環境で Kubernetes を使用する理由

Leroy Merlin は、ロシアとヨーロッパの DIY 小売市場のリーダーです。 当社には 33 人を超える開発者、000 人の社内従業員がおり、ハイパーマーケットや Web サイトを訪れる膨大な数の人々がいます。 彼ら全員を満足させるために、私たちは業界標準のアプローチに従うことにしました。 マイクロサービス アーキテクチャを使用して新しいアプリケーションを開発します。 コンテナを使用して環境を隔離し、適切な配信を保証します。 オーケストレーションには Kubernetes を使用します。 オーケストレーターの使用料金は急速に安くなり、市場ではこのテクノロジーに精通したエンジニアの数が増えており、Kubernetes をサービスとして提供するプロバイダーも登場しています。

もちろん、Kubernetes が行うことはすべて、たとえば、いくつかの Jenkins や docker-compose をスクリプトでカバーするなど、他の方法でも実行できます。しかし、既製の信頼できるソリューションがあるのに、なぜ作業が複雑になるのでしょうか。 それが、私たちが Kubernetes を導入し、XNUMX 年間本番環境で使用している理由です。 現在、XNUMX 個の Kubernetes クラスターがあり、そのうち最も古いクラスターは XNUMX 年以上前のもので、約 XNUMX 個のポッドがあります。

Kubernetes における大きな YAML ファイルの呪い

Kubernetes でマイクロサービスを起動するには、Deployment、Service、Ingress、ConfigMap、Secret 用に少なくとも XNUMX つの YAML ファイルを作成し、クラスターに送信します。 次のアプリケーションでは同じ側枠のパッケージを作成し、XNUMX 番目のアプリケーションでは別のパッケージを作成する、というように続きます。 ドキュメントの数に環境の数を掛けると、すでに数百のファイルが得られることになりますが、これには動的な環境がまだ考慮されていません。

Helm のコアメンテナーである Adam Reese は、「」という概念を導入しました。Kubernetes の開発サイクル"、これは次のようになります:

1. YAML のコピー - YAML ファイルをコピーします。
2. YAML を貼り付けます - 貼り付けます。
3. インデントを修正 - インデントを修正します。
4. 繰り返し - もう一度繰り返します。

このオプションは機能しますが、YAML ファイルを何度もコピーする必要があります。 このサイクルを変えるために、Helm が発明されました。

ヘルムとは

まず、ヘルム - パッケージマネージャー、必要なプログラムを見つけてインストールするのに役立ちます。 たとえば、MongoDB をインストールするには、公式 Web サイトにアクセスしてバイナリをダウンロードする必要はなく、次のコマンドを実行するだけです。 helm install stable/mongodb.

第二に、ヘルム - テンプレートエンジン、ファイルのパラメータ化に役立ちます。 Kubernetes の YAML ファイルの状況に戻りましょう。 同じ YAML ファイルを作成し、それにプレースホルダーを追加して、Helm が値を置き換える方が簡単です。 つまり、大規模な足場のセットの代わりに、必要な値が適切なタイミングで置き換えられるテンプレートのセットが存在します。

第三に、ヘルム - デプロイメントマスター。 これを使用すると、アプリケーションをインストール、ロールバック、更新できます。 これを行う方法を考えてみましょう。

Helm を使用して独自のアプリケーションをデプロイする方法

公式に従って Helm クライアントをコンピューターにインストールしましょう 説明書。 次に、YAML ファイルのセットを作成します。 特定の値を指定する代わりに、プレースホルダーを残しておきます。これは、後で Helm によって情報が入力されます。 このようなファイルのセットは Helm チャートと呼ばれます。 これは、次の XNUMX つの方法で Helm コンソール クライアントに送信できます。

• テンプレートが含まれるフォルダーを示します。
• アーカイブを .tar にパックし、それをポイントします。
• テンプレートをリモート リポジトリに配置し、Helm クライアントでリポジトリへのリンクを追加します。

値を含むファイル、values.yaml も必要です。 そこからのデータがテンプレートに挿入されます。 それも作ってみましょう。

Helm の XNUMX 番目のバージョンには、追加のサーバー アプリケーションである Tiller が含まれています。 Kubernetes の外部でハングして Helm クライアントからのリクエストを待ち、呼び出されると、必要な値をテンプレートに代入して Kubernetes に送信します。

Helm 3 はよりシンプルです。サーバー上でテンプレートを処理する代わりに、情報は完全に Helm クライアント側で処理され、Kubernetes API に直接送信されます。 この簡素化により、クラスターのセキュリティが向上し、ロールアウト スキームが容易になります。

すべてはどのように機能するのか

コマンドを実行します helm install。 アプリケーション リリースの名前を指定し、values.yaml へのパスを指定しましょう。 最後に、チャートが配置されているリポジトリとチャートの名前を示します。 この例では、それぞれ「lmru」と「bestchart」です。

helm install --name bestapp --values values.yaml lmru/bestchart

コマンドは一度だけ実行でき、再度実行すると代わりに実行されます。 install 使用する必要があります upgrade。 簡単にするために、XNUMX つのコマンドの代わりに、次のコマンドを実行できます。 upgrade 追加キー付き --install。 初めて実行すると、Helm はリリースをインストールするコマンドを送信し、将来的には更新します。

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Helm を使用してアプリケーションの新しいバージョンをデプロイする際の落とし穴

物語のこの時点で、私は観客と一緒に「Who Wants to Be a Millionaire」をプレイしており、Helm にアプリのバージョンを更新してもらう方法を考えています。 Смотретьвидео.

Helm の仕組みを学んでいたとき、実行中のアプリケーションのバージョンを更新しようとしたときの奇妙な動作に驚きました。 アプリケーション コードを更新し、新しいイメージを Docker レジストリにアップロードし、デプロイメント コマンドを送信しましたが、何も起こりませんでした。 以下に、アプリケーションを更新する完全には成功していない方法をいくつか示します。 それぞれをより詳細に研究することで、楽器の内部構造と、この明白ではない動作の理由が理解できるようになります。

方法 1. 前回の起動以降、情報を変更しない

ことわざにあるように 公式サイト Helm 氏、「Kubernetes チャートは大きくて複雑になる場合があるので、Helm はあまり何も触れないようにしています。」 したがって、docker レジストリ内のアプリケーション イメージの最新バージョンを更新してコマンドを実行すると、 helm upgrade、それでは何も起こりません。 Helm は何も変更されていないため、アプリケーションを更新するために Kubernetes にコマンドを送信する必要がないと考えます。

ここと以下では、最新のタグは例としてのみ示されています。 このタグを指定すると、Kubernetes は、imagePullPolicy パラメーターに関係なく、毎回 Docker レジストリからイメージをダウンロードします。 最新の製品を使用することは望ましくなく、副作用が発生します。

方法 2. 画像内の LABEL を更新する

同じところに書いてあるように ドキュメンテーション, 「Helm は、前回のリリース以降にアプリケーションが変更された場合にのみアプリケーションを更新します。」 このための論理的なオプションは、Docker イメージ自体の LABEL を更新することだと思われます。 ただし、Helm はアプリケーション イメージを調べず、アプリケーション イメージへの変更についてまったく知りません。 したがって、イメージ内のラベルを更新しても、Helm はそれらのラベルを認識せず、アプリケーション更新コマンドは Kubernetes に送信されません。

方法 3: キーを使用する --force

マニュアルを参照して、必要なキーを探してみましょう。 キーが最も意味のあるものです --force。 わかりやすい名前にもかかわらず、動作は予想とは異なります。 アプリケーションの更新を強制するのではなく、その本当の目的は、FAILED ステータスにあるリリースを復元することです。 このキーを使用しない場合は、コマンドを順番に実行する必要があります。 helm delete && helm install --replace。 代わりにキーを使用することをお勧めします --force、これらのコマンドの順次実行を自動化します。 詳細については、こちらをご覧ください プルリクエスト。 Helm にアプリケーションのバージョンを更新するように指示するには、残念ながら、このキーは機能しません。

方法 4. Kubernetes でラベルを直接変更する

コマンドを使用してクラスター内でラベルを直接更新する kubectl edit - 悪いアイデア。 このアクションにより、実行中のアプリケーションと、最初にデプロイメントのために送信されたアプリケーションとの間で情報の不一致が生じます。 この場合のデプロイ中の Helm の動作は、そのバージョンとは異なります。Helm 2 は何も行わず、Helm 3 はアプリケーションの新しいバージョンをデプロイします。 その理由を理解するには、Helm がどのように機能するかを理解する必要があります。

ヘルムはどのように機能しますか?

アプリケーションが最後のリリース以降に変更されたかどうかを判断するには、Helm は以下を使用できます。

• Kubernetes でアプリケーションを実行する。
• 新しいvalues.yamlと現在のチャート。
• Helm の内部リリース情報。

さらに興味深いのは、Helm はリリースに関する内部情報をどこに保存するのでしょうか?コマンドを実行することで helm history, Helm を使用して、インストールされているバージョンに関するすべての情報を取得します。

送信されたテンプレートと値に関する詳細情報もあります。 リクエストできます:

Helm の XNUMX 番目のバージョンでは、この情報は Tiller が実行されているのと同じ名前空間 (デフォルトでは kube-system) にあり、ConfigMap 内で「OWNER=TILLER」というラベルが付いています。

Helm の XNUMX 番目のバージョンが登場すると、情報はシークレットに移動し、アプリケーションが実行されていたのと同じ名前空間に移動しました。 これにより、同じリリース名で複数のアプリケーションを異なる名前空間で同時に実行できるようになりました。 XNUMX 番目のバージョンでは、名前空間が分離されていても相互に影響を与える可能性がある場合に、深刻な問題が発生しました。

XNUMX 番目の Helm は、更新が必要かどうかを理解しようとするときに、現在提供されている情報と、ConfigMap にあるリリースに関する内部情報という XNUMX つの情報ソースのみを使用します。

XNUMX 番目の Helm は XNUMX 方向のマージ戦略を使用します。その情報に加えて、Kubernetes で現在実行されているアプリケーションも考慮されます。

このため、古いバージョンの Helm はクラスター内のアプリケーション情報を考慮しないため何も行いませんが、Helm 3 は変更を受信し、新しいアプリケーションをデプロイメント用に送信します。

方法 5. --recreate-pods スイッチを使用する

鍵付き --recreate-pods キーを使用して当初に達成する予定だったものを達成できます --force。 コンテナーが再起動され、imagePullPolicy: Always ポリシー (最新タグの詳細) に従って、Kubernetes はイメージの新しいバージョンをダウンロードして起動します。 これは最良の方法では行われません。デプロイメントの StrategyType を考慮せずに、すべての古いアプリケーション インスタンスが突然オフになり、新しいアプリケーション インスタンスの起動が開始されます。 再起動中はシステムが動作しなくなり、ユーザーは損害を受けることになります。

Kubernetes 自体にも、同様の問題が長い間存在していました。 そしてオープンから4年が経った今、 問題、問題は修正され、Kubernetes のバージョン 1.15 以降では、ポッドをロール再起動する機能が表示されます。

Helm は単にすべてのアプリケーションをオフにして、近くの新しいコンテナーを起動します。 アプリケーションのダウンタイムが発生しないように、運用環境ではこれを行うことはできません。 これは開発ニーズにのみ必要であり、ステージ環境でのみ実行できます。

Helm を使用してアプリケーションのバージョンを更新するにはどうすればよいですか?

Helmに送信する値を変更していきます。 通常、これらはイメージ タグの代わりに置き換えられる値です。 非生産的な環境でよく使用される最新の場合、変更可能な情報はアノテーションですが、これは Kubernetes 自体には役に立たず、Helm にとってはアプリケーションを更新する必要があることを示す信号として機能します。 注釈値を入力するためのオプション:

1. ランダムな値 標準関数を使用する - {{ randAlphaNum 6 }}.
   注意点があります。このような変数を含むチャートを使用する各デプロイメントの後、注釈値は一意になり、Helm は変更があると想定します。 バージョンを変更していない場合でも、アプリケーションは常に再起動されることがわかります。 ダウンタイムがないため、これは重要ではありませんが、それでも不快なものです。
2. 現在のペースト 日時 - {{ .Release.Date }}.
   バリアントは、永続的に一意の変数を持つランダム値に似ています。
3. より正しい方法は次のように使用することです チェックサム。 これは、イメージの SHA または git 内の最後のコミットの SHA です。 {{ .Values.sha }}.
   これらはカウントされ、呼び出し側 (Jenkins など) の Helm クライアントに送信される必要があります。 アプリケーションが変更されると、チェックサムも変更されます。 したがって、Helm は必要な場合にのみアプリケーションを更新します。

私たちの試みをまとめてみましょう

• Helm は最も侵襲性の低い方法で変更を行うため、Docker レジストリ内のアプリケーション イメージ レベルでの変更は更新されません。コマンドの実行後は何も起こりません。
• キー --force 問題のあるリリースを復元するために使用され、強制的なアップデートには関連付けられません。
• キー --recreate-pods アプリケーションを強制的に更新しますが、それは破壊的な方法で行われ、すべてのコンテナが突然オフになります。 ユーザーはこれに苦しむことになるため、運用環境ではこれを行うべきではありません。
• コマンドを使用して、Kubernetes クラスターに直接変更を加えます。 kubectl edit しないでください: 一貫性が失われ、動作は Helm のバージョンに応じて異なります。
• Helm の新しいバージョンのリリースにより、多くのニュアンスが明らかになりました。 Helm リポジトリの問題は明確な言語で説明されており、詳細を理解するのに役立ちます。
• 編集可能な注釈をグラフに追加すると、グラフがより柔軟になります。 これにより、ダウンタイムなしでアプリケーションを正しくロールアウトできるようになります。

生活のあらゆる分野で役立つ「世界平和」の考え: 使用後ではなく、使用前に説明書をお読みください。 完全な情報があって初めて、信頼性の高いシステムを構築し、ユーザーを満足させることができます。

その他の関連リンク:

1. を満たす ヘルメット 3
2. ヘルム公式サイト
3. GitHub 上の Helm リポジトリ
4. 25 の便利な Kubernetes ツール: デプロイと管理

このレポートは最初に発表されました。 @Kubernetes カンファレンス Mail.ru クラウド ソリューションによる。 見て ビデオ 他のパフォーマンスやイベントのお知らせを Telegram で購読する Mail.ru グループの Kubernetes について.

出所： habr.com