配置与存储最佳实践
本教程共 65 篇 · 第 37 篇 · 更新于 2026-08-14 · 约 6 分钟阅读
本节目标：把前面四章串起来，记住”什么该写进镜像、什么该外置”，理清 ConfigMap 与 Secret 的边界，并避开 PVC、回收策略、挂载热更新这些常见坑。
前面讲了 ConfigMap、Secret、各类卷、PV/PVC、StorageClass。这章不讲新概念，只讲”怎么用才不踩坑”。这些是我和身边人真实交过学费的总结。
37-1 什么不该写进镜像
镜像应该是”到处能跑的同一个包”。以下东西请外置：
- 数据库地址、端口、功能开关 —— 放 ConfigMap。
- 密码、令牌、证书、私钥 —— 放 Secret。
- 大段配置文件（如 nginx.conf）—— 优先 ConfigMap 卷挂载。
Warning把密码硬编码进镜像，等于把钥匙贴在门上。镜像会被推到仓库、被别人拉取，密钥就泄露了。这跟用不用 Secret 没关系，是纪律问题。
37-2 ConfigMap 与 Secret 的取舍
简单判断：数据泄漏了会不会出事？会，就用 Secret；只是普通配置，用 ConfigMap。
Secret 不等于安全，它默认只是 Base64。要真安全得配合：etcd 静态加密、收紧 RBAC、必要时上外部密钥仓库（如 secrets-store-csi-driver）。别迷信”用了 Secret 就保险”。
Tip配置更新频繁、希望容器热加载的，用卷挂载而不是环境变量。环境变量方式不自动更新，非重启不生效。这是新手最常问的”我改了配置怎么没变”的根源。
37-3 密钥与敏感数据建议
- 不在 YAML 里写明文 Secret 的
data，用stringData让系统帮你编码，或用kubectl create secret生成。 - 给 Secret 设
immutable: true，防止误改导致应用中断。 - 不同环境（开发/测试/生产）用不同命名空间，配合 RBAC 隔离访问。
- 把 Secret 当卷挂、设
readOnly: true，比环境变量更不容易泄露到日志里。
37-4 存储使用的常见坑
第一，回收策略。动态制备默认 Delete，删 PVC 盘就没。数据库这类有状态负载，把 StorageClass 或 PV 的回收策略设成 Retain，或者单独建一个”保留型”类。
第二，访问模式。RWX 需要后端支持（如 NFS）。很多云盘只支持 RWO。多副本要共享写，先确认后端行不行，别闷头用 RWX。
第三，不要 Pod 直连 PV。让 Pod 引用 PVC，PVC 再去绑 PV。这样用户不用懂底层存储，迁移也方便。
Note本地盘（hostPath/local）受节点限制。生产数据库用 hostPath 风险很高：Pod 漂到别的节点，数据就读不到了。真要用本地盘，请用
local类型 StorageClass 加WaitForFirstConsumer，让调度器把 Pod 绑到正确的节点。
37-5 一点经验之谈
配置和存储看似简单，却最容易在出事时才被发现。我建议：把”环境相关的一切”都外置，镜像只装代码和不变的文件；机密一律走 Secret 且默认不动；有状态数据一律走 PVC 并想清楚回收策略。
做到这几条，你的应用在不同环境间搬移会顺很多，半夜被叫起来救火的概率也会降下来。