高度なHelmテクニック

このセクションでは、Helmを使用するためのさまざまな高度な機能とテクニックについて説明します。このセクションの情報は、チャートとリリースの高度なカスタマイズと操作を希望するHelmの「パワーユーザー」を対象としています。これらの高度な機能にはそれぞれトレードオフと注意点があるため、それぞれを慎重に、Helmに関する深い知識を持って使用する必要があります。言い換えれば、ピーター・パーカーの原則を忘れないでください。

ポストレンダリング

ポストレンダリングにより、チャートインストーラーは、Helmによってインストールされる前に、レンダリングされたマニフェストを手動で操作、構成、または検証できます。これにより、高度な構成ニーズを持つユーザーは、kustomizeなどのツールを使用して、パブリックチャートをフォークしたり、チャートメンテナーにソフトウェアのすべての最後の構成オプションを指定したりすることなく、構成変更を適用できます。また、エンタープライズ環境での一般的なツールやサイドカーの挿入、またはデプロイ前のマニフェストの分析にもユースケースがあります。

前提条件

Helm 3.1以上

使い方

ポストレンダラーは、STDINでレンダリングされたKubernetesマニフェストを受け入れ、STDOUTで有効なKubernetesマニフェストを返す実行可能ファイルです。エラーが発生した場合は、0以外の終了コードを返す必要があります。これが2つのコンポーネント間の唯一の「API」です。これにより、ポストレンダリングプロセスで何ができるかについて、大きな柔軟性が得られます。

ポストレンダラーは、install、upgrade、およびtemplateで使用できます。ポストレンダラーを使用するには、使用するレンダラーの実行可能ファイルへのパスを指定して--post-rendererフラグを使用します。

$ helm install mychart stable/wordpress --post-renderer ./path/to/executable

パスにセパレーターが含まれていない場合は、$PATHで検索されます。それ以外の場合は、相対パスを完全修飾パスに解決します。

複数のポストレンダラーを使用する場合は、スクリプト内または構築したバイナリツールでまとめてすべてを呼び出します。bashでは、これはrenderer1 | renderer2 | renderer3のように簡単です。

ポストレンダラーとしてkustomizeを使用する例はこちらで確認できます。

注意点

ポストレンダラーを使用する場合、留意すべき重要な点がいくつかあります。最も重要なのは、ポストレンダラーを使用する場合、そのリリースを変更するすべての人が、再現可能なビルドを実現するために同じレンダラーを使用する必要があるということです。この機能は、どのレンダラーを使用するかをユーザーが切り替えたり、レンダラーの使用を停止したりできるように意図的に構築されていますが、これは偶発的な変更やデータ損失を避けるために、慎重に行う必要があります。

もう1つの重要な注意点は、セキュリティに関するものです。ポストレンダラーを使用する場合は、信頼できるソースからのものであることを確認する必要があります（他の任意の実行可能ファイルの場合と同様）。信頼できない、または検証されていないレンダラーを使用することは、レンダリングされたテンプレートに完全にアクセスできるため（多くの場合、秘密データが含まれています）、推奨されません。

カスタムポストレンダラー

ポストレンダリングステップは、Go SDKで使用した場合、さらに柔軟性を提供します。ポストレンダラーは、次のGoインターフェースを実装するだけで済みます。

type PostRenderer interface {
    // Run expects a single buffer filled with Helm rendered manifests. It
    // expects the modified results to be returned on a separate buffer or an
    // error if there was an issue or failure while running the post render step
    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
}

Go SDKの使用に関する詳細については、Go SDKセクションを参照してください。

Go SDK

Helm 3では、Helmを活用したソフトウェアとツールの構築時のエクスペリエンスを向上させるために、完全に再構築されたGo SDKがデビューしました。完全なドキュメントはhttps://pkg.go.dev/helm.sh/helm/v3にありますが、最も一般的なパッケージの簡単な概要と簡単な例を以下に示します。

パッケージの概要

これは、最もよく使用されるパッケージのリストと、それぞれに関する簡単な説明です。

