Claude Code 插件实战用/status命令构建 Kubernetes 多维度系统健康巡检【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto本文基于 claude-howto 仓库中devops-automation插件07-plugins/devops-automation的/status斜杠命令定义commands/status.md展开。/status是插件内置的系统健康巡检命令用于在部署、发布、排障等场景下快速掌握集群与服务的整体运行状况。读完本文你将理解/status的六步巡检流程、其底层脚本实现、Kubernetes MCP 集成方式以及如何把它与/deploy、/rollback、/incident组合成完整的 DevOps 运维闭环。一、/status在 devops-automation 插件中的定位devops-automation是 claude-howto 仓库 07 章节Plugins下提供的完整 DevOps 自动化插件覆盖部署、监控与故障响应三大场景。插件通过/plugin install devops-automation安装后会提供四个斜杠命令命令用途/deploy部署到生产或预发staging环境/rollback回滚到上一个版本/status检查系统健康状况/incident处理生产故障结构化响应其中/status的定位是系统健康巡检。commands/status.md的文件头元数据明确了这一点--- name: System Status description: Check overall system health and status ---也就是说在 Claude Code 中输入/status时Claude 会依据这段命令定义对全部相关服务执行一次整体健康检查而不是只针对单一组件。二、/status六步巡检流程命令定义核心commands/status.md明确定义了/status执行时要完成的六步巡检流程这是整条命令的核心骨架Query Kubernetes pod status—— 查询 Kubernetes Pod 状态确认工作负载的调度与运行情况Check database connections—— 检查数据库连接验证存储层可达性与健康度Monitor API response times—— 监控 API 响应时间评估服务响应性能Review error rates—— 审查错误率识别异常流量与失败请求Check resource utilization—— 检查资源利用率CPU、内存、Pod 配额等Report overall health—— 汇总以上所有维度输出整体健康报告。这六步依次覆盖了计算层Pod→ 存储层数据库→ 接入层API→ 质量指标错误率→ 容量指标资源利用→ 汇总报告形成了一条从底层到上层、从单项指标到整体结论的完整巡检链路。命令元数据还记录了兼容的模型范围与 Claude Code 版本要求Claude Code 版本2.1.220插件 README 要求 Claude Code 2.1兼容模型Claude Fable 5、Claude Opus 5、Claude Sonnet 5、Claude Sonnet 4.6、Claude Opus 4.8、Claude Haiku 4.5以status.md文件头声明为准。三、巡检的底层实现health-check.sh逐行解读六步流程中的前几步在插件脚本中有着对应的真实实现。/status可以直接调用或参考 scripts/health-check.sh 完成自动化检查。该脚本用纯 Bash 编写结构清晰#!/bin/bash echo System Health Check echo ENV${1:-production} # Check API echo -n API: if curl -sf http://api.$ENV.example.com/health /dev/null; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Database echo -n Database: if pg_isready -h db.$ENV.example.com /dev/null 21; then echo ✅ Healthy else echo ❌ Unhealthy fi # Check Pods echo -n Kubernetes Pods: PODS_READY$(kubectl get pods -n $ENV --no-headers | grep Running | wc -l) PODS_TOTAL$(kubectl get pods -n $ENV --no-headers | wc -l) echo $PODS_READY/$PODS_TOTAL ready echo 脚本的关键设计点环境参数L6ENV${1:-production}通过第一个位置参数指定巡检目标环境如staging/production默认值为production。这与插件其他脚本deploy.sh、rollback.sh统一采用ENV${1:-...}的参数约定保证整个插件命令风格一致API 健康检查L9-L14用curl -sf探测http://api.$ENV.example.com/health-s静默模式、-f在 HTTP 4xx/5xx 时失败退出成功则输出 ✅ Healthy失败输出 ❌ Unhealthy数据库检查L16-L22使用 PostgreSQL 自带工具pg_isready -h db.$ENV.example.com探测数据库就绪状态并将标准错误重定向到/dev/null仅以退出码作为判断依据Pod 状态统计L24-L28通过kubectl get pods -n $ENV --no-headers获取该命名空间全部 Pod再分别统计总数量与处于Running状态的数量最终输出ready/total的 Pod 就绪比例——这正是/status流程第 1 步“Query Kubernetes pod status”的落地实现。从实现看API 检查对应六步流程的“API 响应时间监控”的可执行子集可用/health端点附带返回时延数据库检查对应“数据库连接检查”Pod 统计对应“Kubernetes Pod 状态查询”。而错误率与资源利用率属于需要结合监控平台数据的维度脚本中未硬编码交由 Claude 结合alert-analyzer子代理与 Kubernetes MCP 的数据来完成。四、Kubernetes MCP让 Claude 直接“看到”集群/status要查询 Pod 状态、资源利用率依赖 Claude 对集群的可观测能力。插件通过 MCPModel Context Protocol服务接入 Kubernetes配置见 mcp/kubernetes-config.json{ mcpServers: { kubernetes: { command: npx, args: [modelcontextprotocol/server-kubernetes], env: { KUBECONFIG: ${KUBECONFIG} } } } }配置要点通过npx modelcontextprotocol/server-kubernetes启动 Kubernetes MCP 服务器通过环境变量KUBECONFIG注入集群凭据${KUBECONFIG}引用宿主环境变量从而无需把 kubeconfig 明文写入配置文件接入后Claude 即可调用 MCP 提供的集群工具来列举 Pod、读取状态、查询资源用量为/status的第 1、5 步Pod 状态、资源利用率提供实时数据来源。对应地插件 README 要求运行前先配置集群访问export KUBECONFIG~/.kube/config前置要求来自 07-plugins/devops-automation/README.mdClaude Code 2.1 及以上版本Kubernetes CLIkubectl已安装集群访问已配置KUBECONFIG指向有效配置。五、alert-analyzer子代理告警关联与根因分析/status的第 4 步“Review error rates”与整体健康结论需要分析维度的支撑。插件为此提供了专用子代理alert-analyzeragents/alert-analyzer.md其定义为--- name: alert-analyzer description: Analyzes monitoring alerts and system metrics tools: Read, Grep, Bash ---该子代理被授予Read、Grep、Bash三类工具专门负责告警关联Alert correlation将多个分散告警归并识别同根因事件趋势分析Trend analysis基于时序指标判断系统状态是恶化还是恢复根因识别Root cause identification从告警与指标中定位故障根源指标可视化Metric visualization将数值指标整理为可读的图表/汇总主动问题检测Proactive issue detection在故障发生前发现异常征兆。在实际的/status执行中Claude 可以委派alert-analyzer分析错误率与指标趋势再结合health-check.sh的探测结果与 Kubernetes MCP 的集群数据综合输出第 6 步的“整体健康报告”。六、组合出击/status在 DevOps 运维闭环中的角色/status并非孤立命令它与插件内其他命令协同构成完整的运维闭环结构可见 07-plugins/devops-automation 与各命令定义部署后验收/deploy执行完成后流程见 commands/deploy.md底层脚本为 scripts/deploy.sh立即运行/status验证新版本各组件健康度形成“部署 → 巡检”的验收链路。部署侧还有 hooks/pre-deploy.js 校验 kubectl 与集群连接、hooks/post-deploy.js 等待 Pod ready 并执行冒烟测试回滚前判断/status发现健康度不达标时可用/rollbackscripts/rollback.sh快速回退到上一版本回滚后再次/status确认恢复故障响应入口/status定位到异常后可转入/incidentcommands/incident.md启动结构化故障响应由incident-commanderagents/incident-commander.md负责定级、协调与复盘。一个典型的端到端巡检会话大致如下用户/status Claude 1. 调用 Kubernetes MCP 查询集群 Pod 状态running / 总数、异常 Pod 2. 执行 health-check.sh或等效检查探测 API /health 与数据库连接 3. 委派 alert-analyzer 分析错误率与指标趋势 4. 汇总资源利用率CPU / 内存 / Pod 配额 5. 输出整体健康报告 结果 System Health Check API: ✅ Healthy Database: ✅ Healthy Kubernetes Pods: 3/3 ready Error rate: 0.05%24h 窗口 Resource utilization: CPU 42% / Memory 61% Overall: ✅ Healthy七、适用前提与限制说明结合仓库实际内容使用/status前需要明确以下几点文中api.$ENV.example.com、db.$ENV.example.com等主机名来自 scripts/health-check.sh 的示例实现实际使用时需替换为你自己的服务域名与命名空间数据库检查依赖pg_isreadyPostgreSQL 客户端工具若你的存储层非 PostgreSQL需要调整对应的健康探测命令health-check.sh仅覆盖 API、数据库、Pod 三个可自动探测维度错误率、响应时间、资源利用率等维度需要结合监控平台数据与alert-analyzer子代理的分析能力补全命令元数据声明的兼容模型与 Claude Code 版本以 commands/status.md 与插件 README.md 为准使用前请确认本地环境版本满足要求。八、小结/status是 devops-automation 插件中一个麻雀虽小、五脏俱全的斜杠命令命令定义commands/status.md给出六步巡检流程脚本scripts/health-check.sh提供可执行的健康探测Kubernetes MCPmcp/kubernetes-config.json打通集群实时数据alert-analyzer子代理agents/alert-analyzer.md补足分析能力。将/status与/deploy、/rollback、/incident串接起来即可在 Claude Code 中形成部署 → 巡检 → 回滚 → 响应的完整 DevOps 运维闭环。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
