GKE 自动缩放不会缩小
GKE autoscaling doesn't scale down
我们使用 GKE(Google Kubernetes Engine)来 运行 GCC(Google Cloude Composer)中的 Airflow 作为我们的数据管道。
我们从 6 个节点开始,然后意识到成本激增,我们没有使用那么多 CPU。所以我们认为我们可以降低最大值,但也可以启用自动缩放。
由于我们 运行 管道在夜间运行,白天只有较小的作业,因此我们希望 运行 在 1-3 个节点之间自动缩放。
因此,我们在 GKE 节点池上启用了自动缩放,但没有按照他们的建议在 GCE 实例组上启用。但是,我们得到这个:
这是为什么?
下面是我们过去 4 天 CPU 利用率的图表:
我们从来没有超过 20% 的使用率,那为什么不缩减呢?
今天早上我们手动将其缩减到 3 个节点..
我首先要提到的是,当集群中存在未充分利用的节点时,会触发缩容过程。在这种情况下, "underutilized" 不仅与 CPU 用法有关,因此您的推理并不完全正确。
如文档所述,条件是此节点上所有 pods 运行 的 cpu 和内存请求之和小于为 Autoscaler 定义的利用率阈值。然后,"if a node is unneeded for more than 10 minutes, it will be terminated"。有关详细信息,请参阅 this。
同样重要的是要知道还有一些其他因素可能会阻止缩减过程,例如 node auto-provisioning limits. Check this 有关 pods 的更多信息可以阻止集群自动缩放器删除一个节点。
Cloud Composer 尚未(截至 2019/08/26)支持 GKE 集群自动缩放器,因为集群自动缩放器根据 resource requests of Pods, as well as how many Pods are in the unschedulable state (more information here) 做出缩放决策。 Composer 部署固定数量的 Pods,这意味着自动缩放机制不会强制执行任何缩放操作,除非您自己将自己的工作负载部署到集群中。
自动缩放也很难做到,因为 Airflow worker 或调度程序的实际资源使用取决于您上传了多少 DAG(在 Composer 的情况下,上传到 GCS),这意味着没有准确估计有多少 CPU/memory 您的 Airflow 流程将使用。这意味着您不知道如何决定 Airflow Pods.
的 Pod 资源请求
在没有自动缩放的情况下,动态资源分配仍然有很多选择。例如,您可以使用 KubernetesPodOperator 将带有资源请求的 Pods 部署到 不同的 Kubernetes 集群中,该集群 确实 启用了自动缩放。或者,您可以在启动更多资源密集型工作负载之前使用 GCE 运算符将实例添加到您的集群。
所以,你说"it's not supported"它的k8s有点奇怪。
按照指定启用 GKE 集群自动缩放器 here:
gcloud container clusters update [CLUSTER_NAME] --enable-autoscaling \
--min-nodes 1 --max-nodes 10 --zone [COMPUTE_ZONE] --node-pool default-pool
这是默认节点池,如果您创建了一个新池,请使用那个。
转到您的 airflow-worker 部署并在 name: airflow-worker
或 ports:
之后添加此部署
resource:
requests:
cpu: 400m
然后在这之后,像这样自动缩放你的部署:
kubectl autoscale deployment airflow-worker --cpu-percent=95 --min=1 --max=10 -n <your namespace>
在我的例子中,它就像一个魅力,它为我的 airflow-worker 部署扩展了节点和 pods。
PoC:
$ kubectl get hpa -n <my-namespace> -w
- 名称参考目标 MINPODS MAXPODS 复制品年龄
- 气流工人Deployment/airflow-worker /95% 1 3
0 13 秒
- 气流工人Deployment/airflow-worker 20%/95% 1 10 1
29米
- 气流工人Deployment/airflow-worker 27%/95% 1 10 2
29米
- 气流工人Deployment/airflow-worker 30%/95% 1 10 3
29米
- 气流工人Deployment/airflow-worker 53%/95% 1 10 3
29米
- 气流工人Deployment/airflow-worker 45%/95% 1 10 3
34米
- 气流工人Deployment/airflow-worker 45%/95% 1 10 3
34米
- 气流工人Deployment/airflow-worker 28%/95% 1 10 2
34米
- 气流工人Deployment/airflow-worker 32%/95% 1 10 2
35
- 气流工人Deployment/airflow-worker 37%/95% 1 10 2
43米
- 气流工人Deployment/airflow-worker 84%/95% 1 10 1
43米
- 气流工人Deployment/airflow-worker 39%/95% 1 10 1
44米
- 气流工人Deployment/airflow-worker 29%/95% 1 10 1
44米
您可以看到一段时间后它缩小到 1 个 pod。与节点池缩减到 4 个节点而不是 5-6-7 相同..
我们使用 GKE(Google Kubernetes Engine)来 运行 GCC(Google Cloude Composer)中的 Airflow 作为我们的数据管道。
我们从 6 个节点开始,然后意识到成本激增,我们没有使用那么多 CPU。所以我们认为我们可以降低最大值,但也可以启用自动缩放。
由于我们 运行 管道在夜间运行,白天只有较小的作业,因此我们希望 运行 在 1-3 个节点之间自动缩放。
因此,我们在 GKE 节点池上启用了自动缩放,但没有按照他们的建议在 GCE 实例组上启用。但是,我们得到这个:
这是为什么?
下面是我们过去 4 天 CPU 利用率的图表:
我们从来没有超过 20% 的使用率,那为什么不缩减呢?
今天早上我们手动将其缩减到 3 个节点..
我首先要提到的是,当集群中存在未充分利用的节点时,会触发缩容过程。在这种情况下, "underutilized" 不仅与 CPU 用法有关,因此您的推理并不完全正确。
如文档所述,条件是此节点上所有 pods 运行 的 cpu 和内存请求之和小于为 Autoscaler 定义的利用率阈值。然后,"if a node is unneeded for more than 10 minutes, it will be terminated"。有关详细信息,请参阅 this。
同样重要的是要知道还有一些其他因素可能会阻止缩减过程,例如 node auto-provisioning limits. Check this 有关 pods 的更多信息可以阻止集群自动缩放器删除一个节点。
Cloud Composer 尚未(截至 2019/08/26)支持 GKE 集群自动缩放器,因为集群自动缩放器根据 resource requests of Pods, as well as how many Pods are in the unschedulable state (more information here) 做出缩放决策。 Composer 部署固定数量的 Pods,这意味着自动缩放机制不会强制执行任何缩放操作,除非您自己将自己的工作负载部署到集群中。
自动缩放也很难做到,因为 Airflow worker 或调度程序的实际资源使用取决于您上传了多少 DAG(在 Composer 的情况下,上传到 GCS),这意味着没有准确估计有多少 CPU/memory 您的 Airflow 流程将使用。这意味着您不知道如何决定 Airflow Pods.
的 Pod 资源请求在没有自动缩放的情况下,动态资源分配仍然有很多选择。例如,您可以使用 KubernetesPodOperator 将带有资源请求的 Pods 部署到 不同的 Kubernetes 集群中,该集群 确实 启用了自动缩放。或者,您可以在启动更多资源密集型工作负载之前使用 GCE 运算符将实例添加到您的集群。
所以,你说"it's not supported"它的k8s有点奇怪。 按照指定启用 GKE 集群自动缩放器 here:
gcloud container clusters update [CLUSTER_NAME] --enable-autoscaling \
--min-nodes 1 --max-nodes 10 --zone [COMPUTE_ZONE] --node-pool default-pool
这是默认节点池,如果您创建了一个新池,请使用那个。
转到您的 airflow-worker 部署并在 name: airflow-worker
或 ports:
resource:
requests:
cpu: 400m
然后在这之后,像这样自动缩放你的部署:
kubectl autoscale deployment airflow-worker --cpu-percent=95 --min=1 --max=10 -n <your namespace>
在我的例子中,它就像一个魅力,它为我的 airflow-worker 部署扩展了节点和 pods。
PoC:
$ kubectl get hpa -n <my-namespace> -w
- 名称参考目标 MINPODS MAXPODS 复制品年龄
- 气流工人Deployment/airflow-worker /95% 1 3
0 13 秒 - 气流工人Deployment/airflow-worker 20%/95% 1 10 1 29米
- 气流工人Deployment/airflow-worker 27%/95% 1 10 2 29米
- 气流工人Deployment/airflow-worker 30%/95% 1 10 3 29米
- 气流工人Deployment/airflow-worker 53%/95% 1 10 3 29米
- 气流工人Deployment/airflow-worker 45%/95% 1 10 3 34米
- 气流工人Deployment/airflow-worker 45%/95% 1 10 3 34米
- 气流工人Deployment/airflow-worker 28%/95% 1 10 2 34米
- 气流工人Deployment/airflow-worker 32%/95% 1 10 2 35
- 气流工人Deployment/airflow-worker 37%/95% 1 10 2 43米
- 气流工人Deployment/airflow-worker 84%/95% 1 10 1 43米
- 气流工人Deployment/airflow-worker 39%/95% 1 10 1 44米
- 气流工人Deployment/airflow-worker 29%/95% 1 10 1 44米
您可以看到一段时间后它缩小到 1 个 pod。与节点池缩减到 4 个节点而不是 5-6-7 相同..