Я тестирую Spark 2.3.1 (автономно) на кластере из неизолированного Kubernetes
У меня есть кластер с двумя виртуальными машинами, оба с 8 ГБ оперативной памяти и 2 ядра.
Я развернул кластер с одним главным узлом и двумя подчиненными узлами.
Журналы узлов кажутся правильными, рабочие правильно зарегистрированы с мастером:
kubectl exec spark-master cat /opt/spark/logs/spark-logs
Мастер-журналы
kubectl exec spark-worker1 cat /opt/spark/logs/spark-logs
рабочий-журналы
И, согласно GUI, рабочие, похоже, готовы и способны общаться с мастером.
Spark GUI
Я открыл следующий порт в искровом контейнере:
- 7077, для работника, чтобы добраться до мастера
- 7078, для работника, чтобы достичь мастера
- 37421 spark.driver.port, от spark-default
Затем я попытался выполнить базовое задание spark, запустив sparkind shell из контейнера, используя spark-shell --master spark://spark-master:7077 с sc.makeRDD(List(1,2,4,4)).count в качестве задания.
если я использую spark-shell из подчиненного узла, код выполняется, и я получаю результат. Однако, если я запускаю оболочку от мастера, я получаю следующее сообщение об ошибке:
WARN TaskSchedulerImpl: начальное задание не приняло никаких ресурсов; проверьте интерфейс вашего кластера, чтобы убедиться, что работники зарегистрированы
и иметь достаточные ресурсы
При поиске этого сообщения об ошибке я обнаружил эту проблему с github . Я почти уверен, что это проблема с сетью, потому что работа начинается на рабочем узле. Задание, запущенное в главном контейнере, достигает рабочего, но похоже, что рабочий не может ответить основному. Журналы на рабочих выглядят как this .
Все порты, которые рабочий использует для связи с мастером, открываются в deploy.yml, и брандмауэр отключен.
Кто-нибудь уже сталкивался с такой ситуацией?