我们使用GKE(Google Kubernetes引擎)在GCC(Google Cloude Composer)中为数据管道运行Airflow。
我们从6个节点开始,然后意识到成本猛增,而且我们并没有使用太多的CPU。因此,我们认为可以降低最大值,但也可以启用自动缩放功能。
由于我们在晚上运行管道,而白天只运行较小的工作,因此我们希望在1-3个节点之间运行自动缩放。
因此,在GKE节点池上,我们启用了自动缩放功能,但并未按照他们的建议在GCE实例组上启用。但是,我们得到以下信息:
这是为什么?
我们永远不会超过20%的使用率,为什么不按比例缩小呢?
今天早晨,我们手动将其缩小为3个节点。
答案 0 :(得分:2)
我要提到的第一件事是,当集群中存在未充分利用的节点时,将触发缩小过程。在这种情况下,“未充分利用”不仅与CPU使用率有关,因此您的推理并不完全正确。
如文档所述,条件是该节点上运行的所有Pod的cpu和内存请求之和小于为Autoscaler定义的利用率阈值。然后,“如果不需要一个节点超过10分钟,它将被终止”。有关更多信息,请参见this。
另外,重要的是要知道还有其他一些因素可能会阻止缩小规模的过程,例如node auto-provisioning limits。检查this,了解有关可以阻止群集自动缩放器删除节点的Pod的更多信息。
答案 1 :(得分:2)
Cloud Composer尚不支持(截至2019/08/26)GKE群集自动缩放器,因为该群集自动缩放器基于Pod的resource requests以及扩展池中有多少Pod做出扩展决策。计划外状态(更多信息here)。 Composer部署了固定数量的Pod,这意味着除非您自己将自己的工作负载部署到集群中,否则自动扩展机制不会强制执行任何扩展操作。
自动缩放也很困难,因为Airflow工作程序或调度程序的实际资源使用情况取决于您上传的DAG数(在Composer中为GCS),这意味着无法准确估算您的Airflow有多少CPU /内存流程将使用。这意味着您不知道如何决定Airflow Pod的Pod资源请求。
在没有自动缩放的情况下,动态资源分配仍然有很多选择。例如,您可以使用KubernetesPodOperator将带有资源请求的Pods部署到不同启用了自动缩放的不同 Kubernetes集群中。另外,您可以使用GCE运算符在启动更多资源密集型工作负载之前将实例添加到群集中。
答案 2 :(得分:0)
因此,您说“不支持”其k8有点奇怪。 按照指定的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>
就我而言,它就像一个护身符一样工作,它为我的气流工作人员部署同时缩放了节点和吊舱。
PoC:
$ kubectl get hpa -n <my-namespace> -w
一段时间后您会看到它缩小到1pod。与将节点池缩小到4个节点而不是5-6-7一样。