Я пытаюсь запустить конвейер snakemake в кластере кубернетов (GKE). Задание инициируется виртуальной машиной GCE. Иногда это работает, в большинстве случаев нет.
Я сделал следующие шаги
gcloud container clusters get-credentials snakemake-k8s-demo
kubectl delete pod $(kubectl get pods | grep snakejob|colprint 1)
snakemake --kubernetes --container-image eu.gcr.io/scailyte-is/snakemake-gsdk --use-conda --default-remote-provider GS --default-remote-prefix xxxxxx-snakemake-test-1 --jobs 2
Эта первая попытка сработала очень хорошо.
Затем я удалил файлы, созданные конвейером snakemake, и снова запустил идентичное задание, ничего не меняя.
Задание завершилось ошибкой со следующим сообщением об ошибке:
HTTPSConnectionPool(host='storage.googleapis.com', port=443): Max retries exceeded with url: /storage/v1/b/xxxxxxx-snakemake-test-1/o?projection=noAcl (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f3ee35159d0>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))
Согласно Google Cloud Status Dashboard, с Google Cloud Storage проблем нет.
Последующие попытки не увенчались успехом.
Любые советы по разрешению с благодарностью принимаются.
Проблема была вызвана отсутствием соответствующих правил брандмауэра, разрешающих взаимодействие внутри кластера. Как только соответствующие правила ALLOW были созданы, проблема сразу же исчезла, так как модуль смог связаться со своим DNS-сервером.
Наша политика заключается в том, чтобы запретить любое взаимодействие (включая внутреннее VPC) между конечными точками, если это явно не разрешено. Таким образом, новый кластер в новом адресном пространстве нуждался в дополнениях, чтобы он мог работать должным образом.
Я понял это, включив ведение журнала для последнего правила DENY, которое срабатывает, когда предыдущее правило ALLOW не было применимо.
Я не понял, почему это сработало в первый раз, но подозреваю, что были некоторые различия, на которые я не обращал внимания.