Skip to content

keda trait cannot set trigger-level metricType — CPU/memory scalers broken on KEDA v2.18+ #6738

Description

@wojciechgrazawskiahnl

What happened

The keda trait cannot emit a trigger-level metricType. Its trigger model (KedaTrigger) only carries type, metadata and secrets, and the trait copies only Type and Metadata into the generated ScaledObject. As a result the trait cannot produce a valid cpu or memory ScaledObject on KEDA v2.18+.

KEDA v2.18 removed the CPU/memory scaler's metadata.type field and now requires the metric type to be given as a trigger-level metricType, with no default (an empty metricType is rejected). See the KEDA CPU scaler docs: https://keda.sh/docs/2.18/scalers/cpu/

Because the only way to express the metric type through the trait is metadata.type (which the trait passes through verbatim), the generated ScaledObject is rejected by KEDA v2.18 at reconcile time.

How to reproduce

Deploy an Integration with a CPU trigger via the keda trait on a cluster running KEDA v2.18+:

traits:
  container:
    requestCPU: 200m          # a request is required for a Utilization metric
    limitCPU: 500m
  keda:
    enabled: true
    minReplicaCount: 1
    maxReplicaCount: 3
    triggers:
      - type: cpu
        metadata:
          type: Utilization    # only way to express metric type via the trait
          value: "70"

The resulting ScaledObject never becomes Ready:

Status:
  Conditions:
    Type:     Ready
    Status:   False
    Reason:   ScaledObjectCheckFailed
    Message:  failed to ensure HPA is correctly created for ScaledObject:
              error parsing cpu metadata: scaler cpu info: The 'type' setting is
              DEPRECATED and is removed in v2.18 - Use 'metricType' instead.

Root cause

Trait trigger model — pkg/apis/camel/v1/trait/keda.go (main):

type KedaTrigger struct {
	// The autoscaler type.
	Type string `json:"type,omitempty" property:"type"`
	// The trigger metadata (see Keda documentation to learn how to fill for each type).
	Metadata map[string]string `json:"metadata,omitempty" property:"metadata"`
	// The secrets mapping to use. Keda allows the possibility to use values coming from different secrets.
	Secrets []*KedaSecret `json:"secrets,omitempty" property:"secrets"`
}

No metricType.

Trait apply — pkg/trait/keda.go, populateTriggers() (main):

scaleTrigger := v1alpha1.ScaleTriggers{
	Type:     trigger.Type,
	Metadata: trigger.Metadata,
}

Only Type and Metadata are copied.

Camel K's own KEDA duck type — pkg/apis/duck/keda/v1alpha1/duck_types.go (main) — also omits the field, so even if the trait set it the generated object could not serialize it:

type ScaleTriggers struct {
	Type string `json:"type"`
	// +optional
	Name     string            `json:"name,omitempty"`
	Metadata map[string]string `json:"metadata"`
	// +optional
	AuthenticationRef *ScaledObjectAuthRef `json:"authenticationRef,omitempty"`
	// +optional
	FallbackReplicas *int32 `json:"fallback,omitempty"`
}

Expected behaviour

The keda trait should allow a per-trigger metricType, e.g.:

keda:
  triggers:
    - type: cpu
      metricType: Utilization
      metadata:
        value: "70"

and emit it as the trigger-level spec.triggers[].metricType of the generated ScaledObject:

spec:
  triggers:
    - type: cpu
      metricType: Utilization
      metadata:
        value: "70"

Affected versions

Present in all versions through main (checked 2.5.1, 2.6.0, 2.7.0, 2.8.0, and main; the trait moved from addons/keda/keda.go to pkg/trait/keda.go between 2.5.x and 2.6.x but the data model is unchanged). Impact is limited to KEDA v2.18+ and to scalers that now require a trigger-level metricType (cpu, memory); other scalers (kafka, cron, prometheus, …) are unaffected because they don't use metadata.type.

Environment

  • Camel K: 2.5.1 (verified the gap also exists through main)
  • KEDA: v2.18+

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions