从零开始的云原生之旅（七）：ConfigMap 和 Secret 配置管理
从零开始的云原生之旅（七）：ConfigMap 和 Secret 配置管理
不要把配置写死在代码里！灵活配置才是王道！
📖 文章目录
- 前言
- 一、为什么需要 ConfigMap 和 Secret？
- 1.1 我以前的配置方式
- 1.2 遇到的问题
- 1.3 K8s 的解决方案
- 二、ConfigMap：管理配置数据
- 2.1 什么是 ConfigMap？
- 2.2 创建 ConfigMap
- 2.3 使用 ConfigMap 的 4 种方式
- 三、Secret：管理敏感数据
- 3.1 什么是 Secret？
- 3.2 创建 Secret
- 3.3 使用 Secret
- 3.4 Secret 的加密存储
- 四、实战案例：API 服务配置
- 4.1 配置需求分析
- 4.2 创建 ConfigMap
- 4.3 注入到 Deployment
- 4.4 应用代码读取配置
- 五、实战案例：CronJob 配置
- 5.1 定时任务需求
- 5.2 CronJob 配置详解
- 5.3 调度表达式
- 5.4 并发策略
- 六、配置的动态更新
- 6.1 ConfigMap 更新
- 6.2 应用如何感知更新？
- 6.3 强制更新 Pod
- 七、最佳实践
- 7.1 配置分层
- 7.2 命名规范
- 7.3 版本管理
- 7.4 安全建议
- 八、常见问题排查
- 8.1 ConfigMap 不存在
- 8.2 配置未生效
- 8.3 Secret 解码失败
- 九、ConfigMap vs Secret vs 环境变量
- 结语
前言
在前面的文章中，我学会了部署各种工作负载：
- Deployment：无状态应用
- StatefulSet：有状态应用（Redis）
- DaemonSet：节点级服务（日志采集）
但我发现一个问题：配置都写死在代码里！
// 写死的配置
const (RedisHost = "redis-service"RedisPort = 6379LogLevel = "info"
)
这样有什么问题？
- ❌ 开发、测试、生产环境配置不同，需要重新编译
- ❌ 修改配置需要重新构建镜像
- ❌ 敏感信息（密码、Token）暴露在代码中
这篇文章，我会学习 K8s 的配置管理方案：
- ✅ ConfigMap：管理配置数据
- ✅ Secret：管理敏感数据
- ✅ CronJob：定时任务的配置
- ✅ 配置的动态更新
- ✅ 最佳实践
一、为什么需要 ConfigMap 和 Secret？
1.1 我以前的配置方式
方式 1：写死在代码里
package configconst (RedisHost = "redis-service"RedisPort = 6379LogLevel = "debug" // 开发环境：debug，生产环境：infoAppEnv = "development"
)
问题：
- 换环境要改代码、重新编译
- 镜像和环境强绑定
方式 2：读取配置文件
// 读取 config.yaml
cfg, _ := os.ReadFile("config.yaml")
# config.yaml
redis:host: redis-serviceport: 6379
log_level: info
问题：
- 配置文件怎么放到容器里？
- 不同环境要维护不同的配置文件
- 修改配置要重新构建镜像
方式 3：环境变量
redisHost := os.Getenv("REDIS_HOST")
redisPort := os.Getenv("REDIS_PORT")
# Deployment
env:
- name: REDIS_HOSTvalue: "redis-service"
- name: REDIS_PORTvalue: "6379"
这个还不错，但：
- 配置分散在多个 Deployment 中
- 修改配置要编辑所有 YAML 文件
- 敏感信息（密码）明文存储
1.2 遇到的问题
场景：部署 3 个微服务，都要连 Redis
# service-a/deployment.yaml
env:
- name: REDIS_HOSTvalue: "redis-service" # 写死# service-b/deployment.yaml
env:
- name: REDIS_HOSTvalue: "redis-service" # 又写了一遍# service-c/deployment.yaml
env:
- name: REDIS_HOSTvalue: "redis-service" # 又又写了一遍
Redis 地址改了，要改 3 个文件！
场景：数据库密码
env:
- name: DB_PASSWORDvalue: "mySecretPassword123" # 明文！
问题：
- 密码明文存储在 YAML 文件中
- YAML 文件通常提交到 Git
- 密码泄露！
1.3 K8s 的解决方案
ConfigMap：管理配置数据
# 统一的配置
apiVersion: v1
kind: ConfigMap
metadata:name: common-config
data:redis_host: "redis-service"redis_port: "6379"
所有服务引用同一个 ConfigMap：
# service-a, service-b, service-c 都这样写
env:
- name: REDIS_HOSTvalueFrom:configMapKeyRef:name: common-configkey: redis_host
好处：
- ✅ 配置集中管理
- ✅ 修改一次，所有服务生效
- ✅ 配置和代码分离
Secret：管理敏感数据
# 创建 Secret
apiVersion: v1
kind: Secret
metadata:name: db-secret
type: Opaque
data:password: bXlTZWNyZXRQYXNzd29yZDEyMw== # Base64 编码
使用 Secret：
env:
- name: DB_PASSWORDvalueFrom:secretKeyRef:name: db-secretkey: password # 自动解码
好处：
- ✅ Base64 编码（虽然不是加密）
- ✅ RBAC 权限控制（谁能看 Secret）
- ✅ 可以启用加密存储
二、ConfigMap：管理配置数据
2.1 什么是 ConfigMap？
ConfigMap = 键值对的集合
┌───────────────────────────┐
│ ConfigMap │
│ │
│ key1: value1 │
│ key2: value2 │
│ config.json: { ... } │
│ redis.conf: ... │
│ │
└───────────────────────────┘
用途：
- 应用配置（日志级别、数据库地址）
- 配置文件（
nginx.conf,redis.conf） - 命令行参数
- 环境变量
2.2 创建 ConfigMap
方法 1：从字面量创建
kubectl create configmap my-config \--from-literal=log_level=info \--from-literal=redis_host=redis-service
查看：
kubectl get configmap my-config -o yaml
apiVersion: v1
kind: ConfigMap
metadata:name: my-config
data:log_level: inforedis_host: redis-service
方法 2：从文件创建
# 从单个文件
kubectl create configmap redis-config --from-file=redis.conf# 从目录（目录下所有文件）
kubectl create configmap app-config --from-file=./config/
结果：
apiVersion: v1
kind: ConfigMap
metadata:name: redis-config
data:redis.conf: |bind 0.0.0.0port 6379maxmemory 128mb
方法 3：从 YAML 文件创建（推荐）
# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: api-configlabels:app: apiversion: v0.2
data:# 简单的键值对log_level: "info"app_env: "production"# Redis 配置redis_host: "redis-service"redis_port: "6379"# 缓存配置cache_ttl: "3600"# 特性开关enable_cache: "true"enable_metrics: "true"
kubectl apply -f configmap.yaml
2.3 使用 ConfigMap 的 4 种方式
① 作为环境变量（单个键）
spec:containers:- name: apiimage: my-api:v1.0env:- name: LOG_LEVEL # 环境变量名valueFrom:configMapKeyRef:name: api-config # ConfigMap 名称key: log_level # ConfigMap 中的键
Pod 内看到的：
echo $LOG_LEVEL
# info
② 作为环境变量（所有键）
spec:containers:- name: apiimage: my-api:v1.0envFrom:- configMapRef:name: api-config # 所有键都注入为环境变量
Pod 内看到的：
echo $log_level
# infoecho $redis_host
# redis-serviceecho $cache_ttl
# 3600
注意：键名会自动转换为环境变量格式（大写、下划线）
③ 作为文件挂载（单个文件）
spec:containers:- name: redisimage: redis:7-alpinevolumeMounts:- name: configmountPath: /etc/redis/redis.confsubPath: redis.conf # 只挂载一个文件volumes:- name: configconfigMap:name: redis-config
Pod 内看到的：
cat /etc/redis/redis.conf
# bind 0.0.0.0
# port 6379
# maxmemory 128mb
④ 作为目录挂载（所有键）
spec:containers:- name: appimage: my-app:v1.0volumeMounts:- name: configmountPath: /etc/config # 挂载为目录volumes:- name: configconfigMap:name: api-config
Pod 内看到的：
ls /etc/config/
# cache_ttl
# enable_cache
# log_level
# redis_host
# redis_portcat /etc/config/log_level
# info
每个键变成一个文件！
三、Secret：管理敏感数据
3.1 什么是 Secret？
Secret = 加密存储的键值对
┌───────────────────────────┐
│ Secret │
│ │
│ username: YWRtaW4= │ ← Base64 编码
│ password: cGFzc3dvcmQ= │
│ │
└───────────────────────────┘
与 ConfigMap 的区别：
| 特性 | ConfigMap | Secret |
|---|---|---|
| 用途 | 配置数据 | 敏感数据 |
| 存储 | 明文 | Base64 编码 |
| 大小限制 | 1MB | 1MB |
| 加密 | 不支持 | 可启用加密存储 |
| 权限控制 | 一般 | 更严格（RBAC） |
3.2 创建 Secret
方法 1：从字面量创建
kubectl create secret generic db-secret \--from-literal=username=admin \--from-literal=password=mySecretPassword123
查看：
kubectl get secret db-secret -o yaml
apiVersion: v1
kind: Secret
metadata:name: db-secret
type: Opaque
data:username: YWRtaW4= # Base64("admin")password: bXlTZWNyZXRQYXNzd29yZDEyMw== # Base64("mySecretPassword123")
方法 2：从文件创建
# SSH 私钥
kubectl create secret generic ssh-key \--from-file=ssh-privatekey=~/.ssh/id_rsa# TLS 证书
kubectl create secret tls tls-secret \--cert=path/to/tls.cert \--key=path/to/tls.key
方法 3：从 YAML 创建（手动 Base64 编码）
apiVersion: v1
kind: Secret
metadata:name: db-secret
type: Opaque
data:username: YWRtaW4= # echo -n "admin" | base64password: bXlTZWNyZXRQYXNzd29yZDEyMw==
或使用 stringData（自动编码）：
apiVersion: v1
kind: Secret
metadata:name: db-secret
type: Opaque
stringData: # 不需要手动 Base64username: adminpassword: mySecretPassword123
kubectl apply -f secret.yaml
3.3 使用 Secret
使用方式和 ConfigMap 一样：
① 作为环境变量
env:
- name: DB_USERNAMEvalueFrom:secretKeyRef:name: db-secretkey: username- name: DB_PASSWORDvalueFrom:secretKeyRef:name: db-secretkey: password
② 作为文件挂载
volumeMounts:
- name: db-credsmountPath: /etc/db-credsreadOnly: true # 只读，更安全volumes:
- name: db-credssecret:secretName: db-secret
Pod 内：
ls /etc/db-creds/
# username
# passwordcat /etc/db-creds/password
# mySecretPassword123 ← 自动解码
3.4 Secret 的加密存储
默认情况：Secret 只是 Base64 编码，不是加密！
# 任何人都可以解码
echo "YWRtaW4=" | base64 -d
# admin
启用加密存储（推荐）：
K8s 支持 Encryption at Rest（静态加密），配置后：
- Secret 在 etcd 中加密存储
- 只有 K8s API Server 能解密
- 即使攻击者拿到 etcd 备份，也无法读取 Secret
配置方法（需要集群管理员权限）：
# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:- resources:- secretsproviders:- aescbc:keys:- name: key1secret: <base64-encoded-32-byte-key>- identity: {} # 回退到不加密
这是生产环境必须配置的！
四、实战案例：API 服务配置
4.1 配置需求分析
我的 API 服务需要：
- Redis 地址和端口
- 日志级别
- 缓存 TTL
- 特性开关
这些配置需要：
- ✅ 不同环境不同值（开发/生产）
- ✅ 修改后不重新构建镜像
- ✅ 集中管理
4.2 创建 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:name: api-configlabels:app: apiversion: v0.2
data:# 应用配置log_level: "info"app_env: "production"# Redis 配置redis_host: "redis-service"redis_port: "6379"# 缓存配置cache_ttl: "3600" # 默认 1 小时# 性能配置max_connections: "100"# 特性开关enable_cache: "true"enable_metrics: "true"
kubectl apply -f k8s/v0.2/api/configmap.yaml
4.3 注入到 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:name: api-server
spec:replicas: 2template:spec:containers:- name: apiimage: cloudnative-go-api:v0.2# 环境变量（从 ConfigMap 注入）env:- name: APP_ENVvalueFrom:configMapKeyRef:name: api-configkey: app_env- name: LOG_LEVELvalueFrom:configMapKeyRef:name: api-configkey: log_level- name: REDIS_HOSTvalueFrom:configMapKeyRef:name: api-configkey: redis_host- name: REDIS_PORTvalueFrom:configMapKeyRef:name: api-configkey: redis_port- name: CACHE_TTLvalueFrom:configMapKeyRef:name: api-configkey: cache_ttl
4.4 应用代码读取配置
package configimport ("os""strconv"
)type Config struct {AppEnv stringLogLevel stringRedisHost stringRedisPort intCacheTTL intEnableCache boolEnableMetrics bool
}func LoadConfig() *Config {return &Config{AppEnv: getEnv("APP_ENV", "development"),LogLevel: getEnv("LOG_LEVEL", "debug"),RedisHost: getEnv("REDIS_HOST", "localhost"),RedisPort: getEnvInt("REDIS_PORT", 6379),CacheTTL: getEnvInt("CACHE_TTL", 3600),EnableCache: getEnvBool("ENABLE_CACHE", true),EnableMetrics: getEnvBool("ENABLE_METRICS", true),}
}func getEnv(key, defaultValue string) string {if value := os.Getenv(key); value != "" {return value}return defaultValue
}func getEnvInt(key string, defaultValue int) int {if value := os.Getenv(key); value != "" {if intValue, err := strconv.Atoi(value); err == nil {return intValue}}return defaultValue
}func getEnvBool(key string, defaultValue bool) bool {if value := os.Getenv(key); value != "" {return value == "true"}return defaultValue
}
使用：
func main() {cfg := config.LoadConfig()fmt.Printf("环境: %s\n", cfg.AppEnv)fmt.Printf("日志级别: %s\n", cfg.LogLevel)fmt.Printf("Redis: %s:%d\n", cfg.RedisHost, cfg.RedisPort)
}
五、实战案例：CronJob 配置
5.1 定时任务需求
需求：每小时清理 Redis 的过期键
配置需求：
- 调度时间（Cron 表达式）
- Redis 地址
- 任务超时时间
- 失败重试次数
- 历史记录保留数量
5.2 CronJob 配置详解
apiVersion: batch/v1
kind: CronJob
metadata:name: cleanup-joblabels:app: cleanup-job
spec:# Cron 调度表达式schedule: "0 * * * *" # 每小时的第0分钟# 历史保留限制successfulJobsHistoryLimit: 3 # 保留 3 个成功的failedJobsHistoryLimit: 1 # 保留 1 个失败的# 并发策略concurrencyPolicy: Forbid # 禁止并发# 启动截止时间startingDeadlineSeconds: 100 # 错过100秒就跳过# Job 模板jobTemplate:spec:# 完成后 1 小时删除 PodttlSecondsAfterFinished: 3600# 失败重试次数backoffLimit: 3# 任务超时时间（5分钟）activeDeadlineSeconds: 300template:spec:restartPolicy: OnFailurecontainers:- name: cleanupimage: cleanup-job:v0.2env:# Redis 地址- name: REDIS_HOSTvalue: "redis-service:6379"# Job 信息- name: JOB_NAMEvalueFrom:fieldRef:fieldPath: metadata.nameresources:requests:memory: "64Mi"cpu: "50m"limits:memory: "128Mi"cpu: "100m"
5.3 调度表达式
Cron 格式：
┌───────────── 分钟 (0 - 59)│ ┌───────────── 小时 (0 - 23)│ │ ┌───────────── 日 (1 - 31)│ │ │ ┌───────────── 月 (1 - 12)│ │ │ │ ┌───────────── 星期 (0 - 6) (0 = 周日)│ │ │ │ │* * * * *
常用示例：
| 表达式 | 说明 | 场景 |
|---|---|---|
*/5 * * * * | 每 5 分钟 | 频繁清理 |
0 * * * * | 每小时 | 常规清理 |
0 2 * * * | 每天凌晨 2 点 | 数据库备份 |
0 0 * * 0 | 每周日凌晨 | 周报生成 |
0 0 1 * * | 每月 1 号凌晨 | 月度统计 |
0 9-17 * * 1-5 | 工作日 9-17 点每小时 | 工作时间任务 |
5.4 并发策略
concurrencyPolicy 控制并发行为：
| 策略 | 说明 | 适用场景 |
|---|---|---|
Allow | 允许并发执行（默认） | 独立任务（日志归档） |
Forbid | 禁止并发，跳过新任务 | 数据库备份（避免冲突） |
Replace | 取消旧任务，启动新任务 | 实时报表（只要最新） |
示例：数据库备份
spec:schedule: "0 2 * * *" # 每天 2 点concurrencyPolicy: Forbid # 如果上次备份还没完成，跳过
为什么？
- 备份任务耗时长（可能超过 1 天）
- 并发备份会导致数据库负载过高
- 同时备份会冲突（写同一个文件）
六、配置的动态更新
6.1 ConfigMap 更新
# 方法 1：编辑 ConfigMap
kubectl edit configmap api-config# 方法 2：替换 ConfigMap
kubectl apply -f configmap.yaml# 方法 3：打补丁
kubectl patch configmap api-config \-p '{"data":{"log_level":"debug"}}'
6.2 应用如何感知更新？
① 环境变量方式：不会自动更新
env:
- name: LOG_LEVELvalueFrom:configMapKeyRef:name: api-configkey: log_level
更新 ConfigMap 后：
# 修改 ConfigMap
kubectl patch configmap api-config -p '{"data":{"log_level":"debug"}}'# Pod 内查看
kubectl exec -it api-server-xxx -- env | grep LOG_LEVEL
# LOG_LEVEL=info ← 还是旧值！
原因：环境变量在 Pod 启动时注入，不会动态更新！
② 文件挂载方式：会自动更新（有延迟）
volumeMounts:
- name: configmountPath: /etc/configvolumes:
- name: configconfigMap:name: api-config
更新 ConfigMap 后：
# 修改 ConfigMap
kubectl patch configmap api-config -p '{"data":{"log_level":"debug"}}'# 等待 1-2 分钟
sleep 120# Pod 内查看
kubectl exec -it api-server-xxx -- cat /etc/config/log_level
# debug ← 新值！
K8s 会自动同步，但有延迟（最多几分钟）
6.3 强制更新 Pod
如果希望立即生效：
方法 1：重启 Pod
kubectl rollout restart deployment api-server
方法 2：给 ConfigMap 添加版本号
# configmap-v2.yaml
apiVersion: v1
kind: ConfigMap
metadata:name: api-config-v2 # 新名称
data:log_level: "debug"
# deployment.yaml
env:
- name: LOG_LEVELvalueFrom:configMapKeyRef:name: api-config-v2 # 引用新 ConfigMapkey: log_level
kubectl apply -f configmap-v2.yaml
kubectl apply -f deployment.yaml # 触发滚动更新
方法 3：给 Deployment 添加 ConfigMap 的 Hash（自动触发更新）
# 计算 ConfigMap 的 Hash
CONFIG_HASH=$(kubectl get configmap api-config -o json | md5sum | cut -d' ' -f1)# 添加到 Deployment 的 annotations
kubectl patch deployment api-server -p \"{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"configmap-hash\":\"$CONFIG_HASH\"}}}}}"
每次 ConfigMap 改变，Hash 变化，触发滚动更新！
七、最佳实践
7.1 配置分层
不要把所有配置放在一个 ConfigMap：
# ❌ 不推荐：所有配置混在一起
apiVersion: v1
kind: ConfigMap
metadata:name: all-config
data:log_level: inforedis_host: redis-servicedb_password: password123 # 敏感信息！nginx_conf: |...
✅ 推荐：分层管理
# 通用配置
apiVersion: v1
kind: ConfigMap
metadata:name: common-config
data:log_level: infoapp_env: production---
# Redis 配置
apiVersion: v1
kind: ConfigMap
metadata:name: redis-config
data:redis_host: redis-serviceredis_port: "6379"---
# 敏感数据（Secret）
apiVersion: v1
kind: Secret
metadata:name: db-secret
stringData:password: password123
7.2 命名规范
推荐命名：
<service>-<type>-<env>示例：api-config-prod # API 服务的生产配置api-config-dev # API 服务的开发配置redis-config # Redis 配置db-secret # 数据库密钥
7.3 版本管理
方案 1：在名称中包含版本
metadata:name: api-config-v2
好处：
- 可以同时存在多个版本
- 回滚简单（切换引用）
坏处：
- 要修改 Deployment 引用
方案 2：在 ConfigMap 中记录版本
metadata:name: api-configlabels:version: v2
data:version: "v2"log_level: info
好处：
- 不需要修改 Deployment
- 可以在应用中读取版本号
7.4 安全建议
① Secret 不要提交到 Git
# .gitignore
*-secret.yaml
secret*.yaml
或使用加密工具（如 Sealed Secrets）
② 使用 RBAC 限制访问
# 只允许特定 ServiceAccount 读取 Secret
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: secret-reader
rules:
- apiGroups: [""]resources: ["secrets"]resourceNames: ["db-secret"]verbs: ["get"]
③ 启用 Secret 加密存储
# 生产环境必须启用！
# 配置 API Server 的 --encryption-provider-config
④ 定期轮换密钥
# 每季度更新一次数据库密码
kubectl create secret generic db-secret \--from-literal=password=newPassword123 \--dry-run=client -o yaml | kubectl apply -f -# 重启 Pod 使其生效
kubectl rollout restart deployment api-server
八、常见问题排查
8.1 ConfigMap 不存在
症状：
kubectl get pods
# NAME READY STATUS RESTARTS AGE
# api-server-xxx 0/1 CreateContainerError 0 10s
日志：
kubectl describe pod api-server-xxx
# Events:
# Warning Failed Error: configmap "api-config" not found
解决：
# 检查 ConfigMap 是否存在
kubectl get configmap api-config# 如果不存在，创建它
kubectl apply -f configmap.yaml
8.2 配置未生效
症状：修改了 ConfigMap，应用还是读取旧值
排查：
# 1. 确认 ConfigMap 已更新
kubectl get configmap api-config -o yaml# 2. 检查使用方式
kubectl get deployment api-server -o yaml | grep -A10 "env:"# 3. 如果是环境变量方式，需要重启 Pod
kubectl rollout restart deployment api-server
8.3 Secret 解码失败
症状：
kubectl logs api-server-xxx
# Error: invalid character in password
原因：Base64 编码错误
# 检查 Secret
kubectl get secret db-secret -o yaml
# data:
# password: bXlTZWNyZXRQYXNzd29yZDEyMw==# 手动解码测试
echo "bXlTZWNyZXRQYXNzd29yZDEyMw==" | base64 -d
# mySecretPassword123
如果解码失败，重新创建 Secret：
kubectl delete secret db-secretkubectl create secret generic db-secret \--from-literal=password=mySecretPassword123
九、ConfigMap vs Secret vs 环境变量
| 方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| ConfigMap | 集中管理、易于更新、支持文件 | 明文存储 | 配置数据（非敏感） |
| Secret | 加密存储、权限控制 | 使用复杂 | 密码、Token、证书 |
| 环境变量 | 简单直接 | 分散管理、不能动态更新 | 简单配置、调试 |
| 文件 | 格式自由、支持复杂配置 | 需要挂载卷 | 配置文件（nginx.conf） |
推荐组合：
# 简单配置 → 环境变量（从 ConfigMap）
env:
- name: LOG_LEVELvalueFrom:configMapKeyRef:name: api-configkey: log_level# 复杂配置 → 文件挂载（从 ConfigMap）
volumeMounts:
- name: nginx-configmountPath: /etc/nginx/nginx.confsubPath: nginx.confvolumes:
- name: nginx-configconfigMap:name: nginx-config# 敏感数据 → Secret
env:
- name: DB_PASSWORDvalueFrom:secretKeyRef:name: db-secretkey: password
结语
这篇文章，我学会了：
✅ ConfigMap：管理配置数据
- 创建 ConfigMap 的 3 种方法
- 使用 ConfigMap 的 4 种方式
- 配置集中管理、易于更新
✅ Secret：管理敏感数据
- Base64 编码（不是加密）
- 启用加密存储（生产必须）
- RBAC 权限控制
✅ CronJob：定时任务配置
- Cron 表达式
- 并发策略（Allow/Forbid/Replace）
- 历史记录管理
✅ 动态更新配置
- 环境变量不会自动更新（需重启）
- 文件挂载会自动更新（有延迟）
- 强制更新的 3 种方法
✅ 最佳实践
- 配置分层（不要混在一起）
- 命名规范（service-type-env）
- 版本管理（v1, v2）
- 安全建议（加密、RBAC、轮换）
最大的收获：
不要把配置写死在代码里！
ConfigMap 管理配置，Secret 管理密钥！
配置和代码分离，才能灵活部署！
v0.2 完结！
在 v0.2 中，我学会了：
- K8s 工作负载全景：Deployment、StatefulSet、DaemonSet、CronJob
- StatefulSet 部署 Redis：持久化存储、Headless Service
- DaemonSet 日志采集器：节点级服务、访问宿主机
- ConfigMap 和 Secret：配置管理、敏感数据
下一步（v0.3 预告）：
v0.3 将学习 高级网络和存储：
- Ingress（统一入口）
- NetworkPolicy（网络隔离）
- StorageClass（动态存储）
- 监控和日志（Prometheus + Grafana）
敬请期待！
如果这篇文章对你有帮助，欢迎点赞、收藏、分享！
有问题欢迎在评论区讨论！ 👇