Как красиво попросить Kubernetes получить более новый образ?

У меня есть новый образ Docker, и в идеале я хотел бы выполнить плавное обновление до него и либо забыть предыдущую развернутую версию, либо сохранить только предыдущую версию, но не все ранее развернутые версии.

Поды Kubernetes получат после перезапуска последний образ, если он помечен :latest или imagePullPolicy: Always.

Однако, если тег изображения не изменился, выполнение kubectl apply или kubectl replace не приведет к перезапуску модулей и, следовательно, не приведет к извлечению последнего изображения. Пометка означает сложный сценарий, который всегда удаляет старые изображения с тегами (бесполезно, у кого-то есть хитрость).

Выполнение kubectl rolling-update ... --image ... возможно, если на каждый модуль приходится только один контейнер.

Что работает и в конечном итоге становится чистым и всегда получает последнюю версию, так это удаление пространства имен и повторное создание всех pods/rc/services...

Как я могу попросить Kubernetes правильно использовать мои новые образы, даже если в каждом поде более одного контейнера?


kubernetes google-kubernetes-engine google-container-registry
person Wernight    schedule 20.02.2016    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Грязный обходной путь (не проверено): вы можете уменьшить rc до 0, а затем до исходного размера => это будет перезапуск «pod». Или вы можете использовать 2 активных (размер не 0)/пассивный (размер 0) rc, которые будут включены в один и тот же сервис. И вы будете масштабировать их вверх/вниз.

Пометка означает сложный сценарий, который всегда удаляет старые изображения с тегами (бесполезно, у кого-то есть хитрость).

Тегирование — хороший явный процесс. сборка мусора Kubernetes автоматически удалит ваши старые изображения. Надеюсь, вы знаете, что если вы используете только последний тег, то откат может быть невозможен. Рекомендую настроить систему тегов, например :latest_stable, :latest_dev, :2nd_latest_stable, ....

Эти теги будут только «указателями», и ваш CI будет их перемещать. Затем вы можете определить и написать сценарий некоторой интеллектуальной политики удаления тегов реестра, например. все теги старше 2nd_latest stable можно безопасно удалить. Вы знаете свое приложение, поэтому можете настроить политику, которая будет соответствовать вашим потребностям и политике выпуска.

Пример тега — начальная точка сборки 1/2/3 (идентификатор сборки, идентификатор git, время сборки, ...) — сборка 1 — это :production и :canary, все теги проталкиваются:

# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        37 seconds ago      125.1 MB
image                                       2                   7dda7c549d2d        50 seconds ago      125.1 MB
image                                       production          e53856d910b8        58 seconds ago      125.1 MB
image                                       canary              e53856d910b8        58 seconds ago      125.1 MB
image                                       1                   e53856d910b8        58 seconds ago      125.1 MB

Сборка 2 будет :canary:

# docker tag -f image:2 image:canary
# docker push image:canary
# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        6 minutes ago       125.1 MB
image                                       canary              7dda7c549d2d        6 minutes ago       125.1 MB
image                                       2                   7dda7c549d2d        6 minutes ago       125.1 MB
image                                       production          e53856d910b8        7 minutes ago       125.1 MB
image                                       1                   e53856d910b8        7 minutes ago       125.1 MB

Тесты в норме, сборка 2 стабильна - будет :production:

# docker tag -f image:2 image:production
# docker push image:production
# docker images
REPOSITORY                                  TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
image                                       3                   a21348af4283        9 minutes ago       125.1 MB
image                                       2                   7dda7c549d2d        9 minutes ago       125.1 MB
image                                       canary              7dda7c549d2d        9 minutes ago       125.1 MB
image                                       production          7dda7c549d2d        9 minutes ago       125.1 MB
image                                       1                   e53856d910b8        10 minutes ago      125.1 MB

Домашнее задание: на самом деле сборка 2 нестабильна -> установить :production для сборки 1 (откат) и :canary для сборки 3 (тестовое исправление в сборке 3). Если вы используете только :latest, этот откат невозможен

kubectl непрерывное обновление/откат будет использовать явный :id, а ваш сценарий очистки может использовать политику: все теги старше :production могут быть удалены.

К сожалению, у меня нет опыта развертывания Kubernetes.

person Jan Garaj    schedule 20.02.2016
comment
GC может работать для кластера, но Docker Registry не будет автоматически очищаться. Предположим, я использую хэш git commit в качестве тега (самый простой IMO), он также сохранит все предыдущие коммиты. - person Wernight; 21.02.2016
comment
Спасибо за обновление. Не могли бы вы привести более полный пример полного развертывания и изменения тегов? Например, отправить новый :canary, а затем заменить предыдущий :production, включая отправку Docker? Я думаю, что новое экспериментальное развертывание должно разрешать их автоматически, но оно еще не выпущено. - person Wernight; 22.02.2016
comment
Я знаю, как отправить изображение, но, как я вижу, мне нужно иметь несколько kubernetes.yml с разными метками и сначала выполнить скользящее обновление, а затем, я думаю, после повторной пометки применить kubectl или что-то подобное, но это та часть, которую я м не уверен. Кроме того, насколько я знаю, реестр не поддерживает тегирование из существующего тега удаленно, поэтому на каждую сборку потребуется еще 20 секунд и т. д. - person Wernight; 23.02.2016
comment
@jan-garaj В вашем ответе много интересных идей и несколько полезных советов, но было неприятно видеть фрагмент, начинающийся с «Домашнее задание»: ... как это выглядит так, как будто вы учитель и вы даете домашнюю работу своему ученику. Насколько я знаю, это неправильное поведение здесь, на StackOverflow, поскольку это место, где можно давать ответы на вопросы, а не давать уроки и домашние задания. Извините, если я понял это неправильно. И еще одна проблема - это финишная черта, где вы заявляете, что у вас нет опыта развертывания k8s: почему тогда вы даете советы по развертыванию k8s? о_О - person wobmene; 02.05.2021

arrow_upward
0
arrow_downward

Как насчет того, чтобы пометить развертывание меткой, значением которой является отметка времени или хэш фиксации, а затем использовать kubectl apply, как обычно. Изменение меток в шаблоне должно привести к повторному извлечению образа (если установлено imagePullPolicy: Always) и непрерывному обновлению (в зависимости от конфигурации).

person vvucetic    schedule 24.07.2018