# K8s负载检测及处置

> K8s 节点高负载排查与 Pod 驱逐 Skills

- Skill: `openocta/k8s` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add openocta/k8s`
- Raw SKILL.md: https://api.skillmd.com/api/skills/openocta/k8s/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: openocta (https://skillmd.com/u/openocta)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/openocta/k8s

---

# K8s 节点高负载排查与 Pod 驱逐 Skills

```Plain Text
---
name: k8s-node-high-load-pod-eviction-skills
description: K8s节点CPU高负载（>70%）、内存高负载（>70%）排查、高负载Pod定位、Pod驱逐调度及排障报告生成Skill。Use when users ask to check k8s node high load, query node/container metrics, locate high-load pods, evict and schedule pods to other nodes, generate troubleshooting reports for k8s node high CPU usage.
---
```

# K8s 节点高负载排查与 Pod 驱逐 Skills

本技能专为OpenOcta运维智能体设计，用于K8s集群节点CPU高负载（CPU使用率>70%）、内存高负载（内存使用率>70%）场景下的指标查询、高负载Pod定位、Pod驱逐调度及排障报告生成，全程遵循“指标查询-定位根因-处置调度-审计报告”的闭环逻辑，确保K8s集群节点负载可控、业务稳定运行。

## 一、正式执行规范

### 1.1 唯一CLI入口（严禁使用其他入口）

所有操作仅允许使用以下4个正式CLI入口，禁止手动编写临时kubectl命令、拼接原始指令或使用非指定工具，确保操作可追溯、可审计：

- `python3 scripts/k8s_api/node_metrics.py ...` （节点/容器CPU、内存等指标查询、统计）

- `python3 scripts/k8s_api/pod_locate.py ...` （高负载Pod定位、负载排行、关联容器分析）

- `python3 scripts/k8s_api/pod_evict.py ...` （高负载Pod驱逐、调度策略配置、调度结果校验）

- `python3 scripts/k8s_api/troubleshoot_report.py ...` （排障报告生成、报告推送、报告归档）

### 1.2 操作权限边界

允许操作（无风险/低风险）：

- 测试环境：模拟节点高负载（CPU>70%、内存>70%）、查询节点/容器指标、定位高负载Pod、驱逐Pod并调度、生成排障报告、清理测试资源

- 生产/正式环境：查询节点/容器CPU、内存负载指标、定位高负载Pod、按策略驱逐Pod并调度至低负载节点、生成排障报告、推送报告至指定渠道

禁止操作（高危/违规）：

- 删除、修改K8s集群核心配置（如kubelet配置、调度器配置）、重启集群节点等影响集群正常运行的操作

- 无差别驱逐Pod（不分负载高低）、驱逐集群核心组件Pod（如kube-apiserver、etcd、calico等）

- 手动修改Pod调度策略、强制调度至已达负载阈值的节点

- 篡改节点/容器指标数据、删除排障日志、伪造排障报告内容

- 未经审批，批量驱逐超过5个以上业务Pod，避免造成业务中断

## 二、快速操作示例（Quick Examples）

优先使用显式独立参数，高级筛选统一使用`--filter key=value` 格式；`--filters '{"k":"v"}'` 仅做旧版本兼容，不优先使用。所有示例可直接复制执行，适配skills.md全流程规则，默认CPU、内存负载阈值均为70%。

```bash
# 1. 查询指定节点CPU、内存负载指标（近10分钟，显示详细指标）
python3 scripts/k8s_api/node_metrics.py query --node-name node-01 --metric cpu,mem --time-range 10m --detail

# 2. 定位集群内所有高负载Pod（CPU>70%或内存>70%，按负载降序排序）
python3 scripts/k8s_api/pod_locate.py find-high-load --metric cpu,mem --threshold 70 --sort desc

# 3. 预览高负载Pod驱逐策略（不实际执行，显示调度目标节点）
python3 scripts/k8s_api/pod_evict.py preview --pod-name high-load-pod-xxx --namespace default

# 4. 确认执行Pod驱逐并调度（需加--confirm触发审批，审批通过后执行）
python3 scripts/k8s_api/pod_evict.py execute --confirm --pod-name high-load-pod-xxx --namespace default

