Kubernetes実践導入とコンテナ運用
マニフェスト管理の最適化
YAML管理からの脱却
Kubernetesを運用していると、すぐにYAMLファイルの壁にぶつかります。開発、ステージング、本番といった環境ごとに、ほとんど同じなのに少しだけ違うdeployment.yamlやservice.yamlが大量に生まれてしまうのです。レプリカ数を変更したり、コンテナイメージのタグを更新したりするたびに、複数のファイルを修正するのは手間がかかり、ミスも起きやすくなります。
この問題を解決するのが、「宣言的インフラ管理」と「」です。毎回「これをこう変更しろ」と命令するのではなく、「これが最終的なあるべき姿だ」と宣言するのです。そして、共通部分は一箇所で管理し、重複をなくします。このアプローチを実現するために、KubernetesエコシステムにはKustomizeとHelmという2つの強力なツールが存在します。
これらのツールは、単なるYAMLのコピペ管理から脱却し、より洗練され、自動化されたワークフローを構築するための第一歩です。
Kustomizeで差分を管理する
Kustomizeは、テンプレートを使わずにKubernetesのYAML設定をカスタマイズするためのツールです。中心となるのはbase（共通設定）とoverlays（環境ごとの差分設定）という考え方です。
baseディレクトリには、すべての環境で共通のYAMLファイルを置きます。そして、overlaysの下にdevelopmentやproductionといった環境ごとのディレクトリを作成し、そこに変更したい部分だけを記述した「パッチ」ファイルを置きます。
# overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# どのbase設定を読み込むか指定
resources:
- ../../base
# 本番環境用のイメージタグに変更
images:
- name: my-app
newTag: v1.2.0-stable
# レプリカ数を変更するためのパッチを適用
patches:
- path: replica-patch.yaml
target:
kind: Deployment
name: my-app-deployment
このkustomization.yamlは、baseの設定を読み込み、イメージタグをv1.2.0-stableに上書きし、さらにreplica-patch.yamlで定義された変更（例えばレプリカ数を3にするなど）を適用します。これにより、環境ごとの違いが一目瞭然になり、管理が非常に簡単になります。
Helmでアプリケーションをパッケージ化する
は「Kubernetesのパッケージマネージャー」とよく呼ばれます。アプリケーションとその依存関係、設定を「チャート」という単位でまとめ、再利用可能な形で管理できます。WordPressやPostgreSQLのような一般的なアプリケーションを、コマンド一つでデプロイできるのはHelmのおかげです。
Helmチャートの核心は、テンプレートと値の分離です。templates/ディレクトリには、Goのテンプレート言語を使ったYAMLファイルの雛形を置きます。そして、values.yamlファイルで、環境ごとに変更したい具体的な値を定義します。
# templates/deployment.yaml の一部
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-deployment
spec:
replicas: {{ .Values.replicaCount }}
template:
spec:
containers:
- name: web
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
env:
- name: DATABASE_URL
value: {{ .Values.database.url | quote }}
{{ .Values.replicaCount }}や{{ .Values.image.tag }}といったプレースホルダーは、helm installやhelm upgradeコマンド実行時にvalues.yamlの値で置き換えられます。これにより、一つのチャートを使い回して、異なる設定値を持つ複数のリリースを作成できます。
ConfigMapとSecretの動的管理
アプリケーションの設定情報（ConfigMap）や認証情報（Secret）の管理は、特に注意が必要です。これらのリソースは頻繁に更新される可能性があり、その変更を安全にアプリケーションに反映させる必要があります。
静的なYAMLファイルに直接センシティブな情報を書き込むのは避け、外部のソースから動的に生成・注入する仕組みを構築することが推奨されます。
Kustomizeには、ファイルからConfigMapやSecretを自動生成する便利な機能があります。configMapGeneratorやsecretGeneratorを使うと、ローカルの.envファイルや設定ファイルをもとに、名前がハッシュ化されたConfigMapを生成できます。このハッシュ化が重要です。
# kustomization.yaml の一部
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
# .envファイルからConfigMapを生成
configMapGenerator:
- name: my-app-config
envs:
- config.env
# secret.txtファイルからSecretを生成
secretGenerator:
- name: my-app-secret
files:
- secret.txt
これにより、設定内容を変更すると自動で新しい名前のConfigMap/Secretが作られ、それを参照するDeploymentも更新されるため、設定の変更が確実にPodに反映されます。この「イミュータブル（不変）」なアプローチは、ヒューマンエラーを減らし、デプロイの信頼性を高める上で非常に効果的です。
開発、ステージング、本番といった複数の環境でKubernetesのYAMLファイルを管理する際に、よく発生する問題点は何ですか？
KustomizeがKubernetesの設定を管理するために用いる基本的な考え方はどれですか？
Kubernetesのマニフェスト管理は、単なるYAMLファイルの作成から、再利用可能で保守性の高い「インフラストラクチャ・アズ・コード」へと進化させるプロセスです。KustomizeやHelmを使いこなし、宣言的な構成管理を実践することで、デプロイの自動化と安定運用を実現しましょう。