вот только что график глянул

типо жмут кнопочку разворачивается жупитер
там деофлты такие что по деолфту спарк в определенном сервси акаунте все делает например личном пер юзер да и все

ну в моем случае не надо тачки настраивать ваще

зашли в жупитер там повертели спарки как хотели и вобщем то все

браузера хватит для настройки

а что у вас за сервис? есть паблик линки?

интересный какойто кейс

нет, это внутренний кейс агоды

то есть моя команда предоставляет спарк свежий и основные коммон либы для работы + jupyter (вот сейчас там 400+ запущенных сессий крутится) + плагины для создания нотебука из кода + скедулинг твоего добра

то есть для пользователя это одна страница где он может выбрать какой кернел запустить
либо может закинуть свой код из иде в кластер и потом повертеть его в jupyter интерактивно

с минимальными телодвижениями

в кубик пока только python кернелы уехали с хадупа
спарк в процессе прикидываем как лучше сделать

а не смотрели в сторону https://github.com/jupyter/enterprise_gateway ?

там несколько моих патчей =) потому что он работал через одно место
хотя в нашем форке их было даже больше, но много было агода специфик

плюс все интерфейсы без асинк, поэтому во многих местах time.sleep стоит
а переделывать на async это нужно менять интерфейсы в ipython + jupyter самом (гейтвей это очередная надстройка над всем)
там патчи уже висели годами, но никто не шевелился

после этого я забил, так как парни не понимают что у них регулярно текут сокеты (забывают закрывать),
ну и деплой в каком кубике или докере нужно пробрасывать доп порты
https://github.com/jupyter/enterprise_gateway/issues/532

обычный джупайтер у нас скейлился до 50 где-то запущенных ноутов/сессий, дальше были проблемы
гейтвей кое-как дожил до 150, после этого поняли что грусть печаль, из-за регулярных слипов на старт/стоп/килл кернелов работать людям некомфортно
после этого написали свой гейтвей на java, в тестах до 1000 сессий подымали, всё ок, обычно в работе 400-500 активно запущенных
(вместо питона с хадуп рестом напрямую по бинарному протоколу из джавы ходим что многое упростило, есть ссш кернелы, есть кернелы в кубике)

если у вас до 100 ядер будет, то можете использовать
если планируете хотя бы 300, то как повезёт =)

у них там в коде на старте процесс
1. открыли порт на прослушку
2. сходили по ссш/отправили запрос в ярн/кубик
3. ждём на порту бекконнект с connection_info где ядро запустилось, периодически проваливаясь в time.sleep
4. получили инфу, закрыли порт, отдали клиенту что кернел ок

и вот пока крутится в 3, все пользовательские команды стоят и ждут

ты говоришь про -RemoteProcessProxy.response-address?

да
там в адресе хост передается
не помню порт там же или отдельным параметром

вот сам сервер сидит и слушает сокет этот

вот сейчас его тестирую, наткнулся на этот момент. на версии 2.5.1 в куб пытаюсь прокинуть response-address через stunnel, но порт он мне рандомно подбирает - как я понял из диапазона для каждого ядра. Может дублирования pod поможет решить проблему с забивкой порта?

вот не скажу, нужно смотреть что там как, мы 2 года назад с него сползли, может что-то поменяли, но сильно комитов не вижу на ту часть