GKE 自动缩放不会缩小

Posted 2023-03-29

【中文标题】GKE 自动缩放不会缩小

【英文标题】：GKE autoscaling doesn't scale down

【发布时间】：2019-12-30 09:49:04

【问题描述】：

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

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

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

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

这是为什么？

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

我们从来没有超过 20% 的使用率，那为什么不缩减呢？

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

【问题讨论】：

these troubleshooting items 中的任何一个都适用吗？

【参考方案1】：

首先我要提到的是，当集群中存在未充分利用的节点时，会触发缩减过程。在这种情况下，“未充分利用”不仅与 CPU 使用率有关，因此您的推理并不完全正确。

如文档所述，条件是该节点上运行的所有 Pod 的 CPU 和内存请求的总和小于为 Autoscaler 定义的利用率阈值。然后，“如果一个节点超过 10 分钟不需要，它将被终止”。请参阅this 了解更多信息。

此外，重要的是要知道还有一些其他因素可能会阻止缩减过程，例如node auto-provisioning limits。查看this 了解有关可阻止集群自动扩缩器移除节点的 pod 的更多信息。

【参考方案2】：

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

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

---

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

【讨论】：

谢谢！这回答了我的问题。比我们希望的要复杂一些。我认为我们倾向于在夜间运行期间使用 GCE 运算符并添加实例。

我尝试使用 GCE 运算符来停止和启动集群中的实例，但它没有按预期工作。当我使用API 停止一个实例时，它会在几分钟后自动重新启动。我猜这是因为节点池设置为 3 个实例，一旦它意识到其中一个节点已停止，它就会自动再次启动它。你的意思是说我们可以使用@hexacyanide 运算符吗？

我写了一些关于作曲家自动缩放link.medium.com/AMUlwUIkD0 的资源请求的计算。请检查一下

【参考方案3】：

所以，你说“不支持”它的 k8s 有点奇怪。 按照here 的规定启用 GKE 集群自动扩缩器：

gcloud container clusters update [CLUSTER_NAME] --enable-autoscaling \
    --min-nodes 1 --max-nodes 10 --zone [COMPUTE_ZONE] --node-pool default-pool 

这是在默认节点池上，如果您创建了一个新池，请使用那个。

转到您的气流工作者部署并在 name: airflow-worker 或 ports: 之后添加此部署

resource:
  requests:
    cpu: 400m

然后，像这样自动扩展您的部署：

kubectl autoscale deployment airflow-worker --cpu-percent=95 --min=1 --max=10 -n <your namespace>

在我的情况下，它就像一个魅力，它为我的气流工作部署扩展节点和 Pod。

概念验证：

$ kubectl get hpa -n  <my-namespace> -w   

名称参考目标 MINPODS MAXPODS REPLICAS 年龄 airflow-worker 部署/airflow-worker /95% 1 3 0 13 秒 airflow-worker 部署/airflow-worker 20%/95% 1 10 1 29m airflow-worker 部署/airflow-worker 27%/95% 1 10 2 29m airflow-worker 部署/airflow-worker 30%/95% 1 10 3 29m airflow-worker 部署/airflow-worker 53%/95% 1 10 3 29m airflow-worker 部署/airflow-worker 45%/95% 1 10 3 34m airflow-worker 部署/airflow-worker 45%/95% 1 10 3 34m airflow-worker 部署/airflow-worker 28%/95% 1 10 2 34m airflow-worker 部署/airflow-worker 32%/95% 1 10 2 35 airflow-worker 部署/airflow-worker 37%/95% 1 10 2 43m airflow-worker 部署/airflow-worker 84%/95% 1 10 1 43m airflow-worker 部署/airflow-worker 39%/95% 1 10 1 44m airflow-worker 部署/airflow-worker 29%/95% 1 10 1 44m

您可以看到一段时间后它缩小到 1pod。与节点池相同，缩减为 4 个节点而不是 5-6-7..

【讨论】：

嗯，很好，我会研究一下并尝试一下，看看它是否有效！谢谢！

怎么样？

这个时候，如果你愿意修改Kubernetes的配置，你可以配置autoscaling。但是，Composer 不能保证此配置不会在环境更新或升级时被覆盖。