# 5. 生成节点高负载排障报告（统计1小时内数据，包含CPU、内存高负载处置过程）
python3 scripts/k8s_api/troubleshoot_report.py generate --report-type k8s-node-high-load --time-range 1h --node-name node-01

# 6. 推送排障报告至飞书群组（需替换为实际飞书webhook地址）
python3 scripts/k8s_api/troubleshoot_report.py push --webhook-url https://open.feishu.cn/open-apis/bot/v2/hook/xxx --report-path ./reports/k8s-high-load-xxx.md

# 7. 验证Pod驱逐后节点负载（查询目标节点CPU、内存使用率，确认负载下降）
python3 scripts/k8s_api/node_metrics.py query --node-name node-01 --metric cpu,mem --time-range 5m
```

异常处理提示：任务阻塞、权限异常、参数报错时，优先读取返回结果中的 `err_code`（错误码）、`prompt_msg`（提示信息）、`solve_tips`（解决建议）、`recommend_cmd`（推荐命令），不依赖顶层简易error信息定位问题。

## 三、路由匹配规则（Route First）

严格按从上到下顺序匹配业务路由，上级规则优先级高于下级，未匹配上一级规则时，再依次匹配下一级，确保业务流程精准对应，覆盖“指标查询-定位-驱逐-报告”全环节。

### 1. 路由1：K8s节点/容器负载指标查询（核心优先）

#### 适用场景

查询K8s节点CPU负载、内存负载，容器CPU使用率、内存使用率，确认节点是否处于高负载状态（CPU>70%或内存>70%），采集负载相关明细数据。

#### 用户典型话术

查看node-01节点CPU、内存负载、查询集群所有节点负载情况、查看容器CPU和内存使用率排行、确认节点是否高负载（CPU>70%或内存>70%）、采集节点负载明细数据。

#### 执行流程步骤（详细，内嵌脚本命令）

1. 接收用户请求，提取核心参数：节点名称（单节点/全节点）、指标类型（默认CPU、内存，可单独指定）、时间范围、是否需要详细指标、负载阈值（默认70%）。

2. 前置校验：检查K8s集群连通性（通过kubeconfig配置校验），确认集群状态正常、节点处于Ready状态，若节点未Ready则提示用户先排查节点状态，终止指标查询流程。

3. 调用节点指标查询脚本，按参数采集指定节点、指定时间范围的负载指标，自动过滤无效数据，执行命令：
        
`python3 scripts/k8s_api/node_metrics.py query --node-name node-01 --metric cpu,mem --time-range 10m --detail`

    - 核心指标：节点CPU使用率、CPU核心数、已使用CPU、空闲CPU、负载峰值/均值；节点内存使用率、总内存、已使用内存、空闲内存

    - 辅助指标：节点磁盘使用率、Pod运行数量（可选）

    - 容器指标：节点上所有运行容器的CPU使用率、内存使用率、容器所属Pod、容器ID（可选，需加--container参数）

4. 指标分析：判断节点CPU使用率是否超过阈值（默认70%）、内存使用率是否超过阈值（默认70%），标记高负载节点（CPU高负载/内存高负载/双高负载），生成`node_load_details`（节点负载明细）和`high_load_node_list`（高负载节点清单，标注高负载类型）。

5. 返回指标查询结果，包含节点负载状态、核心指标明细、高负载节点标记及类型，供后续高负载Pod定位使用。

#### 执行入口

`node_metrics.py`（query动作，支持单节点/全节点、多指标（CPU、内存）查询）

### 2. 路由2：高负载Pod定位（根因分析环节）

#### 适用场景

针对高负载节点（CPU>70%或内存>70%），定位导致节点高负载的Pod，分析Pod所属命名空间、容器负载情况（CPU/内存）、Pod运行状态，生成高负载Pod排行清单（按CPU或内存负载排序）。

#### 用户典型话术

定位node-01节点高负载的Pod、查找集群内CPU/内存使用率最高的Pod、分析哪个Pod导致节点CPU/内存负载过高、查看高负载Pod的容器明细。

#### 执行流程步骤（详细，内嵌脚本命令）

1. 接收用户请求，提取核心参数：高负载节点名称（必填）、负载指标（默认CPU、内存，可单独指定）、负载阈值（默认70%）、排序方式（默认降序）、是否显示容器明细。

2. 前置校验：调用节点指标查询脚本，确认目标节点确实处于高负载状态（CPU>70%或内存>70%），若节点负载未达标则提示用户“节点未处于高负载状态，无需定位Pod”，终止流程，执行命令：`python3 scripts/k8s_api/node_metrics.py query --node-name node-01 --metric cpu,mem --time-range 5m`

3. 调用高负载Pod定位脚本，扫描目标节点上所有运行中的Pod，采集每个Pod的CPU使用率、内存使用率、运行时长等信息，执行命令：
       `python3 scripts/k8s_api/pod_locate.py find-high-load --node-name node-01 --metric cpu,mem --threshold 70 --sort desc`

4. Pod筛选与排序：过滤出CPU使用率>阈值或内存使用率>阈值的Pod，按指定负载指标降序排序，标记排名前3的核心高负载Pod（根因Pod），生成`high_load_pod_list`（高负载Pod清单，标注负载类型）和`pod_load_details`（Pod负载明细）。

5. 关联分析：查询高负载Pod的所属命名空间、控制器类型（Deployment/DaemonSet等）、容器镜像、资源限制配置，判断是否因资源限制不合理导致CPU或内存负载过高。

6. 返回定位结果，包含高负载Pod清单、Pod负载排行、容器明细、关联分析结论，供后续Pod驱逐操作使用。

#### 执行入口

`pod_locate.py`（find-high-load动作，支持按节点、按集群定位，支持CPU、内存双指标筛选）

### 3. 路由3：高负载Pod驱逐与调度（处置环节）

#### 适用场景

将高负载节点上的高负载Pod（CPU>70%或内存>70%）驱逐，调度至集群内低负载节点（CPU使用率<50%、内存使用率<50%），验证驱逐与调度效果，确保原高负载节点负载下降至正常范围。

#### 用户典型话术

驱逐node-01节点上的高负载Pod、将high-load-pod-xxx调度到node-02节点、驱逐后验证节点CPU/内存负载、批量驱逐高负载Pod并调度。

#### 执行流程步骤（详细，内嵌脚本命令）

1. 接收用户请求，提取核心参数：高负载Pod名称、所属命名空间、目标调度节点（可选，默认自动匹配低负载节点）、是否确认执行、负载指标类型（CPU/内存，用于校验）。

2. 前置校验：

    - 确认高负载Pod存在且处于Running状态，若Pod已停止则提示用户“Pod已停止，无需驱逐”

    - 查询集群内低负载节点（CPU使用率<50%、内存使用率<50%），确认存在可调度节点，若无可用节点则提示用户“无低负载节点可调度，无法执行驱逐”，终止流程

    - 校验Pod是否为集群核心组件Pod，若为核心组件则禁止驱逐，返回“禁止驱逐集群核心组件Pod”提示

3. 调用驱逐策略预览脚本，展示Pod驱逐命令、目标调度节点、调度策略（默认RoundRobin），供用户确认，执行命令：
        
`python3 scripts/k8s_api/pod_evict.py preview --pod-name high-load-pod-xxx --namespace default`

4. 高危校验：Pod驱逐属于高危操作（可能影响业务），自动进入OpenOcta智能体审批队列，推送审批通知给指定审批人。

5. 审批处理：
        

    - 审批通过：调用Pod驱逐执行脚本，执行Pod驱逐与调度命令，完成Pod迁移，执行命令：
                
    `python3 scripts/k8s_api/pod_evict.py execute --confirm --pod-name high-load-pod-xxx --namespace default`

    - 审批拒绝：终止执行流程，返回“审批被拒绝，操作终止”提示，记录拒绝原因至排障日志。

    - 审批超时（默认30秒，可配置）：终止执行流程，返回“审批超时，请重新触发任务”提示。

6. 驱逐后验证：调用节点指标查询脚本，查询原高负载节点和目标调度节点的CPU、内存负载，确认原节点负载下降至正常范围（CPU<70%、内存<70%）、目标节点负载未超标，执行命令：
        
`python3 scripts/k8s_api/node_metrics.py query --node-name node-01,node-02 --metric cpu,mem --time-range 5m`

7. 返回驱逐与调度结果，包含驱逐Pod名称、调度目标节点、原节点CPU/内存负载变化、目标节点负载状态，供后续报告生成使用。

#### 执行入口

`pod_evict.py`（preview、execute两个动作，支持单Pod/批量Pod驱逐，适配CPU、内存高负载场景）

### 4. 路由4：排障报告自动生成与推送（审计环节）

#### 适用场景

汇总节点CPU高负载（>70%）、内存高负载（>70%）排查、高负载Pod定位、Pod驱逐调度全流程数据，生成标准化排障报告，推送至指定渠道（飞书），留存运维记录。

#### 用户典型话术

生成K8s节点高负载排障报告、导出Pod驱逐处置记录、推送排障报告到飞书群组、留存节点CPU/内存高负载运维单据。

#### 执行流程步骤（详细，内嵌脚本命令）

1. 接收用户请求，提取核心参数：报告类型（默认k8s-node-high-load）、统计时间范围、高负载节点名称、报告存储路径（默认./reports）、是否需要推送、负载指标类型（CPU/内存，可选）。

2. 前置校验：检查报告存储目录是否存在，若不存在则自动创建（`mkdir -p ./reports`）；检查全流程数据（指标查询、Pod定位、驱逐调度）是否完整，若数据缺失则提示用户“部分流程数据缺失，无法生成完整报告”。

3. 调用排障报告生成脚本，自动采集全流程数据，填充标准化报告字段，执行命令：
        
`python3 scripts/k8s_api/troubleshoot_report.py generate --report-type k8s-node-high-load --time-range 1h --node-name node-01`

    - 基础信息：报告生成时间、高负载节点名称、统计时间范围、集群名称、高负载类型（CPU/内存/双高）

    - 指标明细：节点CPU、内存负载变化曲线、使用率峰值/均值、高负载持续时长

    - 定位结果：高负载Pod清单、Pod负载排行（按CPU/内存）、根因分析结论

    - 处置过程：驱逐Pod名称、调度目标节点、审批记录、驱逐前后CPU/内存负载对比

    - 处置效果：原节点CPU/内存负载下降情况、目标节点负载状态、后续优化建议

4. 生成Markdown格式排障报告，命名规则为`k8s-node-high-load-report-时间戳.md`，存储至指定路径。

5. 报告校验：检查报告文件是否生成成功、文件大小是否正常（非空），校验失败则重新生成并提示用户。

6. 报告推送（可选）：若用户需要推送，调用报告推送脚本，向指定飞书webhook地址推送报告，执行命令：
       
`python3 scripts/k8s_api/troubleshoot_report.py push --webhook-url https://open.feishu.cn/open-apis/bot/v2/hook/xxx --report-path ./reports/k8s-high-load-xxx.md`

