troubleshoot-kubernetes-api-server

Diagnose Kubernetes API Server incidents using Netdata MCP metrics.

1|Updated Apr 17, 2026
One-click install
npx skills add https://github.com/netdata/skills --skill troubleshoot-kubernetes-api-server
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: troubleshoot-kubernetes-api-server
Source: https://github.com/netdata/skills/tree/main/skills/troubleshoot-kubernetes-api-server
Command: npx skills add https://github.com/netdata/skills --skill troubleshoot-kubernetes-api-server

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you diagnose Kubernetes API Server incidents by mapping symptoms like webhook stalls, list storms, etcd latency cascades, memory cliffs, and RBAC/auth slowdowns to the specific Netdata-observed health signals and an operator-style diagnostic tree.

Core Features & Use Cases

  • MCP-driven triage: Queries Netdata via MCP for Kubernetes API Server health contexts (for example request rate, dropped requests, audit events, workqueue adds/retries, and latency percentiles) to quickly isolate the failure archetype.
  • Operator playbook alignment: Applies the Netdata operator playbook’s remediation logic by following the same dominant failure patterns, while using Netdata signals as the source of truth.
  • Actionable verification loop: Re-runs targeted MCP verification queries after remediation to confirm signals return to expected bands and avoids “looks fixed” misdiagnoses.

Quick Start

Use the troubleshoot-kubernetes-api-server skill to pull the last 15–30 minutes of Kubernetes API Server MCP metrics for the affected node, identify the dominant failure archetype, and select the matching remediation path from the operator playbook.

Frequently Asked Questions about troubleshoot-kubernetes-api-server

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

FAQPage Schema
How do I troubleshoot Kubernetes API server latency and dropped requests?

To troubleshoot Kubernetes API server latency and dropped requests, query Netdata via MCP for k8s_apiserver contexts to identify dominant failure archetypes like webhook stalls or etcd latency cascades, then apply operator playbook remediation and re-verify the metrics.

What causes Kubernetes API server saturation and 429 errors?

Kubernetes API server saturation and 429 errors are caused by failure archetypes such as list storms, RBAC slow bleeds, and webhook stalls, which you can isolate by analyzing Netdata workqueue and request rate metrics through MCP queries.

How do I diagnose etcd latency cascades affecting the Kubernetes API server?

Diagnose etcd latency cascades affecting the Kubernetes API server by pulling the last 15–30 minutes of MCP metrics, ranking anomalies by context patterns, and following the diagnostic tree to map symptoms to the specific Netdata health signals.

Can I use Netdata MCP to verify Kubernetes API server remediation after a fix?

You can use Netdata MCP to verify Kubernetes API server remediation by re-running targeted verification queries after applying fixes to confirm that request rates, dropped requests, and latency percentiles return to their expected bands.

Does this Kubernetes API server triage process work for OOM-like behavior and unexpected restarts?

Yes, this triage process works for OOM-like behavior and unexpected restarts by mapping those symptoms to memory cliff failure archetypes using Netdata-observed health signals, ensuring you avoid misdiagnoses with a verification loop.