SkillVaultskills Browse all 500 skills

Infrastructure · Version 1.3.0 · Reviewed 2026-08-02

Kubernetes Resource Tuner

Review and harden request and limit sizing and throttling diagnosis with evidence, explicit trade-offs, and a verification plan.

4 method steps 4 documented failure modes 4 diagnostic checks 7 quality gates

Sets requests, limits, QoS class, and autoscaling targets from measured usage instead of guesswork, and explains the throttling trade-off.

₹149 one-time

Get this skill archive

What this skill helps you do

  • Request and limit sizing
  • Throttling diagnosis
  • Autoscaler tuning

How Kubernetes Resource Tuner works

You provide

Usage metrics, current requests and limits, autoscaler config

It inspects

Throttling counters rather than average utilization

It decides

Requests, limits, and QoS class sized from measurement

You verify

Throttled seconds fall while latency variance narrows

What it checks first

Kubernetes Resource Tuner sets requests, limits, QoS class, and autoscaling targets from measured usage instead of guesswork, and explains the throttling trade-off. Use it when the work involves Request and limit sizing, Throttling diagnosis, Autoscaler tuning.

  1. Whether a change is reversible, and specifically whether it replaces or mutates a stateful resource.
  2. Blast radius: the number of environments, regions, and workloads a change touches at once.
  3. Identity and permission scope of the executing principal.
  4. Drift between declared and actual state.

Failure modes it recognizes

  • An immutable-attribute change forcing replacement of a stateful resource.
  • A change applied to all environments simultaneously with no canary.
  • Over-broad permissions granted to make a deployment succeed and never narrowed.
  • Manual changes creating drift that the next apply silently reverts.

Answers it will reject

  • Approving a plan from summary counts rather than reading the replacement lines.
  • Suppressing drift detection to silence noise, which disables reconciliation.
  • Granting administrative rights as a debugging shortcut.

Decision rules it applies

  • Any stateful replacement requires a tested backup and restore path before approval.
  • Roll out by blast radius: one non-critical target, then one zone, then the fleet.
  • Grant the narrowest permission that completes the task, with an expiry.

Evidence it asks for

  • Diff the plan in machine-readable form and classify every action.
  • Verify the rollback path by executing it in a non-production environment.
  • Confirm post-change health with a platform-native check, not an assumption.

The method inside

  1. Establish what is actually true about request and limit sizing from the supplied evidence, and mark what is missing.
  2. Identify the mechanism behind throttling diagnosis rather than restating the symptom.
  3. Choose the smallest defensible change for autoscaler tuning, weighing impact, confidence, effort, and reversibility.
  4. Verify with platform-native checks

Deliverables

  • Request and limit sizing assessment
  • Throttling diagnosis decision and action plan
  • Autoscaler tuning verification checklist

Evidence requirements

  • Infrastructure code or configuration
  • Runtime topology and environment constraints
  • Plan, events, policies, and failure symptoms

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Our pods are not OOMKilled but latency is spiky and unpredictable. Resource usage looks fine.

Expected output

Average usage looking fine while latency is spiky is the signature of CPU throttling against a limit. Check container_cpu_cfs_throttled_seconds_total rather than utilization, because a container can be throttled hard while showing modest average CPU...

Boundaries and compatibility

Ideal for

  • Request and limit sizing: produce a decision or artifact grounded in supplied evidence.
  • Throttling diagnosis: produce a decision or artifact grounded in supplied evidence.
  • Autoscaler tuning: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Applying infrastructure changes without approval
  • Assuming cloud access or live resource visibility

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.