Helm применил не те values: проверяем порядок файлов и итоговый манифест

В values-prod.yaml записано replicas: 3, но после helm upgrade приложение получает одну реплику. Сам файл при этом корректен. Значение могло быть заменено следующим файлом, параметром --set, сохранёнными значениями прежнего релиза либо вообще не использоваться шаблоном. Разберём цепочку на небольшом chart и отделим входные values от результата рендера.

Восстанавливаем точную команду

Для обычного вызова Helm значения chart служат основой, затем учитываются переданные values-файлы и параметры CLI. При нескольких -f более правый файл имеет приоритет для одинакового ключа. Параметры --set имеют более высокий приоритет, чем файлы. Повторяющиеся параметры тоже нужно читать в порядке вызова. Запишите команду из CI целиком вместе с версией chart и namespace.

helm version
helm get values api -n demo -o yaml
helm get values api -n demo --all -o yaml
helm get manifest api -n demo

Команды get обращаются к существующему релизу api. Без --all вы увидите сохранённые пользовательские значения, с --all — вычисленный набор с defaults. Manifest показывает сохранённый результат шаблонов релиза. Эти три представления отвечают на разные вопросы; одно не заменяет другое. Секреты, попавшие в values или манифесты, могут появиться в выводе, поэтому сохраняйте его в защищённом месте.

Минимальный пример перезаписи

Создайте локальный каталог values-lab. В Chart.yaml запишите следующий файл; он нужен только для template и не устанавливается в кластер:

apiVersion: v2
name: values-lab
version: 0.1.0

В values.yaml задайте replicas: 1. В каталоге templates создайте deployment.yaml с таким содержимым. Шаблон использует ровно тот ключ, который мы исследуем:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: values-lab
spec:
  replicas: {{ .Values.replicas }}
  selector:
    matchLabels: {app: values-lab}
  template:
    metadata:
      labels: {app: values-lab}
    spec:
      containers:
        - name: web
          image: nginx:stable-alpine

Рядом с chart создайте base.yaml с replicas: 2 и prod.yaml с replicas: 3. Теперь сравните три локальных рендера:

helm template demo ./values-lab -f base.yaml -f prod.yaml
helm template demo ./values-lab -f prod.yaml -f base.yaml
helm template demo ./values-lab -f base.yaml -f prod.yaml --set replicas=4

В spec.replicas ожидаются соответственно 3, 2 и 4. Эти числа следуют из порядка источников. Если в реальном chart результат другой, найдите ссылку на .Values в шаблоне: ключ может называться replicaCount, находиться внутри subchart или вычисляться условием. Наличие replicas в values ещё не доказывает его использование.

Учитываем типы и списки

Для значения, которое должно остаться строкой, используйте --set-string, когда обычный --set изменяет тип. Вложенные map обычно объединяются по ключам, но список не следует считать набором элементов, который Helm обязательно дополнит по имени. При переопределении списка легко потерять другие элементы. Сравните полный итоговый участок YAML, особенно env, hosts и наборы дополнительных контейнеров.

На upgrade отдельно проверьте --reuse-values и --reset-values. Первый сохраняет прежние значения как основу слияния с новыми переопределениями, второй возвращает основу к values обновляемого chart. Смешивать эти режимы в памяти с обычным template опасно: локально вы можете рендерить другой набор. Поведение вызова без явного режима также зависит от переданных новых значений, поэтому при расследовании используйте точную команду и историю релиза.

Проверяем предполагаемое обновление до применения

Соберите значения и ту же версию chart локально, затем выполните template или предусмотренный вашей версией Helm dry-run. Dry-run может выводить Secret и при серверном режиме обращаться к кластеру, поэтому сначала выберите нужный режим. Локальный template проверяет рендер, но не работу контроллеров и не доступность API целевого кластера.

Когда нашли заменяющий источник, исправьте его в CI или команде релиза и сохраните проверку итогового поля. Этот разбор относится к Helm CLI. Argo CD использует Helm для генерации и имеет собственные поля Application и порядок их приоритета; переносить сюда названия valuesObject или parameters без разбора способа запуска не нужно.

Ещё по теме

• Service в Kubernetes не отвечает: проверяем selector и EndpointSlice
• DNS в Kubernetes отвечает медленно: проверяем CoreDNS, search и ndots

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

Хотите увереннее разворачивать приложения и разбирать сбои в кластере? Сети, конфигурация, хранилища и обновления входят в программу «Kubernetes с нуля до PRO».