Argo CD не запускает Sync: проверяем sync windows и ручной запуск

CI обновил Git, Argo CD видит новую ревизию, но приложение не разворачивается. В интерфейсе появляется Sync Denied. Здесь автоматизация могла остановиться намеренно: AppProject ограничивает время применения. Перезапуск контроллера не расширит окно. Нужно восстановить правило, которое выбрало это Application, и проверить текущий момент в его часовом поясе.

Читаем разрешение у приложения и проекта

argocd app get demo-api --refresh
kubectl -n argocd get application demo-api -o yaml
argocd proj get team-api
kubectl -n argocd get appproject team-api -o yaml

Имя проекта возьмите из spec.project Application. В app get посмотрите состояние SyncWindow и назначенные окна, в AppProject — spec.syncWindows. Сам статус OutOfSync означает отличие желаемого состояния, а не разрешение начать операцию. Если проблема в RBAC пользователя, credentials Git или schema validation, сообщение будет относиться к другому этапу; не объясняйте все задержки расписанием.

Как выбираются приложения

Окно может выбирать Application по имени, namespace назначения и кластеру. Это destination namespace приложения, а не namespace argocd, где хранится сам объект. По умолчанию несколько групп критериев объединяются через «или». Поэтому applications: api-* вместе с namespaces: prod может выбрать и постороннее приложение в prod. Если требуется пересечение, проверьте поддержку и настройку AND вашей версией Argo CD.

Для начала удобнее одно очевидное правило без смешивания критериев. Следующий фрагмент добавляется в spec AppProject и разрешает автоматические Sync приложений api-* ежедневно с 09:00 на восемь часов по Москве:

syncWindows:
  - kind: allow
    schedule: "0 9 * * *"
    duration: 8h
    timeZone: Europe/Moscow
    applications:
      - "api-*"
    manualSync: false

Это ограничение времени, а не расписание обязательного деплоя. Если приложение уже Synced, наступление девяти часов не создаёт новую ревизию. Если подходящее allow-окно существует, вне его активного интервала автоматический Sync не разрешён. Если подходящих окон вообще нет, сами sync windows не блокируют приложение.

Разбираем пересечения allow и deny

Активное подходящее deny-окно имеет приоритет над allow. Добавленное «разрешение на аварийный релиз» не отменит существующий запрет простым пересечением расписаний. Перечитайте все подходящие окна проекта, включая wildcard по namespace и кластеру. При разборе зафиксируйте дату, время, зону и интервал duration: cron задаёт начало, а продолжительность определяет активность после него.

Явный timeZone позволяет сравнивать правило с локальным временем команды без догадок о настройке контроллера. Для зон с переводом часов дополнительно проверьте поведение на переходных датах. Сравнивать только часы на ноутбуке недостаточно, особенно если команда и инфраструктура находятся в разных регионах.

Ручной запуск — отдельное разрешение

Окна влияют и на ручные, и на автоматические операции. manualSync позволяет настроить ручное выполнение в ситуации, когда окно блокирует обычный Sync. Это не выдаёт пользователю права Argo CD RBAC: разрешение действия и разрешение времени проверяются отдельно. Кнопка Sync не должна считаться универсальным обходом любого deny.

Для аварийного релиза ответственный меняет нужное окно или его manual-разрешение в управляемом источнике, проверяет назначенное состояние Application и только затем выполняет согласованную операцию. Не удаляйте все окна проекта ради одного приложения. После завершения верните штатный режим и сохраните, какое правило временно изменялось.

Учитываем уже начавшуюся синхронизацию

Длительная операция может пересечь границу окна. В актуальных версиях для такого поведения существует syncOverrun; его поддержка и сочетание всех подходящих окон требуют проверки в вашей установке. Не обещайте, что закрытие окна автоматически откатит уже созданные ресурсы: временная политика не является транзакцией базы или полным rollback релиза. Для первого разбора достаточно отделить запрет нового старта от уже выполняющейся операции.

После исправления дождитесь допустимого состояния, проверьте фактически применённую ревизию и готовность workload. Запись расследования должна отвечать, какое окно выбрало приложение и почему оно было активно. Тогда повторная пауза в следующем часовом интервале станет ожидаемым поведением, а не очередным подозрением на зависший контроллер.

Ещё по теме

• Argo CD не читает репозиторий: credentials, URL и доступ repo-server
• Миграция базы перед приложением в Argo CD: hooks и sync waves

Продолжить изучение

Хотите выстроить доставку изменений из Git в кластер? Синхронизация, окружения и восстановление после неудачного релиза — темы программы «Argo CD и GitOps: деплой в Kubernetes».