ヘルムセキュリティ

Kubernetes 用の最も人気のあるパッケージ マネージャーに関する物語の本質は、絵文字を使用して表すことができます。

• ボックスは Helm (最新の Emoji リリースに最も近いものです) です。
• ロック - セキュリティ;
• この小さな男が問題の解決策です。

実際には、すべてがもう少し複雑になり、ストーリーには次のような技術的な詳細が満載です。 Helm を安全にする方法.

• 知らなかったり忘れてしまった場合に備えて、Helm とは何なのかを簡単に説明します。 それはどのような問題を解決するのか、そしてそれはエコシステムのどこに位置するのか。
• Helm アーキテクチャを見てみましょう。 コンポーネントのアーキテクチャを理解せずに、セキュリティや、ツールやソリューションの安全性を高める方法についての会話は成立しません。
• Helm コンポーネントについて説明しましょう。
• 最も切実な疑問は将来、つまり Helm 3 の新しいバージョンです。 

この記事の内容はすべて Helm 2 に当てはまります。このバージョンは現在運用中であり、おそらく現在使用しているバージョンであり、セキュリティ リスクが含まれているバージョンです。

スピーカーについて: アレクサンダー・ハヨロフ（アレックス) は 10 年間にわたって開発され、コンテンツの改善に貢献しています モスクワ Python Conf++ そして委員会に参加しました ヘルムサミット。 現在、彼は Chainstack で開発リーダーとして働いています。これは、開発マネージャーと最終リリースの提供を担当する担当者のハイブリッドです。 つまり、製品の開発から運用まですべてが行われる戦場にあります。

Chainstack は、小規模で活発に成長している新興企業であり、その使命は、クライアントが分散アプリケーションの運用のインフラストラクチャと複雑さを忘れられるようにすることです。開発チームはシンガポールにあります。 Chainstack に暗号通貨の売買を依頼するのではなく、エンタープライズ ブロックチェーン フレームワークについて話したいと申し出れば、喜んで答えてくれるでしょう。

ヘルメット

これは、Kubernetes のパッケージ (チャート) マネージャーです。 アプリケーションを Kubernetes クラスターに移行するための最も直感的で汎用的な方法。

もちろん、ここで話しているのは、独自の YAML マニフェストを作成して小さなユーティリティを作成するよりも、より構造的で産業的なアプローチについてです。

Helm は現在入手可能で人気のある最高のものです。

なぜヘルムなのか？ 主な理由は、CNCF によってサポートされているためです。 Cloud Native は大規模な組織であり、Kubernetes、etcd、Fluentd などのプロジェクトの親会社です。

もう 2019 つの重要な事実は、Helm が非常に人気のあるプロジェクトであるということです。 12 年 XNUMX 月に Helm を安全にする方法について話し始めたとき、このプロジェクトには GitHub で XNUMX 個のスターがつきました。 XNUMX月までにその数はXNUMX万XNUMX千人になった。

Helm に興味がある人は多いので、まだ使用していない場合でも、そのセキュリティについて知っておくと役に立ちます。 安全性は重要です。

コア Helm チームは Microsoft Azure によってサポートされているため、他の多くのプロジェクトとは異なり、かなり安定したプロジェクトです。 3 月中旬の Helm 2 Alpha XNUMX のリリースは、非常に多くの人々がこのプロジェクトに取り組んでおり、Helm を開発および改善する意欲とエネルギーを持っていることを示しています。

Helm は、Kubernetes でのアプリケーション管理のいくつかの根本的な問題を解決します。

• アプリケーションのパッケージ化。 WordPress 上の「Hello, World」のようなアプリケーションでも、すでに複数のサービスで構成されており、それらをまとめてパッケージ化する必要があります。
• これらのアプリケーションの管理に伴う複雑さを管理します。
• アプリケーションのインストールまたはデプロイ後に終了しないライフサイクル。 それは存続し続けますが、更新する必要があります。Helm はこれを支援し、これに対する適切な対策とポリシーを導入しようとします。

