用 SubPath 解决 ConfigMap 和 Secret 挂载覆盖问题
把配置文件直接挂进容器虽然方便，但如果路径选错，就可能把原目录整个覆盖掉。SubPath 解决的正是这类“挂载一份文件，却误伤一整个目录”的经典问题。
Secret 实践：文件挂载、自定义文件名、权限与环境变量注入
Secret 在 Pod 中的使用方式，和 ConfigMap 十分相似，但对敏感数据的处理要更谨慎。文件挂载、自定义文件名、权限控制以及环境变量注入，是最常见的四类落地方式。
Secret 创建方式详解：kubectl 命令、YAML 与 Opaque 配置
Secret 的创建方式既可以非常直接，也可以非常规范。无论是命令行快速创建，还是用 YAML 管理 Opaque Secret，核心都在于理解 base64、键名映射和声明式配置的关系。
为什么要引入 Secret：定义、风险提示与常见类型
当配置数据里开始出现密码、令牌、证书这类敏感信息时，ConfigMap 就不再合适了。Secret 解决的是“敏感配置怎么保存和分发”的问题，但它也并不天然等于绝对安全。
ConfigMap 限制与热更新：更新机制、注意事项和不可变配置
ConfigMap 并不是“创建好就万事大吉”的配置容器。它有使用限制，也有热更新机制和 immutable 能力，理解这些边界之后，才能在生产环境里稳定使用它。
ConfigMap 实践：文件挂载、自定义文件名、权限与 optional
除了环境变量，ConfigMap 还非常适合直接把配置文件挂进容器。文件挂载、自定义文件名、默认权限以及 optional 行为，是这类用法里最容易踩坑、也最值得一次讲透的部分。
ConfigMap 实践：用 valueFrom 和 envFrom 注入环境变量
ConfigMap 最常见的使用姿势之一，就是把配置变成容器里的环境变量。valueFrom 适合精确取单个键，envFrom 更适合批量注入，理解两者差异很关键。
ConfigMap 创建方式详解：literal、YAML 与自定义配置文件
当配置来源不再只是单个文件时，ConfigMap 也可以通过 literal、YAML 清单和自定义 conf 文件来组织。掌握这几种方式后，配置管理会更加灵活，也更适合实际项目落地。
ConfigMap 创建方式详解：基于目录、文件与环境变量导入
创建 ConfigMap 的方式很多，但最终都会落到键值对模型上。基于目录、文件和环境变量导入，是最常见也最容易直接接入现有应用配置的三种做法。
为什么要引入 ConfigMap：云原生配置管理的动机、定义与边界
ConfigMap 是 Kubernetes 里最基础的配置管理能力之一。只有先理解它为什么会出现、它解决了什么问题，以及它和 Secret 的边界在哪里，后面的创建和挂载实践才不会停留在“会用命令”的层面。
显示第 191 - 200 条，共 1671 条记录