# Откат Deployment запустил новый образ: проблема изменяемого тега

Диагностика: Откат Deployment запустил новый образ: проблема изменяемого тега. Признаки, последовательность проверки, рабочий пример и критерии восстановления.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kubernetes-rollback-mutable-image-tag/
Language: ru

Rollout undo возвращает прежний Pod template, но изменяемый tag внутри него может уже указывать на другой образ. Поэтому откат Deployment способен запустить новые байты под старым именем. Проверяйте digest и фактический imageID, а не только revision number.

## Восстановите цепочку ревизий

Сохраните Deployment, старый ReplicaSet и image reference каждой версии. Затем получите imageID реально работающих контейнеров на узлах. Revision фиксирует изменение шаблона, а registry tag — внешнюю ссылку с отдельным lifecycle. Если обе ревизии содержат один mutable tag, их различие может вообще не определять содержимое image. Не удаляйте старые ReplicaSet до расследования: retention истории влияет на доступность стандартного rollback. Сохранённое имя без проверенного digest недостаточно для точного возврата.


[Официальный источник 1](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).

## Учтите imagePullPolicy

Кеш узла и pull policy влияют на получение образа по tag. Поэтому два узла могут запускать разные фактические версии, если процесс публикации изменял tag и политика допускает локальный кеш. Digest задаёт конкретное содержимое, хотя доступность registry и самого объекта остаётся отдельным требованием. Не считайте Always универсальным способом rollback: повторное разрешение изменяемого tag как раз может привести к новому содержимому. Проверяйте фактическую policy, установленную при создании объекта.


[Официальный источник 2](https://kubernetes.io/docs/concepts/containers/images/).

## Разберите повторное использование stable

В учебном release A и release B оба публикуются как worker:stable. После обновления registry tag указывает на B. Rollout undo восстанавливает шаблон, где по-прежнему написано worker:stable. Это не выражает требование запустить A. Корректный артефакт release должен связывать revision с проверенным digest A. Пример объясняет identity, а не предлагает реальный repository или утверждает свойства конкретной image registry, которые не проверялись.

| Уровень | Что фиксируется |
| --- | --- |
| Deployment revision | Содержимое Pod template |
| Image tag | Изменяемая ссылка registry |
| Image digest | Идентичность содержимого |
| Running imageID | Фактически созданный экземпляр |


[Официальный источник 3](https://docs.docker.com/build/building/best-practices/).

## Подготовьте проверяемый rollback

Закрепите проверенный digest в release manifest и сохраните предыдущий manifest целиком. Учтите доступность старого image после registry cleanup. Отдельно фиксируйте конфигурацию и артефакты: возврат контейнера не откатывает автоматически ConfigMap, Secret или внешние данные. Перед rollout проверьте совместимость этих частей. Digest pinning также требует управляемого обновления безопасности: закреплённый образ не получает исправления сам по себе от изменения tag у издателя.

## Проверьте фактический возврат

На стенде выполните обновление и rollback, сравнив imageID, параметры запуска и контрольный результат. Артефакт должен содержать mapping revision → digest и доступный путь загрузки. Если после undo часть Pod осталась на новой версии, исследуйте rollout state и фактические экземпляры отдельно. Успешный ответ команды не доказывает идентичность байтов на всех узлах. Повторяйте эту процедуру после смены registry retention, чтобы архивный manifest не превратился в ссылку на уже недоступный image.

Связанные разборы: [software stack reproducibility](/ru/journal/software-stack-reproducibility/); [model update canary](/ru/journal/model-update-canary/).