Flux v1 (Weaveworks): автосинхронизация Kubernetes с git за 30 секунд

В феврале мы писали про ArgoCD - GitOps-контроллер с UI, ролями, проектами и прочей инфраструктурой для команды. Flux от Weaveworks - другой зверь. Никакого UI, никаких абстракций поверх Kubernetes. Просто оператор, который раз в 30 секунд смотрит в git и говорит кластеру «стань таким».

Мы поставили его на два dev-кластера в managed-проектах и выяснили, что это именно то, чего нам не хватало для разработчиков.

Проблема, которую мы решали

Схема до Flux была простая и утомительная. Разработчик собирал образ в CI, пушил в registry, потом писал в чат: «можете накатить обновление в dev?». Инженер в свободный момент бежал на машину, делал kubectl set image или helm upgrade, отвечал «готово». Разработчик проверял. Иногда образ был не тот - ошибся тегом. Иногда инженер был занят и цикл растягивался на час.

Это не трагедия, но это лишние переключения контекста с обеих сторон. В managed-среде у нас несколько проектов параллельно, и таких «накати обновление» накапливается достаточно, чтобы раздражать.

Как работает Flux

Flux - это Kubernetes-оператор. Он живёт в кластере как Deployment, читает из git-репозитория манифесты (или Helm-чарты через Helm Operator), и применяет их через стандартный Kubernetes API. Интервал опроса настраивается, мы выставили 30 секунд - это оптимум для dev.

Отдельная фича - автообновление по образу. Flux умеет следить за container registry и сам обновлять тег образа в манифесте, когда появляется новый. При этом он делает коммит обратно в git - то есть registry-тег и git остаются синхронизированы. Это немного голова кругом, когда понимаешь что оператор сам пишет в репозиторий, но логика правильная: git остаётся source of truth, а не разъезжается с фактическим состоянием кластера.

Схема для нашего случая:

CI собирает образ -> пушит в registry -> Flux видит новый тег -> обновляет манифест в git -> применяет в кластер

Разработчик смерджил PR - через 30-60 секунд новая версия в dev. Без чатиков.

Как настраивали

Установка через официальные манифесты из репозитория Weaveworks. Flux нужен доступ к git: мы добавили deploy key (публичный) в репозиторий с правами на запись - для автообновления тегов. Это слегка неудобно если репозитории разные у каждого проекта, но для dev это разовая настройка.

Конфигурация минимальная. Основное что нужно указать:

• --git-url - адрес репозитория.
• --git-branch - ветка которую смотреть. Мы используем dev для dev-кластеров.
• --git-path - директория с манифестами, если они не в корне.
• --registry-exclude-image - паттерны образов которые не надо трогать (базовые образы, sidecar-ы без версионирования).

Важный момент с автообновлением образов: по умолчанию Flux смотрит все образы во всех Deployment-ах кластера. Это может быть сюрпризом - он начнёт обновлять что угодно с новым тегом в registry. Мы явно аннотировали Deployment-ы:

annotations:
  flux.weave.works/automated: "true"
  flux.weave.works/tag.container-name: semver:~1.2

Аннотация flux.weave.works/tag позволяет задать политику - semver, glob, или regexp. Для dev мы используем glob:dev-* чтобы Flux подхватывал только образы с тегами вида dev-<короткий sha>.

Что получилось

Первые несколько дней разработчики немного нервничали - привычка писать в чат никуда не делась. Потом поняли что можно просто проверить самостоятельно: открыл сервис в браузере, увидел что версия обновилась, двинулся дальше. Несколько человек сказали что это «как деплой на Heroku, только в Kubernetes». Мы не обиделись.

На инженерной стороне: стало меньше мелких переключений. Настоящие проблемы - когда образ не собрался, или манифест невалидный - всё равно требуют вмешательства, но это редкость. Рутинные «накати dev» ушли.

Одна тонкость с которой столкнулись: если кто-то делает kubectl apply или kubectl edit руками в dev-кластере - Flux через 30 секунд это перезапишет. Для dev это нормально и даже правильно: хочешь что-то поправить - правь в git. Для staging мы автосинхронизацию не включали - там деплой только через явное одобрение.

Чем отличается от ArgoCD

Оба инструмента про GitOps, но по-разному. ArgoCD - это система с UI, состоянием приложений, ролями, проектами, ручным approve перед синхронизацией. Flux - минималистичный оператор без интерфейса, «поставил и забыл». ArgoCD лучше подходит для staging/production где нужна видимость и контроль. Flux - для dev-петли где скорость обратной связи важнее церемоний.

Мы сейчас используем оба: Flux на dev, ArgoCD смотрим для staging. Может разойдёмся по назначению, а может один победит другой - посмотрим.

Главное что поменялось: инженеры перестали быть ботами для kubectl set image. Это было несложно, но занимало больше места в голове, чем казалось.