Наша структура выглядит следующим образом:
- Проект A - Определяет и управляет общим VPC, членами которого являются все проекты
- Проект B - Запуск Jupyterhub на GKE
- Project C / D / E ... - Выполнение задачи на GKE
Jupyterhub и dask были развернуты в кластерах с использованием Helm, при этом большинство модификаций были применены через таблицы значений Helm.
Теперь обычно, когда Jupyter и dask находятся в одном кластере, очень легко использовать планировщик dask. После этого также легко просмотреть диагностическое представление Bokeh, посетив EXTERNAL-IP планировщика через веб-браузер.
В нашем случае кластер находится в другом проекте (в том же VPC), поэтому, чтобы разрешить использование планировщика (Project C) из Jupyterhub (Project B), нам нужно было изменить dask-планировщик, чтобы он действовал как внутренний балансировщик нагрузки со следующей командой:
kubectl annotate svc dask-scheduler cloud.google.com/load-balancer-type=Internal
Теперь мы можем использовать dask-планировщик из проекта B, отлично! Однако проблема в том, что теперь мы не можем просматривать Bokeh Dask-планировщика, потому что EXTERNAL-IP (с которым мы обычно видим Bokeh) был заменен этим специальным внутренним IP.
Мне кажется, что я должен иметь возможность выставить внешний IP-адрес и направить его планировщику, но мне не повезло после нескольких дней экспериментов. Стоит также отметить, что плагин dask bokeh от JupyterLab (в отличие от JupyterHub) не работает, что мне кажется странным, поскольку мы разрешаем трафик внутри VPC, и обычно просто предоставление IP-адреса планировщика этому плагину работает (очевидно, ноутбук в состоянии говорить с dask-планировщиком, он просто не видит панель bokeh).
Текущие правила брандмауэра разрешают связь между диапазонами IP GKE на всех портах и всеми протоколами (это было ключом к разрешению Jupyterhub использовать dask-планировщик).
Я могу предоставить больше информации, если необходимо, я все еще изучаю многие из этих концепций, поэтому дайте мне знать, если что-то неясно.
Спасибо!