袋詰め それは明確な方法で編成されています。Linux、Windows、または MacOS の通常のパッケージ マネージャーの動作に完全に準拠したメタデータがあります。 つまり、リポジトリ、さまざまなパッケージの依存関係、アプリケーションのメタ情報、設定、構成機能、情報のインデックス作成などです。Helm を使用すると、これらすべてを取得してアプリケーションで使用できます。

複雑さの管理。 同じタイプのアプリケーションが多数ある場合は、パラメータ化が必要です。 テンプレートはこれに由来しますが、テンプレートを作成する独自の方法を考え出す必要を避けるために、Helm が提供するものをすぐに使用できます。

アプリケーションのライフサイクル管理 -私の意見では、これは最も興味深い未解決の質問です。 これが私が昔ヘルムに来た理由です。 私たちはアプリケーションのライフサイクルを常に監視する必要があり、CI/CD とアプリケーションのサイクルをこのパラダイムに移行したいと考えていました。

Helm を使用すると、次のことが可能になります。

• 導入を管理し、構成とリビジョンの概念を導入します。
• ロールバックが正常に実行されます。
• さまざまなイベントにフックを使用します。
• 追加のアプリケーションチェックを追加し、その結果に応答します。

さらに ヘルムには「バッテリー」が付いています - プラグインの形で含めることができる膨大な数の便利なもので、あなたの生活を簡素化します。 プラグインは独立して作成でき、完全に分離されており、調和のとれたアーキテクチャを必要としません。 何かを実装したい場合は、それをプラグインとして実行し、場合によってはアップストリームに含めることをお勧めします。

Helm は XNUMX つの主要な概念に基づいています。

• チャートリポジトリ — マニフェストで使用できるパラメータ化の説明と配列。 
• 設定 —つまり、適用される値 (テキスト、数値など)。
• リリース 上部の XNUMX つのコンポーネントを収集し、それらを合わせて Release に変換します。 リリースはバージョン管理できるため、インストール時には小さく、アップグレード、ダウングレード、またはロールバック時には大きくなる、組織化されたライフ サイクルを実現できます。

ヘルムアーキテクチャ

この図は、Helm の高レベルのアーキテクチャを概念的に示しています。

Helm は Kubernetes に関連するものであることを思い出してください。 したがって、Kubernetes クラスター (四角形) なしではやっていけません。 kube-apiserver コンポーネントはマスター上に存在します。 Helm がなければ Kubeconfig があります。 Helm は、コンピューター、ラップトップ、メインフレームなど、あらゆるものにインストールされる XNUMX つの小さなバイナリ (Helm CLI ユーティリティ) を提供します。

しかし、これでは十分ではありません。 Helm には Tiller と呼ばれるサーバー コンポーネントがあります。 これはクラスター内での Helm の役割を表しており、他のクラスターと同様に、Kubernetes クラスター内のアプリケーションです。

Chart Repo の次のコンポーネントは、チャートを含むリポジトリです。 公式リポジトリもあれば、企業やプロジェクトのプライベートリポジトリもあるかもしれません。

相互作用

Helm を使用してアプリケーションをインストールする場合に、アーキテクチャ コンポーネントがどのように対話するかを見てみましょう。

• 私たちは話している Helm install, リポジトリ (Chart Repo) にアクセスし、Helm チャートを取得します。

• Helm ユーティリティ (Helm CLI) は Kubeconfig と対話して、どのクラスターに接続するかを判断します。 
• この情報を受け取ると、ユーティリティはクラスター内にある Tiller をアプリケーションとして参照します。 
• Tiller は Kube-apiserver を呼び出して、Kubernetes でアクションを実行し、いくつかのオブジェクト (サービス、ポッド、レプリカ、シークレットなど) を作成します。

次に、図を複雑にして、Helm アーキテクチャ全体が危険にさらされる可能性のある攻撃ベクトルを確認します。 そして、私たちは彼女を守ろうとします。

攻撃ベクトル

最初の潜在的な弱点は、 特権API - ユーザー。 計画の一環として、これは Helm CLI への管理者アクセス権を取得したハッカーです。

特権のない API ユーザー また、近くにあると危険が生じる可能性があります。 このようなユーザーは異なるコンテキストを持ちます。たとえば、Kubeconfig 設定で XNUMX つのクラスター名前空間に固定できます。

