Helm は自作がおすすめ – Chart を自分で管理する意味

Helm は公開されている Chart を使うだけでも便利ですが、ある程度 Kubernetes を運用するなら、自分の環境向けに Chart を自作する方が扱いやすくなる場面があります。

理由は、公開 Chart が悪いからではありません。公開 Chart は多くの環境に対応するために抽象度が高く、values が複雑になりやすいからです。自分の環境で必要な構成が明確なら、最初から自作 Chart として管理した方が、構成の責任範囲を把握しやすくなります。

参考
書籍

参考書籍

Kubernetes 完全ガイド第 2 版

Kubernetes の基本リソース、Helm、Chart、運用設計を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

公開 Chart が難しく見える理由

公開 Chart は、不特定多数の利用者に対応するために多くの分岐を持ちます。Ingress を使うか、Service をどうするか、永続ボリュームをどうするか、既存 Secret を使うか、監視を有効にするか、PodSecurityContext をどうするかなど、対応すべき状態が多いからです。

対応する Kubernetes バージョンが広い
クラウド環境とオンプレミス環境の両方を意識する
Ingress、Service、StorageClass、Secret、ConfigMap の分岐が多い
ユーザーごとの運用方針を values で吸収しようとする
結果として values と template が長くなり、読む側の負担が増える

これは公開 Chart の宿命に近いものです。汎用性を持たせるほど、Chart の内部は複雑になります。

Helm は Linux パッケージ管理とは少し違う

Helm は Kubernetes のパッケージ管理ツールと説明されることがあります。感覚としては近い部分もありますが、APT や DNF と同じものとして見ると少し誤解します。

Linux パッケージは、まずパッケージを入れてから設定ファイルを調整し、サービスを起動して確認する流れが取りやすいです。一方、Helm は Kubernetes リソース一式をまとめて生成し、Service、Secret、ConfigMap、Deployment、Ingress、PVC などが連携して初めて意味を持ちます。

つまり Helm は、単体のソフトウェアをインストールするというより、Kubernetes 上の構成をまとめて展開する仕組みです。この違いが、Helm を難しく見せる大きな理由だと思います。

自作 Chart が向いている場面

自作 Chart が向いているのは、自分の環境の構成方針がある程度決まっている場合です。たとえば、namespace、label、Service、Ingress、StorageClass、Secret の扱いを自分の基準で統一したい場合、自作 Chart はかなり扱いやすくなります。

自宅環境や社内環境など、前提が固定されている
values の項目を必要最小限にしたい
label や annotation のルールを統一したい
Secret や ConfigMap の作り方を自分の運用に合わせたい
Harbor など内部レジストリと組み合わせたい
将来的に Ansible や GitOps と連携させたい

Chart は構成の部品化として見る

自作 Chart の価値は、単に helm install で楽をすることではありません。Kubernetes のマニフェスト群を、自分の環境に合わせた部品として整理できることにあります。

毎回 Deployment、Service、ConfigMap を手で書くのではなく、共通部分を template に寄せ、環境差分を values に寄せます。これにより、アプリケーションごとの違いと、環境として統一したい部分を分けやすくなります。

最小構成の例

mkdir -p myapp-chart/templates

cat > myapp-chart/Chart.yaml <<'EOF'
apiVersion: v2
name: myapp
description: A small internal application chart
type: application
version: 0.1.0
appVersion: "1.0.0"
EOF

cat > myapp-chart/values.yaml <<'EOF'
image:
  repository: nginx
  tag: latest

service:
  type: ClusterIP
  port: 80
EOF

実際には Deployment や Service の template も必要ですが、最初から複雑な Chart を作る必要はありません。まずは小さな Chart を作り、必要な要素だけを増やしていく方が理解しやすいです。

公開 Chart を読まないという意味ではない

自作 Chart をすすめるといっても、公開 Chart を読まなくてよいという意味ではありません。むしろ、よく作られた Chart には学ぶ点が多くあります。

values の切り方
template helper の使い方
label / selector の付け方
Secret と ConfigMap の分け方
upgrade を考慮したリソース設計

ただし、公開 Chart をそのまま採用する場合は、その Chart の設計思想ごと受け入れることになります。自分の環境に合わない部分が多いなら、参考にしつつ自作した方が結果的に運用しやすい場合があります。

自作 Chart の注意点

自作 Chart にも当然デメリットはあります。自分で作るということは、Chart の保守責任も自分で持つということです。Kubernetes API の変更、アプリケーションの更新、Secret の扱い、upgrade 時の互換性などを考える必要があります。

Kubernetes API の deprecated に追従する必要がある
Chart のバージョン管理が必要になる
values の互換性を考える必要がある
Secret や認証情報を Chart に含めない設計が必要になる
本番適用前に helm template や差分確認を行う必要がある

それでも、前提が固定された環境では、自作 Chart の方が読みやすく、変更の影響範囲も追いやすくなります。

Harbor で Chart を管理する意味

自作 Chart を増やす場合、Chart の置き場所も重要になります。Git で管理するだけでも十分な場面はありますが、内部基盤として扱うなら Harbor などで Chart を管理する構成も考えられます。

Harbor に Chart やコンテナイメージを集約すると、Kubernetes クラスタから参照する成果物を内部で管理しやすくなります。インターネット非接続環境や、自宅基盤で構成を閉じたい場合には相性が良いです。

まとめ

Helm は公開 Chart を使うだけでも便利ですが、自分の環境を長く運用するなら、自作 Chart を持つ価値はかなりあります。

公開 Chart は汎用性のために複雑になりがちです。一方、自作 Chart は前提を絞れるため、values を小さくし、template を読みやすくし、自分の運用に合った構成として管理できます。

Helm を使いこなすとは、単に誰かが作った Chart を入れることではなく、自分の Kubernetes 環境の構成をどの単位で部品化し、どう管理するかを決めることだと思います。

Helm は自作がおすすめ – Chart を自分で管理する意味

公開 Chart が難しく見える理由

Helm は Linux パッケージ管理とは少し違う

自作 Chart が向いている場面

Chart は構成の部品化として見る

最小構成の例

公開 Chart を読まないという意味ではない

自作 Chart の注意点

Harbor で Chart を管理する意味

関連する記事

まとめ

コメントを残すコメントをキャンセル

Helm は自作がおすすめ – Chart を自分で管理する意味

公開 Chart が難しく見える理由

Helm は Linux パッケージ管理とは少し違う

自作 Chart が向いている場面

Chart は構成の部品化として見る

最小構成の例

公開 Chart を読まないという意味ではない

自作 Chart の注意点

Harbor で Chart を管理する意味

関連する記事

まとめ

Related posts:

コメントを残す コメントをキャンセル

コメントを残すコメントをキャンセル