В этом материале
Rollout undo возвращает прежний Pod template, но изменяемый tag внутри него может уже указывать на другой образ. Поэтому откат Deployment способен запустить новые байты под старым именем. Проверяйте digest и фактический imageID, а не только revision number.
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 недостаточно для точного возврата.
Учтите imagePullPolicy
Кеш узла и pull policy влияют на получение образа по tag. Поэтому два узла могут запускать разные фактические версии, если процесс публикации изменял tag и политика допускает локальный кеш. Digest задаёт конкретное содержимое, хотя доступность registry и самого объекта остаётся отдельным требованием. Не считайте Always универсальным способом rollback: повторное разрешение изменяемого tag как раз может привести к новому содержимому. Проверяйте фактическую policy, установленную при создании объекта.
Разберите повторное использование 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 | Фактически созданный экземпляр |
Подготовьте проверяемый 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; model update canary.