不可变配置对象
把 ConfigMap 标记为 immutable: true 之后它就不能再被修改：任何改动数据的请求都会被拒绝，只能删除后重建。好处是减少 kubelet 对这类对象的监听与同步开销，也能防止误改；代价是每次变更都要走删除重建流程。要注意这个字段只能从未设置改为不可变，不能改回来；虽然可以删除重建，但重建期间引用它的工作负载可能短暂找不到配置。
基本信息
| 适用对象 | 各版本的 ConfigMap，Secret 也支持同名字段 |
|---|---|
| 关键字段 | immutable: true |
| 变更方式 | 只能删除后重建，名称可以保持不变 |
| 回退限制 | 不能从不可变改回可变 |
| 潜在影响 | 重建窗口内引用方可能创建失败 |
典型使用场景
- 关键配置防误改：不希望有人顺手编辑线上配置
- 减少监听负载：配置对象数量多时降低 kubelet 同步开销
- 版本化配置：把配置内容与版本号绑定，变更即换对象
- 合规要求：要求配置变更留痕、不可原地修改
- 减少漂移：配合声明式发布，让配置差异只在清单层面体现
声明与变更流程
声明与变更流程
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
namespace: prod
data:
version: "2026.10"
log_level: info
immutable: true # 标记后不能再修改 data验证与重建
验证与重建
kubectl patch cm app-config -n prod -p '{"data":{"log_level":"debug"}}'
# 预期报错：字段不可变，修改被拒绝
kubectl get cm app-config -n prod -o jsonpath='{.immutable}'
kubectl delete cm app-config -n prod && kubectl apply -f app-config.yaml # 重建
kubectl rollout restart deploy/web -n prod # 引用方拿新配置操作与结果
| 操作 | 结果 | 注意 |
|---|---|---|
| 修改数据 | 被拒绝 | 报错提示字段不可变 |
| 删除后重建 | 允许 | 名称不变即可被引用方继续使用 |
| 关闭不可变 | 不允许 | 只能删除后重新创建 |
| 引用方重启 | 重建窗口内可能失败 | 需要错开时间或先建新对象 |
不可变对象能减少 kubelet 的监听与同步负担，配置类对象数量多的集群收益比较明显，属于投入小、收益稳的改动。
变更流程要设计好顺序：先准备好新配置内容，再删除重建，随后触发引用方滚动，避免出现「配置不存在」的窗口期。