// シス担のミカタ
Kubernetes

ConfigMap こんふぃぐまっぷ

Kubernetes設定管理環境変数PodSecretコンテナ
ConfigMapについて教えて

簡単に言うとこんな感じ！

アプリの「設定メモ帳」だよ！データベースのURLとか、ログのレベルとか、アプリが動くのに必要な設定値をプログラム本体から切り離してまとめておく仕組みなんだ。「本番環境」と「テスト環境」で設定だけ差し替えられるから、アプリのコードを書き換えずに済むってこと！

ConfigMapとは

ConfigMap（コンフィグマップ） は、Kubernetesでアプリケーションの設定情報をコンテナイメージから切り離して管理するためのオブジェクトです。データベースの接続先URL、ログの出力レベル、言語設定といった「環境ごとに変わる可能性がある値」を、アプリのコードとは別に定義しておくことができます。

たとえば、開発環境・ステージング環境・本番環境でデータベースのホスト名が異なる場合、ConfigMapを差し替えるだけでアプリ本体のイメージを作り直さずに対応できます。「設定と実装の分離」 はモダンなアプリ開発のベストプラクティスであり、ConfigMapはそれをKubernetes上で実現するための標準的な仕組みです。

ConfigMapが保持できるのは機密性のない設定データに限られます。パスワードやAPIキーなどの秘密情報は、暗号化管理が可能な Secret を使うのがルールです。ConfigMapとSecretをうまく使い分けることが、Kubernetesにおける設定管理の基本となります。

ConfigMapの構造と使い方

ConfigMapは「キーと値のペア」の集まりです。値には1行の文字列だけでなく、設定ファイル丸ごとのような複数行テキストも格納できます。

格納できるデータ例具体例
単純な文字列LOG_LEVEL=debug / APP_LANG=ja
URL・ホスト名DB_HOST=mysql.example.com
設定ファイル全体nginx.conf や application.properties の内容
数値・フラグMAX_RETRY=3 / FEATURE_FLAG=true

Podへの渡し方は3通り

ConfigMapの値をアプリに届ける方法は主に3つあります。

┌─────────────────────────────────────────────────┐
│                  ConfigMap                      │
│  LOG_LEVEL: debug                               │
│  DB_HOST:   mysql.example.com                   │
│  nginx.conf: server { listen 80; ... }          │
└────────────┬───────────────┬────────────────────┘
             │               │               │
    ①環境変数として    ②コマンド引数として  ③ファイルとして
     PODに注入         PODに注入         ボリュームにマウント
             ↓               ↓               ↓
      env: DB_HOST     args: --level=debug  /etc/config/nginx.conf
渡し方特徴向いているケース
環境変数アプリが os.getenv() で読める単純なキー・バリュー設定
コマンド引数起動オプションとして渡すCLIツール系アプリ
ボリュームマウントファイルとして /etc/config/ などに配置設定ファイルを丸ごと渡したいとき

覚え方：「ConfigMap ＝ アプリへの手紙」

ConfigMapは「このアプリはこういう環境で動かしてね」と書いた指示書（手紙）を、コンテナに届けるイメージ。本番用と開発用で手紙の内容を変えれば、同じコンテナがどちらの環境でも正しく動く、という考え方です。

歴史と背景

  • 2014年 — Kubernetesがオープンソースとして公開。当初から「設定と実装の分離」の必要性は認識されていたが、専用リソースはなかった
  • 2016年 — Kubernetes 1.2でConfigMapが正式に導入。それ以前は環境変数をPod定義に直書きするしかなく、管理が煩雑だった
  • 2016年〜 — 同時期にSecretも整備され、「機密でない設定はConfigMap、秘密情報はSecret」という役割分担が確立
  • 2018年〜 — Helm（Kubernetesのパッケージ管理ツール）の普及により、ConfigMapをテンプレートで動的生成するパターンが一般化
  • 2021年 — Kubernetes 1.21でImmutable ConfigMap（変更不可フラグ）が安定版に。意図しない設定変更を防ぐセキュリティ強化が進む

ConfigMap vs Secret ── 使い分けの地図

ConfigMapとSecretは兄弟のような存在ですが、扱うデータの性質が違います。

ConfigMap 機密でない設定情報 データベースのホスト名・ポート ログレベル・言語設定 設定ファイル（nginx.conf 等） フィーチャーフラグ 平文で保存・etcdに素のまま格納 base64エンコードなし Secret 機密性の高い情報 パスワード・APIキー TLS証明書・秘密鍵 OAuthトークン コンテナレジストリ認証情報 base64エンコードで保存 暗号化設定を推奨 使い分け

ConfigMapの注意点

  • ConfigMapのデータサイズ上限は 1MB です。大きな設定ファイルは別途管理を検討してください
  • ConfigMapを更新しても、環境変数として渡している場合はPodを再起動するまで反映されない点に注意が必要です（ボリュームマウントの場合は自動反映される）
  • Immutable（変更不可）フラグ を設定すると、誤った変更による障害を防げます。本番環境では積極的に活用しましょう

関連する規格・RFC

規格・ドキュメント内容
Kubernetes公式ドキュメント: ConfigMapsConfigMapの公式定義と使用方法
12 Factor App: III. Config設定を環境から切り離すべき、というアプリ設計原則
Kubernetes API Reference: v1/ConfigMapConfigMapのAPIスキーマ定義

関連用語

  • Secret — パスワードやAPIキーなど機密情報を安全に管理するKubernetesオブジェクト
  • Pod — Kubernetesでコンテナが動く最小単位。ConfigMapはPodに注入して使う
  • Deployment — Podの起動・管理を宣言的に定義するリソース。ConfigMapと組み合わせて使うことが多い
  • Helm — Kubernetesのパッケージ管理ツール。ConfigMapをテンプレートで動的生成できる
  • Namespace — Kubernetesの論理的な分割単位。ConfigMapはNamespaceをまたいで共有できない