У меня есть один вопрос относительно планирования стручков Gitlab. Мы используем копы с 2 группами экземпляров. Эти группы экземпляров динамически масштабируются с использованием кластера автоматического масштабирования. Мы установили метки для этих 2 групп экземпляров. У меня есть 1 вопрос:
1) Как запланировать «вспомогательные» стручки gitlab runner (runner-concurrent) на разных узлах и не планировать эти стручки на одном и том же работнике. Поскольку сейчас у нас есть ситуация, когда мы запускаем 2 задания параллельно, CA раскручивает 2 рабочих узла, но эти 2 задания запланированы на одном узле. Я установил лимиты pod на 3 (2 системных модуля и 1 место для задания gitlab-runner, но в этом случае 1 задание иногда завершится сбоем из-за нехватки ресурсов (ограничения pod). Но иногда оно будет правильно планировать модули на разных узлах ). Я знаю о nodeAffinity et c, но Gitlab в настоящее время не поддерживает это. Есть ли возможность избежать сродства в области действия Gitlab?
Если с моей стороны неясно: когда pods runner-gitlab-concurrent уже запланирован на одном из рабочих узлов, я хочу запланировать другой модуль на другой рабочий узел. В моем случае я вижу, что при параллельном запуске 2 или более заданий они видят, что рабочие узлы свободны и могут быть запланированы на одном и том же узле. Но другие 2 узла становятся свободными.