На двух узлах один и тот же тег образа запускает разные версии приложения. Как механизм адресации образов объясняет это расхождение?
Тег образа — это изменяемая ссылка, а не неизменяемая версия. Разные узлы могут использовать разные локально закешированные образы или получить разные манифесты после перемещения тега в реестре. Для воспроизводимого запуска нужно фиксировать образ по его digest, например по SHA-256.
Контейнерные реестры изначально использовали человекочитаемые теги вроде версии, ветки или latest, чтобы разработчикам было удобно публиковать и выбирать образы. Такая модель упрощает доставку обновлений, но отделяет логическое имя образа от конкретного содержимого.
С ростом кластеров появилась потребность гарантировать, что разные экземпляры приложения запускаются из одного и того же набора слоёв. Для этого используются адресация по содержимому и неизменяемые дайджесты.
Тег можно переназначить на новый манифест. Кроме того, узел может не обращаться к реестру из-за политики загрузки и использовать уже имеющийся локальный образ.
Если Deployment продолжает ссылаться на тот же текстовый тег, оркестратор может не считать это изменением шаблона пода и не запустить новый rollout. В результате часть реплик будет работать на старой версии, а часть — на новой, что создаёт трудно воспроизводимые ошибки и осложняет откат.
Тег является изменяемым указателем на манифест образа. Манифест описывает конфигурацию образа и его слои, а конкретный манифест идентифицируется дайджестом — хешем содержимого. Если тег переместили, его разрешение в реестре стало указывать на другой дайджест.
При запуске оркестратор сначала учитывает локальный кэш и заданную политику загрузки. Поэтому настройка постоянной проверки тега через реестр уменьшает вероятность использования устаревшего локального образа, но не делает сам тег неизменяемым и не гарантирует, что все экземпляры получат один результат при изменении тега во время развертывания.
Надёжный подход — публиковать образ под уникальным тегом и дополнительно фиксировать его по digest. Дайджест связывает запуск с конкретным содержимым: если содержимое изменилось, изменится и дайджест. Для обновления нужно явно изменить ссылку в шаблоне пода, после чего оркестратор выполнит контролируемый rollout.
У этого подхода есть компромисс: дайджест хуже читается человеком и требует автоматизации публикации, хранения метаданных о соответствии версии и продвижения артефакта между окружениями. Зато он обеспечивает воспроизводимость, однозначный аудит и безопасный откат.
После выпуска исправления команда повторно присвоила тег stable новому образу. На части узлов остался старый образ, а другие узлы загрузили новый; поскольку строка образа в шаблоне не изменилась, ожидаемого обновления всех реплик не произошло.
Вариант с сохранением изменяемого тега и принудительной загрузкой при каждом запуске устраняет часть проблем с кэшем, но сохраняет риск гонки: разные узлы могут обратиться к реестру до или после переназначения тега. Вариант с ручным удалением кэша ещё менее надёжен и плохо масштабируется.
Команда стала публиковать каждый образ с уникальным тегом сборки и фиксировать в манифесте развёртывания его digest. Это обеспечило одинаковое содержимое на всех узлах, сделало изменение шаблона явным и позволило быстро откатиться к предыдущему дайджесту.
1. Достаточно ли использовать уникальный тег без digest?
Уникальный тег значительно снижает риск коллизии и обычно является практичным минимумом. Однако сам по себе тег остаётся изменяемым: администратор или процесс публикации теоретически может переназначить его. Digest даёт более строгую гарантию неизменности содержимого, поэтому для критичных и воспроизводимых развёртываний предпочтительна фиксация по digest.
2. Исправит ли политика Always проблему разных версий?
Она заставляет узел проверять образ в реестре при запуске контейнера, но не превращает тег в immutable-идентификатор. Если тег был изменён во время rollout, разные экземпляры всё равно могут получить разные манифесты. Кроме того, эта политика увеличивает зависимость запуска от доступности реестра и сетевых задержек.
3. Почему повторная публикация образа под тем же тегом не всегда запускает обновление?
Оркестратор обычно сравнивает шаблон пода, включая текстовую ссылку на образ, а не содержимое, на которое в данный момент указывает тег. Если ссылка не изменилась, новый rollout может не начаться. Явное изменение digest или уникального тега меняет шаблон, делает обновление наблюдаемым для оркестратора и позволяет управлять его результатом.