Schedule icon
Get icon
Script icon
OutputValues icon
If icon
SlackIncomingWebhook icon
Fail icon
Log icon

Block Deployments When Kubernetes Autoscaling Is Unhealthy

Check Kubernetes HorizontalPodAutoscaler conditions and fail a Kestra workflow when scaling is limited or controller status is stale.

Categories
CloudInfrastructure

Check one Kubernetes HorizontalPodAutoscaler (HPA) before a rollout or on a schedule. This flow is read-only. It does not change replica counts.

How it works

  1. read_hpas reads autoscaling/v2 HPAs from the selected namespace.
  2. check_scaling selects the exact HPA, checks observedGeneration and replica bounds, and inspects AbleToScale, ScalingActive, and ScalingLimited.
  3. publish_evidence saves the PASS/BLOCK decision and JSON report URI.
  4. scaling_gate sends a Slack alert and fails the flow on BLOCK. Invalid or absent API data never produces PASS.

What you get

  • Exact replica values, condition state, scaling-limit reason, and a JSON report.
  • A failure gate for an unhealthy autoscaler or stale controller status.
  • A PASS when the controller is healthy, even when replicas are temporarily at maxReplicas without a reported limit.

Who it's for

  • Platform engineers who manage Kubernetes autoscaling.
  • SREs who need an explicit gate before production rollouts.

Why orchestrate this with Kestra

This flow keeps the check, report, alert, and failure state in one execution. Downstream tasks can depend on the result.

Prerequisites

  • Kubernetes API read access to horizontalpodautoscalers in the selected namespace.
  • A working Node Script task runner and Slack incoming webhook.
  • Kubernetes autoscaling/v2 and an HPA with status conditions.

Secrets

  • K8S_MASTER_URL: trusted Kubernetes API URL.
  • K8S_TOKEN: service account token with get/list HPA permissions.
  • SLACK_WEBHOOK_URL: Slack incoming webhook for blocked checks.

Quick start

  1. Set the secrets, namespace, and hpa_name.
  2. Run against a healthy HPA. Open outputs.publish_evidence.values.report_uri.
  3. Test with ScalingLimited=True and with stale observedGeneration.
  4. Check Slack delivery. Enable the disabled schedule only after both paths work.

How to extend

  • Use this as a gate before a deployment subflow.
  • Record reports in object storage to compare successive checks.
  • Evaluate HPA conditions across a selected set of workloads.

Limits

  • ScalingLimited=True indicates a controller limit, not necessarily an outage.
  • Hitting maxReplicas alone does not prove a scaling problem and does not block.
  • This is one API snapshot, not a historical capacity or latency measurement.
  • A missing target, malformed response, or failed API call cannot authorize a rollout.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.