Kubernetes OOMKilled Runbook 实战解析以 checkout-svc 内存限值修复为例【免费下载链接】claude-cookbooksA collection of notebooks/recipes showcasing some fun and effective ways of using Claude.项目地址: https://gitcode.com/GitHub_Trending/an/claude-cookbooks本文以 Claude Cookbooks 仓库中的 SRE 值班演示为背景逐条拆解 runbooks/oom.md 这份 OOMKilled runbook 的编写逻辑与落地过程。runbook 是故障特征 → 排查路径 → 标准修复的结构化浓缩它以 exit 137 与 OOMKilled 事件为症状入口给出确认击杀来源、检查 Deployment 内存 limit、比对工作集并提升限值、约束 request 与 limit 关系的四步分诊流程。本文同时结合仓库内配套的 checkout-deploy.yaml 清单、alert.json 告警负载以及 sre_incident_responder.ipynb 的完整 agent 会话说明 runbook 如何被值班 agentSkill 机制读取、执行并收敛到只改限值、不开 PR 不热修的合规动作上。读完本文你将掌握如何识别容器 OOMKilled 的可靠信号、如何阅读 Deployment 的 resources 段判断根因、内存 request/limit 的合理配比以及这类 runbook 应如何撰写才能被人工与 Agent 共同准确执行。这份 OOMKilled runbook 在演示中扮演的角色仓库将这份 runbook 放在 SRE 事件响应演示的工作区workspace中与告警、基础设施清单并列共同构成一个自包含、无需外部服务的离线演练场景相关文件均位于managed_agents/example_data/sre/下runbooks/oom.md —— 按故障特征组织的人肉/Agent 双读排查手册本文主体infra/k8s/checkout-deploy.yaml —— 基础设施仓库中被抽查的目标清单alert.json —— 触发会话的 PagerDuty V3 风格告警事件。这份 runbook 被 sre_incident_responder.ipynb 以file类型资源挂载到会话目录runbooks/oom.md同时通过一个名为incident-runbooks的 SkillSKILL.md向 Agent 宣告团队约定runbooks 按故障特征组织如oom.md、5xx.md、latency.md每份列出该类故障的排查步骤与通常需要改动的配置任何基础设施修复都必须以引用所遵循 runbook 的 PR 形式提出禁止直接热修线上资源。 也就是说oom.md 既是给人看的文档也是 Skill 让 Agent 知道该去哪里查、按什么顺序查的路标。仓库 example_data/OVERVIEW.md 说明这类 fixture 刻意保持短小并埋有可被真正发现的问题此处即过低的 128Mi 内存 limit目的是让 Agent 有东西可推敲而非一次就成功的玩具。症状识别把 OOMKilled 从其它失败中分离出来runbook 开头用三行定义了本手册适用的故障特征集合这是按失败特征组织 runbook的核心信号来源具体表现容器退出码退出码 137exit 137Pod 事件出现OOMKilled事件应用日志出现堆耗尽heap-exhausted类错误例如OutOfMemoryError理解这些信号需要一点 Kubernetes 背景容器被杀后docker inspect/kubectl describe pod返回的退出码 137 128 9SIGKILL是 kubelet 内建 OOM killer 判死刑的标准印记而OOMKilled会作为 Pod 的 Last State Reason 出现在 Pod 事件里。真正属于本手册管辖范围的是内核/kubelet 层的内存击杀而不是 JVM/Go runtime 等应用自身抛出OutOfMemoryError后自主退出或靠应用级限流兜底的情况——runbook 第一步就要求把二者分开这决定了后续动作完全不同。在演示会话中Agent 正是按这个特征集去匹配的它从挂载日志中识别出OutOfMemoryError、堆从 101MB 快速爬升到 118→121MB、GC 停顿达 412ms、随后容器以 exit 137 被 OOMKilled、约每 2 分钟重复一轮5 分钟内重启 7 次——这正是 alert.json 中restarts_5m: 7与标题checkout-svc pods crash-looping (CrashLoopBackOff)所指的现场。告警负载data.details携带cluster: prod-us-east、namespace: shop、deployment: checkout-svc等字段这些字段在后续定位清单时被直接复用。分诊四步从确认击杀到修正限值runbook 的中段给出了严格有序的分诊流程每一步都有明确产出适合逐条照做确认击杀来源是 kubelet 的 OOM killerexit 137而非应用自身限制。这一步过滤掉应用自己管理堆、自己退出的假阳性避免把配置问题误诊成资源问题。打开 Deployment 清单runbook 标注的路径模板为infra/k8s/service-deploy.yaml检查spec.template.spec.containers[].resources.limits.memory。在演示中即 checkout-deploy.yamlresources: requests: cpu: 250m memory: 128Mi limits: cpu: 500m memory: 128Mi对照上述 L21-L27可确认清单把 request 与 limit 都压在 128Mi而服务在定价缓存pricing cache预热到约 1.4 万条目后堆占用已达 121MB占 limit 的 94%——limit 几乎与工作集齐平任何 GC 或突发分配都会立刻触发击杀。对照服务文档化的工作集判断runbook 给出明确基准——checkout-svc 在定价缓存预热后需要约 400Mi 工作集若 limit 低于该基准则上调且 512Mi 是标准下一档standard next tier。这是一个把经验沉淀进手册的范例不给模糊的调大一点而是给出可验证的数字与档位。保持requests.memory≤ 新 limit。这是 Kubernetes 调度语义的硬约束——request 决定节点调度与 QoS 归类limit 决定运行时上限若 request 反而高于 limitPod 无法被正确调度或会陷入非预期状态。演示中的修复即遵循该约束request 提到 256Mi、limit 提到 512Mi两者都低于节点容量且留有 4 倍余量。修复约束只走 PR不热修runbook 结尾给出与 Skill 中不得热修约定一致的硬性流程要求Fix:open a PR against the infra repo with the corrected limit. Do not hot-patch the live deployment.这条规则的价值在于强制变更可审、可回滚、可审计。在演示会话中Agent 依此先备份原始文件、就地编辑再用diff -u生成 unified diff最终形成的修复即把 resources 段的两处 128Mi 分别改为 256Mirequest与 512Milimit。随后 agent 调用自定义工具open_pull_request(title, body, diff)提交 PR、调用request_approval(summary)等待值班人决策只有收到{decision: approved}后才允许调用merge_pull_request(pr_number)合并——系统提示词中明令未获批准绝不 merge且修复保持最小化、不重构无关配置。这正是 runbook 改最小可证正确的量原则在 Agent 执行层的落地。从一份 runbook 到一套可执行手册的写作要点回到仓库本身可以提炼出这类 runbook 的通用结构便于自建团队手册症状区What you see用机器可匹配的精确特征定义适用范围。退出码、事件名、日志错误类如OOMKilled/ exit 137 / heap-exhausted远比散文描述更适合人机共读Agent 正是靠这些特征把日志指纹对到oom.md这一份手册上的。分诊区How to triage步骤化、可执行每一步包含做什么、在哪看、期望看到什么。演示中的步骤 2 直接给出 YAML 路径模板infra/k8s/service-deploy.yaml使任何服务都能套用同一路径查找。决策基准Numbers明确工作集期望值约 400Mi与标准档位512Mi避免临场拍脑袋同时写明 request/limit 关系约束。动作边界What not to do明确禁止热修、强制 PR 流程与团队 Skill 中的约定互为呼应。想要亲手复现这份 runbook 的完整执行链路可运行仓库中的 sre_incident_responder.ipynb配置ANTHROPIC_API_KEY后notebook 会完成 Skill 上传、Agent 创建、环境与资源挂载、用 alert.json 触发会话、应答自定义工具调用直至人工审批并合并的全过程最终可在 Console 的 Sessions 视图回放每一步事件。注意演示把 PagerDuty/GitHub/Datadog 均以本地 fixture 模拟生产接入时按 notebook 末尾说明将自定义工具替换为 GitHub MCP、将审批投递到 Slack 按钮即可。小结oom.md 演示了一类高质量 runbook 应有的密度短到几分钟可读完却完整覆盖了信号识别 → 定位配置 → 数字比对 → 合规动作的闭环。它对人类值班员是速查卡对挂载了 incident-runbooks Skill 的 Claude 值班 Agent 则是可逐条执行的指令序列——二者最终收敛到同一个最小修复把 checkout-svc 的内存 request/limit 从 128Mi 提升到 256Mi/512Mi并以 PR 而非热修的方式落地。【免费下载链接】claude-cookbooksA collection of notebooks/recipes showcasing some fun and effective ways of using Claude.项目地址: https://gitcode.com/GitHub_Trending/an/claude-cookbooks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes OOMKilled Runbook 实战解析以 checkout-svc 内存限值修复为例【免费下载链接】claude-cookbooksA collection of notebooks/recipes showcasing some fun and effective ways of using Claude.项目地址: https://gitcode.com/GitHub_Trending/an/claude-cookbooks本文以 Claude Cookbooks 仓库中的 SRE 值班演示为背景逐条拆解 runbooks/oom.md 这份 OOMKilled runbook 的编写逻辑与落地过程。runbook 是故障特征 → 排查路径 → 标准修复的结构化浓缩它以 exit 137 与 OOMKilled 事件为症状入口给出确认击杀来源、检查 Deployment 内存 limit、比对工作集并提升限值、约束 request 与 limit 关系的四步分诊流程。本文同时结合仓库内配套的 checkout-deploy.yaml 清单、alert.json 告警负载以及 sre_incident_responder.ipynb 的完整 agent 会话说明 runbook 如何被值班 agentSkill 机制读取、执行并收敛到只改限值、不开 PR 不热修的合规动作上。读完本文你将掌握如何识别容器 OOMKilled 的可靠信号、如何阅读 Deployment 的 resources 段判断根因、内存 request/limit 的合理配比以及这类 runbook 应如何撰写才能被人工与 Agent 共同准确执行。这份 OOMKilled runbook 在演示中扮演的角色仓库将这份 runbook 放在 SRE 事件响应演示的工作区workspace中与告警、基础设施清单并列共同构成一个自包含、无需外部服务的离线演练场景相关文件均位于managed_agents/example_data/sre/下runbooks/oom.md —— 按故障特征组织的人肉/Agent 双读排查手册本文主体infra/k8s/checkout-deploy.yaml —— 基础设施仓库中被抽查的目标清单alert.json —— 触发会话的 PagerDuty V3 风格告警事件。这份 runbook 被 sre_incident_responder.ipynb 以file类型资源挂载到会话目录runbooks/oom.md同时通过一个名为incident-runbooks的 SkillSKILL.md向 Agent 宣告团队约定runbooks 按故障特征组织如oom.md、5xx.md、latency.md每份列出该类故障的排查步骤与通常需要改动的配置任何基础设施修复都必须以引用所遵循 runbook 的 PR 形式提出禁止直接热修线上资源。 也就是说oom.md 既是给人看的文档也是 Skill 让 Agent 知道该去哪里查、按什么顺序查的路标。仓库 example_data/OVERVIEW.md 说明这类 fixture 刻意保持短小并埋有可被真正发现的问题此处即过低的 128Mi 内存 limit目的是让 Agent 有东西可推敲而非一次就成功的玩具。症状识别把 OOMKilled 从其它失败中分离出来runbook 开头用三行定义了本手册适用的故障特征集合这是按失败特征组织 runbook的核心信号来源具体表现容器退出码退出码 137exit 137Pod 事件出现OOMKilled事件应用日志出现堆耗尽heap-exhausted类错误例如OutOfMemoryError理解这些信号需要一点 Kubernetes 背景容器被杀后docker inspect/kubectl describe pod返回的退出码 137 128 9SIGKILL是 kubelet 内建 OOM killer 判死刑的标准印记而OOMKilled会作为 Pod 的 Last State Reason 出现在 Pod 事件里。真正属于本手册管辖范围的是内核/kubelet 层的内存击杀而不是 JVM/Go runtime 等应用自身抛出OutOfMemoryError后自主退出或靠应用级限流兜底的情况——runbook 第一步就要求把二者分开这决定了后续动作完全不同。在演示会话中Agent 正是按这个特征集去匹配的它从挂载日志中识别出OutOfMemoryError、堆从 101MB 快速爬升到 118→121MB、GC 停顿达 412ms、随后容器以 exit 137 被 OOMKilled、约每 2 分钟重复一轮5 分钟内重启 7 次——这正是 alert.json 中restarts_5m: 7与标题checkout-svc pods crash-looping (CrashLoopBackOff)所指的现场。告警负载data.details携带cluster: prod-us-east、namespace: shop、deployment: checkout-svc等字段这些字段在后续定位清单时被直接复用。分诊四步从确认击杀到修正限值runbook 的中段给出了严格有序的分诊流程每一步都有明确产出适合逐条照做确认击杀来源是 kubelet 的 OOM killerexit 137而非应用自身限制。这一步过滤掉应用自己管理堆、自己退出的假阳性避免把配置问题误诊成资源问题。打开 Deployment 清单runbook 标注的路径模板为infra/k8s/service-deploy.yaml检查spec.template.spec.containers[].resources.limits.memory。在演示中即 checkout-deploy.yamlresources: requests: cpu: 250m memory: 128Mi limits: cpu: 500m memory: 128Mi对照上述 L21-L27可确认清单把 request 与 limit 都压在 128Mi而服务在定价缓存pricing cache预热到约 1.4 万条目后堆占用已达 121MB占 limit 的 94%——limit 几乎与工作集齐平任何 GC 或突发分配都会立刻触发击杀。对照服务文档化的工作集判断runbook 给出明确基准——checkout-svc 在定价缓存预热后需要约 400Mi 工作集若 limit 低于该基准则上调且 512Mi 是标准下一档standard next tier。这是一个把经验沉淀进手册的范例不给模糊的调大一点而是给出可验证的数字与档位。保持requests.memory≤ 新 limit。这是 Kubernetes 调度语义的硬约束——request 决定节点调度与 QoS 归类limit 决定运行时上限若 request 反而高于 limitPod 无法被正确调度或会陷入非预期状态。演示中的修复即遵循该约束request 提到 256Mi、limit 提到 512Mi两者都低于节点容量且留有 4 倍余量。修复约束只走 PR不热修runbook 结尾给出与 Skill 中不得热修约定一致的硬性流程要求Fix:open a PR against the infra repo with the corrected limit. Do not hot-patch the live deployment.这条规则的价值在于强制变更可审、可回滚、可审计。在演示会话中Agent 依此先备份原始文件、就地编辑再用diff -u生成 unified diff最终形成的修复即把 resources 段的两处 128Mi 分别改为 256Mirequest与 512Milimit。随后 agent 调用自定义工具open_pull_request(title, body, diff)提交 PR、调用request_approval(summary)等待值班人决策只有收到{decision: approved}后才允许调用merge_pull_request(pr_number)合并——系统提示词中明令未获批准绝不 merge且修复保持最小化、不重构无关配置。这正是 runbook 改最小可证正确的量原则在 Agent 执行层的落地。从一份 runbook 到一套可执行手册的写作要点回到仓库本身可以提炼出这类 runbook 的通用结构便于自建团队手册症状区What you see用机器可匹配的精确特征定义适用范围。退出码、事件名、日志错误类如OOMKilled/ exit 137 / heap-exhausted远比散文描述更适合人机共读Agent 正是靠这些特征把日志指纹对到oom.md这一份手册上的。分诊区How to triage步骤化、可执行每一步包含做什么、在哪看、期望看到什么。演示中的步骤 2 直接给出 YAML 路径模板infra/k8s/service-deploy.yaml使任何服务都能套用同一路径查找。决策基准Numbers明确工作集期望值约 400Mi与标准档位512Mi避免临场拍脑袋同时写明 request/limit 关系约束。动作边界What not to do明确禁止热修、强制 PR 流程与团队 Skill 中的约定互为呼应。想要亲手复现这份 runbook 的完整执行链路可运行仓库中的 sre_incident_responder.ipynb配置ANTHROPIC_API_KEY后notebook 会完成 Skill 上传、Agent 创建、环境与资源挂载、用 alert.json 触发会话、应答自定义工具调用直至人工审批并合并的全过程最终可在 Console 的 Sessions 视图回放每一步事件。注意演示把 PagerDuty/GitHub/Datadog 均以本地 fixture 模拟生产接入时按 notebook 末尾说明将自定义工具替换为 GitHub MCP、将审批投递到 Slack 按钮即可。小结oom.md 演示了一类高质量 runbook 应有的密度短到几分钟可读完却完整覆盖了信号识别 → 定位配置 → 数字比对 → 合规动作的闭环。它对人类值班员是速查卡对挂载了 incident-runbooks Skill 的 Claude 值班 Agent 则是可逐条执行的指令序列——二者最终收敛到同一个最小修复把 checkout-svc 的内存 request/limit 从 128Mi 提升到 256Mi/512Mi并以 PR 而非热修的方式落地。【免费下载链接】claude-cookbooksA collection of notebooks/recipes showcasing some fun and effective ways of using Claude.项目地址: https://gitcode.com/GitHub_Trending/an/claude-cookbooks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
