でKubernetesのコミュニティ、まだ人気が知らない誰かを見つけるには驚きだろうヘルムのサービスを展開するためのツールを。MacOS用のHomebrewやWindows用のChocolateyなどのツールと同様に、を使用してKubernetesにソリューションを簡単にインストールできますhelm install <package-name>。

ヘルムチャートの使用

ヘルムチャートは、 Chef、 Consul-Template、 Ansible、 Puppet、 Salt Stackなどの変更構成ツールと共通する点が1つあり、 ERBやJinjaなどのテンプレートエンジンを使用して構成ファイルを動的に作成できます。ヘルム、設定ファイルがあるKubernetesの動的に使用して構築されているマニフェスト、ゴーテンプレートとテンプレートエンジンを小枝のライブラリおよびデプロイ時に渡す値を使用してカスタマイズ。

例として、次のような一般的なグラフでエンドポイントとストレージを有効にできます。

# add the remote repo
helm repo add foobar http://example.com/charts
# deploy the chart with set values
helm install stage foobar/foobar \
  --set service.type=LoadBalancer \ 
  --set persistence.enabled=true

# create my-values.yaml
cat <<-EOF > my-values.yaml
service:
  type: LoadBalancer
persistence:
  enabled: true
EOF
# add the remote repo
helm repo add foobar https://example.com/charts
# deploy the chart with external values file
helm install stage foobar/foobar --values my-values.yaml

ヘルムのチャートパッケージは、上の単一のサービスをインストールするのに便利ですKubernetes。問題は次のとおりです。すべてのグラフと調整する必要がある値を持つ複数のグラフをインストールする必要がある場合はどうなりますか？

これはhelmfileのようなツールが役立つところです。単一の構成スクリプト（helmfile.yaml）を使用して、複数のグラフをインストールし、すべてのグラフに一連の値を指定できます。

上記の例を使用するhelmfileと、ヘルムチャートの値をに埋め込んで、次のように同じものを作成できますhelmfile.yaml。

# create helmfile.yaml
cat <<-EOF > helmfile.yaml
repositories:
  - name: foobar
    url: https://example.com/charts
releases:
  - name: stage
    chart: foobar/foobar
    values:
      - service:
          type: LoadBalancer
        persistence:
          enabled: true
EOF
# add the remote repo + deploy the chart with embedded values
helmfile apply

# create my-values.yaml
cat <<-EOF > my-values.yaml
service:
  type: LoadBalancer
persistence:
  enabled: true
EOF
# create helmfile.yaml
cat <<-EOF > helmfile.yaml
repositories:
  - name: foobar
    url: https://example.com/charts
releases:
  - name: stage
    chart: foobar/foobar
    values:
      - my-values.yaml
EOF
# add the remote repo + deploy the chart with external values file
helmfile apply

これは、Dgraphとhelmfile呼ばれる高性能の分散グラフデータベースとMinIOを使用したオブジェクトストレージ（バケット）ソリューションの2つのソリューションを統合するために使用する完全な例です。

Helmfileスクリプト

以下は、MinIOおよびDgraphヘルムチャートの例helmfile.yamlです。この構成を使用する場合、helmfileはHelmチャートリポジトリを追加し、ディレクトリにある値ファイルを使用してこれら2つのHelmチャートを適用します。./values

MinIOチャート値

以下はMinIOの 参照は、最近の画像という設定MinIO や物資が鍵と秘密鍵、などと呼ばれるデフォルトのバケットにアクセスしますdgraph。このdgraphバケットは、mc展開中に実行されるバッチジョブからコマンドラインツールを使用して作成されます。

Dgraphチャート値

以下は、MinIOサーバーに送信されるバックアップを構成するDgraph構成です。Dgraphヘルムチャートが設定されますKubernetes cronジョブスクリプト実行します†指示するDgraphをこのリモートにバックアップを行うためにMinIOのサーバーを。

