A Saturday night player surge can turn a healthy game server fleet into a queue of angry Discord messages within minutes. Static pod counts and manual scaling scripts do not hold up once concurrent lobbies swing from 200 to 4,000 in under ten minutes, which is exactly the kind of load pattern battle royale and MMO launches produce. Kubernetes 1.37, released August 26, 2026, together with KEDA 2.20.2 (shipped July 31, 2026) and Terraform 1.16.1 (September 2, 2026), gives operators a way to scale game server pods on real player-facing signals instead of raw CPU percentage. This tutorial builds a complete autoscaling pipeline for a stateful multiplayer game server fleet, wiring Kubernetes’ native Horizontal Pod Autoscaler (HPA) together with KEDA’s event-driven triggers, a Redis-backed matchmaking queue, and Terraform-managed infrastructure.
By the end, a working project scales a game server deployment up when the matchmaking queue backs up and back down to a baseline replica count when the queue drains, all without a human touching kubectl at 2 a.m. The primary keyword throughout this guide is kubernetes hpa, since that native autoscaler is the foundation every KEDA ScaledObject builds on top of.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why CPU-Based Autoscaling Fails Game Servers
The default Kubernetes HPA behavior scales replicas against CPU or memory utilization. That works reasonably well for stateless web APIs, where request latency correlates loosely with CPU load. Game servers break that assumption in three specific ways. First, a lobby-based multiplayer server can sit at 15% CPU while holding 64 active player connections in memory, meaning CPU never crosses the scaling threshold even as the pod approaches its connection ceiling. Second, matchmaking backlogs are a queue-depth problem, not a compute problem: a spike of 3,000 players queuing for a match saturates Redis lists long before any CPU metric moves. Third, session-based game servers are frequently stateful, so scaling down aggressively on a CPU dip can kill pods mid-match if the eviction policy is not aware of active player counts.
KEDA solves this by extending the standard kubernetes hpa object with custom scalers. Instead of watching CPU, a KEDA ScaledObject can watch a Redis list length, a Prometheus query, or a custom metrics endpoint that reports active player sessions. Kubernetes 1.37 still owns the actual pod creation and termination logic through the HPA controller; KEDA just feeds it better numbers to act on. That distinction matters for the rest of this guide: everything KEDA does ultimately writes into a standard HorizontalPodAutoscaler resource, which is why understanding native HPA mechanics first makes the KEDA layer easier to debug.
The Cloud Native Computing Foundation, which incubated KEDA as a graduated project, describes event-driven autoscaling as a way to decouple the scaling decision from the resource metric entirely, letting any measurable signal, queue depth, message count, or a custom business metric, drive replica counts. Game server fleets are one of the clearest use cases for that model, since the metric that actually matters to players (can I get into a match quickly) rarely maps cleanly onto CPU or memory.
Prerequisites and Versions
Confirm every tool below before starting. Version drift between kubectl, the cluster, and Terraform providers is the single most common cause of failed applies in this stack.
| Tool | Minimum Version | Verified Current Version (Sept 2026) | Purpose |
|---|---|---|---|
| Kubernetes cluster | 1.34 | 1.37.0 (released 2026-08-26) | Container orchestration, native HPA |
| KEDA | 2.14 | 2.20.2 (released 2026-07-31) | Event-driven autoscaling triggers |
| Terraform | 1.9 | 1.16.1 (released 2026-09-02) | Infrastructure as code |
| kubectl | 1.32 | Match cluster minor version | Cluster control |
| Helm | 3.14 | 3.16.x | KEDA and metrics-server install |
| Redis | 7.2 | 8.10.1 (released 2026-08-17) | Matchmaking queue backing store |
| flyctl (optional) | 0.3 | 0.4.100 (released 2026-09-07) | Regional Fly.io Machines for latency-sensitive lobbies |
You also need a Kubernetes cluster with the metrics-server add-on running (required for CPU/memory HPA baselines), cluster-admin access to install CRDs, and a container registry to push the sample game server image. This guide uses a generic managed Kubernetes service; the steps apply equally to EKS, GKE, AKS, or a self-managed cluster, since KEDA and HPA are portable Kubernetes-native resources with no cloud-specific dependencies.
Choosing a Managed Kubernetes Service for a Game Server Fleet
Nothing in this tutorial is specific to a single cloud provider, but the managed service running underneath the cluster still shapes how fast KEDA-driven scaling actually delivers new capacity. The bottleneck is rarely KEDA or the HPA controller, since both react within seconds; it is almost always node provisioning time, meaning how quickly the underlying node pool can schedule the new pods KEDA just requested.
| Managed Service | Node Autoscaler | Typical New Node Time | Notes for Game Fleets |
|---|---|---|---|
| Amazon EKS | Karpenter or Cluster Autoscaler | 45-90 seconds | Karpenter provisions faster than the legacy Cluster Autoscaler for burst scaling |
| Google GKE | Node Auto-Provisioning | 60-120 seconds | Autopilot mode simplifies node management but adds per-pod pricing overhead |
| Azure AKS | Cluster Autoscaler | 60-150 seconds | Node pool spin-up time varies more by VM SKU availability than other providers |
| Self-managed cluster | Depends on IaaS integration | Varies widely | Requires the most manual tuning but gives full control over bin-packing |
If a game’s traffic pattern includes sudden, large spikes (a marketing push, a streamer shoutout, a weekend tournament), keep a small buffer of already-provisioned but idle nodes rather than relying entirely on reactive node autoscaling. The 45-150 second window it takes most providers to add a fresh node is often longer than players are willing to wait in a queue before abandoning matchmaking altogether.
Step 1: Verify Cluster Version and Metrics Server
Start by confirming the cluster is on a supported Kubernetes minor version and that metrics-server is already reporting pod resource usage. KEDA’s HPA-based scalers depend on metrics-server for the CPU/memory fallback path, even when the primary trigger is Redis or a custom metric.
kubectl version --short
kubectl get nodes -o wide
kubectl top nodes
kubectl get deployment metrics-server -n kube-systemExpected output for a healthy cluster running Kubernetes 1.37 looks like this:
Client Version: v1.37.0
Server Version: v1.37.0
NAME STATUS ROLES AGE VERSION
node-pool-a-1 Ready 12d v1.37.0
node-pool-a-2 Ready 12d v1.37.0
node-pool-a-3 Ready 12d v1.37.0
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
node-pool-a-1 412m 10% 2841Mi 36%
node-pool-a-2 389m 9% 2705Mi 34%
node-pool-a-3 455m 11% 2912Mi 37% If metrics-server is not present, install it with Helm before continuing. Every later step assumes this baseline is in place, since a missing metrics pipeline is the number one reason a ScaledObject silently reports zero replicas even when a Redis queue is clearly backed up.
Step 2: Provision the Cluster and Redis Instance With Terraform 1.16
Terraform 1.16, released August 26, 2026, added a store block inside terraform_data resources that persists ephemeral and sensitive values across plan and apply cycles, and it extended import blocks so they can now run inside child modules. Both features matter here: the Redis connection string used by the matchmaking scaler counts as a sensitive value, and teams migrating an existing hand-built cluster into Terraform can now import it module-by-module instead of one flat state file.
terraform {
required_version = ">= 1.16.0"
required_providers {
kubernetes = {
source = "hashicorp/kubernetes"
version = "~> 2.35"
}
helm = {
source = "hashicorp/helm"
version = "~> 2.16"
}
}
}
resource "kubernetes_namespace" "game_servers" {
metadata {
name = "game-fleet"
}
}
resource "helm_release" "redis" {
name = "matchmaking-redis"
repository = "https://charts.bitnami.com/bitnami"
chart = "redis"
version = "20.6.1"
namespace = kubernetes_namespace.game_servers.metadata[0].name
set {
name = "auth.enabled"
value = "true"
}
set {
name = "architecture"
value = "standalone"
}
}
terraform_data "redis_secret" {
input = helm_release.redis.name
store "auth" {
value = random_password.redis_auth.result
}
}
resource "random_password" "redis_auth" {
length = 24
special = false
}Run terraform init followed by terraform plan before applying. Review the plan output carefully: Terraform 1.16 changed how private provider data is stored, so a plan generated with an older client against state written by 1.16 can show unexpected diffs on first run. Apply once the plan looks correct.
terraform init -upgrade
terraform plan -out=tfplan
terraform apply tfplanStep 3: Install KEDA 2.20 With Helm
KEDA installs as a set of CRDs and controller pods that watch ScaledObject resources and translate them into standard Kubernetes HPA objects behind the scenes. Install it into its own namespace to keep RBAC boundaries clean.
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
kubectl create namespace keda
helm install keda kedacore/keda \
--namespace keda \
--version 2.20.2Confirm the controller and metrics adapter pods reach Running status before moving on:
kubectl get pods -n keda
NAME READY STATUS RESTARTS AGE
keda-admission-webhooks-7f9d5b8c9-abc12 1/1 Running 0 45s
keda-operator-6d8f7c5b4d-xyz89 1/1 Running 0 45s
keda-operator-metrics-apiserver-5c9b8d7f6-qrs34 1/1 Running 0 45sThe metrics-apiserver pod is what registers KEDA as an external metrics provider inside the Kubernetes API, which is how a ScaledObject’s Redis-based trigger ends up feeding a native HPA object without any custom controller loop of your own.
Step 4: Deploy the Game Server Fleet
Deploy a baseline game server Deployment with a conservative replica count and defined resource requests. HPA and KEDA both scale off requested resources, not raw node capacity, so under-specifying requests here causes unpredictable scaling math later.
apiVersion: apps/v1
kind: Deployment
metadata:
name: match-server
namespace: game-fleet
spec:
replicas: 3
selector:
matchLabels:
app: match-server
template:
metadata:
labels:
app: match-server
spec:
containers:
- name: match-server
image: registry.example.com/match-server:1.4.2
ports:
- containerPort: 7777
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
readinessProbe:
tcpSocket:
port: 7777
initialDelaySeconds: 5
env:
- name: REDIS_HOST
value: matchmaking-redis-master.game-fleet.svc.cluster.local
---
apiVersion: v1
kind: Service
metadata:
name: match-server
namespace: game-fleet
spec:
selector:
app: match-server
ports:
- port: 7777
targetPort: 7777
type: ClusterIPkubectl apply -f match-server-deployment.yaml
kubectl rollout status deployment/match-server -n game-fleetStep 5: Build the Matchmaking Queue Worker
The matchmaking worker is the piece that actually populates the Redis list KEDA will watch. Players hit an API endpoint to queue for a match, the request pushes an entry onto a Redis list, and a worker pool pulls from that list to form matches. The queue depth on that list is the signal that should drive server autoscaling, since a growing queue means the fleet cannot form matches fast enough with the current replica count.
apiVersion: apps/v1
kind: Deployment
metadata:
name: matchmaking-worker
namespace: game-fleet
spec:
replicas: 2
selector:
matchLabels:
app: matchmaking-worker
template:
metadata:
labels:
app: matchmaking-worker
spec:
containers:
- name: worker
image: registry.example.com/matchmaking-worker:2.1.0
resources:
requests:
cpu: "250m"
memory: "256Mi"
env:
- name: REDIS_HOST
value: matchmaking-redis-master.game-fleet.svc.cluster.local
- name: QUEUE_KEY
value: "match:pending_queue"Apply this alongside the match-server deployment. At this point the fleet runs with static replica counts on both the servers and the workers, which is intentional: get the plumbing correct first, then layer autoscaling on top in the next step so failures are easier to isolate.
Step 6: Create the KEDA ScaledObject for Match Servers
This is the core of the tutorial. The ScaledObject below targets the match-server Deployment and defines a Redis list-length trigger. When the pending queue exceeds five entries per existing replica, KEDA raises the target replica count in the underlying HPA object it manages.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: match-server-scaler
namespace: game-fleet
spec:
scaleTargetRef:
name: match-server
minReplicaCount: 3
maxReplicaCount: 40
cooldownPeriod: 120
pollingInterval: 15
triggers:
- type: redis
metadata:
address: matchmaking-redis-master.game-fleet.svc.cluster.local:6379
listName: "match:pending_queue"
listLength: "5"
authenticationRef:
name: redis-trigger-auth
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
name: redis-trigger-auth
namespace: game-fleet
spec:
secretTargetRef:
- parameter: password
name: matchmaking-redis
key: redis-passwordApply it and inspect the HPA that KEDA generates automatically:
kubectl apply -f match-server-scaledobject.yaml
kubectl get hpa -n game-fleetNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
keda-hpa-match-server-scaler Deployment/match-server 2/5 (avg) 3 40 3Note the naming convention: KEDA prefixes generated HPA objects with keda-hpa-. This is the actual kubernetes hpa resource doing the scaling work, KEDA has simply populated its target metric from Redis instead of requiring you to expose a custom metrics adapter by hand.
Step 7: Add a CPU-Based Fallback Trigger
Queue depth alone misses scenarios where players are already inside active matches and the server pods are compute-bound rather than queue-bound, for example, a physics-heavy battle royale circle-closing phase with 150 concurrent players per pod. Add a second trigger so the ScaledObject reacts to whichever signal fires first.
triggers:
- type: redis
metadata:
address: matchmaking-redis-master.game-fleet.svc.cluster.local:6379
listName: "match:pending_queue"
listLength: "5"
authenticationRef:
name: redis-trigger-auth
- type: cpu
metricType: Utilization
metadata:
value: "70"With both triggers present, KEDA scales to satisfy whichever metric demands more replicas at any given polling interval. This mirrors how Kubernetes 1.37’s own HPA controller handles multiple metrics on a single HorizontalPodAutoscaler: it always scales to the largest replica count any single metric requests, never averaging them.
Step 8: Scale the Matchmaking Workers Independently
Match servers and matchmaking workers have different scaling profiles: workers are cheap, stateless, and can scale aggressively, while match servers are relatively expensive and should scale more conservatively to avoid rapid pod churn mid-session. Give the worker its own ScaledObject with a tighter polling interval and a lower queue threshold.
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: matchmaking-worker-scaler
namespace: game-fleet
spec:
scaleTargetRef:
name: matchmaking-worker
minReplicaCount: 2
maxReplicaCount: 20
cooldownPeriod: 60
pollingInterval: 10
triggers:
- type: redis
metadata:
address: matchmaking-redis-master.game-fleet.svc.cluster.local:6379
listName: "match:pending_queue"
listLength: "2"
authenticationRef:
name: redis-trigger-authThe shorter pollingInterval (10 seconds versus 15) means workers react to queue growth faster than servers, which is the correct order of operations: workers drain the queue into matches, and only then does the match-server fleet need more capacity to host those newly formed matches.
Step 9: Load Test the Autoscaling Pipeline
Simulate a queue spike before trusting this in production. A simple loop that pushes synthetic entries onto the Redis list reproduces a launch-day traffic pattern without needing real players.
kubectl run redis-client --rm -it --image redis:8.10.1 --namespace game-fleet -- bash
# inside the pod
for i in $(seq 1 500); do
redis-cli -h matchmaking-redis-master -a $REDIS_PASSWORD \
LPUSH match:pending_queue "player-$i"
doneWatch the HPA respond in a second terminal:
kubectl get hpa -n game-fleet -wNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS
keda-hpa-match-server-scaler Deployment/match-server 100/5 (avg) 3 40 3
keda-hpa-match-server-scaler Deployment/match-server 100/5 (avg) 3 40 12
keda-hpa-match-server-scaler Deployment/match-server 62/5 (avg) 3 40 22
keda-hpa-match-server-scaler Deployment/match-server 18/5 (avg) 3 40 30Kubernetes’ default HPA scale-up policy allows doubling the replica count or adding four pods per 15-second window, whichever is larger, which is why the jump from 3 to 12 happens in a single interval rather than climbing one pod at a time. Once the synthetic queue drains, expect replicas to hold at the peak for the full 120-second cooldownPeriod before scaling back down, which prevents flapping if a second burst arrives shortly after the first.
Step 10: Protect Active Matches During Scale-Down
Scaling down is where naive autoscaling setups break multiplayer games: Kubernetes has no built-in concept of “this pod is hosting an active match, do not terminate it.” Solve this with a PreStop hook and a graceful termination window long enough for matches to finish.
terminationGracePeriodSeconds: 900
containers:
- name: match-server
lifecycle:
preStop:
exec:
command:
- "/bin/sh"
- "-c"
- "/app/drain.sh && sleep 30"The drain.sh script should mark the pod as unavailable for new match assignments immediately, then poll until the currently hosted match ends (or a hard 15-minute cap is hit) before allowing the container to exit. A 900-second grace period is generous, but most session-based games run matches under 20 minutes, so this bounds the worst case without risking mid-match disconnects during scale-down events.
Step 11: Add Observability With Prometheus Metrics
KEDA exposes its own scaler health as Prometheus metrics on the metrics-apiserver pod, separate from the game server metrics. Scrape both to correlate scaling decisions with actual match server health during incidents.
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: keda-metrics
namespace: keda
spec:
selector:
matchLabels:
app.kubernetes.io/name: keda-operator-metrics-apiserver
endpoints:
- port: metrics
interval: 15sKey metrics worth alerting on include keda_scaler_errors_total, which spikes when a trigger loses its connection to Redis, and keda_scaler_active, which reports whether a given trigger currently believes it should be scaling. A ScaledObject with keda_scaler_active stuck at zero despite a visibly growing Redis queue almost always points at a stale TriggerAuthentication secret.
Securing the Matchmaking Redis Instance
A Redis instance driving autoscaling decisions is a more sensitive piece of infrastructure than a typical cache, since anyone who can write to the queue key can effectively force the fleet to scale up or, in the reverse direction, mask a real queue spike by never letting it register. Lock this down before going anywhere near production traffic.
Three controls matter most. First, enable Redis AUTH (already set via auth.enabled = true in the Terraform block from Step 2) and rotate the password on a schedule, updating the referenced Kubernetes Secret and letting the TriggerAuthentication resource pick up the new value automatically. Second, apply a NetworkPolicy that restricts inbound connections on port 6379 to only the match-server, matchmaking-worker, and KEDA operator pods, following the Redis usage patterns Redis’s own documentation recommends for queue-style workloads. Third, avoid exposing the Redis service through a LoadBalancer or NodePort; a ClusterIP service, as configured in the Helm release above, keeps the matchmaking queue reachable only from inside the cluster’s pod network.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: redis-restrict-access
namespace: game-fleet
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: redis
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: match-server
- podSelector:
matchLabels:
app: matchmaking-worker
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: keda
ports:
- protocol: TCP
port: 6379Multi-Region Failover Considerations
A single-region Kubernetes cluster is a single point of failure for the entire matchmaking pipeline built in this tutorial, since KEDA, the HPA controller, and the Redis queue all live inside that one cluster. Games with a global player base typically need at least two regional clusters, each running its own copy of this stack, with a routing layer in front that sends players to the nearest healthy region.
Keep the Redis instance and its ScaledObjects region-local rather than trying to share one global queue across regions over a WAN link; cross-region Redis calls add 80-150ms of round-trip latency on a typical intercontinental path, which defeats the purpose of a sub-second matchmaking signal. Instead, replicate the Terraform module from Step 2 per region, each with its own namespace, Redis instance, and ScaledObjects, and let a global health check or DNS-based router (independent of Kubernetes) decide which region a new player’s queue request lands in. If one region’s cluster becomes unhealthy, that router should stop sending new matchmaking requests there while existing matches in that region finish naturally under the 900-second termination grace period configured in Step 10.
Step 12: Extend to Regional Fly.io Machines for Latency-Sensitive Matches
Kubernetes clusters typically run in one or two regions, which is fine for matchmaking and persistent services but can add unacceptable latency for competitive lobbies where players expect sub-40ms round trips. A hybrid pattern that pairs this Kubernetes-based autoscaling fleet with Fly.io Machines lets you spin up short-lived, region-local match instances close to players while keeping matchmaking, Redis, and player accounts centralized on the Kubernetes cluster.
fly machine run registry.example.com/match-server:1.4.2 \
--region nrt \
--vm-memory 1024 \
--env REDIS_HOST=matchmaking-redis.example.com \
--autostart --autostop=stopflyctl 0.4.100 (released September 7, 2026) supports the --autostop flag shown here, part of the broader Fly.io Machines lifecycle model, which shuts a Machine down automatically once its match ends, so you only pay for the compute window a given regional match actually needs. Have the matchmaking worker call the Fly.io Machines API directly when a queued match’s players are geographically concentrated far from the primary cluster region, falling back to the in-cluster fleet otherwise.
Complete Working Project Structure
Putting every step together, a production-ready repository for this setup should look like this:
game-fleet-autoscaling/
├── terraform/
│ ├── main.tf
│ ├── variables.tf
│ └── outputs.tf
├── k8s/
│ ├── namespace.yaml
│ ├── match-server-deployment.yaml
│ ├── matchmaking-worker-deployment.yaml
│ ├── match-server-scaledobject.yaml
│ ├── matchmaking-worker-scaledobject.yaml
│ └── service-monitor.yaml
├── scripts/
│ ├── drain.sh
│ └── load-test.sh
└── README.mdApply the Terraform layer first to stand up the namespace and Redis, then apply the Kubernetes manifests in the order shown above: deployments before ScaledObjects, since a ScaledObject targeting a Deployment that does not exist yet will simply sit idle until the target appears. A minimal load-test.sh wraps the Step 9 Redis push loop into a repeatable script, and the README.md should document the exact listLength and pollingInterval values chosen for the deployed game, plus the reasoning behind them, since those numbers are the first thing an on-call engineer needs to sanity-check during an incident six months from now when nobody remembers why they were set that way.
Common Pitfalls
- Forgetting minReplicaCount during a deploy. If a rolling update briefly removes the ScaledObject, KEDA can hand control back to a default HPA with no minimum set, leaving the fleet at zero replicas until the object is reapplied.
- Setting cooldownPeriod too short. A 30-second cooldown on a match-server ScaledObject causes rapid scale-up/scale-down flapping every time queue depth crosses the threshold, churning pods that were mid-startup.
- Mismatched Redis auth secrets. The TriggerAuthentication resource reads a Kubernetes Secret key name that must exactly match the Helm chart’s generated secret key, a common source of silent trigger failures.
- No PreStop hook on stateful match servers. Without a drain script, scale-down events terminate pods hosting live matches, disconnecting every player in that lobby.
- Treating KEDA and HPA as separate systems. Every KEDA ScaledObject generates a real HPA object; conflicting manually created HPAs on the same Deployment will fight KEDA for control and produce unpredictable replica counts.
- Ignoring maxReplicaCount cluster capacity. Setting
maxReplicaCount: 40without confirming the node pool can actually schedule 40 pods leads to pods stuck in Pending during the exact traffic spike you built this system to handle. - Skipping metrics-server health checks. CPU-based fallback triggers silently stop reporting if metrics-server pods crash-loop, and KEDA will not surface this as an error state by default.
Troubleshooting
- ScaledObject shows READY=False. Run
kubectl describe scaledobject match-server-scaler -n game-fleetand check the Conditions section for the exact trigger error, usually a DNS resolution failure against the Redis service name. - HPA reports unknown for the target metric. This means the KEDA metrics-apiserver cannot reach the trigger source. Confirm the Redis Service is in the same namespace or that the fully qualified domain name is correct.
- Replicas stuck at minReplicaCount despite a full queue. Check that the TriggerAuthentication secret has not rotated; a stale password causes silent authentication failures against Redis.
- Pods scale up but never become Ready. This is usually a resource request/limit issue unrelated to KEDA. Check
kubectl describe podfor FailedScheduling events tied to insufficient node capacity. - Scale-down happens mid-match. Verify the PreStop hook actually blocks until
drain.shexits; a script that exits immediately without checking match status defeats the entire graceful termination setup. - Terraform apply fails on the store block. Confirm the Terraform CLI itself is on 1.16.0 or newer; the
storeblock syntax insideterraform_datais rejected by earlier versions with a generic syntax error. - KEDA operator pod CrashLoopBackOff after upgrade. Check for CRD version mismatches between the old and new Helm chart; run
helm upgradewith--reset-valuesalongside a CRD reapply if the controller fails to start after a version bump. - Queue length trigger fires but no scaling occurs. Verify the ScaledObject’s
scaleTargetRefname matches the Deployment name exactly, including case; a typo here causes KEDA to create an orphaned HPA with no effect.
Advanced Tips
Once the baseline pipeline is stable, a few refinements make it production-grade. First, use KEDA’s advanced.horizontalPodAutoscalerConfig.behavior field to set asymmetric scale-up and scale-down policies directly on the generated HPA, rather than relying on cooldownPeriod alone; this gives finer control over how aggressively pods are removed during off-peak hours. Second, pair the Redis list trigger with a Prometheus-based trigger that reads p95 match-formation latency, so the system scales on the actual player experience metric rather than a proxy for it. Third, if running across multiple regions, deploy a separate ScaledObject per region-scoped Deployment rather than one global scaler, since a single global Redis queue conflates demand signals from regions with very different capacity headroom. Finally, budget for KEDA’s own resource footprint: the operator and metrics-apiserver pods are lightweight, but running dozens of ScaledObjects with 10-second polling intervals against a shared Redis instance adds real connection overhead that should be sized into the Redis instance’s own resource requests.
Cost and Capacity Planning
Autoscaling reduces wasted spend compared to a fleet sized for peak load 24/7, but it does not eliminate the need for capacity planning. The table below compares a static provisioning model against the KEDA-driven approach built in this tutorial, using the resource requests defined above as the baseline unit cost.
| Approach | Baseline Replicas | Peak Replicas | Avg. Daily Replica-Hours | Relative Compute Cost |
|---|---|---|---|---|
| Static (sized for peak) | 40 | 40 | 960 | 1.0x (baseline) |
| Manual scaling scripts | 3 | 40 | ~520 | ~0.54x |
| KEDA + HPA (this tutorial) | 3 | 40 | ~310 | ~0.32x |
The gap between manual scripts and KEDA comes from reaction time: cron-based or manually triggered scaling scripts typically check load every few minutes and react conservatively, while KEDA’s default 15-30 second polling interval scales down idle capacity far faster once a spike subsides, without waiting for a human or a scheduled job to notice.
Comparing KEDA Triggers for Game Workloads
KEDA ships dozens of built-in scalers. For game server fleets specifically, three are worth knowing well beyond the Redis list trigger used in this tutorial.
| Trigger Type | Best For | Latency to React | Setup Complexity |
|---|---|---|---|
| Redis List Length | Matchmaking queue depth | Low (polling interval bound) | Low |
| Prometheus Query | Custom game metrics (p95 latency, active sessions) | Medium (depends on scrape interval) | Medium |
| CPU/Memory (native HPA) | Compute-bound physics or AI workloads | Low | Low |
| Kafka Consumer Lag | Event-sourced game state pipelines | Medium | High |
| Cron | Predictable daily peak windows (regional prime time) | Instant (scheduled) | Low |
A mature setup often layers a Cron trigger for known regional peak hours (for example, pre-scaling before 7 p.m. local time in a game’s most active region) alongside the Redis-based reactive trigger built in this tutorial, giving the fleet a head start before demand actually spikes.
Tuning Scaling Profiles by Game Genre
The ScaledObject values used throughout this tutorial (a queue threshold of five, a 120-second cooldown, a 15-second polling interval) are reasonable defaults for a mid-size session-based shooter, but they are not universal. Genre shapes both how aggressively a fleet should scale and how much headroom it needs before a queue backlog becomes a player-facing problem.
Battle royale titles see the sharpest spikes, since a single match consumes 60-150 player slots at once and queue pressure builds in bursts as lobbies fill. These fleets benefit from a lower queue threshold (2-3 rather than 5) and a shorter polling interval, trading a bit of extra scaling churn for faster reaction to sudden fill events. MOBA and team-based shooters queue in much smaller units, typically 5v5 or 6v6, so backlogs build more gradually and a threshold of 8-10 with the default 15-second interval usually holds queue wait times under a few seconds without excessive pod churn. Persistent-world MMOs are the outlier: player counts per server shard grow slowly over hours rather than spiking in minutes, so CPU and memory-based HPA triggers alone often outperform queue-based KEDA triggers, since there is no discrete matchmaking queue to measure in the first place, only a continuously growing shard population. Turn-based and mobile-asynchronous titles sit at the other extreme, where a 60-120 second polling interval (as noted in the FAQ below) is not just acceptable but preferable, since faster reaction offers no real benefit when a “match” might not require a live connection at all.
The practical takeaway is to treat the values in Steps 6 through 8 as a starting point, then adjust listLength and pollingInterval after watching at least one real traffic spike through the Prometheus metrics wired up in Step 11, rather than guessing at genre-appropriate numbers in advance.
Frequently Asked Questions
Does KEDA replace the Kubernetes Horizontal Pod Autoscaler?
No. KEDA generates and manages a standard HorizontalPodAutoscaler object behind the scenes; it extends what metrics that HPA can react to rather than replacing the HPA controller itself. Every ScaledObject created in this tutorial results in a real kubernetes hpa resource visible with kubectl get hpa.
Can this setup scale to zero when no players are online?
KEDA supports scale-to-zero on event-driven triggers like the Redis list trigger, but this tutorial sets minReplicaCount: 3 to keep a warm baseline for matchmaking availability. Scaling match-server pods fully to zero is workable for low-traffic titles but adds cold-start latency of roughly 10-30 seconds before the first queued match can be served.
What Kubernetes version is required for this tutorial?
KEDA 2.20.2 supports Kubernetes 1.32 and newer. This tutorial was built and verified against Kubernetes 1.37.0, the current stable release as of September 2026, but the manifests work unchanged on 1.34 through 1.37 without modification.
Why use Redis instead of a cloud provider’s native queue service?
Redis keeps the setup cloud-agnostic and avoids provider lock-in for a component that needs sub-millisecond read latency for matchmaking lookups. Teams already standardized on a specific cloud queue service can swap the Redis trigger for KEDA’s Kafka, AWS SQS, or Azure Queue scalers with minimal changes to the ScaledObject structure.
How does this handle a sudden 10x traffic spike from a marketing campaign or streamer shoutout?
The maxReplicaCount ceiling and node pool autoscaling both need headroom for this scenario. Pair this KEDA setup with a cluster autoscaler or node auto-provisioning so that when KEDA requests 40 replicas, the underlying node pool can actually schedule them rather than leaving pods Pending.
Is Terraform required, or can this be deployed with kubectl alone?
Terraform is not strictly required; every manifest in this tutorial applies fine with plain kubectl. Terraform 1.16 is used here to manage the Redis Helm release and namespace declaratively, which matters most for teams running multiple environments (staging, production, regional clusters) that need consistent, version-controlled infrastructure.
What happens if the KEDA operator pod crashes during a traffic spike?
The HPA objects KEDA has already created continue functioning independently, since they are standard Kubernetes resources at that point. A crashed KEDA operator stops updating the external metrics feeding those HPAs, meaning the fleet freezes at its current replica count until the operator pod recovers, rather than scaling incorrectly.
Does this approach work for turn-based games with much lower connection churn?
Yes, though the polling interval and cooldown values should be relaxed significantly. Turn-based games rarely need 10-15 second reaction times; a 60-120 second polling interval with a longer cooldown reduces unnecessary scaling events without meaningfully affecting player experience.
Related Coverage
- Multiplayer Game Servers on Cloudflare Durable Objects: 14 Steps [2026]
- AWS Global Accelerator Game Server Setup: 12 Steps [2026]
- Pterodactyl Multi-Game Cloud Server: 13 Steps, $96/Mo [2026]
- Deploy Agones on Kubernetes: 12 Steps, 90 Min [2026]
- Deploy a Multiplayer Game Server With AWS GameLift: 12 Steps [2026]
