ConfigMap обновился, а приложение видит старое значение: env, volume и перезапуск

В ConfigMap уже стоит новый адрес сервиса, а API всё ещё обращается к старому. Перезапуск отдельного процесса иногда помогает, иногда нет. Дело в способе доставки настройки: значение могло попасть в environment при создании контейнера, лежать в проецируемом файле или быть прочитано приложением один раз при старте. Эти варианты требуют разных действий.

Смотрим, откуда контейнер берёт значение

kubectl -n demo get deployment api -o yaml
kubectl -n demo get pod api-example -o yaml
kubectl -n demo get configmap api-settings -o yaml

Найдите env, envFrom, volumes и volumeMounts. Проверяйте конкретное имя ConfigMap и namespace: похожая настройка могла быть изменена у другого приложения. Внутри созданного Pod сохранена фактическая ссылка, а шаблон Deployment мог уже измениться. Для Secret читайте только необходимую метаинформацию и ссылку, не печатайте содержимое в общий журнал.

При env.valueFrom.configMapKeyRef Kubernetes передаёт значение в окружение нового контейнера. Работающий процесс не получает обновление environment после изменения ConfigMap. То же относится к Secret, подключённому через env. Поэтому изменённый объект и старое значение у работающего приложения могут одновременно быть корректными наблюдениями.

Файл обновляется, приложение может не перечитать его

ConfigMap можно подключить как каталог. Пример фрагмента spec Pod показывает один файл app.yaml; контейнер api должен содержать соответствующий volumeMount:

volumes:
  - name: settings
    configMap:
      name: api-settings
      items:
        - key: app.yaml
          path: app.yaml
containers:
  - name: api
    image: registry.example.com/team/api:release
    volumeMounts:
      - name: settings
        mountPath: /etc/api-settings
        readOnly: true

При обычном volume обновления проецируются с задержкой, зависящей от kubelet и его механизма обновления. Это не мгновенная доставка. Приложение должно заново открыть файл либо поддерживать корректное наблюдение за изменениями. Если оно держит прежний открытый дескриптор или загружает YAML только при запуске, новый файл на диске ещё не означает новую конфигурацию в памяти.

Монтаж отдельного файла через subPath меняет результат: такие подключения ConfigMap и Secret не получают автоматических обновлений. Это частая причина, когда файл «точно подключён как volume», но остаётся прежним. Проверьте наличие subPath именно в volumeMounts проблемного контейнера. Для конфигурации immutable изменение данных запрещено; обычно создают объект с новым именем и обновляют ссылку в шаблоне.

Подтверждаем расхождение без утечки секретов

kubectl -n demo exec api-example -c api -- cat /etc/api-settings/app.yaml
kubectl -n demo rollout status deployment/api --timeout=120s

Первая команда применима к несекретному файлу примера и образу с cat. Для Secret лучше проверять версию конфигурации через безопасный диагностический признак приложения, например идентификатор ротации без самого токена. Значения из printenv или полного config могут оказаться в истории терминала и логах поддержки. Сначала решите, какое наблюдение нужно для вывода, затем выводите минимально необходимое.

Выбираем reload или новый rollout

Если приложение поддерживает горячую перезагрузку, проверьте её контракт: какой сигнал или API вызывает перечитывание, что происходит при ошибке файла и как подтверждается новая версия. Нельзя посылать произвольный сигнал процессу, надеясь, что он реализует reload. Для env и приложений без перечитывания потребуется пересоздать Pod управляющим workload.

kubectl -n demo rollout restart deployment/api
kubectl -n demo rollout status deployment/api --timeout=180s

Команды меняют рабочее приложение, поэтому выполняются как согласованная операция релиза после проверки новой конфигурации. restart обновляет шаблон и запускает обычный rollout со своей стратегией доступности. В GitOps-проекте предпочтителен управляемый из источника механизм: новое имя ConfigMap или checksum в аннотации шаблона, рассчитанный из содержимого. Изменение checksum должно действительно менять Pod template.

После обновления проверьте новый Pod, эффективную версию настройки в приложении и запрос, использующий её. Для ротации credentials также убедитесь, что обе стороны допускают переходный период: новая реплика с новым токеном и старая со старым могут работать одновременно. Сохраните способ доставки и подтверждённую приложением версию настройки.

Ещё по теме

• Readiness, liveness и startup: почему перезапуск мешает приложению запуститься
• CPU throttling в Kubernetes: почему приложение тормозит при свободном CPU

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

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