Configure Autoscaling in GoodData.CN

GoodData.CN services can scale horizontally with load. The Helm chart ships autoscaling definitions built on KEDA, which manages a standard Kubernetes HorizontalPodAutoscaler (HPA) for each enabled service.

Prerequisites

• The KEDA operator (version 2.x) installed in the cluster. The GoodData.CN chart does not install KEDA.
• The Kubernetes metrics-server, which the CPU-based HPAs read their metrics from. Most managed Kubernetes distributions ship it by default.
• GoodData.CN 4.14.0 or later.

Enable Autoscaling

Enable autoscaling for all supported services with a single switch in your Helm values:

kedaAutoscaling:
  enabled: true

KEDA then creates one HPA per service, named keda-hpa-<fullname>-<service>-scaledobject, where <fullname> is the Helm release full name (for example gooddata-cn). Verify them with:

kubectl get hpa --namespace <gooddata-cn-namespace>

What Scales and How

The gen-ai-metadata-sync service is present only when the AI services are deployed (deployGenAIService, deployGenAIMetadataSync).

Scale-up reacts within seconds. Scale-down is stabilized so replica counts stay steady under variable load: UI services scale down after 15 minutes of sustained low load, core API services after 30 minutes, removing at most 25% of current replicas per policy period.

Metric-Based Scaling for Export and AI Services

The export-builder and gen-ai-metadata-sync services scale on workload metrics instead of CPU. They stay off until you enable them per component and point kedaAutoscaling.prometheusAddress to a Prometheus-compatible endpoint that scrapes GoodData.CN metrics:

kedaAutoscaling:
  enabled: true
  prometheusAddress: "http://prometheus.monitoring.svc.cluster.local:9090"

exportBuilder:
  kedaAutoscaling:
    enabled: true

genAiMetadataSync:
  kedaAutoscaling:
    enabled: true

Tune or Opt Out Per Component

Every service accepts overrides under <component>.kedaAutoscaling: enabled, minReplicaCount, maxReplicaCount, and the full HPA behavior block. CPU-scaled services additionally accept targetCPUUtilization; the Prometheus-scaled export-builder and gen-ai-metadata-sync accept query and threshold instead.

Raise the ceiling for a demand-heavy service:

resultCache:
  kedaAutoscaling:
    maxReplicaCount: 8

Opt a single service out while the master switch stays on:

metadataApi:
  kedaAutoscaling:
    enabled: false

See Helm Chart Options for the complete list of values.

Disable Autoscaling

To turn autoscaling off after it has been enabled, set the master switch back:

kedaAutoscaling:
  enabled: false

Also remove, or set to false, any per-component kedaAutoscaling.enabled: true overrides, such as the export-builder and gen-ai-metadata-sync opt-ins shown above: an explicit component opt-in takes precedence over the master switch.

The next Helm upgrade then removes the ScaledObjects and their HPAs, and each service returns to its static replicaCount. The KEDA operator itself stays installed; it is managed outside the GoodData.CN chart.

Sizing Notes

• An HPA computes CPU utilization against the container’s CPU request, not its limit. If you override the chart’s resource requests, the CPU targets change meaning accordingly, so prefer the chart defaults unless you have measurements to size against.
• The minimum of 2 replicas keeps services available during node maintenance and zone failures. Autoscaling does not scale any service to zero.
• Keep replicaCount within the autoscaling bounds for autoscaled services. The deployment manifests still carry the configured replicaCount, so during a Helm upgrade a scaled-out service is briefly reconciled to that value before its HPA restores the autoscaled count.