最も興味深い攻撃ベクトルは、Tiller 近くのクラスター内に常駐し、それにアクセスできるプロセスである可能性があります。 これは、クラスターのネットワーク環境を監視する Web サーバーまたはマイクロサービスです。

珍しいものの、ますます人気が高まっている攻撃の亜種には、Chart Repo が関係しています。 悪意のある作成者によって作成されたチャートには安全でないリソースが含まれている可能性がありますが、それを信じてチャートを完成させます。 または、公式リポジトリからダウンロードしたチャートを置き換えて、たとえばポリシーの形式でリソースを作成し、そのアクセスをエスカレーションすることもできます。

これら XNUMX つの側面すべてからの攻撃をかわして、Helm アーキテクチャのどこに問題があるのか​​、そしておそらくどこに問題がないのかを把握してみましょう。

図を拡大して要素を追加してみましょう。ただし、基本的なコンポーネントはすべてそのままにしておきます。

Helm CLI は Chart Repo と通信し、Kubeconfig と対話し、作業がクラスターの Tiller コンポーネントに転送されます。

Tiller は XNUMX つのオブジェクトで表されます。

• Tiller-deploy svc。特定のサービスを公開します。
• Tiller-deploy ポッド (図では XNUMX つのレプリカ内の単一コピー)。ロード全体が実行され、クラスターにアクセスします。

対話にはさまざまなプロトコルとスキームが使用されます。 セキュリティの観点から、私たちは次のことに最も関心を持っています。

• Helm CLI がチャート リポジトリにアクセスするメカニズム: どのようなプロトコル、認証があるか、そしてそれを使用して何ができるか。
• Helm CLI が kubectl を使用して Tiller と通信する際に使用するプロトコル。 これはクラスター内にインストールされる RPC サーバーです。
• Tiller 自体は、クラスター内に存在し、Kube-apiserver と対話するマイクロサービスにアクセスできます。

これらすべての領域について順番に説明していきます。

RBAC

RBAC が有効になっていない限り、Helm またはクラスター内のその他のサービスのセキュリティについて話しても意味がありません。

これは最新の推奨事項ではないようですが、多くの人が運用環境であってもまだ RBAC を有効にしていないと思います。これは、非常に手間がかかり、多くの設定が必要なためです。 ただし、これを行うことをお勧めします。

https://rbac.dev/ — RBAC のウェブサイト弁護士。 これには、RBAC のセットアップに役立ち、RBAC が優れている理由と、基本的に運用環境で RBAC を使用する方法を示す、大量の興味深い資料が含まれています。

Tiller と RBAC がどのように機能するかを説明してみます。 Tiller は、特定のサービス アカウントの下でクラスター内で動作します。 通常、RBAC が構成されていない場合、これはスーパーユーザーになります。 基本構成では、Tiller が管理者になります。 これが、Tiller がクラスターへの SSH トンネルであると言われる理由です。 実際、これは真実であるため、上の図の既定のサービス アカウントの代わりに別の専用サービス アカウントを使用できます。

Helm を初期化し、サーバーに初めてインストールするときは、次を使用してサービス アカウントを設定できます。 --service-account。 これにより、必要な最小限の権限セットを持つユーザーを使用できるようになります。 確かに、そのような「ガーランド」、つまりRoleとRoleBindingを作成する必要があります。

残念ながら、Helm はこれを行ってくれません。 Helm を渡すために、あなたまたは Kubernetes クラスター管理者は、サービス アカウントのロールとロールバインディングのセットを事前に準備する必要があります。

疑問が生じます。Role と ClusterRole の違いは何ですか? 違いは、特殊な名前空間でのみ機能する通常のロールやロールバインディングとは異なり、ClusterRole はすべての名前空間で機能することです。 クラスター全体とすべての名前空間に対してポリシーを構成することも、各名前空間に対して個別にカスタマイズすることもできます。

