Изменение объекта Secret в Kubernetes не означает, что уже запущенный процесс перечитает новое значение.
Поведение зависит от способа подключения: переменная окружения фиксируется при старте контейнера, а mounted volume обновляется иначе и все равно требует поддержки reload со стороны приложения.
Где остается старое значение
Нужно отделить состояние API Kubernetes, файловой системы pod и памяти приложения.
- kubectl показывает новый Secret, но приложение использует старый пароль.
- Новый pod получает значение, а давно работающие pods нет.
- Файл в volume обновился, но соединение с сервисом не пересоздалось.
- Secret через subPath не меняется до перезапуска.
Почему возникает проблема
Источник Secret может обновиться корректно, но цепочка доставки и перечитывания остается незавершенной.
- Secret передан через env или envFrom и доступен только при старте процесса.
- Volume обновляется с задержкой, а приложение читает файл один раз.
- Использование subPath исключает обычное обновление смонтированного содержимого.
- Deployment не получает изменение pod template и не выполняет rollout.
- Обновлен Secret с тем же именем в другом namespace или context.
Пошаговая диагностика
Не выводите значение секрета в логи: достаточно сравнить metadata, checksum или безопасный fingerprint.
- Проверьте namespace, имя Secret и resourceVersion в нужном кластере.
- Посмотрите, подключен Secret как env, volume, CSI или внешний оператор.
- Сравните время обновления Secret и создания каждого pod.
- Проверьте путь volume и наличие subPath в pod spec.
- Установите, умеет ли приложение перечитывать файл или сигнал reload.
Выберите явную стратегию ротации
Секрет должен не только обновиться в Kubernetes, но и безопасно вступить в силу в приложении.
- Для env выполняется управляемый rollout pods.
- Для volume приложение отслеживает файл или получает reload.
- Смена учетных данных допускает переходный период старого и нового значения.
- Ошибочный Secret можно быстро откатить без раскрытия содержимого.
Как исправить проблему
Используйте rollout или reload в соответствии со способом подключения секрета.
- Для env перезапустите workload управляемым rollout после обновления Secret.
- Автоматизируйте rollout checksum-аннотацией или проверенным reloader-контроллером.
- Для volume уберите subPath, если требуется автоматическое обновление файла.
- Добавьте приложению безопасное перечитывание и пересоздание зависимых соединений.
- Настройте readiness, чтобы pod принимал трафик только с рабочим новым секретом.
Как проверить результат
- Все новые pods созданы после нужной resourceVersion Secret.
- Приложение успешно подключается с новым значением.
- Readiness не пропускает pod с ошибочной конфигурацией.
- Старое значение отозвано только после завершения перехода.
Типичные ошибки
- Печатать Secret в лог для сравнения.
- Ждать обновления env внутри уже работающего процесса.
- Удалять все pods одновременно без стратегии доступности.
- Ротировать внешнюю учетную запись до проверки нового значения.
Как предотвратить повторение
- Документируйте способ подключения и ротации каждого секрета.
- Проверяйте rollout и readiness в тестовом окружении.
- Используйте безопасные fingerprints вместо значений в диагностике.
- Добавьте алерт на ошибки авторизации после ротации.
Когда нужна помощь
Если Kubernetes Secret обновился, а приложение видит старое значение, я проверю способ подключения, rollout и reload, настрою безопасную ротацию без вывода секретов и лишнего простоя.