# ConfigMap изменён, процесс видит старое: env, volume и subPath

Диагностика: ConfigMap изменён, процесс видит старое: env, volume и subPath. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-configmap-update-reload/
Language: ru

Изменённый ConfigMap не гарантирует немедленное изменение процесса. Env values фиксируются при старте, volume projection обновляется с задержкой, а subPath mount не получает обычные обновления. Затем само приложение должно перечитать файл: Kubernetes не выполняет это за него.

## Определите способ потребления

Сохраните Pod template, имя ConfigMap, UID Pod и способ ссылки: env, envFrom или volumeMount. У одного приложения разные параметры могут приходить разными путями. Убедитесь, что изменён объект в нужном namespace и что Pod использует именно его. Сравнение файла на ноутбуке с действующим процессом не подтверждает применение конфигурации. Для проверки выберите безопасный несекретный параметр, значение которого можно однозначно увидеть без публикации внутренних данных или выполнения тяжёлой операции.


[Официальный источник 1](https://kubernetes.io/docs/concepts/configuration/configmap/).

## Разделите три обновления

Env из ConfigMap автоматически не обновляется в уже работающем процессе; нужен новый Pod. Смонтированные ключи volume со временем обновляются по механизму kubelet sync/cache. При subPath автоматического обновления не происходит. Даже обновлённый файл может оставаться непрочитанным приложением, если оно загружает configuration только при старте. Поэтому проверяйте object version, projected file и effective application setting отдельно. Сохраните настройки detection strategy, если оператор имеет доступ к этой части кластера.


[Официальный источник 2](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).

## Разберите старое значение

В учебном опыте ConfigMap содержит batch_profile=small. Оператор меняет его на medium, но процесс продолжает использовать small из env. Ожидание очередного sync не поможет такому способу потребления. Если параметр поступает из volume, сравнивают обновление файла и предусмотренный reload. Имена профилей условны и не рекомендуют параметры LLM engine. Сценарий показывает только lifecycle configuration и необходимость подтвердить, какой источник реально читает программа.

| Уровень | Наблюдаемое подтверждение |
| --- | --- |
| API object | Нужное содержимое ConfigMap |
| Env | Значение при создании процесса |
| Volume file | Полученное projection содержимое |
| Приложение | Фактически применённый setting |

## Выберите reload или rollout

Используйте documented reload приложения, если он предусмотрен и проверен. Иначе спланируйте замену Pod с доступным ресурсным бюджетом. Для versioned или immutable ConfigMap создайте новый объект и измените ссылку в template, сохранив предыдущую для rollback. Не удаляйте старый объект до завершения перехода, если он нужен работающим Pod. Отдельно проверьте совместимость образа и configuration: возврат контейнерного digest не восстанавливает внешний изменяемый ConfigMap автоматически.

## Проверьте новый процесс

После изменения подтвердите файл или env, затем эффективное поведение приложения на безопасном тесте. Сохраните manifest, object reference, время projection и момент применения. Если reload не поддерживается, успех должен относиться к новому UID Pod, а не старой интерактивной сессии. Артефакт помогает отличить задержку kubelet от read-once поведения программы. Эти границы нужно повторно проверить после изменения способа mount, чтобы привычное ожидание обновления не стало неверным после перехода на subPath или env.

Связанные разборы: [software stack reproducibility](/ru/journal/software-stack-reproducibility/); [gpu maintenance change register](/ru/journal/gpu-maintenance-change-register/).