pkg/action：Helmアクションを実行するためのメインの「クライアント」が含まれています。これは、CLIが内部で使用しているのと同じパッケージです。別のGoプログラムから基本的なHelmコマンドを実行する必要がある場合は、このパッケージを使用してください。
pkg/{chart,chartutil}：チャートのロードと操作に使用されるメソッドとヘルパー。
pkg/cliとそのサブパッケージ：標準のHelm環境変数と、そのサブパッケージには出力と値ファイルの処理が含まれます。
pkg/release：Releaseオブジェクトとステータスを定義します。

明らかに、これら以外にも多くのパッケージがあるので、詳細についてはドキュメントを確認してください！

簡単な例

これは、Go SDKを使用してhelm listを実行する簡単な例です。

package main

import (
    "log"
    "os"

    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/cli"
)

func main() {
    settings := cli.New()

    actionConfig := new(action.Configuration)
    // You can pass an empty string instead of settings.Namespace() to list
    // all namespaces
    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    client := action.NewList(actionConfig)
    // Only list deployed
    client.Deployed = true
    results, err := client.Run()
    if err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    for _, rel := range results {
        log.Printf("%+v", rel)
    }
}

ストレージバックエンド

Helm 3では、デフォルトのリリース情報ストレージが、リリースの名前空間内のSecretsに変更されました。Helm 2では、デフォルトでリリース情報がTillerインスタンスの名前空間内のConfigMapsとして保存されます。以下のサブセクションでは、さまざまなバックエンドを構成する方法を示します。この構成は、HELM_DRIVER環境変数に基づいています。値[configmap, secret, sql]のいずれかに設定できます。

ConfigMapストレージバックエンド

ConfigMapバックエンドを有効にするには、環境変数HELM_DRIVERをconfigmapに設定する必要があります。

シェルで次のように設定できます。

export HELM_DRIVER=configmap

デフォルトのバックエンドからConfigMapバックエンドに切り替える場合は、これに関する移行を独自に行う必要があります。次のコマンドでリリース情報を取得できます。

kubectl get secret --all-namespaces -l "owner=helm"

本番環境のメモ：リリース情報には、チャートと値ファイルの内容が含まれているため、不正アクセスから保護する必要がある機密データ（パスワード、秘密鍵、その他の認証情報など）が含まれている可能性があります。RBACなどを使用してKubernetes認証を管理する場合、Secretリソースへのアクセスを制限しながら、ConfigMapリソースへのより広範なアクセスを許可することが可能です。たとえば、デフォルトのユーザー向けロール「view」は、ほとんどのリソースへのアクセスを許可しますが、Secretsにはアクセスできません。さらに、シークレットデータは、暗号化されたストレージ用に構成できます。ConfigMapバックエンドに切り替える場合は、アプリケーションの機密データが公開される可能性があるため、その点を考慮してください。

SQLストレージバックエンド

リリース情報をSQLデータベースに保存するベータ版のSQLストレージバックエンドがあります。

このようなストレージバックエンドの使用は、リリース情報が1MBを超える場合に特に役立ちます（その場合、Kubernetesの基盤となるetcdキーバリューストアの内部制限のため、ConfigMap/Secretsに保存できません）。

SQLバックエンドを有効にするには、SQLデータベースをデプロイし、環境変数HELM_DRIVERをsqlに設定する必要があります。DBの詳細は、環境変数HELM_DRIVER_SQL_CONNECTION_STRINGで設定します。

シェルで次のように設定できます。

export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme

注：現時点ではPostgreSQLのみがサポートされています。

本番環境に関する注意：以下のことを推奨します。

データベースを本番環境に対応させる。PostgreSQLについては、詳細についてサーバー管理ドキュメントを参照してください。
リリース情報のKubernetes RBACを反映させるために、権限管理を有効にする。

デフォルトのバックエンドからSQLバックエンドに切り替えたい場合は、移行を自分で行う必要があります。リリース情報は次のコマンドで取得できます。

kubectl get secret --all-namespaces -l "owner=helm"