ARGOCD ssh: ошибка рукопожатия: чтение tcp 10.#.3.21:36808->20.#.#.#:22: чтение: соединение сброшено узлом и не удалось получить клиент git для репо

создал argocd-приложение, упомянул два источника, оно получило статус sync ok, но каждые несколько секунд начинает получать

ssh: handshake failed: read tcp 10.254.3.21:36808->20.41.6.26:22: read: connection reset by peer 
and failed to get git client for repo 

ошибки. Какие-либо предложения

project: default
destination:
  server: 'https://kubernetes.default.svc'
  namespace: akv2k8s
syncPolicy:
  automated:
    prune: true
    selfHeal: true
sources:
  - repoURL: 'http://charts.spvapi.no'
    targetRevision: 2.3.2
    helm:
      valueFiles:
        - $values/charts/akv2k8s.yaml
    chart: akv2k8s
  - repoURL: 'git@ssh.##.azure.com:v3/####'
    targetRevision: helm_chart_test
    ref: values

я уже добавил секрет repo-cred с помощью sshkey, который отлично работает, если я использую только одно репо в качестве источника.

Несколько источников в ArgoCD — это бета-функция. В документации не вижу ни одного примера с использованием SSH: github.com/argoproj/argo-cd/blob/master/docs/proposals/…. Попробуйте вместо этого использовать HTTPS?

HiroCereal 20.04.2023 13:44
Введение в Ansible Roles
Введение в Ansible Roles
Ansible - это отличный инструмент управления конфигурацией, который можно использовать для автоматизации настройки или развертывания на большом...
"DevOps: Jenkins & AWS Series, часть 5: Установка Gradle на Ubuntu 22.04
"DevOps: Jenkins & AWS Series, часть 5: Установка Gradle на Ubuntu 22.04
В этой статье блога мы проведем вас через процесс установки Gradle на Ubuntu 22.04, интеграции его с Jenkins и создания задания Gradle. Мы...
9 шагов по безопасному развертыванию функций с помощью флагов функций
9 шагов по безопасному развертыванию функций с помощью флагов функций
В этой статье мы рассмотрим шаги по безопасному развертыванию обновления.
0
1
178
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Оказывается, основной причиной является параллелизм в функции LsRemote:

func (m *nativeGitClient) LsRemote(revision string) (res string, err error) {
    for attempt := 0; attempt < maxAttemptsCount; attempt++ {
        res, err = m.lsRemote(revision)
        if err == nil {
            return
        } else if apierrors.IsInternalError(err) || apierrors.IsTimeout(err) || apierrors.IsServerTimeout(err) ||
            apierrors.IsTooManyRequests(err) || utilnet.IsProbableEOF(err) || utilnet.IsConnectionReset(err) {
            // Formula: timeToWait = duration * factor^retry_number
            // Note that timeToWait should equal to duration for the first retry attempt.
            // When timeToWait is more than maxDuration retry should be performed at maxDuration.
            timeToWait := float64(retryDuration) * (math.Pow(float64(factor), float64(attempt)))
            if maxRetryDuration > 0 {
                timeToWait = math.Min(float64(maxRetryDuration), timeToWait)
            }
            time.Sleep(time.Duration(timeToWait))
        }
    }
    return
}

Кажется, что когда 2 запроса попадают в репо одновременно, один из них завершается ошибкой. Но это поведение не начинается сразу, сначала выполняется некоторое количество одновременных запросов.

Так что это очень похоже на преднамеренное регулирование Azure DevOps.

На данный момент решение состоит в том, чтобы увеличить maxAttemptsCount с 1 по умолчанию до 50, установив переменную среды ARGOCD_GIT_ATTEMPTS_COUNT.

Я наблюдал, как число повторных попыток увеличилось до 12, пока оно, наконец, не увенчалось успехом. Нужно проверить, можно ли контролировать это дросселирование. Если нет, возможно, этот код ArgoCD можно было бы улучшить. Например, рандомизация паузы между повторными попытками может дать лучшие результаты.

эта переменная ARGOCD_GIT_ATTEMPTS_COUNT для репо-сервера решает проблему для меня, спасибо

jitender singh 17.05.2023 17:08

Другие вопросы по теме