Stay organized with collectionsSave and categorize content based on your preferences.
The Google Kubernetes Engine (GKE) deployment model is is a good choice for
independent teams who want to self-manage the infrastructure and configuration
of their own Autoscalers on Kubernetes.
This document is part of a series that also includes:
This series is intended for IT, Operations, and Site Reliability Engineering (SRE)
teams who want to reduce operational overhead and to optimize the cost of
Spanner deployments.
The GKE deployment has the following advantages and disadvantages:
Advantages:
Kubernetes-based: For teams that might not be able to use services such
as Cloud Run functions, deployment to Kubernetes enables use
of the Autoscaler.
Configuration: The control over scheduler parameters belongs to the
team that owns the Spanner instance which gives them the
highest privileges to adapt the Autoscaler to their needs.
Disadvantages:
Infrastructure: Compared to the Cloud Run functions design,
some long-lived infrastructure and services are required.
Maintenance: With each team being responsible for the Autoscaler
configuration and infrastructure it might become difficult to make sure that
all Autoscalers across the company follow the same update guidelines.
Audit: Because of the high level of control by each team, a centralized
audit might become more complex.
This page introduces two ways you can deploy the
Autoscaler to GKE based on your requirements:
Adecoupled deployment topology.
The decoupled deployment model has the advantage that you can assign Poller
and Scaler components individual permissions so that they run as separate
service accounts. This means you have the flexibility to manage and scale
the two components to suit your needs. However, this deployment model
requires that the Scaler component be deployed as a long-running service,
which consumes resources.
Aunified deployment topology.
The unified deployment model has the advantage that the Poller and
Scaler components can be deployed as a single pod, which runs as a Kubernetes
cron job. When the two components are deployed as a single pod there are no
long-running components and only a single service account is required.
For most use cases, we recommend the unified deployment model.
Configuration
The Autoscaler tool manages Spanner instances through the
configuration defined in aKubernetesConfigMap.
If multiple Spanner instances need to be polled with the same
interval, we recommend that you configure them in the sameConfigMap. The
following is an example of a configuration where two Spanner instances
are managed with one configuration:
An instance can have one Autoscaler configuration with the linear method for
normal operations, and also have another Autoscaler configuration with the
direct method for planned batch workloads. See the complete list of configuration options in thePollerREADMEfile.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[],[],null,["# Deploy the Autoscaler tool to GKE\n\nThe Google Kubernetes Engine (GKE) deployment model is is a good choice for\nindependent teams who want to self-manage the infrastructure and configuration\nof their own Autoscalers on Kubernetes.\n\nThis document is part of a series that also includes:\n\n- [Autoscaling Spanner](/spanner/docs/autoscaling-overview)\n- [Autoscaler tool overview](/spanner/docs/autoscaler-tool-overview)\n- [Deploy the Autoscaler tool for Spanner to Cloud Run functions](/spanner/docs/set-up-autoscaling-gke)\n\nThis series is intended for IT, Operations, and Site Reliability Engineering (SRE)\nteams who want to reduce operational overhead and to optimize the cost of\nSpanner deployments.\n\nThe GKE deployment has the following advantages and disadvantages:\n\nAdvantages:\n\n- **Kubernetes-based**: For teams that might not be able to use services such as Cloud Run functions, deployment to Kubernetes enables use of the Autoscaler.\n- **Configuration**: The control over scheduler parameters belongs to the team that owns the Spanner instance which gives them the highest privileges to adapt the Autoscaler to their needs.\n\nDisadvantages:\n\n- **Infrastructure**: Compared to the Cloud Run functions design, some long-lived infrastructure and services are required.\n- **Maintenance**: With each team being responsible for the Autoscaler configuration and infrastructure it might become difficult to make sure that all Autoscalers across the company follow the same update guidelines.\n- **Audit**: Because of the high level of control by each team, a centralized audit might become more complex.\n\nThis page introduces two ways you can deploy the\nAutoscaler to GKE based on your requirements:\n\n- A [decoupled deployment topology](https://github.com/cloudspannerecosystem/autoscaler/tree/main/terraform/gke#decoupled-model). The decoupled deployment model has the advantage that you can assign Poller and Scaler components individual permissions so that they run as separate service accounts. This means you have the flexibility to manage and scale the two components to suit your needs. However, this deployment model requires that the Scaler component be deployed as a long-running service, which consumes resources.\n- A [unified deployment topology](https://github.com/cloudspannerecosystem/autoscaler/tree/main/terraform/gke#unified-model). The unified deployment model has the advantage that the Poller and Scaler components can be deployed as a single pod, which runs as a Kubernetes cron job. When the two components are deployed as a single pod there are no long-running components and only a single service account is required.\n\nFor most use cases, we recommend the unified deployment model.\n\n### Configuration\n\nThe Autoscaler tool manages Spanner instances through the\nconfiguration defined in a [Kubernetes `ConfigMap`](https://kubernetes.io/docs/concepts/configuration/configmap).\nIf multiple Spanner instances need to be polled with the same\ninterval, we recommend that you configure them in the same `ConfigMap`. The\nfollowing is an example of a configuration where two Spanner instances\nare managed with one configuration: \n\n apiVersion: v1\n kind: ConfigMap\n metadata:\n name: autoscaler-config\n namespace: spanner-autoscaler\n data:\n autoscaler-config.yaml: |\n ---\n - projectId: spanner-autoscaler-test\n instanceId: spanner-scaling-linear\n units: NODES\n minSize: 5\n maxSize: 30\n scalingMethod: LINEAR\n - projectId: spanner-autoscaler-test\n instanceId: spanner-scaling-threshold\n units: PROCESSING_UNITS\n minSize: 100\n maxSize: 3000\n metrics:\n - name: high_priority_cpu\n regional_threshold: 40\n regional_margin: 3\n\nAn instance can have one Autoscaler configuration with the linear method for\nnormal operations, and also have another Autoscaler configuration with the\ndirect method for planned batch workloads. See the complete list of configuration options in the\n[Poller `README` file](https://github.com/cloudspannerecosystem/autoscaler/blob/main/src/poller/README.md#configuration-parameters).\n\nDeploy to GKE\n-------------\n\nTo learn how to deploy the Autoscaler to GKE in either the decoupled or unified\ndeployment model, see the\n[step-by-step guide to GKE deployment](https://github.com/cloudspannerecosystem/autoscaler/blob/main/terraform/gke/README.md).\n\nWhat's next\n===========\n\n- Learn how to [deploy the Autoscaler tool to Cloud Run functions](/spanner/docs/set-up-autoscaling-cloud-run).\n- Read more about Spanner [recommended thresholds](/spanner/docs/monitoring-cloud#create-alert).\n- Read more about Spanner [CPU utilization metrics](/spanner/docs/cpu-utilization) and [latency metrics](/spanner/docs/latency-guide).\n- Learn about [best practices for Spanner schema design](/spanner/docs/schema-design) to avoid hotspots and for loading data into Spanner.\n- Explore reference architectures, diagrams, and best practices about Google Cloud. Take a look at our [Cloud Architecture Center](/architecture)."]]