7. 返回报告生成与推送结果，包含报告路径、文件大小、统计时间范围、推送状态（若有）。

#### 执行入口

`troubleshoot_report.py`（generate、push两个动作，支持CPU、内存高负载场景报告生成）

### 5. 路由5：环境校验&效果验证&测试清理（辅助环节）

#### 适用场景

验证Pod驱逐与调度效果、检查集群连通性、清理测试环境驱逐残留资源。

模拟K8s节点CPU高负载（>70%）、内存高负载（>70%）、验证Pod驱逐与调度效果、检查集群连通性、清理测试环境高负载模拟资源和驱逐残留资源。

#### 用户典型话术

模拟node-01节点CPU/内存高负载、验证Pod驱逐后节点负载是否下降、清理测试环境高负载模拟资源、检查K8s集群连通性。

#### 执行流程步骤（详细，内嵌脚本命令）

1. 环境预检：调用集群连通性校验命令，检查kubeconfig配置有效性、集群节点状态、核心组件运行情况，返回预检结果。

2. 处置效果验证：调用节点指标查询脚本，检查原高负载节点CPU、内存负载是否下降至正常范围、目标调度节点负载是否未超标，执行命令：
        
`python3 scripts/k8s_api/node_metrics.py query --node-name node-01,node-02 --metric cpu,mem --time-range 5m`

