我们如何为 Kubernetes 自动伸缩添加原生 Spanner 支持——以及在此过程中的收获
问题所在
我们在 Kubernetes 上运行多个工作负载，用于处理存储在 Cloud Spanner 表中的作业。模式很简单：生产者写入状态为 status = 'pending'（待处理）的行，工作节点拾取这些行并将其标记为 done（已完成）。问题在于——你应该运行多少个工作节点？
固定的副本数量意味着在空闲时段浪费资金，或在流量高峰期间吞吐量下降。我们需要基于实际队列深度而非 CPU 或内存使用率的自动伸缩机制。
KEDA（Kubernetes 事件驱动自动伸缩）是此类问题的标准解决方案——它基于外部指标（如队列长度、数据库计数和自定义查询）来伸缩工作负载。它已经支持 GCP Pub/Sub、Cloud Tasks 和 Cloud Storage 的伸缩器。但不支持 Spanner。
因此，我们构建了一个。
KEDA 的工作原理
KEDA 位于你的工作负载和外部系统之间。在每个轮询间隔，它执行你的查询，获取一个数值，并根据公式 ceil(currentValue / targetValue)（当前值除以目标值向上取整）告诉 Kubernetes HPA 应该运行多少个副本。
伸缩器
gcp-spanner 触发器接受任何返回单个 INT64 值的 SQL 查询：
triggers:
- type: gcp-spanner
metadata:
projectId: my-project
instanceId: my-instance
databaseId: my-database
query: "SELECT COUNT(*) FROM jobs WHERE status = 'pending'"
targetValue: "5" # 一个副本处理 5 个待处理作业
activationValue: "2" # 低于此阈值时保持 0 个副本
credentialsFromEnv: GOOGLE_APPLICATION_CREDENTIALS_JSON
当 targetValue（目标值）设为 5 且有 20 个待处理作业时，KEDA 将维持 4 个工作节点副本。当队列清空至 0 时，它会缩容至零。
伸缩行为
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
