上 k8s 生产环境的一些准备！

2022-04-24 00:00:00 团队 运行 服务 应用程序 容器


来源：公众号 | 运维开发故事（mygsdcsf）

在生产中运行应用程序可能很棘手。这篇文章提出了一个自以为是的清单，用于在 Kubernetes 上使用 Web 服务（即应用程序公开 HTTP API）进入生产环境。

一般

  • 应用程序的名称、描述、用途和拥有团队被清楚地记录在案（例如通过服务树）
  • 定义应用程序的关键级别（例如，如果应用程序对业务非常关键，则为“关键链路程序”）
  • 开发团队对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）（可以自动设置）
  • 警报规则是根据影响而不是潜在原因定义的

测试

  • 断点测试（系统/混沌测试）
  • 执行负载测试以反映预期的流量模式
  • 测试了数据存储（如 PostgreSQL 数据库）的备份和恢复

24/7 服务团队

  • 所有相关的 24/7服务团队都被告知上线（例如其他团队、SRE 或其他角色，如事件指挥官）
  • 24/7 服务团队对应用程序和业务环境有足够的了解
  • 24/7 服务团队拥有必要的生产访问权限（例如 kubectl、kube-web-view、应用程序日志）
  • 24/7 服务团队拥有解决技术堆栈（例如 JVM）生产问题的专业知识
  • 24/7 服务团队经过培训并有信心执行标准操作（扩展、回滚等）
  • 设置了呼叫 24/7 服务团队的监控警报
  • 告警自动升级规则已到位（例如，在 10 分钟后没有确认升级级别）
  • 存在进行事后分析和传播事件学习的过程
  • 定期进行应用程序与操作审查（例如查看 SLO 违规情况）


相关文章