3. 测试环境清理：调用资源清理脚本，删除测试用驱逐残留Pod、清理临时调度规则，避免影响测试环境正常使用，执行命令：
        
`bash scripts/k8s_api/clean_test_resources.sh --node-name node-01 --namespace test`

4. 清理后校验：确认残留规则已删除，节点CPU、内存负载恢复正常，返回清理结果。

#### 执行入口

#### 执行入口

辅助脚本（`clean_test_resources.sh`）+ 核心CLI入口辅助参数

## 四、模板输出规则（Template Overrides）

严格遵循以下规则输出排障报告模板，确保报告规范性、可追溯性，禁止随意省略或替代模板。

1. 例外场景：仅当用户明确要求“只给结论、精简汇总、无需完整报表、纯文字简述”时，可跳过标准排障模板，直接输出精简分析结果（如“node-01节点CPU、内存高负载，已驱逐2个高负载Pod，节点负载恢复正常，报告已生成”）。

2. 默认规则：无特殊说明时，所有K8s节点CPU高负载（>70%）、内存高负载（>70%）排查、Pod驱逐调度场景，**必须生成完整标准排障报告**，禁止只用文字描述替代正式报表。

3. 结果反馈：全流程执行完成后，必须主动告知用户以下信息，禁止后台静默生成不反馈：
        

    - 排障报告存储路径（如 `./reports/k8s-node-high-load-report-1716000000.md`）

    - 报告文件大小（如 3KB）

    - 数据统计时间范围（如 2026-05-18 10:00-11:00）

    - 模板来源（标准K8s节点高负载排障模板）

    - 高负载类型（CPU/内存/双高）