†バックアップをサポートするスクリプトは、これらの機能が有効になっている場合、Access JWTトークン（ACLを参照）および相互TLS（TLSを参照）を適切にサポートするRESTfulまたはGraphQLリクエストをDgraphに発行します。このスクリプトは、と連携Dgraphの使用、v21.03.0およびそれ以前のバージョンGraphQLをでサポートされている場合Dgraphのバージョン。

この構成の適用

始める前に、上記のコードスニペットをダウンロードすることに加えて、helmfile構成に値を挿入するために使用できるいくつかの環境変数を設定する必要があります。

まず、上記のコードスニペットをダウンロードして、次のようなディレクトリ構造を作成します。

.
├── helmfile.yaml
└── values
    ├── dgraph.yaml.gotmpl
    └── minio.yaml.gotmpl

# required
export MINIO_ACCESS_KEY=backups
export MINIO_SECRET_KEY=password123
# optional (set values that make sense in your environment)
export MINIO_NAMESPACE=test  # default is 'minio'
export DGRAPH_NAMESPACE=test # default is 'dgraph'

helmfile apply

結果のテスト

MinIOは、あなたが使用して表示することができますグラフィカルなインターフェイス、持っているポートフォワードを：

export MINIO_POD_NAME=$(kubectl get pods \
  --namespace $MINIO_NAMESPACE \
  --selector "release=minio" \
  --output jsonpath="{.items[0].metadata.name}"
)
kubectl port-forward $MINIO_POD_NAME 9000:9000

ログインすると、バケットが1つ表示されますdgraph。

構成内の完全バックアップに設定された時間である約15分後（values/dgraph.yaml.gotmpl)、Dgraphによって作成されたコンテンツが表示されます：

バックアップでエラーが発生した場合は、次の方法でステータスを確認できます。

JOBS=( $(kubectl get jobs \
  --namespace $DGRAPH_NAMESPACE \
  --no-headers \
  --output custom-columns=":metadata.name"
) )
for JOB in "${JOBS[@]}"; do
   JOB_POD=$(kubectl get pods \
     --namespace $DGRAPH_NAMESPACE \
     --selector job-name=$JOB \
     --no-headers \
     --output custom-columns=":metadata.name"
   )
printf "\nLogs for job=$JOB\n------------------------\n"
kubectl logs --namespace $DGRAPH_NAMESPACE $JOB_POD
done

ただし、Dgraph v21.03.0では、バックアップが非同期（バックグラウンドでの非ブロッキング実行）になっているため、ログを調べて、タイムスタンプに基づいて、トリガーされたバックアップ要求に接続されているログエントリを推測する必要があります。

例えば：

kubectl logs $DGRAPH_NAMESPACE-dgraph-alpha-0 | \
  grep -E 'backup_(ee|processor).go'

Dgraph v21.03.0より前では、kube -state-metricsなどを使用してアラートを設定し、バックアップcronジョブラベルに関連するKubernetesCronjobの失敗をスキャンできました。Prometheus AlertManagerを使用した例として、次の例を示します：dgraph-backup-alert-rules.yaml。

Dgraphのv21.03.0、バックアップイベントからエラーを検出し、報告するように設定、ログヒューリスティックが必要になります。

資力

この記事のトピックで私が遭遇したいくつかのリンクは次のとおりです。

兜

• ヘルムチャートとは何ですか？ https://www.freecodecamp.org/news/what-is-a-helm-chart-tutorial-for-kubernetes-beginners/
• ホームページ：https://helm.sh/
• ヘルムチャートリポジトリ：https://artifacthub.io/
• 最初のヘルムチャートを作成します。https://docs.bitnami.com/tutorials/create-your-first-helm-chart/
• ヘルムチャートの構造：https://helm.sh/docs/topics/charts/

• Helmfileとは何ですか？ https://tanzu.vmware.com/developer/guides/kubernetes/helmfile-what-is/
• ソースコード：https://github.com/roboll/helmfile
• Helmfileの例： https://github.com/cloudposse/helmfiles

gotemplate yamlファイルの色構文の強調表示：

• コード拡張子（gotemplate-syntax）：https://marketplace.visualstudio.com/items?itemName=casualjim.gotemplate
• vscode-gotemplateソース：https://github.com/casualjim/vscode-gotemplate

