이 시리즈는 운영 오버헤드를 줄이고 Spanner 배포 비용을 최적화하려는 IT, 운영, 사이트 안정성 엔지니어링(SRE) 팀을 대상으로 합니다.
GKE 배포에는 다음과 같은 장점과 단점이 있습니다.
장점:
Kubernetes 기반: Cloud Run Functions와 같은 서비스를 사용할 수 없는 팀의 경우 Kubernetes에 배포하면 자동 확장 처리를 사용할 수 있습니다.
구성: 니즈에 따라 자동 확장 처리를 적용할 수 있는 최고 권한을 부여하는 Spanner 인스턴스를 소유한 팀에서 스케줄러 파라미터를 제어합니다.
단점:
인프라: Cloud Run Functions 설계와 달리 일부 장기 실행 인프라와 서비스가 필요합니다.
유지보수: 각 팀에서 자동 확장 처리 구성과 인프라를 담당하므로 회사 전체의 모든 자동 확장 처리가 같은 업데이트 가이드라인을 따르게 하기가 어려워질 수 있습니다.
감사: 각 팀의 제어 수준이 높으므로 중앙 집중식 감사가 더 복잡해질 수 있습니다.
이 페이지에서는 요구사항에 따라 GKE에 자동 확장 처리를 배포하는 두 가지 방법을 소개합니다.
분리된 배포 토폴로지.
분리된 배포 모델의 장점은 Poller 및 Scaler 구성요소가 별도의 서비스 계정으로 실행되도록 이러한 구성요소에게 개별 권한을 할당할 수 있다는 점입니다. 즉, 니즈에 맞게 두 구성요소를 유연하게 관리하고 확장할 수 있습니다. 그러나 이 배포 모델을 사용하려면 Scaler 구성요소를 리소스를 소비하는 장기 실행 서비스로 배포해야 합니다.
통합 배포 토폴로지.
통합 배포 모델의 장점은 Poller 및 Scaler 구성요소를 Kubernetes 크론 작업으로 실행되는 단일 포드로 배포할 수 있다는 점입니다. 두 구성요소가 단일 포드로 배포되면 장기 실행 구성요소가 없으며 단일 서비스 계정만 있으면 됩니다.
대부분의 사용 사례에서는 통합 배포 모델을 사용하는 것이 좋습니다.
구성
자동 확장 처리 도구는 Kubernetes ConfigMap에 정의된 구성을 통해 Spanner 인스턴스를 관리합니다.
Spanner 인스턴스 여러 개를 동일한 간격으로 폴링해야 하는 경우에는 같은 ConfigMap에서 이러한 인스턴스를 구성하는 것이 좋습니다. 다음은 구성 하나로 Spanner 인스턴스 2개를 관리하는 구성의 예시입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-05(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)."]]