Обновление образа развертывания в Kubernetes

Я новичок в Kubernetes и использую k8s v1.4, Minikube v0.15.0 и плагин Spotify maven Docker.
В процессе сборки моего проекта создается образ Docker и помещается его непосредственно в движок Docker Minikube.

Модули создаются с помощью созданного мной развертывания (с использованием набора реплик), и для стратегии задано значение type: RollingUpdate.

Я видел это в документации:

Примечание. Внедрение развертывания запускается тогда и только тогда, когда изменяется шаблон модуля развертывания (т. е. .spec.template).


Я ищу простой способ / обходной путь для автоматизации процесса: запускается сборка> отправляется новый образ Docker (без изменения версии)> Развертывание обновит модуль> служба откроет новый модуль.


kubernetes docker minikube
person yuval simhon    schedule 19.01.2017    source источник
comment
Если вы вообще не меняете образ, то нет никакого способа гарантировать, что вы получите новый образ в каждом модуле, если только вы не установите ImagePullPolicy: Always, не убьете каждый модуль и не создадите его заново при развертывании. Однако, если вы каждый раз создаете новый образ докера, имеет смысл обновить и тег.   -  person Anirudh Ramanathan    schedule 19.01.2017
comment
@AnirudhRamanathan Поскольку я не создаю новый образ каждый раз, просто обновляю его, я выберу первый подход, так что есть способ автоматически убить старые модули?   -  person yuval simhon    schedule 19.01.2017
comment
ImagePullPolicy: Always не работает с локальными образами, поэтому пока я вручную удаляю модули с определенной меткой, затем набор реплик создает их с обновленным изображением. интересно, есть ли способ сделать это автоматически.   -  person yuval simhon    schedule 19.01.2017

Ответы (3)


arrow_upward
26
arrow_downward

если вы не меняете имя или тег изображения контейнера, вы просто масштабируете свое приложение до 0 и обратно до исходного размера с помощью sth, например:

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

Как упоминалось в комментариях, в вашей конфигурации уже требуется ImagePullPolicy: Always.

При изменении изображения я обнаружил, что это самый простой способ обновить

kubectl set image deployment/application app-container=$IMAGE

Если вы не меняете изображение, вам не к чему будет вернуться в случае возникновения проблем. Поэтому я бы не предлагал использовать это вне среды разработки.

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

replica_spec=$(kubectl get deployment/applicatiom -o jsonpath='{.spec.replicas}')
kubectl scale --replicas=0 deployment application
kubectl scale --replicas=$replica_spec deployment application

Ваше здоровье

person pagid    schedule 19.01.2017
comment
есть способ сделать то же самое с Kubernetes API? - person yuval simhon; 22.01.2017
comment
Еще раз здравствуйте - см .: stackoverflow.com/questions/41792851/ - person pagid; 22.01.2017
comment
Не будет ли ваше приложение простоем, если вы уменьшите, а затем увеличите масштаб? Если да, как я могу избежать простоев? - person B. Stucke; 09.09.2020
comment
Да, будет простой - это ответ от 2017 года, есть и другие способы запустить обновление, например. kubectl rollout restart ... - person pagid; 29.09.2020

arrow_upward
6
arrow_downward

Используйте следующие функции, если у вас хотя бы версия 1.15.

kubectl rollout restart deployment/deployment-name

Подробнее об этом читайте здесь перезапуск развертывания kubectl

person Ashfaq    schedule 14.09.2020

arrow_upward
0
arrow_downward

Мне любопытно, почему вы не меняете версию образа (:

Другой вариант (помимо kubectl rollout restart) - использовать патч kubectl:

kubectl patch deployment name -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"version\":\"$BUILD_SHA_OR_DATE\"}}}}}}"

С помощью этой команды у вас есть возможность изменять определенные поля в спецификации развертывания, такие как селектор меток, метка модуля, переменные среды и т. Д.

(*) Другой вариант, который больше подходит для отладки, но о котором стоит упомянуть, - это проверить историю изменений вашего развертывания:

$ kubectl rollout history deployment my-dep
deployment.apps/my-dep
 
REVISION  CHANGE-CAUSE
2         <none>
4         <none>
5         <none>
6         <none>
11        <none>
12        <none>

А затем вернувшись к предыдущей версии, запустив:

 $kubectl rollout undo deployment my-dep --to-revision=11

А потом вернемся к новому.

(**) ПРИЧИНА ИЗМЕНЕНИЯ - <none>, потому что вы должны запускать обновления с флагом --record - как уже упоминалось здесь:

kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record

(***) Существует обсуждение относительно прекращения поддержки этого флага.

person RtmY    schedule 20.10.2020
comment
В моем случае мы не меняем версию образа при развертывании сред разработки / подготовки из той же ветки. Тег / версия - это просто ярлык ветки. Таким образом, мы можем упростить очистку и сэкономить место в реестре. Но я весь в ушах за лучшие подходы :) - person Martin Melka; 05.01.2021
comment
Я рекомендую использовать git commit (или первые 8 цифр, как я) для тегов изображений, таким образом вы можете очень легко найти соответствующую фиксацию и заставить k8s получить правильную версию. ПРИМЕЧАНИЕ: если вы изменяете только src своего приложения в образе, пространство, занятое в реестре, будет только размером src, а не полным размером образа снова. - person santiago arizti; 26.03.2021