Run any Skill in Manus with one click

autoscale-findings

Stars4

Forks2

UpdatedJuly 2, 2026 at 01:54

Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

confighub

confighub/examples

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	autoscale-findings
description	Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.
phase	verify
allowed-tools	Bash(cub-autoscale --help) Bash(cub-autoscale * --help) Bash(cub auth status) Bash(cub-autoscale preflight) Bash(cub-autoscale findings) Bash(cub-autoscale findings *)

autoscale-findings

Report autoscaling anti-patterns across the fleet, most-severe first. Read-only.

Why this matters

Three high-signal checks that need no live cluster facts, over ConfigHub-managed Units only:

autoscaler-pinned (medium) — an HPA/ScaledObject with min == max: it's an autoscaler that can't scale.
pdb-blocks-min-scale (medium) — the cross-resource case: a PodDisruptionBudget whose minAvailable is >= the autoscaler's minReplicas (or 100%), so at minimum scale no pod may be voluntarily evicted (node drains stall). This join of HPA minReplicas against PDB minAvailable is the check no single-resource validator makes.
no-autoscaler (low) — a Deployment/StatefulSet no HPA or ScaledObject targets.

When to use

"What autoscaling problems do we have?" → findings.
"Which HPAs can't actually scale?" → findings (autoscaler-pinned).
"Is a PDB blocking scale-down anywhere?" → findings (pdb-blocks-min-scale).
"Which workloads lack an autoscaler?" → findings (no-autoscaler).
"Autoscaling findings for prod / the ml component." → findings --environment prod / --component ml.

Do not load for

The raw autoscaler inventory — use autoscale-audit (list, snapshot).
Fixing autoscaling — use autoscale-edit.
Live cluster state — kubectl.

Preflight gates

cub-autoscale preflight succeeds. If it fails, ask the user to run cub auth login (interactive) and retry.

The toolkit

cub-autoscale findings -o table — severity-ranked findings (--min-severity low|medium|high).

Server-side --where + label shorthands scope the fleet.

Stop conditions

Zero findings — report the fleet is clean for that scope.
The user wants to fix something — hand off to autoscale-edit.

Tool boundary

Read-only. Never use kubectl to answer a ConfigHub-state question.

References

cub-autoscale findings --help.
Companion skills: autoscale-audit, autoscale-edit, autoscale-guardrails.

More from this repository

same repository

cost-management-app-operator

confighub/examples

Operate the Cost Management App app through its generated CLI and browser surface. Use for "Turn fleet cost findings into governed recommendations, approvals, and receipts.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

2026-07-124

add-on-manager-operator

confighub/examples

Operate the Add-on Manager app through its generated CLI and browser surface. Use for "Install, upgrade, review, and prove platform add-ons through governed ConfigHub delivery paths.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

2026-07-024

autoscale-audit

confighub/examples

Inventory and report Kubernetes autoscaling stored in ConfigHub across a fleet with the cub-autoscale CLI — HorizontalPodAutoscalers and KEDA ScaledObjects: each one's scale target, min/max replicas, and whether it is pinned (min == max). Use for "what autoscalers do we have?", "list our HPAs / ScaledObjects", "which workloads are autoscaled?", "per-cluster autoscaler counts", "is autoscaler X pinned?". Not for autoscaling findings/anti-patterns (use autoscale-findings), edits or HPA→KEDA conversion (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-024

autoscale-edit

confighub/examples

Set Kubernetes autoscaling as config-as-data with the cub-autoscale CLI — edit a HorizontalPodAutoscaler's min/max replicas and cpu/memory targets, convert an HPA to a KEDA ScaledObject, apply reusable autoscaling profiles to one Unit or across a whole selector, and promote changes downstream. Use for "raise the HPA max to 20", "set cpu target to 60%", "convert this HPA to KEDA", "make every prod HPA scale out earlier", "apply the hpa-range profile", "roll the autoscaling change downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use autoscale-audit / autoscale-findings) or enforcement Triggers (use autoscale-guardrails).

2026-07-024

autoscale-guardrails

confighub/examples

Install and inspect the autoscaling enforcement pack with the cub-autoscale CLI — an autoscale-policy Space with two Warn=true Triggers: a vet-cel rule that flags any HPA/ScaledObject that is pinned (min == max), and a vet-schemas rule that schema-validates every mutation (the post-convert check for convert-keda output, since keda.sh is in the schema catalog) — wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default) and status (Units with ApplyWarnings/Gates). Use for "enforce that no HPA is pinned", "make sure converted ScaledObjects pass schema validation", "which autoscalers are flagged?". Not for read-only findings (use autoscale-findings) or fixing autoscaling (use autoscale-edit).

2026-07-024

observability-audit

confighub/examples

Inventory the observability posture of Kubernetes workloads stored in ConfigHub across a fleet with the cub-observability CLI — ServiceMonitors, Services (and which expose metrics), and telemetry-sidecar presence. Use for "what ServiceMonitors / Services do we have?", "which Services expose metrics?", "which workloads have an otel sidecar?", "per-cluster observability counts". Not for ServiceMonitor coverage gaps (use observability-findings), fixes (use observability-instrument / observability-guardrails), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-014

name	autoscale-findings
description	Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.
phase	verify
allowed-tools	Bash(cub-autoscale --help) Bash(cub-autoscale * --help) Bash(cub auth status) Bash(cub-autoscale preflight) Bash(cub-autoscale findings) Bash(cub-autoscale findings *)

autoscale-findings

Report autoscaling anti-patterns across the fleet, most-severe first. Read-only.

Why this matters

Three high-signal checks that need no live cluster facts, over ConfigHub-managed Units only:

autoscaler-pinned (medium) — an HPA/ScaledObject with min == max: it's an autoscaler that can't scale.
pdb-blocks-min-scale (medium) — the cross-resource case: a PodDisruptionBudget whose minAvailable is >= the autoscaler's minReplicas (or 100%), so at minimum scale no pod may be voluntarily evicted (node drains stall). This join of HPA minReplicas against PDB minAvailable is the check no single-resource validator makes.
no-autoscaler (low) — a Deployment/StatefulSet no HPA or ScaledObject targets.

When to use

"What autoscaling problems do we have?" → findings.
"Which HPAs can't actually scale?" → findings (autoscaler-pinned).
"Is a PDB blocking scale-down anywhere?" → findings (pdb-blocks-min-scale).
"Which workloads lack an autoscaler?" → findings (no-autoscaler).
"Autoscaling findings for prod / the ml component." → findings --environment prod / --component ml.

Do not load for

The raw autoscaler inventory — use autoscale-audit (list, snapshot).
Fixing autoscaling — use autoscale-edit.
Live cluster state — kubectl.

Preflight gates

cub-autoscale preflight succeeds. If it fails, ask the user to run cub auth login (interactive) and retry.

The toolkit

cub-autoscale findings -o table — severity-ranked findings (--min-severity low|medium|high).

Server-side --where + label shorthands scope the fleet.

Stop conditions

Zero findings — report the fleet is clean for that scope.
The user wants to fix something — hand off to autoscale-edit.

Tool boundary

Read-only. Never use kubectl to answer a ConfigHub-state question.

References

cub-autoscale findings --help.
Companion skills: autoscale-audit, autoscale-edit, autoscale-guardrails.