协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
castai-common-errors【开发与工程】Diagnose CAST AI connection, agent, node autoscaling, and workload autoscaling failures without making speculative changes. Use when a cluster is disconnected, recommendations are absent, pods are not optimized, or capacity does not scale as expected. Trigger with: "debug CAST AI", "CAST AI is not scaling", "why is CAST AI disconnected".
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
name: castai-common-errors description: 'Diagnose CAST AI connection, agent, node autoscaling, and workload autoscaling failures without making speculative changes. Use when a cluster is disconnected, recommendations are absent, pods are not optimized, or capacity does not scale as expected. Trigger with: "debug CAST AI", "CAST AI is not scaling", "why is CAST AI disconnected".' allowed-tools: Read, Grep, Bash(kubectl:), Bash(helm:), Bash(castctl:*) version: 2.0.0 argument-hint: '[cluster-context-or-symptom]' model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:
Separate observation, connectivity, policy, capacity, and disruption failures before proposing a change. Preserve the failing state, use current component topology, and stop when the evidence requires cloud-provider or CAST AI support access.
castai-agent namespaceRecord expected versus actual behavior, timestamps, workload identity, pending-pod reason, and recent configuration changes. Use Read and Grep on runbooks and IaC to determine whether Cost Monitoring, Node Autoscaling, or Workload Autoscaling is actually enabled.
Use Bash(castctl:) for version or non-mutating status commands supported by the installed client. Use Bash(helm:) to inspect releases and values, then Bash(kubectl:*) to inspect workloads, readiness, events, and bounded logs in castai-agent. Do not restart components before collecting evidence.
| Plane | Evidence | Likely boundary |
|---|---|---|
| Connection | Agent readiness, outbound failures, console disconnect | Identity, network, or cloud permissions |
| Node scaling | Pending pods, policy bounds, node-template fit | Unsatisfied constraints or maximum CPU boundary |
| Workload scaling | Missing recommendations, policy assignment, metrics | Metrics server, confidence, policy, or unsupported workload |
| Disruption | Eviction denial, PDB events, deferred changes | PDB or selected apply mode |
| Reporting | Missing cost or savings window | Ingestion, baseline, adoption, or pricing configuration |
Choose the smallest reversible check. Confirm regional endpoint alignment, effective scaling-policy assignment, metrics availability, supported workload type, node-template constraints, and cloud quota. Treat the deprecated cluster minimum CPU setting as migration debt, not a current control to add.
Map the evidence to the owning layer. Change repository-managed values only through their source of truth; do not mix console edits into Terraform or GitOps ownership. Escalate with a redacted bundle when the failure is inside the hosted control plane or an undocumented provider response.
Use Read and Grep for configuration and runbook evidence. Use Bash(kubectl:), Bash(helm:), and Bash(castctl:*) only for bounded inspection commands. Do not apply, upgrade, restart, connect, disconnect, or expose Secret objects during diagnosis.
Recommendations are absent because metrics-server is missing, so the remedy belongs to cluster observability. A node remains pending because every approved node template conflicts with its constraints; increasing a global limit without reviewing the workload is not the remedy.
| Failure | Response |
|---|---|
| Kube context is ambiguous | Stop before any cluster command and resolve it |
| Logs include credentials or inventory | Redact locally and do not attach raw output |
| A PDB blocks Immediate mode | Preserve the PDB and evaluate Deferred mode with the workload owner |
| Evidence points to cloud quota | Escalate to the cloud owner with the exact denied dimension |