Если вы применяете в своей инфраструктуре GitOps-подход, то вам точно знакомы такие решения по автоматизации доставки для Kubernetes, как FluxCD и ArgoCD. Это популярные инструменты, которые позволяют синхронизировать наполнение отслеживаемого Git-репозитория и отобразить его в кластере Kubernetes. Сегодня воздержимся от их сравнения и сконцентрируемся на разговоре о том, какие удобства при работе может предоставить FluxCD.
Как он вообще работает
FluxCD — это набор контроллеров, которые работают внутри Kubernetes-кластера и следят за соответствием между состоянием Git-репозитория (или другого источника) и фактическим состоянием ресурсов в кластере. В основе лежит паттерн reconciliation loop. Суть его в том, что контроллеры периодически сравнивают желаемое состояние (которое описано в Git/Helm/OCI) и текущее состояние в кластере, при расхождениях приводя систему к заявленному виду.
Таким образом мы можем автоматизировать доставку манифестов, упростить аудит изменений и восстановление состояния кластера из Git. FluxCD хорошо вписывается в CI/CD-процессы. CI генерирует манифесты, Helm-релизы, образы и так далее, а FluxCD занимается их применением и поддержкой в кластере.
Ключевые компоненты:
source-controller — отвечает за получение артефактов (Git, Helm, OCI). Он следит за репозиториями, chart-репозиториями и OCI-реестрами. Также он проверяет наличие новых коммитов, тегов или новых артефактов и делает их доступными другим контроллерам в виде ресурсов типа GitRepository, HelmRepository, Bucket и ImageRepository;
kustomize-controller — применяет манифесты и поддерживает Kustomize, включая работу с иерархиями, патчами и генераторами. Отвечает за сборку и расчет финального манифеста перед его отправкой в
kube-apiserver;helm-controller — управляет Helm-релизами и Chart-репозиториями, поддерживает автоматическое обновление зависимостей, хранение release-состояния в кластере и интеграцию с OCI-реестрами для чартов;
notification-controller — обрабатывает события кластера и отправляет уведомления в Slack, Microsoft Teams, Loki и другие каналы, в том числе через вебхуки. Его используют для оперативного информирования о статусе реконсиляций, возникающих ошибках и деплое новых релизов.
Вся логика строится вокруг reconciliation loop — контроллеры периодически сравнивают желаемое и текущее состояние и приводят систему к нужному виду.
Хотите выиграть призы и бонусы на аренду серверов?
Приглашаем решить ИТ-кроссворд! Более 100 вопросов на разные темы из мира ИИ и машинного обучения — ежедневно с 6 по 9 июля.
Визуализация
Начнем с того, что сам FluxCD не имеет встроенного графического интерфейса, но отлично интегрируется со сторонними GUI. Например, в FreeLens (это, как несложно догадаться по названию, бесплатный брат приложения Lens для удобной работы с сущностями Kubernetes) можно подключить специальный плагин, который наглядно отображает всю работу инструмента. Подробнее о нем можете почитать в статье разработчика.
В базовой версии FreeLens и так можно было следить за всеми ресурсами — проверять статусы реконсиляции всех размещенных Kustomization, проваливаться в GitRepository и так далее, но данный плагин объединяет все это в одном месте.
Чтобы не искать нужное в Custom Resource, просто открываете вкладку FluxCD. Там отображаются статусы GitRepository, Kustomization, HelmRelease, а также история последних операций, ошибки и ссылки на конкретные коммиты в Git:
Другие Flux UIs/GUIs можно найти здесь.
Управление порядком деплоя
С визуализацией разобрались, теперь посмотрим на внутренние настройки FluxCD. Один из важнейших аспектов развертывания — это соблюдение строгой последовательности при создании ресурсов в кластере.
Например, если вам нужно развернуть кастомный ресурс (CR), для работы которого требуются CRD и сам оператор, порядок действий должен быть следующим:
Сначала разворачиваются CRD.
Затем запускается оператор.
И только после этого начинается деплой самого кастомного ресурса.
Для этого нам нужно прописать параметр dependsOn. Выглядит это следующим образом:
apiVersion: … kind: Kustomization metadata: name: … … spec: dependsOn: - name: <имя ресурса, от которого зависит данный ресурс>
Такая схема обеспечивает предсказуемость деплоя и сводит к минимуму возникновение «гонок за ресурсами» при первичном развертывании или обновлениях.
Важный нюанс:
dependsOnсвязывает между собой разные объектыKustomization. При проектировании такой цепочки необходимо следить за тем, чтобы зависимости не образовывали циклов.
Если вы работаете с несколькими окружениями (dev/stage/prod), хорошей практикой будет организация иерархии Kustomization: на базовом уровне разворачиваются CRD и операторы, а на следующих слоях — зависящие от них приложения.
Остановка и восстановление процесса реконсиляции на время ручных работ в кластере
Развертывание сервисов через CI/CD-пайплайны иногда занимает много времени. Если вам нужно быстро протестировать исправления в манифестах или внести ad-hoc изменения прямо в кластер, автоматическую реконсиляцию FluxCD полезно временно приостановить. Для этого используются команды flux suspend ks <имя ks> (чтобы заморозить процесс) и flux resume ks <имя ks> (чтобы включить реконсиляцию обратно).
После выполнения suspend контроллер перестает применять изменения к указанному ресурсу. Это позволяет выполнить ручные правки в кластере, протестировать их и подготовить финальную версию манифестов для отправки в Git. По завершении работ достаточно выполнить resume, чтобы вернуть систему в штатный режим, а проверенные изменения зафиксировать в CI/CD-пайплайне.
Помимо CLI-команд, приостановить реконсиляцию можно через интерфейс FreeLens: для этого перейдите на вкладку Kustomization, выберите нужный ресурс и нажмите кнопку suspend/resume. Также этот параметр можно задать декларативно прямо в манифесте:
apiVersion: ... kind: Kustomization metadata: name: ... ... spec: suspend: true
Мой вам совет: не оставляйте suspend надолго — это ломает логику GitOps-модели.
Шифрование ключей
Обеспечение безопасности секретов — одна из самых критичных задач при внедрении GitOps, так как Flux сам по себе не шифрует данные в Git-репозитории.
Из коробки он поддерживает нативную интеграцию с популярными инструментами шифрования, такими как Mozilla SOPS и Sealed Secrets (от Bitnami), позволяя расшифровывать секреты прямо «на лету» в процессе реконсиляции. Кроме того, Flux поддерживает работу с Kubernetes Secret и ExternalSecretOperator.
Вариантов организации хранения секретов несколько, поэтому выбирайте то, что подходит под вашу архитектуру и нужды.
Общие требования и принципы
Не храните plain-text секреты в репозиториях. Риск утечки данных сохраняется даже в приватных репозиториях.
Минимизируйте круг лиц и CI/CD-процессов, имеющих доступ к ключам дешифрования.
Регулярно проводите ротацию ключей и регламентируйте процедуры их восстановления.
Настройте аудит-логи для отслеживания доступа к репозиторию и ключам (например, с помощью HashiCorp Vault audit devices).
Удаление/неудаление ресурсов после их исключения из kustomization-файла деплоя в кластер
Важный аспект GitOps — управление ресурсами, которые были удалены из репозитория. FluxCD контролирует этот процесс через параметр prune.
Возможны два сценария:
prune: true— ресурсы удаляются из кластера. В таком случае Git остается единственным источником истины;prune: false— ресурсы остаются в кластере, даже если их удалили из Git.
Когда опция prune активна, FluxCD автоматически выполняет очистку (garbage collection) удаленных объектов. Однако здесь есть важный нюанс: если этот режим включен для пространства имен (namespace) со stateful-компонентами, возникает риск безвозвратной потери данных. Поэтому критически важно грамотно проектировать политики для таких ресурсов, как StatefulSet и PersistentVolumeClaim.
Распространенное решение — выносить stateful-ресурсы в отдельный манифест Kustomization с параметром prune: false и контролировать их жизненный цикл обособленно. Такая гибкость настроек позволяет адаптировать FluxCD под самые разные модели эксплуатации.
Пример Kustomization с включенным удалением ресурсов из кластера:
apiVersion: ... kind: Kustomization metadata: name: ... ... spec: prune: true
Отслеживание циклов реконсиляции
Выше мы уже упоминали FreeLens и функции suspend/resume. Теперь разберем, как отслеживать актуальность версии приложения в кластере Kubernetes.
В интерфейсе FreeLens на вкладке Kustomization предусмотрен столбец Applied Revision. В нем отображаются ветка последнего коммита и его хэш, благодаря чему можно мгновенно определить, какие именно изменения сейчас развернуты в кластере.
Если свежие изменения еще не применились, автоматику можно не ждать: команда flux reconcile kustomization <имя-ks> принудительно запустит новый цикл реконсиляции вне очереди.
FluxCD — мощный и гибкий инструмент, который при правильной настройке берет на себя рутину GitOps. В этой статье мы разобрали фичи, которые я использую если не ежедневно, то регулярно, и они действительно упрощают эксплуатацию кластеров.
Расскажите в комментариях, какими фишками FluxCD пользуетесь вы и какой стек выбрали для себя. Буду рад обсудить и обменяться опытом!
Спасибо за прочтение!