上一篇【第85篇】K8s成本优化——你的云账单一半都能省掉，老板看了想加鸡腿
下一篇【第87篇】微服务应用K8s化改造实战——从传统部署到云原生
摘要
前面85篇把K8s的方方面面都讲透了。最后这篇运维模块收官——把它们汇总成一份**“生产就绪检查清单”**，上线前逐项打勾。
一个集群"能跑"和"能上生产"之间差着十万八千里：高可用配了吗？安全策略开了吗？监控告警有吗？备份能恢复吗？这份清单就是"上线前的最后一道关"。
一、高可用架构
1.1 控制平面
【高可用检查】 ☐ 多个控制平面节点(3或5, 奇数) → 单master是"玩具配置", 生产必须多master ☐ etcd 集群 3/5 节点(奇数, 同机房低延迟, 第061篇) → etcd数据盘用SSD ☐ 控制平面组件跨节点/跨AZ分布 → 别都挤在一个物理机/可用区 ☐ API Server 前有负载均衡器(HAProxy/云LB) → kubectl的server指向LB, 不是单个master ☐ kube-apiserver证书有效期监控(年更坑, 第084篇)1.2 工作节点
☐ 工作节点 ≥ 3 (避免单点) ☐ 节点跨可用区分布(防止AZ故障全挂) ☐ 节点有自动修复(云厂商Node Auto Repair) ☐ 节点有自动伸缩(第085篇 CA/Karpenter) ☐ 关键应用多副本 + PodAntiAffinity打散(第027篇) → 避免同一应用Pod都在一个节点二、安全
2.1 四道防线
【安全检查(对应第052-059篇)】 ☐ RBAC 最小权限(第053篇) → 没有随便给cluster-admin → CI/CD用独立SA+RoleBinding ☐ NetworkPolicy 默认拒绝+按需放通(第047/056篇) → 关键ns有微隔离 → 用支持策略的CNI(Calico/Cilium) ☐ Pod Security Standards 强制(第058篇) → 业务ns至少baseline, 高安全用restricted ☐ Secret 不裸奔(第057篇) → etcd加密 / Vault / Sealed / External Secrets ☐ 镜像安全(第059篇) → CI里Trivy扫描, 挡漏洞/Critical → 不用latest标签(用digest或固定版本) ☐ API Server 安全(第052篇) → 匿名认证关闭 → 审计日志开启 ☐ kubeconfig 权限管控(谁有集群管理员?)三、监控与告警
3.1 可观测性
【监控检查(第075/076篇)】 ☐ Prometheus + Node Exporter + Kube-State-Metrics 已部署 ☐ Grafana 有核心大盘(Node/Pod/集群/应用) ☐ 日志集中收集(EFK/PLG) ☐ AlertManager 配置告警规则 → 节点NotReady / Pod CrashLoop / 资源压力 / 证书过期 ☐ 告警能真正通知到人(钉钉/Slack/邮件/电话) ☐ 关键SLO有监控(延迟/错误率/饱和度) ☐ 分布式追踪(可选, Istio+Jaeger, 第077篇)四、备份与灾备
4.1 保命设施
【备份检查(第082篇)】 ☐ etcd 定时快照 + 异地存储 → 每天1次 + 升级前手动 ☐ Velero 定时备份(资源+YAML+关键PV) ☐ 备份恢复演练做过(不演练=没备份!) → RTO/RPO 符合业务要求 ☐ 数据库有独立逻辑备份(mysqldump/PG) ☐ 灾难恢复Runbook文档化(谁、怎么做、联系谁)五、资源治理
5.1 不让集群失控
【资源治理检查(第029-032篇)】 ☐ 所有Deployment设了 requests + limits(第029篇) → 不设requests=节点被虚假占满 ☐ 用 QoS 分级(第030篇) → 核心服务 Guaranteed ☐ LimitRange 设默认requests/limits(第031篇) → 防有人不设置 ☐ ResourceQuota 限制团队资源池(第032篇) → 多团队防互相挤占 ☐ HPA 配了(第025篇) → 流量波动自动扩缩 ☐ 资源使用有监控和优化(第085篇)六、网络
5.2 连通与出口
【网络检查(第043-051篇)】 ☐ CNI 插件运行正常(Calico/Cilium/Flannel) ☐ CoreDNS 高可用(第046篇) ☐ Ingress Controller 部署+高可用(第017/018篇) → 多副本, 不被单点 ☐ 外部流量有TLS终止+证书自动续期(cert-manager) ☐ NetworkPolicy 生效(不是用了Flannel却以为有策略) ☐ 出口流量管控(egress, 防数据泄露) ☐ 负载均衡器/网关有DDoS防护(可选)七、上线前必做
7.1 最后一道关
【Go-Live 前】 ☐ 负载测试(压测验证容量) → 知道集群/应用在多少QPS下开始降级 ☐ 混沌测试(故意杀节点/Pod, 看自愈, 第062篇) → 验证高可用真的工作 ☐ 回滚方案明确(第013篇/ArgoCD回滚, 第078篇) → 出问题怎么快速回退 ☐ 文档齐全 → 架构图/部署文档/值班手册/Oncall流程 ☐ Oncall 机制(谁值班、怎么告警、升级路径) ☐ 变更流程(重大变更走审批+窗口期) ☐ 密钥/配置分离(不硬编码, 第020/021篇)八、一份完整清单速查
| 领域 | 必做项 | 参考篇 |
|---|---|---|
| 高可用 | 多master/etcd奇数/跨AZ/LB | 061/081 |
| 安全 | RBAC/NetworkPolicy/PSA/Secret加密/镜像扫描 | 052-059 |
| 监控 | Prometheus/Grafana/AlertManager/日志 | 075/076 |
| 备份 | etcd快照/Velero/演练 | 082 |
| 资源 | requests/limits/QoS/Quota/HPA | 025/029-032 |
| 网络 | CNI/CoreDNS/Ingress/TLS | 043-51 |
| 上线 | 压测/混沌/回滚/文档/Oncall | 全系列 |
本篇小结
这份生产就绪清单把前85篇串成了"上线前的验收标准"：高可用（多master+奇数etcd+跨AZ+LB）、安全（RBAC+NetworkPolicy+PSA+Secret加密+镜像扫描）、可观测（Prometheus+Grafana+AlertManager+日志）、备份（etcd快照+Velero+演练）、资源治理（requests/limits+QoS+Quota+HPA）、网络（CNI+CoreDNS+Ingress+TLS）。
上线前还要做负载测试、混沌工程验证自愈、明确回滚方案、文档和Oncall齐备。“能跑"≠"能上生产”——逐项打勾再放行。运维模块到此通关。下篇进入实战案例与前沿，先讲微服务应用K8s化改造。
上一篇【第85篇】K8s成本优化——你的云账单一半都能省掉，老板看了想加鸡腿
下一篇【第87篇】微服务应用K8s化改造实战——从传统部署到云原生
