上k8s生产环境的准备_vlambda技术博客

一般

应用程序的名称、描述、用途和拥有团队被清楚地记录在案（例如通过服务树）

定义应用程序的关键级别（例如，如果应用程序对业务非常关键，则为“关键链路程序”）

开发团队对k8s技术栈有足够的知识/经验，比如服务无状态等

确定并通知负责的 24/7 待命团队

存在上线计划，包括（潜在回滚的步骤）

应用

应用程序的代码库 (git) 有关于如何开发、如何配置以及如何更改的明确说明（对于紧急修复很重要）

代码依赖被固定（即修补程序更改不会意外引入新库）

遵循OpenTracing/OpenTelemetry语义约定

所有发起的 HTTP 调用都定义超时时间

HTTP 连接池根据预期流量配置合理的值

线程池或非阻塞异步代码已正确实现与配置

redis，数据库连接池配置大小正确

为依赖服务实施重试和重试策略（例如退避抖动）

根据业务需求定义的回滚机制

实施了减载/速率限制机制（可能是提供的基础设施的一部分）

应用程序指标公开以供收集（例如由 Prometheus 抓取）

应用程序日志转到 stdout/stderr

应用程序日志遵循良好的实践（例如结构化日志记录、有意义的消息）、明确定义日志级别，并且默认情况下对生产禁用调试日志记录（可以选择打开）

应用程序容器因致命错误而崩溃（即它没有进入某些不可恢复的状态或死锁）

应用程序设计与代码由高级工程师审查

安全与合规

应用程序可以作为非特权用户（非 root）运行

应用程序不需要可写的容器文件系统（即可以只读挂载）

HTTP 请求经过身份验证和授权（例如使用 OAuth）

缓解拒绝服务 (DOS) 攻击的机制已经到位（例如入口速率限制、WAF）

进行了安全审计

代码/依赖项的自动漏洞检查已经到位

处理后的数据被理解、分类（例如 PII）并记录在案

已创建威胁模型并记录风险

遵循其他适用的组织规则和合规标准

持续集成/持续交付

每次更改都会自动运行

自动化测试是交付管道的一部分

生产部署不需要手动操作

所有相关团队成员都可以部署和回滚

生产部署有冒烟测试和可选的自动回滚

从代码提交到生产的前置时间很快（例如 15 分钟或更短，包括测试运行）

Kubernetes

开发团队受过 Kubernetes 主题培训，了解相关概念

Kubernetes 清单使用最新的 API 版本（例如，用于部署的apps/v1）

容器以非 root 用户身份运行并使用只读文件系统

定义了适当的就绪探针

未使用 Liveness Probe，或者使用 Liveness Probe 有明确的理由

Kubernetes 部署至少有两个副本

如果足够，则配置水平自动缩放 (HPA)

根据性能与负载测试设置内存和 CPU 请求

内存限制等于内存请求（避免内存过度使用）

未设置 CPU 限制或 CPU 节流的影响很好理解

为容器环境正确配置了应用程序（例如 JVM 堆、单线程运行时、非容器感知的运行时）

每个容器运行单个应用程序进程

应用程序可以在不中断的情况下处理正常关闭和滚动更新

如果应用程序不处理正常终止，则使用Pod Lifecycle Hook（例如preStop 中的“sleep 20” ）

设置所有必需的 Pod 标签

应用程序设置为高可用性：Pod 分布在故障域或应用程序部署到多个集群

Kubernetes Service 为 pod 使用正确的标签选择器（例如，不仅匹配“应用程序”标签，还匹配“组件”和“环境”以供将来扩展）

可选：根据需要使用容忍（例如将 pod 绑定到特定的节点池）

监控

收集了四个黄金信号的指标

收集应用程序指标（例如通过 Prometheus 抓取）

将数据库（例如 PostgreSQL 数据库）受到监控

SLO 已定义

存在监控仪表板（例如 Grafana）（可以自动设置）

警报规则是根据影响而不是潜在原因定义的

24/7 服务团队

所有相关的 24/7服务团队都被告知上线（例如其他团队、SRE 或其他角色，如事件指挥官）

24/7 服务团队对应用程序和业务环境有足够的了解

24/7 服务团队拥有必要的生产访问权限（例如 kubectl、kube-web-view、应用程序日志）

24/7 服务团队拥有解决技术堆栈（例如 JVM）生产问题的专业知识

24/7 服务团队经过培训并有信心执行标准操作（扩展、回滚等）

设置了呼叫 24/7 服务团队的监控警报

告警自动升级规则已到位（例如，在 10 分钟后没有确认升级高级级别）

存在进行事后分析和传播事件学习的过程

定期进行应用程序与操作审查（例如查看 SLO 违规情况）

vlambda博客
学习文章列表