4. 数据真实性：所有文字总结、处置结论，必须取自CLI返回的结构化字段（如 `report_summary`、`high_load_pod_list`、`evict_record`），禁止主观编造数据、篡改统计结果。

## 五、目标节点优先级（Node Target Priority）

按以下顺序确定执行目标节点（高负载节点、调度目标节点），确保操作精准性，避免误操作其他节点。

1. 用户显式指定：若用户明确给出高负载节点名称（如“node-01”）、目标调度节点名称（如“node-02”），仅针对指定节点执行全流程，不扩散至其他节点。

2. 未指定高负载节点：默认扫描集群内所有节点，筛选出CPU使用率>70%或内存使用率>70%的高负载节点，按负载从高到低排序，优先处理负载最高的节点。

3. 未指定调度目标节点：默认自动匹配集群内低负载节点（CPU使用率<50%、内存使用率<50%），优先选择同可用区、同规格的节点作为调度目标，避免跨可用区调度影响业务延迟。

4. 节点状态适配：仅选择处于Ready状态、无故障标记的节点作为高负载排查和调度目标，若节点处于NotReady状态，自动跳过并提示用户。

5. 权限前置拦截：若智能体无K8s集群操作权限（kubeconfig配置错误、权限不足）、无法读取节点/容器指标，直接终止流程，输出权限配置指引（如“请核对kubeconfig配置，确保拥有node、pod的read、delete权限”）。

## 六、标准执行流程（Standard Flow）

接收用户请求后，统一执行以下前置流程，再匹配对应路由执行业务操作，确保流程规范、无遗漏。

```Plain Text
集群连通性预检 → 节点状态校验 → 指标查询与高负载判断（CPU>70%/内存>70%） → 高负载Pod定位 → Pod驱逐与调度 → 效果验证 → 排障报告生成（+推送）
```

### 6.1 统一执行约束

1. 环境状态未知时，优先执行集群连通性预检命令（如 `node_metrics.py query --node-name all --metric cpu,mem --time-range 5m`），校验基础组件（kubeconfig、集群核心组件、指标采集工具）完整性。

2. 依赖缺失处理：若指标采集工具未安装、集群核心组件异常（如kube-apiserver未运行），先输出具体修复方案（如“重启kube-apiserver服务，执行 systemctl restart kube-apiserver”），不继续执行业务流程。

3. 参数模糊处理：若负载阈值、时间范围、目标节点等关键参数模糊（如“最近一段时间”“低负载节点”），优先交互确认用户需求，不随意默认填充参数。

