🛠️ ConfigMap уже обновлён, а приложение всё ещё читает старый файл

Проверяем:

kubectl get configmap app-config -n production -o yaml

Значение новое.

Внутри Pod:

kubectl exec -n production -- cat /etc/app/config.yaml

— старое.

До поиска cache приложения проверьте manifest.

Если есть:

volumeMounts:

• name: app-config mountPath: /etc/app/config.yaml subPath: config.yaml

то причина может быть прямо здесь.

Обычный ConfigMap volume обновляется eventually после изменения ConfigMap.

Но ConfigMap, смонтированный как subPath, не обновляет этот файл в уже работающем container.

То есть:

ConfigMap API = новый subPath file = старый

— ожидаемый сценарий.

Что проверить:

1. Сам ConfigMap. 2. Pod/Deployment manifest:

volumes: configMap: volumeMounts: subPath:

3. Фактический файл внутри container.

Дальше развилка.

Файл уже новый, приложение читает старое:

→ проверяйте reload/cache приложения.

Файл старый и есть subPath:

→ auto-update ждать не нужно.

Файл старый, но subPath нет:

→ учитывайте eventual kubelet update и продолжайте разбирать volume/config delivery.

Ещё одна оговорка: ConfigMap через env или envFrom не обновляет environment уже работающего процесса. Обычно нужен новый Pod.

GitOps тоже может быть полностью Synced: он применил ConfigMap, но это не означает автоматический rollout workload, если Pod template не изменился.

Возможные решения зависят от приложения:

— новый Pod или rollout; — checksum ConfigMap в Pod template; — отказ от subPath; — directory mount; — reloader/controller; — application-level reload.

Не выбирайте способ автоматически: restart и изменение mount semantics могут влиять на доступность и filesystem внутри контейнера.

Вывод:

ConfigMap → manifest → subPath → файл в container → reload приложения

Сохраните этот сценарий для случаев «конфиг уже новый, приложение — ещё старое».

🔹🔹🔹🔹