RBAC が別の大きな問題を解決することは言及する価値があります。 残念ながら、Helm はマルチテナントではない (マルチテナントをサポートしていない) と多くの人が不満を抱いています。 複数のチームがクラスターを使用して Helm を使用する場合、このクラスター内でポリシーを設定してアクセスを制限することは基本的に不可能です。これは、Helm が実行される特定のサービス アカウントがあり、その下からクラスター内のすべてのリソースが作成されるためです。 、それは時々非常に不便です。 これは真実です - バイナリ ファイル自体やプロセスと同様に、 Helm Tiller にはマルチテナンシーの概念がありません.

ただし、クラスター内で Tiller を複数回実行できる優れた方法があります。 これに問題はなく、Tiller はすべての名前空間で起動できます。 したがって、RBAC、Kubeconfig をコンテキストとして使用し、特別な Helm へのアクセスを制限できます。

このようになります。

たとえば、異なるチーム (XNUMX つの名前空間) のコンテキストを持つ XNUMX つの Kubeconfig があります: 開発チーム用の X チームと管理クラスター用です。 管理クラスタには独自のワイド Tiller があり、これは Kube-system 名前空間にあり、対応する高度なサービス アカウントです。 また、開発チーム用の別の名前空間により、サービスを特別な名前空間にデプロイできるようになります。

これは実行可能なアプローチです。Tiller は予算に大きな影響を与えるほど電力を消費しません。 これは簡単な解決策の XNUMX つです。

自由に Tiller を個別に構成し、チーム、特定の開発者、または環境 (開発、ステージング、運用) のコンテキストを Kubeconfig に提供できます (すべてが同じクラスター上に存在するかどうかは疑わしいですが、これは可能です)。

話を続けて、RBAC から話題を変えて、ConfigMap について話しましょう。

ConfigMap

Helm はデータ ストアとして ConfigMap を使用します。 アーキテクチャについて話したとき、リリース、構成、ロールバックなどに関する情報を保存するデータベースはどこにもありませんでした。これには ConfigMaps が使用されます。

ConfigMap の主な問題は既知です。ConfigMap は原理的に安全ではありません。 機密データを保存することは不可能です。 ここでは、パスワードなど、サービスの範囲を超えてはいけないすべてのことについて話します。 現時点での Helm の最もネイティブな方法は、ConfigMap の使用からシークレットの使用に切り替えることです。

これは非常に簡単に行われます。 Tiller 設定をオーバーライドし、ストレージがシークレットになるように指定します。 その後、展開ごとに、ConfigMap ではなくシークレットを受け取ります。

シークレット自体は奇妙な概念であり、あまり安全ではないと主張する人もいるでしょう。 ただし、Kubernetes 開発者自身がこれを行っていることを理解する価値があります。 バージョン 1.10 以降、つまりかなり前から、少なくともパブリック クラウドでは、適切なストレージに接続してシークレットを保存することが可能でした。 チームは現在、シークレット、個々のポッド、またはその他のエンティティへのアクセスをより適切に分散する方法に取り組んでいます。

Storage Helm をシークレットに転送することをお勧めします。そうすれば、シークレットは一元的に保護されます。

もちろん残ります データストレージ制限は1MB。 ここでの Helm は、ConfigMap の分散ストレージとして etcd を使用します。 そこで彼らは、これがレプリケーションなどに適したデータチャンクであると考えました。 これについては Reddit で興味深い議論があります。週末にこの面白い読み物を見つけるか、抜粋を読むことをお勧めします。 ここで.

チャートリポジトリ

チャートは社会的に最も脆弱であり、特にストック ソリューションを使用する場合は「中間者」の発生源になる可能性があります。 まず最初に、HTTP 経由で公開されるリポジトリについて話します。

Helm Repo を HTTPS 経由で公開する必要があることは間違いありません。これが最良のオプションであり、安価です。

に注意を払う チャート署名メカニズム。 このテクノロジーは非常にシンプルです。 これは GitHub で使用するものと同じもので、公開キーと秘密キーを備えた通常の PGP マシンです。 必要なキーを用意し、すべてに署名して、これが実際にあなたのチャートであることを確認してください。