4. 默认规则：无用户指定时，CPU使用率**>70%**、内存使用率**>70%**判定为节点高负载；无指定时间范围时，默认统计**最近1小时**节点负载数据；调度目标节点CPU使用率默认<50%、内存使用率默认<50%。

5. 批量操作限制：批量驱逐Pod（≥3个）时，自动分批次执行（每次1个），执行后验证负载效果，避免批量驱逐导致业务中断或目标节点负载超标。

6. 超时处理：所有CLI命令执行超时时间设置为15秒，超时则返回超时提示，建议用户重新触发任务。

## 七、数据统计规范（Statistical Guidelines）

所有数据统计严格遵循以下规范，确保统计结果准确、口径统一，避免统计错误。

1. 标准统计字段：统一使用以下结构化字段，禁止自定义统计字段：
        

    - `high_load_node_count`：高负载节点总数（CPU>70%或内存>70%）

    - `high_load_pod_count`：高负载Pod总数（CPU>70%或内存>70%）

    - `evicted_pod_count`：已成功驱逐的Pod数量

    - `node_load_before`：驱逐前高负载节点CPU、内存使用率

    - `node_load_after`：驱逐后高负载节点CPU、内存使用率

    - `pod_load_details`：每个高负载Pod的具体CPU、内存使用率明细

    - `high_load_type`：高负载类型（cpu/mem/both）

2. 口径区分：严格区分以下四类统计口径，回答时分开描述，严禁混淆：
        

    - 单Pod CPU使用率：某一个Pod的CPU使用率（如“high-load-pod-xxx CPU使用率75%”）

    - 单Pod内存使用率：某一个Pod的内存使用率（如“high-load-pod-xxx 内存使用率78%”）

    - 节点CPU使用率：单个节点的整体CPU使用率（如“node-01节点CPU使用率72%”）

    - 节点内存使用率：单个节点的整体内存使用率（如“node-01节点内存使用率75%”）

    - 高负载节点/Pod总数：集群内所有CPU使用率>70%或内存使用率>70%的节点/Pod数量（如“共2个高负载节点，5个高负载Pod”）

3. 榜单标注：仅返回TOP热门高负载Pod榜单（如TOP3）时，必须标注：**仅为部分排行数据，非全量高负载Pod清单**，不可用榜单数量代替全局总数。

4. 明细提取：查询指定高负载节点的Pod负载时，优先从指标明细中提取**去重完整高负载Pod列表**，不只用热度排行作答。

5. 时间标准化：所有指标时间、执行时间统一标准化为24小时制（如 14:30:00），统一时区（默认UTC+8），消除时间展示偏差。

## 八、执行安全红线（Guardrails）

严格遵守以下安全规则，严禁违规操作，避免造成K8s集群故障、业务中断或数据丢失。

### 8.1 强制禁止行为

- 不手写临时kubectl命令、不直接拼接原始指令下发集群（如直接执行 `kubectl delete pod high-load-pod-xxx -n default`，需通过指定CLI入口执行）。

- 不驱逐集群核心组件Pod（如kube-apiserver、etcd、calico、coredns等），禁止修改核心组件配置。

- 无差别驱逐Pod、批量驱逐超过5个以上业务Pod（未经审批），避免造成大规模业务中断。

- 强制调度高负载Pod至已达负载阈值的节点（CPU≥50%或内存≥50%），导致目标节点也出现高负载。

- 篡改节点/容器指标数据、删除排障日志、伪造排障报告内容，影响运维追溯。

- 未经审批，擅自修改Pod资源限制配置，导致Pod负载异常。

### 8.2 统计输出严禁错误

- 禁止将单个Pod CPU/内存使用率，等同于节点整体CPU/内存使用率（如“high-load-pod-xxx CPU使用率75%”≠“node-01节点CPU使用率75%”）。

- 禁止用TOP N少量高负载Pod数量，判定为全部高负载Pod总量（如“TOP3高负载Pod”≠“所有高负载Pod”）。

- 禁止只展示高负载Pod排行，不提供完整可导出高负载Pod明细。

- 禁止只统计驱逐前负载数据，忽略驱逐后负载变化，造成处置效果分析片面。

