对于一个每周运行一次的程序来说，(GKE)值得吗？

Question

我的团队正在将所有云应用程序从AWS迁移到GCP，我们正在考虑使用GKE作为我们的主程序，直到我们得到了谷歌现在将对GKE中的每个集群收取每小时0.10美元的管理费.。

我们还没有开始使用GKE，现在正在考虑这是否是我们的最佳选择。我们的工作负载由两个进程密集型的数据分析管道组成，我们使用这些管道在不同的AWS实例中同时运行多达20个分析，每周运行一次，最多15分钟至3h (并且可能在不久的将来每周运行两次)。在AWS上，我们目前为每个管道生成了几个EC2机器实例，每个分析都生成一个实例，因此我们正在考虑GKE，因为我们可以在同一个集群上运行几个分析，并让GKE为我们进行缩放。

我也有这样的印象，这个成本是在每个节点不断运行一个吊舱的成本之上的，对吗？对于我们在集群中创建的每一个节点池，我们都必须支付一个吊舱24/7运行的费用，因此这是另一个需要考虑的“空闲成本”。

我们每周只需要在集群上运行大约15分钟到6小时的工作负载，所以支付节点24小时运行的费用似乎有点浪费，但也许我没有看到这里的大局，因为分析可以在同一个集群上运行，从而节省我们的钱？在我们不使用GKE的时候，是否有一种有效的关闭GKE的方法--无论是豆荚还是更好的，整个集群本身？这样我们每个月至少可以节省690小时的空闲时间。

一旦完成了最后的分析，我们所有的集群就会被杀死和删除，并且每周重新创建，一旦需要新的分析，是否是可行的？这会否涉及成本？这样做“自动”可行吗？

Answer 1

如果您的工作负载只是昙花一现，那么这个解决方案可能不值得在部署K8S时进行下面的管理工作。

Kubernetes最适合于连续的、有规则的传入流量且需要零停机时间的工作负载类型。这就是为什么它使您能够执行诸如滚动更新和实现高级流量管理模式(如金丝雀版本)等工作。

虽然您可以将集群自动扩展到0个工作节点，但是运行控制平面节点的成本仍然很高，这需要运行apiserver、controller-manager、scheduler和kube-proxy的pods，此外还要运行autoscaler荚和日志/度量收集器。

如果使用基础设施作为代码管理集群并设计管道，以便它们能够在最少的人工干预(等待apiserver出现、等待员工注册和出现等)的情况下建立和拆卸集群，那么按需部署和销毁集群绝对是可行的。一种更优雅的方法是使用聚类API，尽管这需要一个管理集群。

现在，是否值得处理K8S固有的所有复杂性，只为了从缩小规模中获益，并且只运行偶尔的工作负载？我想说，最好将您的实例作为常规自动标度组来管理。