Что стоит настроить во FluxCD после базовой установки

FluxCD часто начинают использовать с минимального сценария: есть Git-репозиторий с манифестами, есть Kustomization, контроллер периодически забирает изменения и приводит кластер к нужному состоянию. Для первого GitOps-пайплайна этого достаточно, но в реальной инфраструктуре быстро появляются дополнительные требования: остановить выкладку во время инцидента, дождаться CRD перед установкой приложения, безопасно хранить секреты, разделить права между командами и автоматически обновлять версии образов.

Хорошая новость в том, что большую часть таких задач FluxCD умеет решать штатными средствами. Ниже — шесть возможностей, которые стоит настроить после базового bootstrap.

Пауза, ручной reconcile и управление интервалами

FluxCD не обязан применять каждое изменение немедленно. У ресурсов GitRepository, OCIRepository, Kustomization и HelmRelease есть интервалы проверки, таймауты и механика приостановки. Это полезно, когда кластер находится в нестабильном состоянии или нужно временно заморозить конкретный контур.

Базовые операции обычно выполняются через CLI:

flux suspend kustomization apps-prod
flux resume kustomization apps-prod
flux reconcile kustomization apps-prod --with-source

flux suspend не удаляет уже созданные ресурсы, а только останавливает дальнейшее применение изменений для выбранного объекта. reconcile --with-source принудительно просит Flux перечитать источник и снова сверить желаемое состояние с кластером. Это удобно после ручного исправления секрета, восстановления registry или починки CRD-оператора.

На уровне YAML стоит явно задавать interval, retryInterval и timeout. Тогда поведение будет предсказуемым: Flux не начнёт слишком агрессивно долбить сломанный endpoint, но и не будет ждать час, чтобы поднять приложение после исправления ошибки.

Зависимости между Kustomization и HelmRelease

В Kubernetes часто важен порядок: сначала CRD, потом оператор, затем приложения, которые используют эти CRD. Если всё положить в один каталог и применять без зависимостей, можно получить гонки: HelmRelease уже создан, а нужный controller ещё не готов.

Во FluxCD для этого есть поле dependsOn. Например, прикладной слой можно запускать только после инфраструктурного:

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: apps
  namespace: flux-system
spec:
  interval: 10m
  path: ./clusters/prod/apps
  prune: true
  sourceRef:
    kind: GitRepository
    name: platform
  dependsOn:
    - name: infrastructure

Контроллер дождётся, пока зависимая Kustomization перейдёт в Ready, и только потом начнёт применять следующий слой. Так проще разложить кластер на понятные уровни: CRD и операторы, системные сервисы, базы данных, приложения.

Для сложных случаев можно использовать более точные проверки готовности, но даже простой dependsOn уже убирает значительную часть случайных падений при первичном развёртывании кластера.

Health-проверки вместо слепого применения YAML

GitOps не заканчивается командой kubectl apply. Важно понимать, что Deployment действительно раскатился, StatefulSet поднял реплики, а CRD-оператор успел создать нужные ресурсы. Во FluxCD за это отвечают wait, healthChecks и таймауты в Kustomization.

Пример:

spec:
  wait: true
  timeout: 5m
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: api
      namespace: prod

С такой настройкой Flux не отметит синхронизацию успешной сразу после применения манифеста. Он будет ждать, пока объект станет готовым, и только затем выставит Ready=True. Если приложение не стартует, ошибка появится в статусе Kustomization, а зависимые слои не поедут дальше.

postBuild-подстановки для разных окружений

У FluxCD есть механизм postBuild, но его важно понимать правильно: это не запуск shell-скриптов после деплоя, а этап подстановки переменных в уже собранные Kustomize-манифесты. Он помогает держать одну базу YAML и переиспользовать её для разных окружений.

Например:

spec:
  postBuild:
    substitute:
      cluster_name: homelab
      domain: apps.example.local
    substituteFrom:
      - kind: ConfigMap
        name: cluster-vars
        optional: true

В манифестах можно использовать ${cluster_name} или ${domain}, а значения хранить рядом с конфигурацией конкретного кластера. Это проще и безопаснее, чем размножать почти одинаковые каталоги dev, stage и prod с ручными отличиями в нескольких строках.

Если нужны настоящие интеграционные тесты после выкладки, их лучше выносить в отдельный Kubernetes Job, CI-пайплайн или контроллер, а во Flux оставлять декларативную часть: применить, дождаться готовности, показать статус.

Мультитенантность через namespace, RBAC и serviceAccountName

В FluxCD нет необходимости давать всем командам полный доступ к flux-system. Ресурсы можно раскладывать по namespace, ограничивать Kubernetes RBAC и указывать, от имени какого service account выполнять reconcile.

Ключевые элементы такой схемы:

• отдельный namespace для команды или продукта;
• Kustomization или HelmRelease, созданные в этом namespace;
• serviceAccountName в спецификации, чтобы контроллер применял ресурсы с ограниченными правами;
• запрет cross-namespace-ссылок на уровне контроллеров, если нужно жёстко изолировать команды.

Так платформа может владеть базовой инфраструктурой, а продуктовые команды — только своими приложениями. Даже если команда ошибётся в манифесте, RBAC не позволит ей изменить чужой namespace или системный компонент.

SOPS-секреты и автоматическое обновление образов

Хранить открытые секреты в Git нельзя, но GitOps без секретов быстро превращается в набор ручных действий. FluxCD интегрируется с SOPS: в репозиторий попадает зашифрованный YAML, а контроллер расшифровывает его перед применением в кластер.

Типовая настройка для Age-ключа выглядит так:

spec:
  decryption:
    provider: sops
    secretRef:
      name: sops-age

Сам ключ хранится как Kubernetes Secret в namespace, где работает Flux. В Git остаётся только зашифрованное содержимое. При этом важно помнить: после применения Kubernetes Secret всё равно хранится средствами самого Kubernetes, поэтому для production стоит включать encryption at rest для etcd и аккуратно настраивать доступы.

Вторая полезная автоматизация — обновление версий образов. Связка ImageRepository, ImagePolicy и ImageUpdateAutomation позволяет Flux сканировать registry, выбирать подходящий тег по semver или другому правилу и создавать commit с обновлением YAML. После этого обычный GitOps-цикл применяет новую версию.

Для production лучше добавлять pull request и ревью, но сам механизм остаётся тем же: источник правды — Git, а не ручная команда в кластере.

Итог

FluxCD раскрывается сильнее всего, когда используется не как «демон для применения YAML», а как набор контроллеров для управляемого жизненного цикла кластера. Паузы и ручной reconcile помогают переживать инциденты, dependsOn задаёт порядок слоёв, health-проверки дают понятный статус, postBuild убирает дублирование конфигов, RBAC и service account изолируют команды, а SOPS и image automation закрывают секреты и обновления.

Если базовая синхронизация уже работает, следующий шаг — включать эти возможности постепенно. Начать можно с dependsOn, wait: true и SOPS: они быстро дают практическую пользу и не требуют перестраивать весь репозиторий.