Есть четыре разных перезапуска:
— Перезапуск контейнера — процесс убит и пересоздан, объект пода остался. UID и IP не меняются, restart count +1.
— Пересоздание пода — объект удалён, создан новый. UID новый, IP новый, restart count сбрасывается в 0.
— Rolling update — новый ReplicaSet поднимает новые поды, старые завершаются. Тоже новые UID и IP.
— In-place resize (1.35 GA) — cgroups обновляются, процесс не трогается. UID и IP неизменны.
Простой тест:
Изменился ли UID пода?
Если да — это пересоздание, а не перезапуск.
Если нет — тот же объект пода продолжил жить, перезапустился только процесс внутри.
➡️ Что часто упускают
kubelet следит за спецификацией пода — а не за ConfigMap'ами, Secret'ами или CRD Istio. Если вы обновили ConfigMap, но spec пода не изменился — kubelet ничего не сделает. Изменение для kubelet попросту невидимо.
Этот факт объясняет большую часть расследований «почему мой конфиг не обновился?» в проде.
💬 Что вызывает перезапуск, а что — нет?
— ConfigMap/Secret через env var — процесс читает переменные один раз при execve(). POSIX-контракт: никто извне не может их менять. Нужен явный rollout restart.
— ConfigMap/Secret как volume — kubelet делает атомарную подмену симлинка. Срабатывает IN_CREATE на ..data, а не IN_MODIFY на файле — большинство наивных реализаций reload этот момент пропускает. Приложение должно само перечитать файл.
— Смена образа — всегда пересоздание пода через rolling update. Новый ReplicaSet, новый UID, новый IP. Это не перезапуск.
— CPU/Memory в 1.35 GA — резайз без пересоздания пода. UID и IP не меняются. Контейнер перезапускается только если так указано в resizePolicy.
— Istio VirtualService / DestinationRule — никогда не перезапускает. Istiod пушит конфиг через xDS gRPC прямо в Envoy, в память. Файлов на диске нет.
— NetworkPolicy — никогда. CNI агент обновляет eBPF/iptables на ноде, поды не трогаются.
💬 Команды для проверки
Перезапуск или пересоздание?
kubectl get pod <pod> -n <namespace> -o custom-columns="NAME:.metadata.name,UID:.metadata.uid,IP:.status.podIP,RESTARTS:.status.containerStatuses[0].restartCount"
События в поде
kubectl describe pod <pod> -n <namespace> | grep -A 20 "Events:"
Понимание этих сценариев экономит время в инцидентах. Фраза «под перезапустился» слишком общая: сначала смотрим на UID и restart count. Так сразу видно, пересоздался сам pod или перезапустился только контейнер внутри.
С hot-reload сложнее. Он удобен, но не всегда даёт явный сигнал об ошибке: приложение может принять кривой конфиг, а проблема проявится позже и в другом месте. Пересоздание pod дороже, зато честнее: если что-то сломано, это быстрее станет видно по статусам, readiness и rollout.
#заметкиИнженера