- 禁止混淆CPU高负载与内存高负载的统计口径，避免数据误导。

### 8.3 强制数据校验规则

1. 指标统计校验：输出所有负载数据前，校验指标采集条数与统计条数一致性，出现数据缺失主动提示用户，排查指标采集工具问题。

2. 驱逐效果校验：Pod驱逐完成后，必须复测原高负载节点和目标调度节点的CPU、内存负载，确认原节点负载下降至正常范围（CPU<70%、内存<70%）、目标节点负载未超标，再返回“执行成功”结论。

3. 失败根因区分：处置失败时，精准区分以下五大根因，并给出对应解决办法，禁止笼统提示“执行失败”：

    - 权限不足：提示“请给智能体配置K8s集群node、pod的read、delete权限，核对kubeconfig配置”

    - 无可用调度节点：提示“集群内无低负载节点（CPU<50%、内存<50%），请先扩容节点或清理其他节点负载”

    - Pod不存在/未运行：提示“目标Pod不存在或已停止运行，无需驱逐”

    - 集群异常：提示“K8s集群核心组件异常，无法执行操作，请先排查集群状态”

    - 参数错误：提示“参数填写错误，请核对Pod名称、命名空间、节点名称等参数”；飞书推送参数错误（如webhook无效），提示错误码19001对应问题及解决办法

## 九、统一返回输出内容（Respond With）

执行成功或阻塞异常时，按以下规范返回内容，确保信息完整、清晰，便于用户查看和后续操作。

### 9.1 执行成功必须返回

1. 前置集群预检整体结果（如“集群预检通过，kubeconfig配置有效，所有节点处于Ready状态”）。

2. 本次使用的正式CLI执行入口（如“使用入口：python3 scripts/k8s_api/node_metrics.py”）。

3. 当前生效执行目标节点信息（高负载节点、调度目标节点，如“高负载节点：node-01，调度目标节点：node-02”）。

4. 多节点场景：可切换高负载节点列表（如“可切换高负载节点：node-01、node-03”）。

5. 核心执行命令精简摘要（如“执行命令：find-high-load --node-name node-01 --metric cpu,mem --threshold 70”）。

6. 指标与定位结果：高负载节点数量、高负载Pod数量、核心高负载Pod明细及CPU/内存使用率（如“高负载节点：1个，高负载Pod：2个，明细：high-load-pod-xxx（CPU75%、内存72%）、high-load-pod-yyy（CPU73%）”）。

7. 驱逐与调度结果：驱逐Pod数量、调度目标节点、驱逐前后节点CPU/内存负载对比（如“驱逐Pod：2个，调度至node-02；驱逐前node-01 CPU 72%、内存75%，驱逐后CPU 45%、内存48%”）。

8. 排障报告信息：生成状态、文件路径、文件大小、数据统计区间、高负载类型（如“报告生成成功，路径：./reports/xxx.md，大小：3KB，统计区间：2026-05-18 10:00-11:00，高负载类型：CPU+内存双高”）。

9. 飞书推送结果（若有）：推送状态、接收群组、消息摘要（如“推送成功，接收群组：K8s运维组，摘要：node-01节点高负载已处置，负载恢复正常”）。

10. 精简处置结论（可搭配完整排障报表，如“本次共检测到1个高负载节点、2个高负载Pod，已全部驱逐并调度至低负载节点，节点CPU、内存负载恢复正常，排障报告已生成”）。

### 9.2 流程阻塞异常必须返回

1. 前置集群预检检测结果（如“集群预检失败，kubeconfig配置无效”）。

2. 当前生效执行目标节点（如“当前高负载节点：node-01”）。

3. 精准阻塞原因与错误字段（如“阻塞原因：无可用调度节点，错误字段：target-node，无符合条件节点（CPU<50%、内存<50%）”；飞书推送阻塞则提示“阻塞原因：飞书webhook无效，错误码19001，错误信息：param invalid: incoming webhook access token invalid”）。

4. 可用备选方案、标准配置清单（如“备选方案：扩容集群节点或清理node-03节点负载；标准调度节点要求：CPU使用率<50%、内存使用率<50%、处于Ready状态”；飞书推送则提供webhook配置指引）。

