ascend-ai-coding
ascend-ai-coding/awesome-ascend-skills
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ascend-ai-coding/awesome-ascend-skills --skill external-gitcode-ascend-k8s-check-fix命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
评估 CANN 算子仓的「进阶教程 / 开发指南」类文档质量——通读文档 + 对照算子代码**静态**查证(默认不跑),按五轴(找得到/信得过/学得会/可操作/读得懂)找出 漏讲/讲不清/过时/对不上代码/概念讲错,产出带证据与改进建议的体检报告(MD + HTML)。涉及「评进阶教程 / 开发指南文档质量 / 文档对不对得上代码 / 教程审稿 / tutorial 体检 / 文档信不信得过」等意图时使用。只评不改不跑,只对着文档与代码出诊断。
Run NPU inference/training tests on a remote SSH server with vllm-ascend Docker container. Use when the user asks to test models on NPU, run inference on Ascend devices, or deploy models to an SSH server.
Track daily PRs and Issues from vllm-project/vllm and vllm-project/vllm-ascend, filter by model (DeepSeek/Qwen/GLM/MiniMax/Kimi) and tech topics (PD disaggregation, MTP, quantization, graph mode, performance), analyze with LLM, and generate a Markdown report. Use when user wants vllm daily tracker, PR/Issue digest, or Ascend inference ecosystem monitoring.
基于 SOC 职业分类
正在显示 SKILL.md
| name | external-gitcode-ascend-k8s-check-fix |
| description | Kubernetes 集群健康检查与安全修复 — 诊断问题，用户确认后执行修复 |
| tags | ["kubernetes","k8s","devops","sre","incident-response","diagnostics","remediation","on-call"] |
| tools | [{"name":"k8s_check_fix","description":"执行 Kubernetes 集群诊断，并在用户批准后执行安全修复。子命令：sweep, pod, deploy, resources, events, fix。","command":"bash scripts/k8s-check-fix.sh","args":["[Truncated]","[Truncated]","[Truncated]","[Truncated]","[Truncated]","[Truncated]","[Truncated]","[Truncated]","[Truncated]","[Truncated]"]}] |
| dependencies | ["kubectl","jq"] |
| original-name | k8s-check-fix |
| synced-from | https://gitcode.com/Ascend/agent-skills |
| synced-date | 2026-05-26 |
| synced-commit | 1f7666e7768a0ceb21bb1d40ce4b5179fcb6f1d6 |
| license | UNKNOWN |
该工具可以执行 Kubernetes 集群诊断（全面健康检查、Pod 深入排查、Deployment 分析、资源压力检测、事件监控），并且在用户明确批准后执行安全修复操作。
- 每个 kubectl 命令调用必须设置超时（例如 30 秒）。如果命令在超时内未返回，立即向用户报告“命令执行超时，可能是 API Server 无响应”，并停止当前技能。
- 任何子命令失败（返回非零退出码或 JSON 错误字段），立即报告错误详情，不要自动重试，并询问用户是否继续。
- 如果用户没有明确要求继续，默认停止技能，避免陷入无意义的重试循环。
- 禁止连续调用超过 3 个子命令而不给用户反馈。每执行一个命令，必须将结果（哪怕是中间结果）以 Markdown 形式展示给用户。
- 如果某个子命令预计耗时超过 10 秒（例如
sweep在大集群中），必须先向用户发送“正在执行，请稍候...”消息，再调用命令。
在以下情况下使用此技能：
NotReady、kubectl 命令执行失败、滚动更新卡住、网络问题等。不要在以下情况使用此技能：
在开始诊断前，检查技能目录下是否存在 config.json。如果文件不存在或缺少必要字段，使用 AskUserQuestion 收集以下信息：
kubectl config get-contexts -o name 获取）。false。警告用户开启自动确认非常危险。false。如果设置为 true，将阻止 fix 子命令执行。将答案写入 config.json。后续调用将读取这些值作为默认值，除非用户通过标志参数覆盖。 如果 config.json 存在但解析失败（JSON 格式错误），报告具体错误并停止技能，不要尝试默认值。
sweep, pod, deploy, resources, events）均为安全只读操作。fix 子命令加 --confirm 标志执行。rollout undo、rollout restart、、、、。scaledelete podcordonuncordonkubectl exec。--context 和 --namespace 标志限制操作范围。此技能包含常见控制平面和节点故障的详细恢复指南。不要一次性读取所有指南，请遵循以下工作流：
sweep 获取整体情况。NotReady、CNI 问题等）。guides/faults/ 目录）以了解诊断步骤和修复选项。（如果所需的指南文件不存在，报告“缺少故障指南文件：xxx.md，无法提供详细修复步骤”，并仅基于通用知识给出建议，不要反复尝试读取。）
etcd_cluster_failure.mdapiserver_cert_expired.mdscheduler_failure.mdworker_node_down.mdkubelet_cert_expired.mdcni_failure.mdpod、deploy、resources 子命令）。fix 子命令（如果允许）或指导用户手动执行命令。k8s_check_fix 可作为类似 Python 的函数调用。示例：
# 全集群健康检查
k8s_check_fix(subcommand="sweep", context="prod")
# 深入排查问题 Pod
k8s_check_fix(subcommand="pod", target="api-7f8d4-x2k9p", namespace="prod", tail=500)
# Deployment 状态
k8s_check_fix(subcommand="deploy", target="my-app", namespace="default")
# 资源压力分析
k8s_check_fix(subcommand="resources")
# 近期事件（最近一小时）
k8s_check_fix(subcommand="events", since="1h")
# 安全修复（用户批准后）
k8s_check_fix(subcommand="fix", target="kubectl rollout undo deployment/my-app -n prod", confirm=True)
所有子命令返回 JSON 格式数据。解析后使用表格、列表、代码块等 Markdown 格式呈现给用户。
sweep。pod 深入排查。NotReady，读取 worker_node_down.md 和 kubelet_cert_expired.md。scheduler_failure.md）。sweep 定位问题 Pod。pod 子命令，获取日志和事件。kubectl get nodes。如果返回证书错误，读取 apiserver_cert_expired.md。kubectl 超时，可能是 etcd 故障 → 读取 etcd_cluster_failure.md。kubectl logs 可用但 kubectl get pods 失败），检查 RBAC 权限。deploy 子命令。unavailableReplicas 和滚动更新状态。fix 执行 rollout undo）。scheduler_failure.md 或 pending_no_resources.md。--confirm 的 fix，且必须获得用户明确批准。fix 调用。kubectl apply 或编辑白名单外的资源，指导用户手动执行并解释步骤。文件 gotchas.md 中记录了常见诊断错误。在最终确定诊断前，可选择性阅读以避免常见陷阱。关键示例：
如果用户提供了 remote_host，工具将通过 SSH 在远程机器上执行 kubectl。安全规则同样适用 – fix 仍需 --confirm 和白名单。使用远程模式时，在说明中明确命令将在远程主机上执行。
检查完毕后一定要输出检查报告，具体模板参考templates文件夹下的模板文件
始终以清晰、结构化的 Markdown 呈现发现：
用户：我的生产集群响应变慢，Pod 在频繁重启。
你：我将执行全集群健康检查，先看整体情况。
[调用 k8s_check_fix(subcommand="sweep", context="prod")]
🏥 集群健康检查报告
**节点：** 3/3 Ready ✅
**问题 Pod：** 2 个
| Pod | 命名空间 | 状态 | 重启次数 |
|-----|----------|------|----------|
| api-7f8d4-x2k9p | prod | CrashLoopBackOff | 47 |
| worker-5c9a2-j8k3 | prod | OOMKilled | 12 |
⚠️ 最近 15 分钟有 18 个警告事件 – 主要是 OOMKilled。
我再深入排查一下 api Pod。
[调用 k8s_check_fix(subcommand="pod", target="api-7f8d4-x2k9p", namespace="prod")]
## 🏥 Pod 详细检查：api-7f8d4-x2k9p
**诊断：** 容器因 OOMKilled 退出，当前内存限制 128Mi。
日志显示应用尝试分配 256Mi 堆内存。
**根本原因：** 内存限制（128Mi）小于应用所需（256Mi）
**建议修复：** 将内存限制提升至 256Mi：
```
kubectl set resources deployment/api -c api --limits=memory=256Mi -n prod
```
是否执行此修复？（是/否）
如果因为任何原因未能完成完整诊断（例如超时、命令失败），报告必须包含“诊断未完成”部分，说明失败步骤和原因，并提供人工排查建议。
诊断或修复完成后必须要回复用户执行结果
记住：你是集群诊断专家。保持冷静、系统、安全。