将自动扩缩器工具部署到 GKE

对于希望自行管理 Kubernetes 上自有自动扩缩器的基础架构和配置的独立团队，Google Kubernetes Engine (GKE) 部署模型是不错的选择。

本文档是系列文章中的一篇，该系列文章还包括：

本系列文章适用于想要降低运营开销和优化 Spanner 部署费用的 IT、运营和站点可靠性工程 (SRE) 团队。

GKE 部署具有以下优势和缺点：

优点：

  • 基于 Kubernetes：对于可能无法使用 Cloud Run 函数等服务的团队，部署到 Kubernetes 后即可使用自动扩缩器。
  • 配置：对调度程序参数的控制属于拥有 Spanner 实例的团队，这使他们拥有最高权限，可以根据自己的需求调整自动扩缩器。

缺点：

  • 基础架构：与 Cloud Run 函数设计相比，需要一些长效基础架构和服务。
  • 维护：由于每个团队都负责自动扩缩器配置和基础架构，因此很难确保公司中的所有自动扩缩器都遵循相同的更新准则。
  • 审核：由于每个团队都具有更高级别的控制，因此集中式审核可能会更复杂。

本页介绍了两种根据您的要求将自动扩缩器部署到 GKE 的方法：

  • 分离式部署拓扑。分离式部署模型的优势在于，您可以为轮询器和规模扩缩器组件分配各自的权限，以便它们作为单独的服务账号运行。这意味着，您可以灵活地管理和扩缩这两个组件，以满足您的需求。不过，这种部署模型要求将 Scaler 组件部署为长时间运行的服务，这会消耗资源。
  • 统一的部署拓扑。统一部署模型的优势在于，Poller 和 Scaler 组件可以作为单个 pod 部署，该 pod 会作为 Kubernetes cron 作业运行。将这两个组件部署为单个 pod 时，没有长期运行的组件，并且只需要一个服务账号。

对于大多数使用场景，我们建议采用统一的部署模型。

配置

自动扩缩器工具通过 Kubernetes ConfigMap 中定义的配置管理 Spanner 实例。如果您需要以相同的间隔轮询多个 Spanner 实例，我们建议您在相同的 ConfigMap 中配置它们。以下是一个配置示例，在其中，使用一个配置管理两个 Spanner 实例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: autoscaler-config
  namespace: spanner-autoscaler
data:
  autoscaler-config.yaml: |
    ---
    - projectId: spanner-autoscaler-test
      instanceId: spanner-scaling-linear
      units: NODES
      minSize: 5
      maxSize: 30
      scalingMethod: LINEAR
    - projectId: spanner-autoscaler-test
      instanceId: spanner-scaling-threshold
      units: PROCESSING_UNITS
      minSize: 100
      maxSize: 3000
      metrics:
      - name: high_priority_cpu
        regional_threshold: 40
        regional_margin: 3

一个实例可以有一个包含用于正常操作的线性方法的自动扩缩器配置，但还有另一个包含用于计划批量工作负载的直接方法的自动扩缩器配置。如需查看配置选项的完整列表，请参阅轮询器 README 文件。

部署到 GKE

如需了解如何在分离式或统一部署模型中将自动扩缩器部署到 GKE，请参阅 GKE 部署分步指南。

后续步骤