GKE 自动扩缩不会缩小规模

Question

我们使用 GKE（Google Kubernetes Engine）在 GCC（Google Cloude Composer）中运行 Airflow 作为我们的数据管道。

我们一开始有 6 个节点，后来意识到成本飙升，而且我们没有使用那么多的 CPU。所以我们认为我们可以降低最大值，但也可以启用自动缩放。

由于我们在夜间运行管道，并且白天只运行较小的作业，因此我们希望在 1-3 个节点之间运行自动缩放。

因此，我们在 GKE 节点池上启用了自动缩放，但没有按照他们的建议在 GCE 实例组上启用自动缩放。然而，我们得到这个：

为什么是这样？

下面是过去 4 天的 CPU 利用率图表：

我们从未超过 20% 的使用率，那为什么不缩小规模呢？

今天早上我们手动将其缩小到 3 个节点。

Answer 1

截至 2019 年 8 月 26 日，Cloud Composer 尚不支持 GKE 集群自动伸缩器，因为集群自动伸缩器根据Pod 的资源请求以及有多少 Pod 处于不可调度状态来做出伸缩决策（更多信息请参见此处））。Composer 部署固定数量的 Pod，这意味着自动缩放机制不会强制执行任何缩放操作，除非您自己将自己的工作负载部署到集群中。

自动缩放也很难做到，因为 Airflow 工作线程或调度程序的实际资源使用量取决于您上传的 DAG 数量（在 Composer 的情况下上传到 GCS），这意味着无法准确估计您的 Airflow 进程将使用多少 CPU/内存。这意味着您不知道如何决定 Airflow Pod 的 Pod 资源请求。

在没有自动缩放的情况下，动态资源分配仍然有很多选择。例如，您可以使用 KubernetesPodOperator 将带有资源请求的 Pod 部署到启用了自动缩放的不同Kubernetes 集群中。或者，您可以使用 GCE 运算符将实例添加到集群，然后再启动更多资源密集型工作负载。