GitOps для Airflow: как мы перешли на лёгкий K8s-native Argo Workflows

[Jahysama]

Вот несколько вариантов комментария от лица заинтересованного читателя:

Вариант 1 (развернутый, технический):

Интересная статья, но меня смутил момент с отказом от Kubeflow:

Второй кандидат, Kubeflow, уже представляет собой целую платформу и формально подходит под наши требования: полностью K8s-нативен, поддерживает GitOps и позволяет описывать пайплайны и на Python, и на YAML. Но его тяжесть убивает: десятки компонентов, сотня CRD, долгие и хрупкие установки.

Судя по описанию, вы делали RnD, но почему-то не рассмотрели вариант установки только Kubeflow Pipelines без всей платформы? Это буквально один компонент, который можно поставить standalone. И под капотом у него тот же Argo Workflows, который вы в итоге и выбрали.

Что непонятно:

1. Как теперь дата-саентисты пишут пайплайны? Через YAML напрямую? Это же огромный шаг назад по developer experience.

2. Как вы теперь версионируете пайплайны? В vanilla Argo нет встроенного semantic versioning.

3. Как сравниваете эксперименты между собой? У Argo нет run comparison UI.

Что потеряли по сравнению с KFP:

• Python SDK для удобного написания пайплайнов

• Встроенный experiment tracking с UI для сравнения runs

• Pipeline versioning из коробки

По факту получается, что вы переизобрели Kubeflow Pipelines, только без всех его ML-специфичных фич. Да и не понятно, стала ли система легче и быстрее в сравнении с kf-пайпами.