Kubernetes как сделать развертывание для обновления образа

У меня есть развертывание с одним модулем с моим настраиваемым образом докера, например:

containers:
  - name: mycontainer
    image: myimage:latest

Во время разработки я хочу выпустить новую последнюю версию и обновить развертывание. Не могу найти, как это сделать, без явного определения тега / версии и увеличения его для каждой сборки, и выполните

kubectl set image deployment/my-deployment mycontainer=myimage:1.9.1

Вы можете настроить свой модуль с периодом отсрочки (например, 30 секунд или более, в зависимости от времени запуска контейнера и размера образа) и установить "imagePullPolicy: "Always". И пользуйся kubectl delete pod pod_name. Будет создан новый контейнер и автоматически загружен последний образ, после чего старый контейнер будет остановлен.

Пример:

spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: my_container
    image: my_image:latest
    imagePullPolicy: "Always"

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

kubectl --user="kube-user" --server="https://kubemaster.example.com"  --token=$ACCESS_TOKEN set image deployment/my-deployment mycontainer=myimage:"$BUILD_NUMBER-$SHORT_GIT_COMMIT"

Еще один трюк - запустить:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

а потом:

kubectl set image deployment/my-deployment mycontainer=myimage

Фактически это будет запускать скользящее обновление, но убедитесь, что вы также imagePullPolicy: "Always"установили.

Обновить:

Еще один трюк, который я обнаружил, когда вам не нужно изменять имя изображения, - это изменить значение поля, которое будет запускать скользящее обновление, например terminationGracePeriodSeconds. Вы можете сделать это с помощью kubectl edit deployment your_deploymentили kubectl apply -f your_deployment.yamlили используя такой патч:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

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

ОБНОВЛЕНИЕ 2019-06-24

Основываясь на комментарии @Jodiug, если у вас есть 1.15версия, вы можете использовать команду:

kubectl rollout restart deployment/demo

Подробнее по теме:

https://github.com/kubernetes/kubernetes/issues/13488

Что ж, есть интересная дискуссия на эту тему в проекте kubernetes GitHub. См. Проблему: https://github.com/kubernetes/kubernetes/issues/33664

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

Первый

1. подготовить развертывание

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: registry.example.com/apps/demo:master
        imagePullPolicy: Always
        env:
        - name: FOR_GODS_SAKE_PLEASE_REDEPLOY
          value: 'THIS_STRING_IS_REPLACED_DURING_BUILD'

2.Deploy

sed -ie "s/THIS_STRING_IS_REPLACED_DURING_BUILD/$(date)/g" deployment.yml
kubectl apply -f deployment.yml

Второй (один лайнер):

kubectl patch deployment web -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

Конечно, в imagePullPolicy: Alwaysобоих случаях требуется.

kubectl rollout restart deployment myapp

Это текущий способ запустить непрерывное обновление и оставить старые наборы реплик на месте для других операций, обеспечиваемых kubectl rolloutаналогичными откатами.

Я использую Gitlab-CI для создания образа, а затем развертываю его непосредственно в GCK. Если использовать небольшой аккуратный трюк для достижения непрерывного обновления без изменения каких-либо реальных настроек контейнера, который меняет метку на текущий commit-short-sha.

Моя команда выглядит так:

kubectl patch deployment my-deployment -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"build\":\"$CI_COMMIT_SHORT_SHA\"}}}}}}"

Где вы можете использовать любое имя и любое значение для метки, если она меняется с каждой сборкой.

Радоваться, веселиться!

Похоже, что k8s ожидает от нас предоставления разных тегов изображения для каждого развертывания. Моя стратегия по умолчанию - заставить систему CI генерировать и отправлять образы докеров, помечая их номером сборки:xpmatteo/foobar:456 .

Для локальной разработки может быть удобно использовать скрипт или make-файл, например:

# create a unique tag    
VERSION:=$(shell date +%Y%m%d%H%M%S)
TAG=xpmatteo/foobar:$(VERSION)

deploy:
    npm run-script build
    docker build -t $(TAG) . 
    docker push $(TAG)
    sed s%IMAGE_TAG_PLACEHOLDER%$(TAG)% foobar-deployment.yaml | kubectl apply -f - --record

Команда sedзаменяет заполнитель в документе развертывания фактически созданным тегом изображения.

Я использую Azure DevOps для развертывания контейнерных приложений, мне легко удается решить эту проблему с помощью идентификатора сборки.

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

ImageName: buildID

как только ваш образ будет успешно построен (CI), в конвейере компакт-диска в файле развертывания yml я дал имя изображения как

ImageName: окр: buildID

здесь evn: buildid - это переменная azure DevOps, имеющая значение идентификатора сборки.

так что теперь каждый раз у меня есть новые изменения для сборки (CI) и развертывания (CD).

прокомментируйте, если вам нужно определение сборки для CI / CD.