Kubernetesでアプリケーションを運用していると、「環境ごとに設定ファイルを変えたい」「機密ではない設定値を管理したい」といったケースが出てきます。そんな時に登場するのが ConfigMap（コンフィグマップ） です。

この章では、ConfigMapがどんな役割を果たし、どうやって使うのかを実例を交えて丁寧に解説します。

🧠 ConfigMapとは？

ConfigMapは、設定情報（Key-Value形式）をKubernetesクラスタ内で管理するための仕組みです。設定値をPodのコンテナに「注入」することで、アプリケーションの設定をKubernetes側で制御できます。

✅ どんな情報を入れる？

ConfigMapは、機密性のない設定値（例えば環境名やログレベル、外部APIのURLなど）を格納します。

例：

• LOG_LEVEL=debug
• ENV=staging
• API_URL=https://api.example.com

☝️ パスワードなどの機密情報はConfigMapではなく、Secretを使います。

💡 なぜ使うの？

アプリケーションの設定を application.properties や .env に書くと、コンテナイメージの中に組み込まれてしまいますよね。

でもこれでは、「本番用」と「開発用」で設定を切り替えるのが大変です。

ConfigMapを使うことで：

• コンテナイメージは同じままで、
• 環境ごとの設定だけ切り替えられる！

つまり、アプリケーションの設定をクラスタ側に委ねることで、柔軟で安全な構成管理が可能になります。

🛠️ ConfigMapの作り方

以下はConfigMapをYAMLで定義する基本的な方法です。

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  LOG_LEVEL: "debug"
  API_URL: "https://api.example.com"

作成コマンド：

kubectl apply -f my-configmap.yaml

🧪 Podでの使い方（例）

作ったConfigMapを、Podの中で使うにはいくつか方法があります。

① 環境変数として渡す

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: my-config
        key: LOG_LEVEL

この方法だと、アプリケーションが環境変数から設定を読み込むようにしておけばOKです。

② ファイルとしてマウントする

volumeMounts:
  - name: config-volume
    mountPath: /etc/config

volumes:
  - name: config-volume
    configMap:
      name: my-config

このようにマウントすると、ConfigMap内の各キーがファイル名となり、値が中身になります。

# Pod内で確認
cat /etc/config/LOG_LEVEL
# => debug

📘 ConfigMapの操作コマンド

# 作成（直接キー指定）
kubectl create configmap my-config --from-literal=LOG_LEVEL=debug

# ファイルから作成
kubectl create configmap my-config --from-env-file=app.env

# 中身の確認
kubectl get configmap my-config -o yaml

🧩 応用：ConfigMapの更新とロールアウト

ConfigMapを更新しても、それを使っているPodは自動的には再起動されません。そのため、設定を反映させるには以下のような対応が必要です：

• Deploymentにアノテーションを追加して手動ロールアウト
• checksum をPod定義に入れて差分を検出して再起動

🎯 まとめ