第 6 章 · 03 配置存储与生产运维

第 6 章 · 03 配置存储与生产运维

对象与流量都通了，生产级的最后一块拼图是"运维能力"：配置与敏感数据怎么管理、故障怎么自动发现与自愈、资源怎么限制、新版本怎么安全发布、多团队怎么隔离。本节覆盖 ConfigMap/Secret、探针、资源与 QoS、发布策略、命名空间与 RBAC、Helm/Kustomize，最后给出标准排障路径。

学习目标

• 用 ConfigMap 分离配置、用 Secret 管理敏感数据（并知道它的局限）
• 配置三种探针并理解它们的分工
• 理解 requests/limits 与 QoS 三档，知道内存超限的后果
• 掌握滚动更新与蓝绿/金丝雀部署策略
• 理解命名空间的作用域边界与 RBAC 角色体系
• 遵循标准路径排查 Pending 与 CrashLoopBackOff

一、ConfigMap 与 Secret：配置与敏感数据

ConfigMap 把配置与 Pod 分离：改配置无需重启应用或重建镜像，多个 Pod 可共享同一配置。敏感数据（凭据）不能放 ConfigMap——那是 Secret 的职责。

Secret 存储和管理敏感信息（密码、SSH 密钥）。三个必须知道的点：

Secret 不自动加密——默认没有启用加密机制，它只是"独立的存储对象"。data 字段必须 base64 编码——注意 base64 是编码不是加密，它的作用是避免明文直接出现在 YAML 文件中。创建方式：

kubectl create secret generic some-secret --from-literal=password='donttellmypassword'
kubectl create secret generic some-secret --from-file=/some/file.txt
​

在 Deployment 中引用：

spec:
  containers:
  - name: app
    env:
    - name: USER_PASSWORD
      valueFrom:
        secretKeyRef:
          name: some-secret
          key: password
​

把 Secret 提交 Git 的推荐流程：用第三方工具加密（如 kubeseal/Sealed Secrets）后提交，部署时由控制器自动解密。

二、探针三兄弟：自愈与就绪

livenessProbe（存活探针）：检查失败时重启容器——判断"这个容器还活着吗"。

livenessProbe:
  exec:
    command:
    - cat
    - /appStatus
  initialDelaySeconds: 10   # 容器启动后等 10 秒再第一次探测
  periodSeconds: 5          # 之后每 5 秒探测一次
​

readinessProbe（就绪探针）：判断容器是否准备好接收流量——探测成功才把 Pod 标记为 Ready。与 Service 配合：只有探针成功的容器才会收到发往 Service 的请求。liveness 管"要不要杀掉重启"，readiness 管"要不要放流量进来"，两者职责分离。

startupProbe（启动探针）：给慢启动容器用的"宽限窗口"——启动探针成功前不执行 liveness/readiness 探针，避免慢启动容器被 liveness 误杀。启动窗口由 failureThreshold × periodSeconds 控制。

三、资源限制与 QoS

设置 resource limits 的理由：明确应用应消耗的 CPU/内存上限，超限即异常；保证集群资源不被单一应用独占。

spec:
  containers:
  - image: python
    name: yay2
    resources:
      limits:
        cpu: 500m          # 0.5 核
        memory: 128Mi
      requests:
        cpu: 250m          # 0.25 核（调度依据）
        memory: 64Mi
​

三个关键认知：

limits 按容器设置，不按 Pod——Pod 里两个容器写 2GB limit 不是各 1GB，而是各自 2GB、合计最多 4GB。

CPU 可压缩、内存不可压缩——CPU 超限会被限流但继续运行；内存超限容器被终止（成为 OOM 候选）。所以内存 limits 是"生死线"，必须认真设置。

QoS 三档：Guaranteed（request=limit 全部设置，最高优先级）、Burstable（至少设了 request）、BestEffort（什么都不设，最低优先级）——资源紧张时先杀谁，由这个档位决定。

ResourceQuota 按命名空间限制聚合资源消耗（对象数量 + CPU/内存总量），是多团队场景的"资源上限"。

四、滚动更新与发布策略

滚动更新：改镜像后，旧 Pod 逐个终止、新 Pod 逐个创建，服务不中断；Deployment 的版本历史以 RS 为单位保留，回滚 = 切回旧 RS。

两种经典发布策略：

蓝绿（Blue/Green）：同时部署 V1 与 V2，V2 验证通过后流量整体切换。优点：任何时刻都能快速切换/回滚；缺点：新版本出问题时所有用户都受影响。

金丝雀（Canary）：部署 V2 后先切 5% 流量，表现好逐步增加到 30%、最终 100%。优点：问题只影响一小部分用户；缺点：新版本的测试必然发生在生产环境（真实用户流量）。K8s 生态中用 Argo Rollouts 等工具实现（第 8 章展开）。

五、命名空间与 RBAC

命名空间把集群拆成"虚拟集群"，按合理方式分组应用。两个关键边界：

命名空间提供作用域，不提供隔离——两个命名空间的 Pod 默认可以互通（网络隔离要靠 NetworkPolicy）；删除命名空间会级联删除其中所有资源。

默认命名空间：default（用户默认）、kube-system（系统进程）、kube-public（公开数据）、kube-node-lease（节点心跳）。集群级资源（Node、PV）不能放进命名空间——kubectl api-resources --namespaced=false 可查。

RBAC：Role 作用于命名空间级别，ClusterRole 作用于整个集群；ServiceAccount 为 Pod 内进程提供身份（创建 Pod 不指定时自动用 default）。CI/CD 流水线需要操作集群时，创建一个带足够权限的 ServiceAccount 并绑定——这是"程序身份"的标准做法。

六、Helm 与 Kustomize

Helm 是 K8s 包管理器：Chart 是 YAML 文件包，模板引擎用 {{ .Values.xxx }} 占位；helm install/upgrade/rollback/history 是核心命令；Helm 2 的 Tiller 组件因安全问题在 Helm 3 移除（纯客户端）。

Kustomize 不改动原始文件即可定制/打补丁：kustomization.yml 声明 overlay，kustomize build 生成最终清单——"原生 K8s 方式的参数化"。

七、标准排障路径

排障不是碰运气，按固定顺序来：

1. kubectl get pods（必要时 -A）看状态；
2. kubectl describe pod：关注 State（Waiting/CrashLoopBackOff）与 Last State（之前为何失败、Exit Code）与 Events；
3. kubectl logs（多容器加 -c）看容器实际输出。

Pending 排查：集群资源已满（扩容）→ ResourceQuota 达上限（调整）→ PVC 挂载 pending；-o wide 看是否分配到节点——没分配可能是 scheduler 挂了。

CrashLoopBackOff：容器反复"启动→崩溃→启动"；原因通常是配置错误（拼写/不支持的值）或资源不可用；describe + logs 定位，修复后 kubectl scale deployment --replicas=0 再调回 1 重启。

小结

本章完成了 Kubernetes 从架构到运维的闭环：控制平面与工作负载构成骨架，调度与网络打通流量，配置/探针/资源/发布策略构成生产运维工具箱，命名空间与 RBAC 提供多团队治理，排障路径沉淀为可复用的方法论。K8s 管理的是"运行中的状态"——但状态从哪来？声明式清单由谁来生成与部署？下一章回到"定义"层面：基础设施即代码。

下一节预告

第 7 章《基础设施即代码》将用 Terraform 管理云资源、用 Ansible 管理配置，理解声明式与过程式、状态文件与幂等性的哲学分野。