Обновление базового образа Docker в развертывании Kubenretes

Question

У нас есть базовое изображение с тегом последней. Это базовое изображение используется для множества приложений. Может быть какое-то обновление базового образа, например (обновление ОС, ...). Нужно ли перестраивать и повторно развертывать все приложения при изменении базового образа? Или, поскольку тег является последним и новое базовое изображение также будет с последним тегом, оно будет обновляться на уровне докера и будет позаботиться без перезапуска?

Спасибо

Answer 1

У этого вопроса есть два уровня.

Docker

Если вы используете что-то вроде FROM baseimage:latest, это точное изображение будет сброшено при вашей первой сборке. Docker кэширует слои при последовательных сборках, поэтому он не только будет собирать из одного и того же baseimage:latest, но также будет пропускать выполнение элементов Dockerfile до первого изменения / отсутствия кэширования. Чтобы внести изменения в уведомление о сборке в baseimage, необходимо выполнить docker pull baseimage:latest до сборки, чтобы при следующем запуске использовалось новое содержимое в теге latest.

То же самое касается версионных тегов, когда они агрегируют второстепенные версии / версии исправлений, как при использовании baseimage:v1.2, но программное обеспечение обновляется с baseimage:v1.2.3 до v1.2.4, и по тому же процессу содержимое v1.2.4 публикуется как v1.2. Так что знайте, как обрабатывается версия для определенного изображения.

Kubernetes

Когда вы используете :latest для развертывания в Kubernetes, у вас обычно установлен imagePullPolicy: Always. Что касается сборки Docker выше, означает, что изображение всегда вытягивается перед запуском. Это далеко от идеала и далеко не неизменно. В зависимости от момента перезапуска контейнера вы можете одновременно запустить два модуля: оба одинаковых изображения :latest, но для каждого из них :latest будет означать различное действительное изображение под ним.

Кроме того, вы не можете реально изменить изображение в Deployment с :latest на :latest, потому что это, очевидно, не изменится, означая, что вам не повезло запускать непрерывное обновление, если вы не передадите версию в метке или чем-то еще .

Хорошей практикой является как-то версия ваших образов и загрузка обновлений в кластер с этой версией. Вот как это разработано и предназначено для использования в целом. Вот некоторые схемы управления версиями:

• семантическая (т.е. v1.2.7): хорошо, если ваш инструмент CI / CD хорошо его поддерживает, я использовал его в Concourse CI
• git_sha: работает во многих случаях, но проблематично для пересборок, которые не вызваны изменениями кода
• branch-buildnum или branch-sha-buildnum: мы используем его довольно часто

это не значит, что я не пользуюсь последним. На самом деле большинство моих сборок построено как branch-num, но когда они выпускаются в производство, они также помечаются и помещаются в реестр как branch-latest (т.е. для prod как master-latest), что очень полезно, когда вы хотите развернуть новый кластер с текущими производственными версиями (значения тегов по умолчанию в наших таблицах руля указывают на последние и устанавливаются на определенный тег при выпуске через CI)

Answer 2

Kubernetes имеет настройку imagePullPolicy: для управления этим. По умолчанию узел извлекает изображение только в том случае, если у него его еще нет, за исключением того, что если изображение использует тег :latest, оно всегда вытягивает изображение.

Если у вас есть базовое изображение, а затем какое-то производное изображение FROM my/base:latest, производное изображение будет включать определенную версию базового изображения в качестве его самых нижних слоев. Если вы обновите базовое изображение и не перестроите производные изображения, они все равно будут использовать ту же версию базового изображения. Поэтому, если вы обновляете базовый образ, вам необходимо перестроить все развернутые образы.

Если у вас есть запущенный модуль какой-либо формы, и на нем есть тег :latest и фактическое изображение, на которое указывает тег, изменения, Kubernetes не сможет это заметить, поэтому вам нужно вручную удалить модули, чтобы заставить его воссоздать их. Это плохо. Рекомендуется использовать какой-то явный тег не самой последней версии (отметка даты работает отлично), чтобы вы могли обновить образ в развертывании, и Kubernetes выполнит его повторное развертывание.