• ミニオヘルムチャート：https://artifacthub.io/packages/helm/minio/minio
• Dgraphヘルムチャート：https://artifacthub.io/packages/helm/dgraph/dgraph

• Helmfileの例：https://github.com/darkn3rd/blog_tutorials/tree/master/kubernetes/helmfile_1

ご覧のとおり、helmfileと組み合わせるとHelmチャートは非常に強力です。これらを一緒に使用すると、組織インフラストラクチャ全体を数分以内にKubernetesにデプロイできます。

この記事は、Helmとhelmfileに代わるものがあることに言及せずに完成することはできません…

代替手段としてKustomize

Helmチャートと同じ役割を果たすもう1つのツールは、kustomizeです。これは、Kubernetesクライアントツール（kubectl）に組み込まれているか、kustomizeコマンドとして外部から利用できます。これはテンプレートや変数を使用しませんが、デプロイ中にKubernetesマニフェストにパッチを適用するために使用されるマニフェストとkustomizeファイルのディレクトリを使用します。

個人的には、複雑なソリューションのパッチファイルのディレクトリを管理するのは難しいと思います。実際には、エラーは非常に一般的であり、解決策は非常に速く手に負えなくなり、管理できなくなります。それでも、Kubernetes演算子が使用されていて、演算子の周囲に作成するHelmチャートがない場合は、kustomizeが唯一の解決策になる可能性があります。

長所

• 標準化されたツーリング：kustomizeのツールが中に埋め込まれているkubectlコマンドので、さらなるツールが必要とされません。
• Helmは使用できません：Kubernetes オペレーターなどの一部のソリューションには、マニフェストを動的に作成するために必要なHelm チャートがない場合があるため、kustomize が使用可能な代替手段です

• 複雑さ：パッチファイルのディレクトリの管理は、トラブルシューティングとデバッグが難しい場合があります。
• メンテナンス：パッチのディレクトリを管理すると、すぐに手に負えなくなり、管理できなくなる可能性があります。また、小さなファイルが多数あると、エラーが発生しやすくなります。

• helmify-kustomizeチャートを展開するときのように外部スクリプトを実行します。このスクリプトでは、kustomizeを使用してHelmチャートを動的に作成できます。（このソリューションを提供してくれたKuoka Yusukeに感謝します）
• サポートkustomizeの構文を直接内部helmfile。これにはhelmプラグインが必要な場合があり、現在、goコードの形式を除いて文書化されていません。（これを実現させてくれた久岡裕介に感謝します）

代替手段としてのTerraform

もう1つの解決策は、HCL言語を使用する組み込みテンプレートエンジンと組み合わせて、Terrafomを使用してKubernetesプロバイダーとHelmプロバイダーを介してKubernetesリソース を管理することです。

このソリューションを使用すると、クラウドリソースをプロビジョニングし、作成されたこれらのリソース（uidなど）の結果に基づいて、クラウドリソースに基づく値を使用してHelmチャートをデプロイできます。例：GKEクラスターとGCSバケットを作成し、同じGKEクラスター上のGCSバケットを参照する値を使用してグラフを展開します。Kubernetesのアクセスに必要な資格情報がプロビジョニングさから来るGKEのクラスタ。

長所：

• 統合（標準化されたツール）：同じツールを使用して、Kubernetesインストール自体（AKS、GKE、EKS）とKubernetesリソースを含むクラウドリソース（Azure、GCP、AWS）を管理します。

