🥇Helm 3 の紹介 | プロホスター

ノート。翻訳。: 今年の 16 月 3.0 日は、Kubernetes のパッケージマネージャーである Helm の開発における重要なマイルストーンとなります。この日、プロジェクトの将来のメジャーバージョンである XNUMX の最初のアルファリリースが発表されました。このリリースにより、Helm には待望の重要な変更がもたらされ、Kubernetes コミュニティの多くの人が大きな期待を寄せています。私たち自身もその XNUMX つであり、アプリケーションのデプロイメントに Helm を積極的に使用しているため、CI/CD を実装するツールに Helm を統合しています。ワーフそして時々、私たちは上流の発展に貢献します。この翻訳は、Helm 7 の最初のアルファリリースに特化し、プロジェクトの歴史と Helm 3 の主な機能について語る、Helm 公式ブログの 3 つのメモを組み合わせたものです。その著者は、Microsoft 従業員の Matt "bacongobbler" Fisher です。 Helm の主要なメンテナーの XNUMX 人です。

15 年 2015 月 2 日、現在 Helm として知られるプロジェクトが誕生しました。設立からわずか 2018 年後、Helm コミュニティは Kubernetes に参加し、同時に Helm XNUMX に積極的に取り組んでいました。XNUMX 年 XNUMX 月、Helm は CNCFに参加しました開発（インキュベート）プロジェクトとして。現在に遡ると、新しい Helm 3 の最初のアルファリリースが近づいています。 (今回のリリースではすでに起こっています XNUMX月中旬 - 約翻訳）.

この記事では、すべてがどこで始まったのか、どのようにして今日の状況に至ったのかについて話し、Helm 3 の最初のアルファリリースで利用できるいくつかのユニークな機能を紹介し、今後どのように進めていく予定であるかを説明します。

要約：

Helm の作成の歴史。
ティラーに優しい別れを告げる。
チャートリポジトリ。
リリース管理;
チャートの依存関係の変更。
図書館のチャート。
次は何？

ヘルムの歴史

出産

Helm 1 は、Deis によって作成されたオープンソースプロジェクトとして始まりました。私たちは小さなスタートアップでした吸収された 2017 年春のマイクロソフト。私たちのもう XNUMX つのオープンソースプロジェクト (同じく Deis という名前) には、次のツールがありました。 deisctl、これは（とりわけ）Deis プラットフォームのインストールと運用に使用されました。フリートクラスター。当時、Fleet は最初のコンテナオーケストレーションプラットフォームの XNUMX つでした。

2015 年半ばに、私たちは方針を変更することを決定し、Deis (当時は Deis Workflow に名前変更されました) を Fleet から Kubernetes に移行しました。最初に再設計されたものの XNUMX つはインストールツールです。 deisctl。これを使用して、フリートクラスターに Deis ワークフローをインストールし、管理しました。

Helm 1 は、Homebrew、apt、yum などの有名なパッケージマネージャーをイメージして作成されました。その主な目標は、Kubernetes でのアプリケーションのパッケージ化やインストールなどのタスクを簡素化することでした。 Helm は、2015 年にサンフランシスコで開催された KubeCon カンファレンスで正式に導入されました。

Helm を使用した最初の試みはうまくいきましたが、いくつかの重大な制限がないわけではありませんでした。彼は、入門用の YAML ブロックとしてジェネレーターを追加した Kubernetes マニフェストのセットを取得しました。 （フロントの問題）* を作成し、結果を Kubernetes にロードしました。

* ノート。翻訳。: Helm の最初のバージョンから、Kubernetes リソースを記述するために YAML 構文が選択され、構成を記述するときに Jinja テンプレートと Python スクリプトがサポートされました。これと Helm の最初のバージョンの構造全般については、「Helm の簡単な歴史」の章で詳しく書きました。この素材.

たとえば、YAML ファイル内のフィールドを置換するには、マニフェストに次の構成を追加する必要がありました。

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

今、テンプレートエンジンが存在するのは素晴らしいことですよね。

さまざまな理由から、この初期の Kubernetes インストーラーでは、ハードコーディングされたマニフェストファイルのリストが必要で、少数の固定されたイベントシーケンスのみが実行されました。非常に使いにくいため、Deis Workflow 研究開発チームは製品をこのプラットフォームに移行しようとして苦労しましたが、アイデアの種はすでに蒔かれていました。私たちの最初の試みは、素晴らしい学習の機会でした。私たちは、ユーザーの日常の問題を解決する実用的なツールを作成することに本当に情熱を持っていることに気づきました。

過去の失敗の経験に基づいて、私たちは Helm 2 の開発を開始しました。

兜作り2

2015 年末に、Google チームから連絡がありました。彼らは、Kubernetes 用の同様のツールを開発していました。 Deployment Manager for Kubernetes は、Google Cloud Platform で使用されていた既存のツールの移植でした。「類似点と相違点について数日かけて話し合ってもよろしいでしょうか？」と彼らは尋ねました。

2016 年 2 月、ヘルムチームとデプロイメントマネージャーチームはシアトルで集まり、アイデアを交換しました。交渉は、両方のプロジェクトを統合して Helm XNUMX を作成するという野心的な計画で終わりました。Deis と Google とともに、スキップボックス (現在は Bitnami の一部 - おおよその翻訳)、そして私たちは Helm 2 の開発に取り組み始めました。

Helm の使いやすさを維持したいと考えましたが、次の点を追加しました。

カスタマイズ用のグラフテンプレート。
チームのクラスター内管理。
世界クラスのチャートリポジトリ。
署名オプション付きの安定したパッケージ形式。
セマンティックバージョニングとバージョン間の下位互換性の維持に対する強い取り組み。

これらの目標を達成するために、Helm エコシステムに XNUMX 番目の要素が追加されました。このクラスター内コンポーネントは Tiller と呼ばれ、Helm チャートのインストールと管理を担当していました。

2 年の Helm 2016 のリリース以来、Kubernetes にはいくつかの主要な革新が追加されました。ロールベースのアクセス制御を追加しました (RBAC)、最終的には属性ベースのアクセス制御 (ABAC) に置き換わりました。新しいリソースタイプが導入されました (当時、デプロイメントはまだベータ版でした)。カスタムリソース定義 (当初はサードパーティリソースまたは TPR と呼ばれていました) が発明されました。そして最も重要なことは、一連のベストプラクティスが明らかになったということです。

これらすべての変化の中でも、Helm は Kubernetes ユーザーに忠実にサービスを提供し続けました。 XNUMX 年が経過し、多くの新しい追加が行われた後、Helm が進化するエコシステムの増大するニーズに確実に応え続けることができるように、コードベースに大幅な変更を加える時期が来たことは明らかでした。

ティラーへの優しい別れ

Helm 2 の開発中に、Google の Deployment Manager との統合の一環として Tiller を導入しました。 Tiller は、共通のクラスター内で作業するチームにとって重要な役割を果たしました。これにより、インフラストラクチャを運用するさまざまな専門家が同じリリースのセットを操作できるようになります。

Kubernetes 1.6 ではロールベースのアクセス制御 (RBAC) がデフォルトで有効になったため、運用環境で Tiller を使用することがより困難になりました。考えられるセキュリティポリシーの数が膨大であるため、私たちはデフォルトで寛容な構成を提供するという立場にあります。これにより、初心者は最初にセキュリティ設定に飛び込むことなく、Helm と Kubernetes を試すことができました。残念ながら、この権限構成では、ユーザーに必要のない広範な権限が与えられる可能性があります。 DevOps および SRE エンジニアは、Tiller をマルチテナントクラスターにインストールするときに追加の操作手順を学ぶ必要がありました。

コミュニティが特定の状況で Helm をどのように使用しているかを学んだ後、Tiller のリリース管理システムは状態を維持したり、リリース情報の中央ハブとして機能したりするためにクラスター内コンポーネントに依存する必要がないことがわかりました。代わりに、Kubernetes API サーバーから情報を受信し、クライアント側でグラフを生成し、インストールの記録を Kubernetes に保存するだけで済みます。

Tiller の主な目標は Tiller なしでも達成できた可能性があるため、Helm 3 に関する私たちの最初の決定の XNUMX つは Tiller を完全に放棄することでした。

Tiller がいなくなったことで、Helm のセキュリティモデルは根本的に簡素化されました。 Helm 3 は、現在の Kubernetes の最新のセキュリティ、アイデンティティ、認証方法をすべてサポートするようになりました。 Helm 権限は次を使用して決定されます。 kubeconfigファイル。クラスター管理者は、ユーザー権限を任意の粒度レベルで制限できます。リリースは引き続きクラスター内に保存され、Helm の残りの機能はそのまま残ります。

チャートリポジトリ

大まかに言うと、チャートリポジトリは、チャートを保存および共有できる場所です。 Helm クライアントはチャートをパッケージ化してリポジトリに送信します。簡単に言えば、チャートリポジトリは、index.yaml ファイルといくつかのパッケージ化されたチャートを備えた基本的な HTTP サーバーです。

Charts Repository API が最も基本的なストレージ要件を満たすことにはいくつかの利点がありますが、いくつかの欠点もあります。

チャートリポジトリは、運用環境で必要なほとんどのセキュリティ実装と互換性がありません。実稼働シナリオでは、認証と認可のための標準 API を用意することが非常に重要です。
Helm のチャート来歴ツールは、チャートの署名、整合性および来歴の検証に使用され、チャート公開プロセスのオプションの部分です。
マルチユーザーのシナリオでは、同じグラフを別のユーザーがアップロードすることができ、同じコンテンツを保存するために必要なスペースが XNUMX 倍になります。この問題を解決するために、よりスマートなリポジトリが開発されましたが、それらは正式な仕様の一部ではありません。
単一のインデックスファイルを検索、メタデータの保存、チャートの取得に使用すると、安全なマルチユーザー実装の開発が困難になります。

プロジェクト Docker ディストリビューション (Docker Registry v2 とも呼ばれます) は Docker Registry の後継であり、基本的に Docker イメージのパッケージ化、配布、保存、配信のためのツールセットとして機能します。大規模なクラウドサービスの多くは、ディストリビューションベースの製品を提供しています。この注目の高まりのおかげで、ディストリビューションプロジェクトは、長年にわたる改善、セキュリティのベストプラクティス、およびフィールドテストの恩恵を受け、オープンソースの世界で最も成功した縁の下の力持ちの XNUMX つとなりました。

しかし、配布プロジェクトはコンテナイメージだけでなく、あらゆる形式のコンテンツを配布できるように設計されていることをご存知ですか?

努力のおかげで Open ContainerInitiative (または OCI)、Helm チャートは任意の Distribution インスタンスに配置できます。現時点では、このプロセスは実験的なものです。完全な Helm 3 に必要なログインサポートやその他の機能は現在開発中ですが、OCI チームと配布チームが長年にわたって行ってきた発見から学ぶことができることを楽しみにしています。そして、彼らの指導と指導を通じて、私たちは高可用性サービスを大規模に運用することがどのようなものかを学びます。

Helm チャートリポジトリに対する今後の変更の詳細については、こちらをご覧ください。リンク.

リリース管理

Helm 3 では、アプリケーションの状態は次のオブジェクトのペアによってクラスター内で追跡されます。

release オブジェクト - アプリケーションインスタンスを表します。
リリースバージョンシークレット - 特定の時点でのアプリケーションの望ましい状態を表します (新しいバージョンのリリースなど)。

挑戦 helm install リリースオブジェクトとリリースバージョンシークレットを作成します。電話 helm upgrade リリースオブジェクト (変更可能) が必要で、新しい値と準備されたマニフェストを含む新しいリリースバージョンのシークレットを作成します。

Release オブジェクトには、リリースに関する情報が含まれています。ここで、 release は、名前付きチャートと値の特定のインストールです。このオブジェクトは、リリースに関するトップレベルのメタデータを記述します。リリースオブジェクトはアプリケーションのライフサイクル全体にわたって存続し、すべてのリリースバージョンのシークレットと、Helm チャートによって直接作成されたすべてのオブジェクトの所有者です。

リリースバージョンシークレットは、リリースを一連のリビジョン (インストール、更新、ロールバック、削除) に関連付けます。

Helm 2 では、リビジョンは非常に一貫していました。電話 helm install v1 を作成し、その後の更新 (アップグレード) - v2 などとなります。リリースおよびリリースバージョンのシークレットは、リビジョンと呼ばれる単一のオブジェクトに折りたたまれています。リビジョンは Tiller と同じ名前空間に保存されました。これは、各リリースが名前空間の観点から「グローバル」であることを意味します。その結果、名前のインスタンスは XNUMX つだけ使用できました。

Helm 3 では、各リリースは XNUMX つ以上のリリースバージョンシークレットに関連付けられています。リリースオブジェクトは常に、Kubernetes にデプロイされている現在のリリースを記述します。各リリースバージョンシークレットは、そのリリースの XNUMX つのバージョンのみを記述します。たとえば、アップグレードでは、新しいリリースバージョンのシークレットが作成され、その新しいバージョンを指すようにリリースオブジェクトが変更されます。ロールバックの場合は、以前のリリースバージョンのシークレットを使用して、リリースを以前の状態にロールバックできます。

Tiller が放棄された後、Helm 3 はリリースデータをリリースと同じ名前空間に保存します。この変更により、同じリリース名のチャートを別の名前空間にインストールできるようになり、クラスターの更新/再起動の間に etcd でデータが保存されます。たとえば、WordPress を「foo」名前空間にインストールしてから「bar」名前空間にインストールし、両方のリリースに「wordpress」という名前を付けることができます。

チャートの依存関係の変更

パックされたチャート (使用 helm packageHelm 2 で使用する ) は Helm 3 にもインストールできますが、チャート開発ワークフローは完全に見直されたため、Helm 3 でチャート開発を続行するにはいくつかの変更を加える必要があります。特に、チャートの依存関係管理システムが変更されました。

チャートの依存関係管理システムは、 requirements.yaml и requirements.lock на Chart.yaml и Chart.lock。これは、コマンドを使用したチャートが helm dependencyHelm 3 で動作するには、いくつかのセットアップが必要です。

例を見てみましょう。 Helm 2 のチャートに依存関係を追加し、Helm 3 に移行すると何が変わるかを見てみましょう。

ヘルム 2 で requirements.yaml このように見えました:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Helm 3 では、同じ依存関係が Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

チャートは引き続きダウンロードされ、ディレクトリに配置されます charts/、つまりサブチャート (サブチャート)、カタログに載ってます charts/は変更せずに引き続き機能します。

ライブラリーチャートの紹介

Helm 3 は、ライブラリチャートと呼ばれるチャートのクラスをサポートしています。 (図書館図)。このチャートは他のチャートによって使用されますが、それ自体ではリリースアーティファクトを作成しません。ライブラリチャートテンプレートは要素のみを宣言できます define。他のコンテンツは単に無視されます。これにより、ユーザーは複数のチャートで使用できるコードスニペットを再利用および共有できるため、重複を避け、原則を維持できます。 DRY.

ライブラリチャートはセクションで宣言されます dependencies ファイル内 Chart.yaml。インストールと管理は他のチャートと何ら変わりません。

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

私たちは、このコンポーネントがチャート開発者にもたらすユースケースと、ライブラリチャートから得られるベストプラクティスに興奮しています。

次は何ですか？

Helm 3.0.0-alpha.1 は、Helm の新しいバージョンの構築を開始するための基盤です。この記事では、Helm 3 のいくつかの興味深い機能について説明しました。それらの多くはまだ開発の初期段階にあり、これは正常なことです。アルファリリースのポイントは、アイデアをテストし、初期のユーザーからフィードバックを収集し、仮定を確認することです。

アルファ版がリリースされ次第 (これはすでに起こっています — 約翻訳）、コミュニティから Helm 3 のパッチの受け付けを開始します。新しい機能の開発と採用を可能にし、ユーザーがチケットを開いて修正を行うことでプロセスに参加していると感じられる強力な基盤を作成する必要があります。

Helm 3 に導入される主な改善点のいくつかを強調してみましたが、このリストは決してすべてを網羅したものではありません。 Helm 3 の完全なロードマップには、更新戦略の改善、OCI レジストリとのより深い統合、チャート値を検証するための JSON スキーマの使用などの機能が含まれています。また、コードベースをクリーンアップし、過去 XNUMX 年間放置されていた部分を更新する予定です。

何かを見逃していると思われる場合は、ぜひご意見をお聞かせください。

私たちのディスカッションに参加してくださいスラックチャンネル:

#helm-users 質問やコミュニティとの簡単なコミュニケーション用。
#helm-dev プルリクエスト、コード、バグについて議論します。

毎週木曜 19:30 MSK に開催される公開開発者通話でチャットすることもできます。ミーティングでは、主要な開発者とコミュニティが取り組んでいる問題や、その週の議論のトピックについて話し合うことに専念します。誰でも会議に参加して参加できます。 Slack チャネルで利用可能なリンク #helm-dev.

翻訳者からの追伸

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

出所： habr.com

Helm 3 の紹介