Сообщить об ошибкеКороткий ответ
Переменные окружения, переданные из ConfigMap, читаются процессом только один раз при старте контейнера и не обновляются без перезапуска; файлы, смонтированные как volume из ConfigMap, обновляются на диске автоматически (с задержкой синхронизации kubelet), но приложение должно само отслеживать изменение файла, чтобы подхватить новую конфигурацию без перезапуска.
Как это работает подробнее
при использовании envFrom/env.valueFrom.configMapKeyRef значения подставляются в переменные окружения процесса на старте контейнера операционной системой — после этого никакая синхронизация с Kubernetes API не происходит. При монтировании ConfigMap как volume kubelet периодически (обычно за время, близкое к TTL кэша kubelet, порядка минуты) обновляет содержимое файлов в уже запущенном контейнере, но само приложение должно реализовать механизм отслеживания изменений файла (например, через inotify или периодический опрос).
Пример кода
spec:
template:
metadata:
annotations:
checksum/config: "{{ sha256sum-of-configmap }}"Что использовать на практике
- Практика. для конфигурации, которая должна меняться "на лету" без простоя, предпочтительно монтирование как файл с логикой горячей перезагрузки в приложении; если приложение не поддерживает это, распространённый паттерн — добавить в манифест аннотацию с хэшем содержимого ConfigMap, которая меняется при каждом обновлении конфигурации и тем самым провоцирует rolling update Deployment (пересоздание подов с новой конфигурацией).
Подводные камни
- Риски. менять ConfigMap и ожидать, что переменные окружения в уже работающих подах обновятся без их перезапуска — это невозможно архитектурно; не предусматривать механизм управляемого перезапуска/rollout после изменения конфигурации, из-за чего часть подов работает со старой, а часть — с новой конфигурацией в неопределённый период.