はじめに
Kubernetesの公式ドキュメントのConfigMapのページ を読んでいたところ、Immutable（不変な） ConfigMaps / Secrets という仕組みがあることに気づきました。
ConfigMapやSecretを「あとから変更できない」状態にできる仕組みらしく、覚えておきたかったので軽くまとめておきます📝
immutable: true とは？
ConfigMapのYAMLにimmutable: trueというフィールドを追加すると、そのConfigMapをImmutableにできます。
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
MESSAGE: "hello"
immutable: true
Secretも同じように書けます。
apiVersion: v1
kind: Secret
metadata:
name: my-secret
data:
PASSWORD: ...
immutable: true
これを付けると、以下のような挙動になります。
-
dataやbinaryDataの更新ができなくなる -
Immutableをあとからfalseに戻せない - 変更しようとすると
kube-apiserverがエラーを返す - 内容を変えたい場合は削除→作り直しが必要
つまり、完全な「読み取り専用」ConfigMap / Secretを作れる、というイメージです。
Immutableのメリット（公式より）
公式ドキュメントでは、主にこんな利点が挙げられていました。
- 誤った更新や、意図しない変更からアプリケーションを守れる
- ConfigMap/Secret を大量にマウントしているクラスターだと、kube-apiserverの負荷を下げられる（watch を閉じられる）
「めったに変えないけど、壊れると困る設定」に使うと良さそうな印象でした。
Pod 周りの挙動
もうひとつ気になったのが、Podとの関係です。
-
Immutableでも 削除自体は可能 - ただし 既存の
Podは削除後も古いマウントを保持したまま - 同じ名前で新たに作り直しても、自動では中身が更新されない
そのため、更新したい場合は
-
ConfigMap/Secretを削除・再作成 - それに依存する
Podを再起動（再デプロイ）
という運用が必須になります。
まとめ
-
ConfigMap / Secretにはimmutable: trueというフィールドがある - 作成後は内容の更新ができない完全な読み取り専用リソースになる
- 誤更新防止や、大規模クラスターでの
kube-apiserver負荷軽減に有効 - 中身を変えるには削除 → 再作成 → Podの再デプロイが必要
今回こういう仕組みがあると知れたので、今後の設計や運用を考えるときの選択肢のひとつとして覚えておこうと思います。