anton-cluster-health

Triage Anton cluster Kubernetes health from CNI/DNS to apps.

3|Updated May 13, 2025
One-click install
npx skills add https://github.com/wcygan/anton --skill anton-cluster-health
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: anton-cluster-health
Source: https://github.com/wcygan/anton/tree/main/.claude/skills/anton-cluster-health
Command: npx skills add https://github.com/wcygan/anton --skill anton-cluster-health

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Provides a safe, read-only triage of the Kubernetes stack from the network and control planes down to applications, helping operators quickly determine if the cluster is healthy and where to start investigating.

Core Features & Use Cases

  • Read-only triage across layers 3–6 (CNI/DNS → Flux → platform components → apps), never mutating cluster state.
  • Guided, stepwise checks that surface the first failing layer and point to the appropriate next skill (e.g., debug-flux-reconciliation, upgrade-talos-or-k8s).
  • Explicit handling of silent-killer scenarios (1Password ESO store readiness, envoy gateway programming, cloudflared tunnel status) to avoid false positives from Flux alone.

Quick Start

Describe the current health of the Anton cluster by running the layer-3 to layer-6 triage and report the first red layer and recommended next steps.

Frequently Asked Questions about anton-cluster-health

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I triage Kubernetes cluster health across the network and application stack?

Kubernetes cluster health triage runs read-only checks from the CNI/DNS layer up through Flux, cert-manager, and applications to surface the first failing layer. It reports the initial red layer and recommends targeted next steps for investigation.

How does read-only Kubernetes triage handle silent-killer scenarios in Flux and gateway components?

Kubernetes triage explicitly checks silent-killer scenarios like 1Password ESO store readiness, envoy gateway programming, and cloudflared tunnel status to prevent false positives from Flux health checks alone. It identifies the actual failing component.

Can I use this triage to check if my Anton cluster is healthy without mutating cluster state?

Yes, the triage performs strictly read-only checks across layers 3 through 6, ensuring no mutations to the Kubernetes cluster state. It safely determines if the Anton cluster is healthy and pinpoints where to start investigating failures.

What is the best way to diagnose Flux, cert-manager, or ESO issues in a Kubernetes cluster?

Diagnosing Flux, cert-manager, or ESO issues requires a stepwise triage that checks the CNI/DNS network layer first, then platform components, and finally applications. This approach surfaces the first failing layer and points to the appropriate next debugging skill.

Why does my Kubernetes cluster show healthy Flux reconciliation but applications are still failing?

Applications can fail despite healthy Flux reconciliation due to underlying CNI/DNS issues or silent-killer scenarios like unready 1Password ESO stores or misconfigured envoy gateways. The triage checks these dependencies first before evaluating Flux status.

What are the limitations of using read-only triage for Kubernetes debugging?

Read-only triage limitations include its inability to mutate cluster state or automatically resolve detected failures. It only identifies the first failing layer and recommends next steps, requiring a separate debugging skill to execute actual remediation.