FluxCD становится всё более востребованным инструментом среди инженеров, выстраивающих GitOps-пайплайны для Kubernetes. Пока ArgoCD остаётся привычным выбором многих команд, FluxCD предлагает иную философию: никакого встроенного UI, зато максимальная гибкость, нативная интеграция с экосистемой и прозрачная архитектура контроллеров.
Как устроен механизм и почему он работает
В основе FluxCD лежит принцип reconciliation loop - контроллеры непрерывно сверяют желаемое состояние из Git, Helm или OCI-реестра с тем, что реально крутится в кластере. Обнаружили расхождение - моментально привели систему в порядок. Никаких ручных применений, никакого «забыл задеплоить».
Архитектура разбита на специализированные компоненты. Каждый решает строго свою задачу:
- source-controller - следит за репозиториями и реестрами, раздаёт артефакты другим контроллерам
- kustomize-controller - собирает финальный манифест и отправляет его в kube-apiserver
- helm-controller - управляет Helm-релизами, включая OCI-чарты
- notification-controller - рассылает оповещения в Slack, Teams, через вебхуки
Порядок деплоя и управление зависимостями
Одна из острых болей при работе с Kubernetes - гонки за ресурсами при первичном развёртывании. Оператор стартует раньше CRD, всё падает. FluxCD решает это через параметр dependsOn: можно явно указать, какой объект Kustomization должен успешно реконсилироваться прежде, чем запустится следующий. CRD сначала, оператор потом, приложение в конце. Предсказуемо и надёжно.
Важная оговорка: зависимости не должны образовывать циклов. Иначе реконсиляция зависнет намертво.
Ручные правки, секреты и контроль над удалением ресурсов
Иногда нужно быстро проверить фикс прямо в кластере, не гоняя полный пайплайн. Для этого FluxCD позволяет временно заморозить реконсиляцию командой flux suspend - и вернуть её командой flux resume после проверки. Удобно. Но злоупотреблять не стоит: долгий suspend ломает саму логику GitOps-модели.
Отдельного внимания заслуживает работа с секретами. FluxCD не шифрует данные в репозитории самостоятельно, зато нативно интегрируется с Mozilla SOPS и Sealed Secrets - расшифровка происходит прямо в процессе реконсиляции. Plain-text секреты в репозитории - недопустимо, даже в приватных.
Наконец, параметр prune определяет судьбу ресурсов, которые убрали из Git. При значении true объект исчезает и из кластера. При false - остаётся, даже если в репозитории его уже нет. Выбор зависит от того, насколько строго команда придерживается принципа «Git - единственный источник истины».
