上一篇【第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用独立SARoleBinding ☐ 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有监控(延迟/错误率/饱和度) ☐ 分布式追踪(可选, IstioJaeger, 第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/LB061/081安全RBAC/NetworkPolicy/PSA/Secret加密/镜像扫描052-059监控Prometheus/Grafana/AlertManager/日志075/076备份etcd快照/Velero/演练082资源requests/limits/QoS/Quota/HPA025/029-032网络CNI/CoreDNS/Ingress/TLS043-51上线压测/混沌/回滚/文档/Oncall全系列本篇小结这份生产就绪清单把前85篇串成了上线前的验收标准高可用多master奇数etcd跨AZLB、安全RBACNetworkPolicyPSASecret加密镜像扫描、可观测PrometheusGrafanaAlertManager日志、备份etcd快照Velero演练、资源治理requests/limitsQoSQuotaHPA、网络CNICoreDNSIngressTLS。上线前还要做负载测试、混沌工程验证自愈、明确回滚方案、文档和Oncall齐备。“能跑≠能上生产”——逐项打勾再放行。运维模块到此通关。下篇进入实战案例与前沿先讲微服务应用K8s化改造。上一篇【第85篇】K8s成本优化——你的云账单一半都能省掉老板看了想加鸡腿下一篇【第87篇】微服务应用K8s化改造实战——从传统部署到云原生 【Kubernetes从入门到精通】第86篇：生产就绪检查清单——你的K8s集群真的可以上线吗
上一篇【第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用独立SARoleBinding ☐ 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有监控(延迟/错误率/饱和度) ☐ 分布式追踪(可选, IstioJaeger, 第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/LB061/081安全RBAC/NetworkPolicy/PSA/Secret加密/镜像扫描052-059监控Prometheus/Grafana/AlertManager/日志075/076备份etcd快照/Velero/演练082资源requests/limits/QoS/Quota/HPA025/029-032网络CNI/CoreDNS/Ingress/TLS043-51上线压测/混沌/回滚/文档/Oncall全系列本篇小结这份生产就绪清单把前85篇串成了上线前的验收标准高可用多master奇数etcd跨AZLB、安全RBACNetworkPolicyPSASecret加密镜像扫描、可观测PrometheusGrafanaAlertManager日志、备份etcd快照Velero演练、资源治理requests/limitsQoSQuotaHPA、网络CNICoreDNSIngressTLS。上线前还要做负载测试、混沌工程验证自愈、明确回滚方案、文档和Oncall齐备。“能跑≠能上生产”——逐项打勾再放行。运维模块到此通关。下篇进入实战案例与前沿先讲微服务应用K8s化改造。上一篇【第85篇】K8s成本优化——你的云账单一半都能省掉老板看了想加鸡腿下一篇【第87篇】微服务应用K8s化改造实战——从传统部署到云原生