HPA and KEDA

When automating a workload, ScaleOps automatically updates HPA or KEDA Scalers for cpu and memory utilization triggers according to the pod’s original resource request to keep the original triggers behavior.

This mechanism will keep the exact same behaviour for horizontal scaling while optimizing the pod’s resources.

HPA

When a workload has HPA set with a trigger of targetAverageUtilization for resource type of either cpu or memory, ScaleOps will automatically update the HPA trigger to targetAverageValue to keep the same horizontal scaling trigger with the pod’s new size.

KEDA

When a workload has KEDA Scaler set with a trigger of Utilization for resource type of either cpu or memory, ScaleOps will automatically update the KEDA Scaler trigger to AverageValue to keep the same horizontal scaling trigger with the pod’s new size.

Terraform-managed HPAs

When HPA resources are managed by Terraform, ScaleOps modifications to spec.metrics, metadata.labels, and metadata.annotations may be detected as drift and reverted on the next terraform apply. This can cause repeated deployment failures due to resource conflicts with the scaleops-hpa-controller.

To prevent this, configure computed_fields to allow ScaleOps to manage these fields without Terraform reverting them:

resource "kubernetes_manifest" "hpa" {
  manifest = yamldecode(file("path_to_hpa"))
  field_manager {
    force_conflicts = true
  }
  computed_fields = ["spec.metrics", "metadata.labels", "metadata.annotations"]
}

This tells Terraform to treat these fields as externally managed, so ScaleOps can update HPA triggers and metadata alongside Terraform without conflicts.