Contributing a GCP Cloud Spanner Scaler to KEDA

How we added native Spanner support to Kubernetes autoscaling — and what we learned along the way

The problem

We run several workloads on Kubernetes that process jobs stored in Cloud Spanner tables. The pattern is simple: a producer writes rows with status = 'pending', workers pick them up and mark them done. The question is — how many workers do you run?

Fixed replica counts mean either wasted money during quiet periods or dropped throughput during spikes. We needed autoscaling based on actual queue depth, not CPU or memory.

KEDA (Kubernetes Event-Driven Autoscaling) is the standard answer for this — it scales workloads based on external metrics like queue lengths, database counts, and custom queries. It already had scalers for GCP Pub/Sub, Cloud Tasks, and Cloud Storage. But not Spanner.

So we built one.

How KEDA works

What we learned contributing to KEDA

1. Schema generation matters

KEDA auto-generates its scaler schema from Go struct tags. We needed to add Credentials and CredentialsFromEnvFile fields to the metadata struct purely so they appear in the schema — even though GetGCPAuthorization reads them directly from the config. This is the same pattern used by other GCP scalers.

2. ParseCommand has a quirk

KEDA's e2e test helper splits commands on spaces, honouring single-quotes only. So --ddl="value with spaces" breaks — "value" doesn't get treated as a quoted string. The fix is --ddl 'value with spaces' — space-separated flag and value, with single quotes.

3. Cleanup must be independent of Kubernetes

Our first attempt deleted the Spanner test instance via gcloud running in a pod. But DeleteKubernetesResources removes the pod before t.Cleanup fires — leaving orphaned (and billing) Spanner instances. The fix: delete via the Go Spanner Admin API directly from the test binary, completely independent of any pod.

Docs: keda.sh — GCP Spanner scaler

Using it

kubectl apply -f - <<EOF

apiVersion: keda.sh/v1alpha1

kind: ScaledObject

metadata:

  name: spanner-worker-scaler

spec:

  scaleTargetRef:

    name: job-processor

  minReplicaCount: 0

  maxReplicaCount: 20

  triggers:

    - type: gcp-spanner

      metadata:

        projectId: my-project

        instanceId: my-instance

        databaseId: my-database

        query: "SELECT COUNT(*) FROM jobs WHERE status = 'pending'"

        targetValue: "5"

        activationValue: "2"

        credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON

EOF

That's it. KEDA will handle the rest.