加えて、 Helm クライアントは TLS をサポートします (サーバー側の HTTP の意味ではなく、相互 TLS)。 通信するにはサーバーキーとクライアントキーを使用できます。 正直に言うと、私は相互証明書が好きではないので、そのような仕組みは使っていません。 基本的に、 チャートミュージアム - Helm 2 の Helm リポジトリをセットアップするためのメイン ツール - 基本認証もサポートしています。 より便利で静かな場合は、基本認証を使用できます。

プラグインもあります ヘルム-GCを使用すると、Google Cloud Storage で Chart Repos をホストできるようになります。 これは非常に便利で、うまく機能し、説明されているすべてのメカニズムがリサイクルされるため、非常に安全です。

HTTPS または TLS を有効にし、mTLS を使用し、基本認証を有効にしてリスクをさらに軽減すると、Helm CLI と Chart Repo を使用した安全な通信チャネルが得られます。

gRPC API

次のステップは非常に重要です。Tiller を保護することです。Tiller はクラスター内にあり、一方ではサーバーですが、他方では、それ自体が他のコンポーネントにアクセスし、誰かになりすまそうとします。

すでに述べたように、Tiller は gRPC を公開するサービスであり、Helm クライアントは gRPC 経由で Tiller にアクセスします。 もちろん、デフォルトでは TLS は無効になっています。 なぜこれが行われたのかは議論の余地がありますが、最初のセットアップを簡素化するためだと思われます。

本番環境やステージングの場合でも、gRPC で TLS を有効にすることをお勧めします。

私の意見では、チャートの mTLS とは異なり、これはここでは適切であり、PQI インフラストラクチャの生成、証明書の作成、Tiller の起動、初期化中の証明書の転送という非常に簡単に実行されます。 この後、生成された証明書と秘密キーを自分自身に提示して、すべての Helm コマンドを実行できます。

こうすることで、クラスターの外部から Tiller へのすべてのリクエストから身を守ることができます。

そのため、Tiller への接続チャネルを確保し、すでに RBAC について議論し、Kubernetes API サーバーの権限を調整して、対話できるドメインを削減しました。

保護されたヘルム

最終的な図を見てみましょう。 同じアーキテクチャで、同じ矢印が付いています。

すべての接続を安全に緑色で描画できるようになりました。

• Chart Repo の場合は、TLS または mTLS と基本認証を使用します。
• Tiller の mTLS は、TLS を使用して gRPC サービスとして公開され、証明書を使用します。
• クラスターは、R​​ole と RoleBinding を持つ特別なサービス アカウントを使用します。 

私たちはクラスターを大幅に保護しましたが、賢い人がこう言いました。

「絶対に安全な解決策は XNUMX つだけあります。それは、電源を切ったコンピューターであり、コンクリートの箱の中に置かれ、兵士によって守られているのです。」

データを操作して新しい攻撃ベクトルを見つけるには、さまざまな方法があります。 しかし、私はこれらの推奨事項が安全性に関する基本的な業界標準を達成すると確信しています。

ボーナス

この部分はセキュリティとは直接関係ありませんが、役立ちます。 あまり知られていない面白いことをいくつか紹介します。 たとえば、公式および非公式のチャートを検索する方法です。

リポジトリ内 github.com/helm/charts 現在、約 300 のチャートと XNUMX つのストリーム (stable と incubator) があります。 貢献した人なら誰でも、保育器から厩舎に行くのがいかに難しく、厩舎から飛び出すのがいかに簡単かをよく知っています。 ただし、これは、パッケージを便利に検索できるポータルではないという単純な理由から、Prometheus やその他の好きなもののチャートを検索するのに最適なツールではありません。

でもサービスはあるよ ハブ.ヘルム.shこれにより、チャートの検索がさらに便利になります。 最も重要なのは、さらに多くの外部リポジトリと約 800 のチャームが利用できることです。 さらに、何らかの理由でチャートを安定版に送信したくない場合は、リポジトリに接続できます。

Hub.helm.sh を試して、一緒に開発しましょう。 このサービスは Helm プロジェクトの下にあり、フロントエンド開発者で外観を改善したいだけであれば、その UI に貢献することもできます。

こちらにも注目していただきたいのですが、 オープンサービスブローカーAPIの統合。 面倒でわかりにくいように思えますが、誰もが直面する問題を解決します。 簡単な例で説明しましょう。

