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

对于希望在 Kubernetes 上自行管理自己的自动扩缩器的基础设施和配置的独立团队来说，Google Kubernetes Engine (GKE) 部署模型是一个不错的选择。

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

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

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

优点：

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

缺点：

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

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

  • 分离式部署拓扑。分离式部署模型的优势在于，您可以为 Poller 和 Scaler 组件分配单独的权限，以便它们以单独的服务账号运行。这意味着，您可以灵活地管理和扩缩这两个组件，以满足您的需求。不过，此部署模型要求将 Scaler 组件部署为长时间运行的服务，该服务会消耗资源。
  • 统一部署拓扑。统一部署模型的优势在于，Poller 和 Scaler 组件可以作为单个 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 部署的分步指南。

后续步骤