Сколько секунд argoCD докатывает изменения?

Question

deepseek-v3.2 · Accepted Answer

## Временные рамки синхронизации Argo CD

При ответе на вопрос "сколько секунд ArgoCD докатывает изменения" важно понимать, что не существует единственного фиксированного значения. Argo CD — это инструмент **непрерывной поставки** (Continuous Delivery), работающий по принципу **pull-based**, и его поведение зависит от конфигурации и внешних факторов. Интервал, через который Argo CD обнаруживает и применяет изменения, определяется несколькими ключевыми компонентами.

### Основные механизмы синхронизации и их тайминги

Концептуально процесс "докатывания" изменений можно разделить на три фазы: обнаружение, синхронизация, применение. Продолжительность каждой варьируется.

1.  **Обнаружение изменений в Git-репозитории (репозиторий-источник)**:
    *   **Polling-интервал** (**период опроса по умолчанию — 3 минуты**). Argo CD периодически опрашивает Git, чтобы проверить, не появились ли новые коммиты в отслеживаемой ветке. Этот интервал настраивается параметром `timeout.reconciliation` в конфигурации Argo CD (`argocd-cm` ConfigMap).
    *   **Webhook-уведомления**. Если настроен вебхук (например, от GitHub, GitLab, Bitbucket), он мгновенно уведомляет Argo CD о новом push-событии, сводя задержку обнаружения к долям секунды. В этом случае фактор 3 минуты исключается.

2.  **Применение изменений (Операция синхронизации - Sync)**:
    После обнаружения расхождений между желаемым состоянием (Git) и фактическим (Kubernetes кластер) необходимо запустить синхронизацию. Это может произойти:
    *   **Автоматически (Auto-Sync)**: Если для приложения включена **автоматическая синхронизация** (в UI или через `spec.syncPolicy.automated`), Argo CD начнет операцию синхронизации сразу после обнаружения изменений.
    *   **Вручную**: Пользователь должен нажать кнопку "Sync" в UI или выполнить `argocd app sync <app-name>`. Время до начала операции в этом случае не определено.

3.  **Время выполнения операции Sync**:
    Это тот этап, когда Argo CD последовательно применяет манифесты к кластеру Kubernetes. Его длительность **зависит от сложности приложения**:
    *   Количества и размера ресурсов (Deployments, Services, ConfigMaps и т.д.).
    *   Наличия хуков (pre-sync, sync, post-sync) и времени их выполнения.
    *   Стратегий обновления рабочих нагрузок (например, `RollingUpdate` в Deployment). Argo CD лишь инициирует обновление, а фактическое "докатывание" новых подов контролируется `kube-controller-manager` и может занимать минуты, если есть `readinessProbe`, `minReadySeconds` или большой объем данных для образа.

### Примерная временная шкала (на примере)

Предположим, у нас настроен **вебхук** и включен **Auto-Sync**.

```yaml
# Фрагмент Application manifest (application.yaml)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  source:
    repoURL: https://github.com/example/my-repo.git
    targetRevision: HEAD
    path: k8s-manifests
  syncPolicy:
    automated: # Автоматическая синхронизация включена
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
```

**Последовательность и ориентировочное время:**
1.  **t=0с**: Разработчик делает `git push`.
2.  **t<5с**: Вебхук от Git-провайдера доставляет событие в Argo CD API. Контроллер приложения обнаруживает изменение.
3.  **t~5-10с**: Argo CD начинает операцию синхронизации, применяет манифесты к API Kubernetes.
4.  **t~10с - несколько минут**: Кластер Kubernetes обрабатывает изменения. Например, обновление Deployment:
    ```bash
    # Argo CD инициирует команду, которая приводит к чему-то вроде этого внутри кластера:
    kubectl apply -f deployment.yaml
    # Далее kube-controller-manager создает новый ReplicaSet и начинает rolling update.
    ```
    Время здесь зависит не от Argo CD, а от скорости скачивания образов (`imagePullPolicy`), готовности подов (`readinessProbe`) и т.д.

### Ключевые параметры, влияющие на скорость

*   **`argocd-cm` ConfigMap**:
    ```yaml
    data:
      # Уменьшение этого значения ускоряет обнаружение при опросе (Polling)
      timeout.reconciliation: 180s
      # Увеличение лимитов для больших приложений
      timeout.reconciliation.hard.limit: 10800s
    ```
*   **Настройки приложения** (`syncPolicy`):
    *   `automated`: Включение автоматизирует процесс.
    *   `syncOptions`:
        - `Prune=false`: Увеличивает безопасность, но может замедлить.
        - `ApplyOutOfSyncOnly=true`: Ускоряет синхронизацию, применяя только изменившиеся ресурсы.

### Вывод: теоретический минимум и практическая реальность

*   **Теоретический минимум (при идеальных условиях)**: От `git push` до начала обновления в кластере может пройти **менее 10-30 секунд**, если настроены вебхук и Auto-Sync, а приложение простое.
*   **Практическая реальность**: В production-средах полный цикл "докатывания" (до переключения трафика на новые версии подов) часто занимает **от 1 до 5 минут**. Основная задержка приходится не на Argo CD, а на процессы внутри самого Kubernetes кластера (скачивание образов, graceful shutdown старых подов, прохождение проверок готовности новыми подами).

Таким образом, **Argo CD сам по себе не "докатывает" изменения в классическом смысле** (как, например, `kubectl rollout`), а выступает триггером и контроллером состояния. Основное время обычно тратится на процессы оркестрации в Kubernetes после того, как Argo CD выполнит свою часть работы — синхронизацию манифестов.

Сколько секунд argoCD докатывает изменения?

Комментарии (1)

Временные рамки синхронизации Argo CD

Основные механизмы синхронизации и их тайминги

Примерная временная шкала (на примере)

Ключевые параметры, влияющие на скорость

Вывод: теоретический минимум и практическая реальность