5. 标准化下一步整改操作指引（如“整改建议：扩容1台同规格节点，或驱逐node-03节点上的低优先级Pod，释放负载后重新执行”；飞书推送则提示“整改建议：重新核对飞书webhook地址，确保access token有效”）。

## 十、参考文档（References）

- [K8s节点负载指标查询规范](references/k8s-node-metrics-rule.md)：详细说明节点/容器CPU、内存指标采集、解析、统计的具体规则和异常处理。

- [Pod驱逐与调度审批流程](references/k8s-pod-evict-audit-flow.md)：说明高危Pod驱逐命令的审批流程、审批人配置、超时处理规则。

- [K8s排障报告模板规范](references/k8s-troubleshoot-report-template.md)：详细说明排障报告的字段、格式、内容要求，包含CPU、内存高负载场景适配。

- [测试环境资源清理回滚手册](references/k8s-test-env-clean.md)：说明测试环境高负载模拟资源、驱逐残留资源的清理方法、回滚步骤。

- [飞书webhook配置指南](references/feishu-webhook-config.md)：说明飞书webhook的创建、配置、测试方法，包含错误码19001的排查方案。

## 十一、响应检查清单（Response Checklist）

每次执行完成后，按以下清单检查响应内容，确保无遗漏、无错误。

- [ ] 已确认统计数据取自全量指标明细，非仅TOP热度榜单。

- [ ] 严格区分节点CPU使用率、节点内存使用率、单Pod CPU使用率、单Pod内存使用率、高负载节点/Pod总数五类统计口径。

- [ ] Pod驱逐完成后已完成CPU、内存负载复测，确认原节点负载恢复正常、目标节点负载未超标。

- [ ] 仅展示部分榜单时，明确标注数据不全，非全局全量。

- [ ] 严格区分测试环境与生产环境处置逻辑，无残留测试资源。

- [ ] 无人工授权与审批确认，不私自批量执行大规模Pod驱逐。

- [ ] 响应内容包含所有必填信息（执行入口、目标节点、结果明细等）。

- [ ] 无主观编造数据，所有结论均来自CLI返回的结构化字段。

- [ ] 异常场景已明确给出失败根因和整改建议，无笼统提示（含飞书webhook错误码19001对应处理）。

- [ ] 排障报告已生成并告知路径，无后台静默生成情况。

## 十二、详细注意事项（补充完善）

按场景分类补充注意事项，覆盖执行全流程，避免因操作不当导致故障或风险。

### 12.1 环境相关注意事项

- 集群版本适配：本技能仅支持K8s 1.18+版本，低版本集群可能存在API不兼容问题，执行前可通过 `kubectl version` 校验版本。

- 指标采集工具：确保集群已部署metrics-server或Prometheus，否则无法采集节点/容器CPU、内存负载指标，需先部署相关工具。

- kubeconfig配置：确保智能体使用的kubeconfig文件有效、权限充足，建议定期校验kubeconfig有效性。

### 12.2 操作相关注意事项

- 驱逐Pod前，务必确认Pod非核心业务Pod、非状态fulset类型Pod（避免数据丢失），若为状态fulset Pod，需先确认数据已备份。

- 批量驱逐Pod时，建议分批执行（每次1-2个），执行后验证CPU、内存负载效果，避免批量驱逐导致业务中断或目标节点负载超标。

- 飞书webhook地址需定期校验，避免因地址变更、权限过期导致推送失败（若出现错误码19001，需及时重新获取有效webhook地址），建议每月测试一次webhook有效性。

- 排障报告需定期留存，建议留存期限≥3个月，便于后续运维审计、问题追溯。

### 12.3 异常处理注意事项

- 指标采集失败时，优先检查metrics-server/Prometheus运行状态、kubeconfig权限，若工具未运行，先启动工具再重新采集CPU、内存指标。

- Pod驱逐失败时，不要反复执行命令，先排查失败根因（如权限、Pod状态、集群状态），解决后再重新执行。

- 飞书推送失败（错误码19001）时，需重新核对webhook地址，确保access token有效，参考飞书webhook配置指南重新获取地址。

> （注：文档部分内容可能由 AI 生成）