第6章 补给线：配置与存储注入声明
第6章 补给线：配置与存储注入声明
章节摘要：本章跟着一条线走——容器镜像里没有的两样东西，运行时配置与持久数据，如何沿着各自的补给线送达 orders-api：ConfigMap 与 Secret 以环境变量或文件挂载注入，存储则经"申请人 PVC、管理员或 StorageClass 供给 PV"的申领制度落地。镜像保持通用，环境差异全部外置，是这一章要立下的工程纪律。
一条主线
前五章的声明越来越完整，但一直有个细节被刻意绕开：orders-api 怎么知道数据库地址是哪个？日志级别开多少？TLS 证书从哪读？答案是——都不写在镜像里。镜像一旦把环境信息烧死，一个应用就要为开发、测试、生产各造一个镜像，"镜像不可变"的工程价值当场作废。
本章的两条补给线解决镜像的"不知道"：
- 配置线：ConfigMap 装非敏感配置，Secret 装敏感数据，两者都以键值形态存在于集群，可整体更新、可挂载为文件、可注入为环境变量；
- 存储线：容器写进自身文件系统的数据随容器消亡，Volume 提供容器外的落点；进阶的申领制度（PVC 描述需求、PV 描述供给、StorageClass 自动撮合）让"要多少存储"也成为声明的一部分。
图 6-1：镜像、配置、数据的三层供给关系
沿途站点
本章两节，两条补给线各一节：
- 6.1 ConfigMap 与 Secret：把配置从镜像里解耦：两条注入路径（环境变量与文件挂载）的取舍、Secret 的编码与安全边界、配置更新的生效粒度，以及"配置也是资源对象"带来的版本化红利。
- 6.2 从 Volume 到 PVC：存储的申领制度：从 emptyDir 的临时卷起步，走过 hostPath 的节点本地卷，进入 PV 与 PVC 的供给与申领模型，最后用 StorageClass 把"申请一百 Gi 高性能盘"变成一行声明。
两节都直接服务于前文的案例：6.1 兑现 1.2 节环境变量的伏笔与 5.2 节 TLS 证书的 secretName，6.2 兑现 4.3 节 StatefulSet 卷模板里 PVC 的伏笔——本章结束时，本教程主线声明里的所有占位符都将被填实。
拐点与结论
本章的认知拐点有二。其一在 6.1：Secret 不是加密存储，而是编码存储——Base64 只是编码，真正的防线在 RBAC 权限与 etcd 静态加密，把 Secret 当保险箱是认知错位。其二在 6.2：PVC 声明的是需求而非设备——应用要的是"100Gi、单副本读写"，至于背后是云盘还是本地盘，由 StorageClass 按策略撮合；需求与供给解耦，应用声明才能跨环境迁移。
结论一句话：镜像管"程序是什么"，配置管"环境是什么"，存储管"数据放哪里"——三者分离的应用才配得上"可迁移"三个字。
读完你应该
- 写出 ConfigMap 的两条注入路径并按场景选择（启动期变量对热更新文件）；
- 说明 Secret 的编码本质、三道防线与常见泄漏路径，配置出规范引用 Secret 的声明；
- 解释配置热更新的生效边界：挂载文件可滚动刷新、环境变量不热更；
- 画出 PVC、PV、StorageClass 三者关系图，并写出自动申领的声明；
- 说出 emptyDir、hostPath、PVC 卷的适用与禁区，为有状态负载选对卷类型。
下一章的接力
至此，一份 Deployment 从写出、受理、落地、自愈到配置补给的全程已经走完。最后一章切到运维视角：声明跑起来之后，如何用日志、指标、追踪看清它；声明与现状不一致时，按什么手册排障；以及当一份声明要复制到一百个环境时，Helm 与 GitOps 如何接管。