Kubernetes ConfigMap・Secretの確認・更新手順｜反映されない原因も解説
Kubernetesでアプリの設定値・機密情報を扱う際、ConfigMapとSecretの違い、設定の参照方法、更新がPodへ反映される条件を整理する運用ガイドです。値を表示しない確認コマンドから始めます。
この記事の目的
設定を保持するオブジェクトの確認と、反映方式によるPod再起動の要否・セキュリティ上の注意を整理します。
まず確認すること
kubectl config current-contextで接続先を確認し、kubectl get configmaps/secrets -n appで対象を特定します。
get -o yamlや画面キャプチャで公開しないこと。base64は暗号化ではありません。 app・APP・POD_NAMEなどは説明用です。作業前にcontext・namespace・対象オブジェクトを照合してください。関連ガイド
Kubernetes基本操作
context・namespaceを確認し、kubectlでPod・Eventsを調査します。
ガイドへ →KubernetesDeployment更新・切り戻し
rollout history・status・undoと変更前後の確認を行います。
ガイドへ →KubernetesService・EndpointSliceの接続確認
Service selector・EndpointSlice・targetPortとReadyを点検します。
ガイドへ →1. ConfigMapとSecretの役割
| 比較 | ConfigMap | Secret |
|---|---|---|
| 主な内容 | 秘密ではない設定値・設定ファイル | パスワード・トークン・鍵など |
| API上の扱い | 通常の設定オブジェクト | 秘匿情報を扱う専用オブジェクト |
| 注意点 | 設定でも機密情報が混ざることがある | base64は暗号化ではない。RBAC・暗号化保存・外部Secrets管理を設計 |
| Podへの渡し方 | 環境変数・Volume | 環境変数・Volumeなど |
Secretだからといってアクセス制御や保管場所の検討が不要になるわけではありません。Secretを読めるRBAC権限や暗号化保存（etcdのEncryption at Rest等）は別途確認します。
2. 値を露出させず対象と参照関係を確認
権限がない場合はForbiddenになるので、対象の不存在と混同しないでください。get secret -o yamlやdescribe configmapは値を含む場合があり、共有前に必ず伏せます。
3. 環境変数とVolumeの反映差
| Podへの設定方法 | 更新後の挙動 | 運用上の確認 |
|---|---|---|
| 環境変数 | 起動済みコンテナの環境変数は自動更新されない | Pod再作成・再起動等による反映と影響範囲を計画 |
| 通常のVolumeマウント | 更新がkubeletの同期を通じて反映されることがある | 即時とは限らない。アプリが読み直すか確認 |
| subPathによるマウント | ConfigMap/Secret変更が反映されない | Pod再作成等の反映手順を設計 |
ConfigMap・SecretのVolume更新とアプリの設定再読込は別です。新ファイルが見えるだけでは業務への反映を保証できません。
4. Deployment側の参照を確認
PodテンプレートのenvFrom・configMapKeyRef・secretKeyRef・volumes・volumeMountsを確認します。参照先のNamespaceはPodと同じかどうか、オブジェクト名・キー名の一致も確認します。
5. ConfigMapの変更前検証と反映例
以下は機密情報を含まないConfigMapを検証する例です。Secretの値は同じ方法で平文ファイルに書かないでください。GitOpsやCI管理下では手作業で更新せず、管理元の変更フローを優先します。
--dry-run=serverはリソースを永続保存せず、APIの検証を行いますが、アプリケーションの実行時動作やGitOpsの再上書きまでは保証しません。kubectl diffは更新前のSecret値を含むようなYAMLに対して安易に使わないでください。変更前に「どのアプリ・Podで利用しているか」「どのGitOps/CI定義が管理元か」「いつ・どう反映するか」「切り戻せるか」を確認します。GitOps管理下で手動のkubectl editを行っても宣言的な値で上書きされる場合があります。
Deploymentの変更・再起動が必要な場合はDeploymentの更新・切り戻し手順を参照してください。
6. 差分・反映方式・切り戻しの判断
以下は機密情報を含まないConfigMapの想定例です。Secret値は出力しません。まずGitOps/CIの管理元から変更前の定義（旧版）を安全に確保し、利用Pod・アプリの設定読み込み方式を記録してください。
| 検証結果（想定） | 次の行動 |
|---|---|
kubectl diff終了コード0 | 差分なし。変更対象や管理元を再確認し、不要なapply・restartを実施しない |
kubectl diff終了コード1 | 差分を確認。ConfigMapのキー削除・追加、参照Pod、環境変数かVolumeかを照合し、影響と復旧手段を承認後に変更する |
kubectl diff終了コードが1より大きい、またはserver dry-run失敗 | 不正な定義・RBAC・Webhook・接続先の問題を調べ、反映を中止する |
| ConfigMapは更新できたがアプリへ未反映 | 環境変数は既存Podへ自動反映されない。通常Volumeは遅延して更新され得るが、subPathは自動反映されない。アプリの再読込可否を確認し、必要なら管理元からPod更新を計画する |
| 新設定でエラー・業務不具合 | 影響範囲と証跡を保全。管理元に保持した旧ConfigMap定義へ戻す手続きを承認のうえ行い、必要なPod再作成とアプリの機能確認を実施 |
注意：通常のkubectl applyの成功は既存Podの設定反映を保証せず、rollout statusの成功も業務正常を保証しません。設定を変更する場合は影響するアプリの実動作・Pod Ready・ログ・Service経由の応答で完了判断します。元の定義が不明なら手動切り戻しを行わず、GitOps管理者へエスカレーションします。Kubernetes公式 — ConfigMapの更新と反映差。
7. 反映後に検証する項目
- 設定を更新した対象オブジェクト名・Namespaceが正しいか
- Podの再作成が必要な反映方式か
- アプリが実際に設定値を読み込んでいるか
- PodのReady・restart・ログ・業務通信に問題がないか
- Secret値がログ・チケット・監視出力へ漏れていないか
更新後にPodが起動できない場合はCrashLoopBackOffの調査、レジストリ認証が関係する場合はImagePullBackOffの調査へ進みます。