Kubernetes生产环境必须坚持规范优先：命名标签结构化、镜像安全基线严格、资源requests/limits成对设置、日志监控闭环、SLO驱动运维。
在 Kubernetes 生产环境中，稳定、安全、可维护比“跑起来”重要得多。很多团队踩过坑才意识到：规范不是束缚，而是避免半夜被报警叫醒的底线。
命名与标签必须结构化
资源命名不能靠直觉，标签（Labels）更不是可选项。所有 Pod、Deployment、Service、Namespace 都要遵循统一前缀+业务域+环境的命名模式，例如 app-prod-payment-api；关键标签至少包含 app、env、team、version 四个维度。没有标签的资源等于“黑盒”，无法做自动化调度、监控聚合、权限隔离和成本分摊。
- 禁止使用 default 命名空间部署业务应用，每个团队/项目独占独立 Namespace
- Label value 中避免空格、下划线、大写字母，统一用小写短横线（kebab-case）
- 通过准入控制器（如 OPA 或 Kyverno）强制校验命名与标签策略，而非依赖人工约定
容器镜像与安全基线不可妥协
生产镜像必须来自可信仓库（如私有 Harbor），且满足最小化原则：基础镜像用 distroless 或 Alpine（非 Ubuntu/CentOS），关闭 shell、包管理器和非必要二进制；镜像需静态扫描（Trivy / Grype），阻断 CVE-2023 及以上严重漏洞；运行时以非 root 用户启动（设置 runAsNonRoot: true + runAsUser），并禁用 CAP_SYS_ADMIN 等高危能力。
- 禁止在 Dockerfile 中使用 latest 标签，镜像 tag 必须绑定 Git Commit SHA 或语义化版本号
- 启用镜像签名（Cosign）与验证策略，防止中间人篡改或误拉取未审核镜像
- Secret 不进镜像、不进代码库；ConfigMap 和 Secret 挂载路径需显式声明 readOnly: true
资源限制与弹性必须配对设置
只设 requests 不设 limits = 资源争抢；只设 limits 不设 requests = 调度失败。CPU 和内存的 requests/limits 必须成对出现，且 ratio 合理：内存 limit ≥ request × 1.3（预留 GC 和突发缓冲），CPU limit ≤ request × 2（防过度超卖）。同时开启 HorizontalPodAutoscaler（HPA），但指标必须基于真实业务压力（如 QPS、队列长度），而非 CPU 使用率这种易受干扰的指标。
- 为关键服务设置 PodDisruptionBudget（PDB），保障滚动更新或节点维护时最小可用副本数
- LimitRange 和 ResourceQuota 必须在 Namespace 级别启用，防止单个团队耗尽集群资源
- 定期用 kubectl top nodes/pods + metrics-server 数据反查实际用量，动态调优 requests/limits
日志、监控与故障响应要闭环
日志不落地 = 无从排查；监控无告警 = 问题已爆发。所有容器 stdout/stderr 必须输出结构化 JSON 日志（如 logfmt 或 ECS 兼容格式），由 DaemonSet（如 Fluent Bit）统一采集到 Loki 或 ELK；核心指标（pod restarts、container cpu/memory usage、ingress 5xx rate）接入 Prometheus，并配置分级告警（warning / critical）到企业微信/钉钉；每次故障后必须生成 RCA 报告，归档至内部 Wiki，并同步更新对应的 SLO 文档与应急预案。
- 禁止在容器内写日志文件到磁盘，避免填满根分区或影响 PVC 生命周期
- Prometheus scrape interval ≤ 30s，但 long-term 存储用 Thanos 或 Cortex 做降采样与压缩
- 每个微服务必须定义明确的 SLO（如 99.9% 请求延迟
规范不是一次性文档，而是随集群演进持续校准的活契约。真正落地的关键，是把检查项嵌入 CI/CD 流水线和集群准入流程里——让错误在上线前就被拦截，而不是在凌晨三点靠经验盲猜。
