Kubernetes Helm Chart を自作する意味 – 借り物の Chart と運用責任を分けて考える

Helm は公開 Chart を使うだけでも便利ですが、ある程度 Kubernetes を運用するなら、Chart を自分の環境向けに管理する意味が出てきます。問題は自作か公開 Chart かという二択ではなく、その Chart の前提、差分、責任を自分で説明できるかどうかです。

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

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

公開 Chart は多くの環境で動くように作られるため、values の量が増えます。その複雑さは欠点というより汎用性の代償です。ただし、運用する側がその分岐を理解しないまま導入すると、障害時にどの値がどの Kubernetes リソースへ反映されたのか追いづらくなります。

公開 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 は自由度が高い一方で、互換性、アップグレード、Secret の扱い、values の設計を自分で引き受けることになります。つまり、自作 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 環境の構成をどの単位で部品化し、どう管理するかを決めることだと思います。

関連する記事

次に進む

参考書籍

関連記事

Kubernetes Helm の導入 – Chart でアプリケーション構成を管理する Kubernetes MetalLB を Helm で導入する – Harbor で Chart を管理する考え方 Kubernetes 上に Harbor を構築する – Helm で内部コンテナレジストリを運用する意味 Kubernetes MetalLB を Helm で導入する – オンプレ環境で LoadBalancer Service を使う Kubernetes 運用設計ガイド Kubernetes マニフェストの apiVersion を理解する Kubernetes disk-pressure で Pod が起動しない場合 Kubernetes で送信元アドレスが変わる問題 – externalTrafficPolicy、hostNetwork、BGP 経路広告で考える