従来のアプリケーションである WordPress を実行したい Kubernetes クラスターがあります。 通常、すべての機能を利用するにはデータベースが必要です。 さまざまなソリューションがあり、たとえば、独自のステートフル サービスを起動できます。 これはあまり便利ではありませんが、多くの人がそうしています。

私たち Chainstack のように、MySQL や PostgreSQL などのマネージド データベースをサーバーに使用している企業もいます。 そのため、当社のデータベースはクラウド内のどこかに配置されています。

しかし、問題が発生します。サービスをデータベースに接続し、データベース フレーバーを作成し、資格情報を転送して、それを何らかの方法で管理する必要があります。 通常、これらはすべてシステム管理者または開発者によって手動で行われます。 申し込みが少ない場合でも問題ありません。 数が多い場合はコンバインが必要です。 そのようなハーベスターがあります - それはサービスブローカーです。 これにより、パブリック クラウド クラスター用の特別なプラグインを使用し、API であるかのように、ブローカーを通じてプロバイダーにリソースを注文できます。 これを行うには、ネイティブ Kubernetes ツールを使用できます。

とてもシンプルです。 たとえば、基本層を使用して Azure のマネージド MySQL にクエリを実行できます (これは構成可能です)。 Azure API を使用して、データベースが作成され、使用できるように準備されます。 これに干渉する必要はありません。プラグインがこれを担当します。 たとえば、OSBA (Azure プラグイン) は資格情報をサービスに返し、それを Helm に渡します。 クラウド MySQL で WordPress を使用できるようになり、管理されたデータベースをまったく扱わず、内部のステートフル サービスについて心配する必要がなくなります。

Helm は、一方ではサービスのデプロイを可能にし、他方ではクラウド プロバイダーのリソースを消費できるようにする接着剤として機能すると言えます。

独自のプラグインを作成して、このストーリー全体をオンプレミスで使用することができます。 そうすれば、企業クラウド プロバイダー用の独自のプラグインを作成するだけです。 特に規模が大きく、開発、ステージング、または機能のインフラストラクチャ全体を迅速にデプロイしたい場合は、このアプローチを試すことをお勧めします。 これにより、運用や DevOps が楽になります。

すでに述べたもう一つの発見は、 Helm-gcs プラグインこれにより、Google バケット (オブジェクト ストレージ) を使用して Helm チャートを保存できるようになります。

使用を開始するには XNUMX つのコマンドのみが必要です。

1. プラグインをインストールします。
2. それを開始します。
3. gcp にあるバケットへのパスを設定します。
4. 標準的な方法でチャートを公開します。

利点は、ネイティブ gcp メソッドが認証に使用されることです。 サービス アカウント、開発者アカウントなど、好きなものを使用できます。 非常に便利で、運用コストもかかりません。 私と同じように、opsless の哲学を推進する場合、特に小規模なチームにとって、これは非常に便利です。

代替案

Helm だけがサービス管理ソリューションではありません。 これについては多くの疑問があり、それがおそらく第 XNUMX バージョンがこれほど早く登場した理由でしょう。 もちろん代替手段はあります。

これらは、Ksonnet や Metaparticle などの特殊なソリューションにすることができます。 従来のインフラストラクチャ管理ツール (Ansible、Terraform、Chef など) を、私が説明したのと同じ目的に使用できます。

最後に解決策があります オペレーターフレームワーク、人気が高まっています。

Operator Framework は、Helm の代替として検討すべき最上位の選択肢です。

CNCF と Kubernetes によりネイティブであり、 しかし参入障壁ははるかに高い、より多くのプログラムを作成し、マニフェストの記述を少なくする必要があります。

Draft、Scaffoldなど、さまざまなアドオンがあります。 たとえば、開発者がテスト環境をデプロイするために Helm を送信して起動するサイクルが簡素化されるなど、作業が大幅に楽になります。 私は彼らをエンパワラーと呼びます。

これは、すべてがどこにあるかを示す視覚的なチャートです。

