1. ConfigMap：把配置从镜像里拽出来
配置进镜像 = 每改一次配置就要重建镜像。ConfigMap 把键值对或整文件交给 Pod 使用，常见两种方式：
- 环境变量：envFrom / valueFrom。启动时注入；进程要自己支持重读才能「热更」。
- 卷挂载：挂载为目录下文件。更新 ConfigMap 后，kubelet 会同步文件（有延迟）；应用需 watch 文件或周期性重载。
注意：单个 ConfigMap 建议控制在合理大小（官方约 1Mi 量级）；超大配置考虑拆对象或配置中心。
图 1：ConfigMap 可走 env 或 volume；Secret 同理。env 是启动快照，volume 更适合证书文件与需轮换的凭据。
2. Secret：必须配合「权限与加密」一起谈
API 里 Secret 的 data 字段是 base64——这是传输/存储格式，不是加密。能 kubectl get secret -o yaml 的人就能解码。 正经做法包括：RBAC 限制谁可读 Secret、集群启用 etcd 加密、生产用 Vault / 云 KMS / External Secrets Operator 把真正密钥放在集群外同步进来。
- 不要把 Secret 打进镜像层或 Git。
- 应用日志、错误栈、探针响应里不要打印环境变量全集。
- 按命名空间隔离；跨 namespace 引用要显式设计。
3. requests 与 limits：调度、QoS 与 OOM
requests：调度器用来选节点——「这台机器还剩多少可分配资源」。不设 requests 可能导致所有 Pod 堆在同一节点，最后一起 OOM。
limits：运行时硬顶。CPU 超限倾向节流（变慢）；内存超限会被 cgroup OOMKill（容器重启）。
QoS 大类（简化）：requests=limits → Guaranteed；只设其一或不等 → Burstable；都没设 → BestEffort（节点压力下最先被驱逐）。
实践：至少为内存设 requests；limits 略高于 requests 给一点突发；Java/Go 等要配合 JVM/GOMAXPROCS 理解，避免 limit 与进程自认 CPU 数不一致。
图 2：requests 决定「能否调度上去、占多少账」；limits 决定「跑起来能不能突破」。内存超 limit 即 OOM。
4. HPA：按指标自动扩缩副本
HorizontalPodAutoscaler 根据 CPU 利用率（或自定义指标如 QPS、队列深度）在 minReplicas～maxReplicas 之间调整 Deployment 副本数。 需要 metrics-server（或自定义 metrics API）。扩缩行为可用 behavior 配置，避免「抖动扩缩」。
图 3：HPA 持续采集指标，调整 Deployment 副本；缩容常需 stabilization window 防止抖动。
5. 最小清单
- 非敏感 → ConfigMap；敏感 → Secret + RBAC + 外部密钥（进阶）。
- 大配置/热更 → volume；简单开关 → env。
- 每个工作负载设 memory requests；生产设 limits 与探针。
- 有流量波动 → HPA + 合理 min/max + behavior。