• 統合（分離プロビジョニング）：Terrafomがプロバイダーブロックと実際のリソースを評価する方法が原因で、異なるプロバイダーによって管理されるリソース間の統合は完全にシームレスではありません（プロバイダー構成を参照）。基本的に、リソースは、Kubernetesプロバイダーリソースも利用される同じTerrafom モジュールで作成しないでください。
• 複雑（異なるツール）：あなたが同じツール共有することがありますがTerrafomの言語（HCLクラウドおよび用）Kubernetesリソースを、Terrafomは純粋なほど人気がないkubectlとhelm社会のほとんどの地域で使用されるツール、およびによって使用されるテラフォームのテンプレートエンジンtemplatefileはありません少なくともgotemplateと比較して人気があります。
• 複雑さ（信頼できる情報源）：信頼できる情報源は、Kubernetes APIによって報告されるライブのKubernetesリソース自体ではなく、実際のオンライン状態と同期する必要があるオフライン状態ファイルです。これは、実際にはKubernetesプロバイダーリソースよりもクラウドリソースにとって面倒であるため、この問題は無視できる可能性があります。
• メンテナンス（依存関係地獄）：terraformコマンドラインツール、プロバイダー、モジュールのバージョンへの変更、およびモジュールの依存関係が破壊的な変更を引き起こす可能性がある依存関係の悪夢があり、インフラストラクチャを破棄して再作成する必要があります。
• 品質または機能の制限：クラウドリソースとのやり取りを可能にするTerrafomプロバイダーには、またはHelmがアクセスするKubernetesAPIには存在しないバグがあります。kubeconfigファイルの使用などの機能の場合、これはKubernetesプロバイダーの新しいバージョンではサポートされていません（または問題がありました）。jsonencodeのような一部の関数は、ブール値と整数を文字列に変換し、望ましくないJSON型を作成します。このような多くの落とし穴や痛烈な問題は、Hashicorpがインストールしたgitボットの自動化によって自動的に閉じられます。kubectl Hashicorpはこの問題に適切な注意を払っています。

ヘルムファイルプロバイダーのために久岡裕介に大声で叫ぶ

別の方法として構成を変更する

もう1つの解決策は、PuppetやChefなどの構成変更プラットフォームを実際に使用することです。これらはKubernetesマニフェストを動的に構成できるテンプレートエンジンを使用するか、KubernetesAPIと直接通信するモジュールやクックブックを備えている場合があります。

長所

• 標準化されたプラットフォーム：不変のインフラストラクチャを備えたKubernetesリソースと、可変のインフラストラクチャを備えた従来の構成管理の両方に同じツールを使用します。

• 不要（不変のイメージ）：変更可能なインフラストラクチャを管理するためのPuppetやChefなどの変更構成プラットフォームに関する機能の多くは、コンテナーイメージが不変であるため、構成状態が目的の状態に収束するために使用されません。
• 冗長（状態はすでに管理されています）：Kubernetesによってデプロイされたインフラストラクチャコンポーネントは、可変インフラストラクチャを管理するためのコンバージェンスループと同様に、組み込みの調整ループによって管理されるため、PuppetやChefなどの変更構成プラットフォームは冗長です。
• 複雑さ：PuppetやChefなどの変更構成プラットフォーム は複雑でドメイン固有（独自のDSLまたはインターフェースを持っている）であるため、特にコンバージェンスに関するほとんどの機能が使用されない場合は、これによりさらに不必要な複雑さが追加されます。
• 高価：上記の複雑さを考えると、リードタイム、テスト、およびメンテナンスの両方で、時間とリソースに追加のコストがかかります。さらに、これらのプラットフォームは、使用法によっては過剰なライセンスコストがかかる可能性があります。

Ansibleは、クラウドリソースのプロビジョニングに関して、 Terrafomといくつかの点で似ていますが、 Ansibleはオフライン状態ファイルを維持しませんが、 Kubernetesまたは他のクラウドWebAPIとの直接の対話からの信頼できる情報源を使用します。

まとめ

helmfileは、Helmチャートを管理するための最も柔軟で効率的なツールであり、Helmチャート自体は、実際に動的なKubernetesマニフェストを管理するための最も効果的な方法であることがわかりました。

あなたが使用したいかもしれないいくつかのニッチな状況があるかもしれませんkustomizeまたはTerrafomを。PuppetやChefのような構成の変更に関しては、信じられないほどの複雑さと費用（リードタイム、メンテナンス、ライセンス）が追加されるため、これは決してお勧めしません。ただそれをしないでください。