Сообщить об ошибкеКороткий ответ
Тег `latest` мутабелен — он может указывать на разные образы в разное время, поэтому невозможно однозначно определить, какая именно версия кода запущена, и трудно гарантированно откатиться; вместо него нужно использовать неизменяемый тег, привязанный к конкретной версии или коммиту, например семантическую версию (`1.5.0`) или хэш коммита (`sha-abc1234`).
Как это работает подробнее
`latest` — это просто ещё один тег, который по соглашению Docker присваивается образу, если тег не указан явно; ничто не мешает каждому новому `docker build`/`push` перезаписывать его на другой образ. Kubernetes при этом может закэшировать старый образ на ноде и не подтянуть новый, если `imagePullPolicy` не настроена явно на `Always`, что приводит к непредсказуемому поведению подов.
Пример кода
example.yaml
# Плохо:
image: myapp:latest
# Хорошо:
image: myapp:1.5.0
# или ещё строже, по digest:
image: myapp@sha256:3f8a1c9e2b7d...Что использовать на практике
- На практике. с конкретным неизменяемым тегом или digest'ом (`image@sha256:...`) можно точно воспроизвести, какой код работал в момент инцидента, откатиться на конкретную прошлую версию и избежать ситуации, когда разные поды одного Deployment внезапно оказываются на разных версиях образа.
- Пример. Ожидаемое поведение: при использовании `myapp:1.5.0` любой инженер или CI-система точно знает, какая версия кода задеплоена, и может воспроизвести тот же образ локально или откатить Deployment на предыдущий известный тег.
Подводные камни
- Частые ошибки. используют `latest` в манифестах production «для простоты», полагаясь на `imagePullPolicy: Always`, что всё равно не решает проблему воспроизводимости и усложняет диагностику инцидентов; путают удобство в локальной разработке (`latest` для быстрого докеr-run) с требованиями к production-деплою.