文章目录第5章 ConfigMap Secret 配置管理5.1 为什么需要配置管理5.1.1 问题背景5.1.2 核心概念5.1.3 数据流向原理5.2 ConfigMap 详解5.2.1 四种创建方式方式一：从字面量创建（--from-literal）方式二：从文件创建（--from-file）方式三：从目录创建（--from-file=目录）方式四：YAML 清单创建（生产标准方式）5.2.2 三种注入方式注入方式一：env 单 key 注入注入方式二：envFrom 批量注入注入方式三：Volume 挂载文件（生产最常用）5.2.3 subPath 深度解析（高频踩坑点）5.2.4 热更新机制验证与原理5.3 Secret 详解5.3.1 三种类型类型一：Opaque（最常用）类型二：dockerconfigjson（私有镜像仓库）类型三：kubernetes.io/tls（HTTPS 证书）5.3.2 Secret 注入方式环境变量注入（简单但安全性较低）Volume 挂载（推荐，安全性更高）5.3.3 生产级安全加固加固一：etcd 静态加密加固二：Immutable Secret/ConfigMap（K8s 1.21+ 支持）加固三：RBAC 严格限制访问5.4 综合实战：部署带完整配置的 Web 应用5.5 企业级工程实践5.5.1 多环境配置管理（Kustomize 标准结构）5.5.2 配置变更触发滚动更新5.5.3 配置校验（CI/CD 质量门）5.6 生产环境踩坑实录坑1：Secret 密码末尾多换行，数据库认证失败坑2：envFrom 注入后部分变量静默丢失坑3：subPath 挂载后配置不更新坑4：ConfigMap 不存在导致整个 Deployment 无法启动坑5：Secret YAML 被误提交到 Git 仓库坑6：ConfigMap 超过 1MB 无法创建5.7 面试高频考点Q1：ConfigMap 和 Secret 有什么区别？Q2：ConfigMap 热更新的原理是什么？哪些场景不支持？Q3：Secret 安全吗？生产环境如何加固？Q4：subPath 的作用和缺点？Q5：如何实现修改 ConfigMap 后自动滚动更新 Deployment？Q6：env 和 envFrom 的区别和适用场景？5.8 练习题基础实操题（10道）进阶实战题（5道）5.9 本章总结第5章 ConfigMap Secret 配置管理5.1 为什么需要配置管理5.1.1 问题背景在前面的章节中，我们部署的 Nginx、CentOS 等应用都使用镜像内置的默认配置。但在真实企业环境中，同一个应用镜像需要在不同环境（开发、测试、预发、生产）运行，每个环境的数据库地址、端口、日志级别、第三方密钥都不一样。如果把配置写死在镜像里，就需要为每个环境单独构建镜像，这显然违反了"一次构建，到处运行"的容器化原则。ConfigMap 和 Secret 就是 Kubernetes 提供的配置与代码分离机制，将配置从镜像中抽离，运行时注入到容器中。5.1.2 核心概念资源用途典型场景ConfigMap存储非敏感配置数据Nginx 配置文件、应用 properties/yml、环境变量Secret存储敏感配置数据数据库密码、TLS 证书、API Key、镜像仓库认证 第5章 ConfigMap Secret 配置管理
文章目录第5章 ConfigMap Secret 配置管理5.1 为什么需要配置管理5.1.1 问题背景5.1.2 核心概念5.1.3 数据流向原理5.2 ConfigMap 详解5.2.1 四种创建方式方式一：从字面量创建（--from-literal）方式二：从文件创建（--from-file）方式三：从目录创建（--from-file=目录）方式四：YAML 清单创建（生产标准方式）5.2.2 三种注入方式注入方式一：env 单 key 注入注入方式二：envFrom 批量注入注入方式三：Volume 挂载文件（生产最常用）5.2.3 subPath 深度解析（高频踩坑点）5.2.4 热更新机制验证与原理5.3 Secret 详解5.3.1 三种类型类型一：Opaque（最常用）类型二：dockerconfigjson（私有镜像仓库）类型三：kubernetes.io/tls（HTTPS 证书）5.3.2 Secret 注入方式环境变量注入（简单但安全性较低）Volume 挂载（推荐，安全性更高）5.3.3 生产级安全加固加固一：etcd 静态加密加固二：Immutable Secret/ConfigMap（K8s 1.21+ 支持）加固三：RBAC 严格限制访问5.4 综合实战：部署带完整配置的 Web 应用5.5 企业级工程实践5.5.1 多环境配置管理（Kustomize 标准结构）5.5.2 配置变更触发滚动更新5.5.3 配置校验（CI/CD 质量门）5.6 生产环境踩坑实录坑1：Secret 密码末尾多换行，数据库认证失败坑2：envFrom 注入后部分变量静默丢失坑3：subPath 挂载后配置不更新坑4：ConfigMap 不存在导致整个 Deployment 无法启动坑5：Secret YAML 被误提交到 Git 仓库坑6：ConfigMap 超过 1MB 无法创建5.7 面试高频考点Q1：ConfigMap 和 Secret 有什么区别？Q2：ConfigMap 热更新的原理是什么？哪些场景不支持？Q3：Secret 安全吗？生产环境如何加固？Q4：subPath 的作用和缺点？Q5：如何实现修改 ConfigMap 后自动滚动更新 Deployment？Q6：env 和 envFrom 的区别和适用场景？5.8 练习题基础实操题（10道）进阶实战题（5道）5.9 本章总结第5章 ConfigMap Secret 配置管理5.1 为什么需要配置管理5.1.1 问题背景在前面的章节中，我们部署的 Nginx、CentOS 等应用都使用镜像内置的默认配置。但在真实企业环境中，同一个应用镜像需要在不同环境（开发、测试、预发、生产）运行，每个环境的数据库地址、端口、日志级别、第三方密钥都不一样。如果把配置写死在镜像里，就需要为每个环境单独构建镜像，这显然违反了"一次构建，到处运行"的容器化原则。ConfigMap 和 Secret 就是 Kubernetes 提供的配置与代码分离机制，将配置从镜像中抽离，运行时注入到容器中。5.1.2 核心概念资源用途典型场景ConfigMap存储非敏感配置数据Nginx 配置文件、应用 properties/yml、环境变量Secret存储敏感配置数据数据库密码、TLS 证书、API Key、镜像仓库认证