Всем привет. Есть вопрос по использованию KubernetesPodOperator. Дано: Airflow 2.5.3, в качестве

executor выставлен CeleryKubernetesExecutor.
Есть один воркер.
Задача: используя KubernetesPodOperator поднять под на кастомном образе и выполнить в нем код.
Что еще есть: большой и страшный корпоративный прокси, к-й прописан в энвах всего чего можно (в мастерах, в воркерах и в образе самого Airflow).
В чем проблема: при попытке поднять под через @task.kubernetes сталкиваюсь с тем, что Airflow не может скачать из внешнего докера (docker.io) Alpine - отваливается по тайм-ауту.
При этом - кастомный образ без проблем пуллится с локального хранилища.
Образ Alpine из внешнего докера (docker.io) без проблем скачивается руками (nerdctl pull...) как на мастер, так и на воркер-ноды.
Подскажите, пож-та, куда копать?
Гугление результатов особых не дает(

Что пробовал:
в KubernetesPodOperator через env_vars прокидывать параметры прокси (http/HTTP, https/HTTPS) руками - не помогло

в тематической группе по Airflow мне никто ничего не ответил :(
вот и пришел к вам

в каком месте airflow пытается скачивать образ? он же просто pod создаёт

у Airflow есть особенность - при использовании kpo он создает sidecar-под, который проксирует xcom-запросы между создаваемым подом и воркером и вот именно при деплое сайдкара происходит пулл alpine

ещё раз вопрос, в каком месте airflow пытается скачивать образ?

ответ могу показать в виде логов логи в картинке отправлю в лс?

imgbb.com - сюда ссылку. но лучше текстом через pastebin

https://ibb.co/HHhRgLY

ну так это не airflow скачивает, это kubernetes скачивает.

тогда всё еще страннее у кубера настроен прокси, но почему-то он настройки прокси игнорирует

в каком месте настроено? Образ скачивает container engine, у его процесса должны быть настройки прокси

а что в AF? спарк?

см. здесь https://stackoverflow.com/questions/77318225/how-to-configure-proxy-in-kubernetes-to-pull-images

это логи AF, что в эвентах пода

спс да, нашел этот файл на мастере но там отличается синтаксис вместо [Service] Environment="HTTP_PROXY=http://proxy.example.com" Environment="HTTPS_PROXY=http://proxy.example.com" Environment="NO_PROXY=localhost" имеем [Service] Environment="HTTP_PROXY=http://proxy.example.com" "HTTPS_PROXY=http://proxy.example.com" "NO_PROXY=localhost" адреса корректные

Стикер

они дублируют то что на картинке

там дальше Pod Event

Значит косяк в настройках прокси

Это должно быть не на мастере

питоновский код задача - виртуализацию venv поменять на схему 1 таска = 1 под

да, это должно быть на всех нодах. добавь везде и перезапусти containerd

покопался в нодах, на которых развернут airflow везде прокси есть кроме одной - и на этой ноде живет только redis (компонент Airflow), который как раз отвечает за управление CeleryKubernetesExecutor

на всех надо

отсюда мой следующий вопрос, уже чисто по куберу) у меня теперь как минимум есть задача сделать так, чтобы редис уехал с проблемной ноды. снимать метку airflow с этой ноды мне запретили старшие товарищи :/ допустим в конфиге airflow я меняю метку на другую, метку ставлю только на "нормальные" ноды. правильно же понимаю, что без рестарта сервиса (helm upgrade и/или kill po) сервис сам не уедет?

Если редис стейтфулсетом раскатан он и так и так не уедете

вопрос не понятен. тебе метку запретили снимать чисто ради метки (что тупо), или всё таки ради того, чтоб именно на эту ноду приезжал под редиса (тогда ты пытаешься сделать то, что тебе запретили, и это тоже не очень умно)??

и опять у тебя зачем то airflow в вопросе. Какое отношение конфиг airflow имеет к вопросу?

как раз пытаюсь добиться объяснений про первый вариант. редису этой проблемной ноде не место. мне предложили придумать новую метку и пометить ей разрешенные ноды дискутирем, в общем...