Argo CD и Helm: где искать values, которые реально попали в релиз

В values-prod.yaml поменяли число реплик, приложение синхронизировалось, но масштаб остался прежним. При запуске через Argo CD нужно расследовать Application, а не искать команду helm upgrade в CI. Helm здесь генерирует манифесты, а жизненным циклом ресурсов управляет Argo CD. Значение из файла может быть успешно прочитано и затем переопределено другим полем.

Сохраняем фактическую спецификацию Application

kubectl -n argocd get application demo-api -o yaml
argocd app get demo-api --refresh
argocd app manifests demo-api

В source или sources найдите repoURL, targetRevision, path либо chart и секцию helm. Запишите разрешённую ревизию из статуса. Приложение может управляться ApplicationSet, а его значения — браться из отдельного репозитория. Изменение похожего файла в другом branch не затрагивает фактический вход генератора.

Не ищите установленный Helm-релиз через helm get values: Argo CD обычно использует helm template, а не helm install. Удобная картинка параметров в UI также не обязана показывать все источники values. Проверяемым результатом остаётся желаемый манифест, который генерирует именно это Application.

Читаем приоритет от самого сильного источника

Порядок переопределений Argo CD: parameters, затем valuesObject, затем values, затем valueFiles и defaults chart. В списке valueFiles последний файл сильнее предыдущих при совпадении ключа. Поэтому наличие правильного значения в values-prod.yaml ещё не доказывает, что оно станет итоговым.

source:
  repoURL: https://git.example.com/team/charts.git
  targetRevision: main
  path: charts/api
  helm:
    valueFiles:
      - values-common.yaml
      - values-prod.yaml
    valuesObject:
      replicaCount: 4
    parameters:
      - name: replicaCount
        value: "5"

Это фрагмент spec Application с заполнителем repoURL. Если defaults задают 1, common — 2, prod — 3, то valuesObject задаёт 4, а parameters окончательно выбирает 5. Удаление parameters вернёт управление значению 4, а не сразу файлу prod. Чтобы файл стал владельцем ключа, нужно проверить и убрать согласованным изменением все перекрывающие уровни.

Параметр forceString у отдельного элемента parameters нужен, когда значение должно остаться строкой. Это влияет на тип входа шаблона и возможную YAML-валидацию результата. Списки и вложенные структуры проверяйте в рендере полностью: переопределение не следует трактовать как автоматическое дополнение элементов по смысловому имени.

Разбираем отдельный репозиторий values

В multi-source Application chart и values могут поступать из разных источников. Источник с ref задаёт именованную ссылку, а valueFiles использует её через $values. Важны revision этого репозитория и путь от его корня. Ниже chart расположен в Git, а значения — в другом Git-репозитории:

sources:
  - repoURL: https://git.example.com/team/charts.git
    targetRevision: main
    path: charts/api
    helm:
      valueFiles:
        - $values/environments/prod/api.yaml
  - repoURL: https://git.example.com/team/config.git
    targetRevision: main
    ref: values

Ссылка $values стоит в начале пути. Источник values без path используется для файлов значений, а не для генерации отдельного набора ресурсов. Перед изменением проверьте поддержку multi-source вашей версией Argo CD. Если файл необязательный и включён ignoreMissingValueFiles, его отсутствие может пройти без ошибки и оставить defaults; при расследовании такой флаг нужно увидеть явно.

Сравниваем исправление до Sync

После изменения источника Application выполните refresh и manifests, найдите конкретное поле нужного объекта. Для replicaCount важно, чтобы chart действительно обращался к этому ключу. При HPA контроллер может затем изменить live replicas, поэтому сначала отделите правильный desired от последующего изменения live. Так вы не спутаете ошибку values с конкуренцией владельцев поля.

Если Application генерируется, исправляйте соответствующий template или generator ApplicationSet. Временная CLI-подстановка параметра может быть заменена следующим согласованием. Сохраните карту конкретного ключа: из какого файла пришёл, чем перекрывался и какое поле получилось в манифесте. После Sync проверьте не только статус приложения, но и требуемое поведение workload; рендер доказывает выбор конфигурации, а не способность приложения работать с ней.

Ещё по теме

• Helm Job завис при установке через Argo CD: hooks, имена и жизненный цикл
• Prune и selfHeal в Argo CD: какие изменения они исправляют

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

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