我们使用GKE(Google Kubernetes Engine)在GCC(Google Cloude Composer)中为数据管道运行Airflow。
我们从6个节点开始,然后意识到成本飙升,而且我们并没有使用那么多的CPU。因此,我们认为可以降低最大值,但也可以启用自动缩放功能。
由于我们在晚上运行管道,而在白天只运行较小的工作,因此我们希望在1-3个节点之间运行自动缩放。
因此,在GKE节点池上,我们启用了自动缩放功能,但并未按照他们的建议在GCE实例组上启用。但是,我们得到以下信息:
为什么是这样?
We never pass 20% usage, so why doesn't it scale down?
This morning we manually scaled it down to 3 nodes..
Cloud Composer does not yet (as of 2019/08/26) support the GKE cluster autoscaler, because the cluster autoscaler makes scaling decisions based on the resource requests of Pods, as well as how many Pods are in the unschedulable state (more information here). Composer deploys a fixed number of Pods, which means the autoscaling mechanism doesn't force any scaling action unless you yourself are deploying your own workloads into the cluster.
自动缩放也很困难,因为Airflow工作人员或调度程序的实际资源使用情况取决于您上传的DAG数(在Composer中为GCS),这意味着无法准确估算您的Airflow进程将使用多少CPU /内存。 。这意味着您不知道如何确定Airflow Pod的Pod资源请求。
在没有自动缩放的情况下,动态资源分配仍然有很多选择。例如,你可以使用KubernetesPodOperator与资源请求到部署荚不同的是Kubernetes集群并有自动缩放功能。另外,您可以使用GCE运算符将实例添加到群集中,然后再启动更多占用大量资源的工作负载。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句