container-management:cluster-diagnosis git:20260918.2022c1eA

Immutable. This exact content is served forever at /api/v1/blob/6210f9cb8744a66b.

---
name: container-management:cluster-diagnosis
description: >
  Use when a user asks to inspect, health-check, patrol/巡检, diagnose, or
  troubleshoot a Kubernetes cluster managed by the DCE/kpanda module. Covers
  cluster health overview, node status, abnormal Pods, events, cluster
  unavailability, node NotReady, pending or failed Pods, and Chinese requests
  like 集群巡检、集群体检、检查集群健康状态、排查集群异常、查看集群状态.
---

# Kpanda Cluster Diagnosis

Diagnose cluster health through a standardized 4-step inspection workflow.

**REQUIRED SUB-SKILL:** Use `dce` for all command execution, auth checks, and catalog discovery.

## Workflow

### Step 1 — Cluster Overview
- `dce container-management cluster get-cluster --name <cluster> -o json`
- Verify cluster exists and status is Running. If not, report immediately.

### Step 2 — Node Health
- `dce container-management core list-nodes --cluster <cluster> -o json`
- Flag NotReady, Cordoned, or pressured nodes. Continue regardless.

### Step 3 — Abnormal Pod Discovery
- `dce container-management core list-pods --cluster <cluster> -o json`
- Find Pods not in Running/Succeeded. Collect by namespace. If none, skip Step 4.

### Step 4 — Deep Diagnosis
- `dce container-management core list-cluster-events --cluster <cluster> -o json`
- `dce container-management core get-pod --cluster <cluster> --namespace <ns> --name <pod> -o json`
- Correlate events with Pod states to infer root cause.

## User omitted cluster name
Run `dce container-management cluster list-clusters -o json`, present list, ask user to pick one.

## Auth not established
Stop and instruct user to run `dce auth login --hostname <host>`.

## Output Format

Present the final answer as structured Markdown. Do not include a step-by-step
tool execution log, skill loading details, API retry details, JSON parsing
details, or other internal process unless the user explicitly asks for them.
If data is incomplete, explicitly say that the judgment is based on currently
available data in the conclusion.

Use these top-level sections in this order. Treat the template as the report
spine, not as a limit on evidence: preserve domain-specific tables and details
inside the matching sections when they are needed to support the conclusion.

# Conclusion

Use 1-2 sentences to state the current judgment, risk level
(`normal` / `watch` / `risk` / `critical`), and the most important issue.
For user-facing answers, localize the section title and risk labels to the
user's language.

## Key Metrics

Start with a Markdown summary table with 3-6 key indicators. Prefer these
fields when available: cluster status, node Ready ratio, NotReady/Cordoned node
count, abnormal Pod count, warning event count, and top affected namespace.

| Metric | Current Value | Status |
|--------|---------------|--------|
| Cluster status | `<value>` | `<normal/watch/risk/critical>` |

If the cluster has meaningful abnormalities, include supporting detail tables
under this section, such as:

- Node health: `Node | Ready | Schedulable | Pressure | Key condition`
- Pod anomalies: `Namespace | Phase/Reason | Count | Impact`
- Event highlights: `Type | Reason | Object | Last seen | Impact`

## Main Findings

Use a numbered list with 2-3 findings. Each finding must explain the impact.
Do not collapse multiple independent cluster risks into one generic finding; if
nodes, Pods, and events point to different risks, keep them distinct.

## Cause Analysis

Analyze 2-3 causes around the main findings. For each cause, include:

Cause N: `<cause>`

Evidence: `<specific event, node state, pod state, or metric>`.

Impact: `<user-visible or operational impact>`.

## Recommended Actions

Group concrete actions by:

### Immediate

### Monitor

### Optimize Later

## Follow-up Questions

Provide 2-3 copyable follow-up questions in the user's language. They should
guide the user toward deeper root-cause analysis, remediation planning, or an
exportable stakeholder report.

## Rules

- Prefer `-o json` for machine-readable output.
- Do not guess flags or body shape. Confirm with `dce commands show` before executing unfamiliar commands.
- Report empty API responses as "no resources found" rather than silently skipping.
- Do not perform remediation (restart, delete, scale). This skill is read-only.
- Put the conclusion first. Do not write the final answer as a troubleshooting
  transcript.
- Use tables for indicators whenever possible.
- Recommended actions must be specific and executable.