X 軸は何が起こっているかを個人的に制御できるレベル、Y 軸は Kubernetes のネイティブ性のレベルです。 Helm バージョン 2 はその中間に位置します。 バージョン 3 では、それほど大きくはありませんが、制御とネイティブ性のレベルの両方が向上しました。 Ksonnet レベルのソリューションは、依然として Helm 2 よりも劣っています。しかし、この世界に他に何があるのか​​を知るためには、検討する価値があります。 もちろん、構成マネージャーはユーザーの管理下にありますが、それは決して Kubernetes にネイティブなものではありません。

Operator Framework は完全に Kubernetes にネイティブであり、よりエレガントかつ綿密に管理できるようになります (ただし、エントリー レベルについては覚えておいてください)。 むしろ、これは、Helm を使用して膨大な数のアプリケーションをパッケージ化するためのマスハーベスターではなく、特殊なアプリケーションとその管理の作成に適しています。

エクステンダーは、単に制御を少し改善したり、ワークフローを補完したり、CI/CD パイプラインの手を抜いたりするだけです。

ヘルムの未来

良いニュースは、Helm 3 が登場するということです。Helm 3.0.0-alpha.2 のアルファ版がすでにリリースされているので、試してみることができます。 非常に安定していますが、機能はまだ制限されています。

Helm 3 が必要な理由は何ですか? まず、今回のお話は、 ティラーの失踪、コンポーネントとして。 すでにおわかりのとおり、アーキテクチャのセキュリティの観点からすべてが簡素化されるため、これは大きな前進です。

Helm 2 が作成されたとき、つまり Kubernetes 1.8 の頃、あるいはそれ以前のころ、多くの概念が未熟でした。 たとえば、CRD コンセプトは現在積極的に実装されており、Helm は CRDを使用する構造を保存します。 サーバー部分をメンテナンスせずにクライアントのみを使用することも可能になります。 したがって、ネイティブ Kubernetes コマンドを使用して構造とリソースを操作します。 これは大きな前進です。

表示されます ネイティブOCIリポジトリのサポート (オープンコンテナイニシアチブ)。 これは大きな取り組みであり、Helm は主にチャートを投稿することに興味を持っています。 たとえば、Docker Hub は多くの OCI 標準をサポートしているということになります。 推測ではありませんが、おそらく従来の Docker リポジトリ プロバイダーが Helm チャートをホストする機会を提供し始めるでしょう。

私にとって物議を醸す話は、 Luaのサポート、スクリプトを作成するためのテンプレート エンジンとして。 私は Lua の大ファンではありませんが、これは完全にオプションの機能です。 これを 3 回確認しました。Lua を使用する必要はありません。 したがって、Lua を使えるようになりたい人、Go が好きな人は、私たちの巨大なキャンプに参加し、そのために go-tmpl を使用してください。

最後に、私に決定的に欠けていたのは、 スキーマの出現とデータ型の検証。 int または string に関する問題はなくなり、ゼロを二重引用符で囲む必要もなくなります。 これを値として明示的に記述できる JSONS スキーマが表示されます。

大幅に手直しされる予定 イベント駆動型モデル。 それはすでに概念的に説明されています。 Helm 3 ブランチを見ると、イベントやフック、その他のものがどれだけ追加されているかがわかります。これにより、デプロイメント プロセスとその反応が大幅に簡素化され、一方で制御が追加されます。

Helm 3 は、よりシンプルで、より安全で、より楽しいものになります。これは、Helm 2 が気に入らないからではなく、Kubernetes がより高度になっているためです。 したがって、Helm は Kubernetes の開発を使用し、その上に Kubernetes の優れたマネージャーを作成できます。

もう一つの良いニュースは、 DevOpsConf アレクサンダー・ハヨロフはこう言います。 コンテナは安全に保てますか? 開発、テスト、運用プロセスの統合に関する会議がモスクワで開催されることをお知らせします。 30月1日とXNUMX月XNUMX日。 20月XNUMX日までならまだできるよ レポートを送信 ソリューションに関するあなたの経験について教えてください たくさんのうちの一つ DevOps アプローチのタスク。

カンファレンスのチェックポイントとニュースをフォローしてください。 メーリングリスト и 電報チャンネル.

出所： habr.com