环境
我正在运行具有3个节点的Cloud Composer集群（composer-1.6.0-airflow-1.10.1），并在创建Composer环境时提供了默认的Yaml GKE文件。我们有3个工人celery节点，每个节点运行4个工人线程（celery.dag_concurrency
问题
我注意到，两个celery worker pods被安排在同一群集节点上（假设为节点A），第三个pods位于节点B上。NodeC运行着一些支持的pods，但是其cpu和内存利用率很小。
以前，我们每个工人使用10个工人线程，这导致所有三个工人吊舱都调度在同一节点上！由于节点内存不足，导致Pod每隔几分钟被逐出。
我希望每个pod都安排在一个单独的节点上，以实现最佳的资源利用。
GKE Master version - 1.11.10-gke.5
Total size - 3 nodes
Node spec:
Image type - Container-Optimised OS (cos)
Machine type - n1-standard-1
Boot disk type - Standard persistent disk
Boot disk size (per node) - 100 GB
Pre-emptible nodes - Disabled
解决方法
默认情况下，Cloud Composer不会为工作吊舱指定请求的内存。通过以防止在同一节点上调度两个工作容器的方式设置请求的内存，可以解决该问题。就我而言，我将请求的内存设置为1.5Gi
答案 0 :(得分：1)
Cloud Composer的辅助容器尝试通过在调度过程中使用容器抗亲和力来避免进行协同调度，但这并不总是有效的。例如，当其他节点尚不可用时（例如，在GKE版本升级或Airflow升级后群集恢复联机时），仍然可以在同一节点上调度多个Pod。 >
在这些情况下，解决方案是使用GKE工作负载界面删除Airflow工作人员，这导致他们被重新创建并最终达到平衡。同样，您观察到的驱逐在某种程度上具有破坏性，但最终有助于平衡节点上的工作人员。
这显然有点不方便，因此在发布#136548942下的公共发行跟踪器中已将其作为功能请求进行了跟踪。我建议跟随那里。