Обновление образа докера в Google Cloud Platform

Я думал, что понял, как обновлять образ Docker в Google Container Engine, но теперь он просто возвращается к исходной версии образа. Вот что я сделал:

Исходное изображение

docker build -t gcr.io/jupiter-1068/jupiter .
gcloud docker push gcr.io/jupiter-1068/jupiter
kubectl create -f rc.yaml

версия 2

docker build -t gcr.io/jupiter-1068/jupiter:2 .
gcloud docker push gcr.io/jupiter-1068/jupiter:2
kubectl rolling-update staging --image=gcr.io/jupiter-1068/jupiter:2

Это сработало. Но затем я попытался обновиться до версии 3 так же, как и до версии 2, и, похоже, на ней работает исходный код изображения. Что происходит?

Обновить

Повторил попытку с :latest. Выход kubectl describe rc staging:

Name:       staging
Namespace:  default
Image(s):   gcr.io/jupiter-1068/jupiter:latest
Selector:   app=jupiter,deployment=f400f87308696febbe567614f3cc3428,version=1
Labels:     run=staging
Replicas:   1 current / 1 desired
Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed
No events.

Выход kubectl describe pod <podname>:

Name:               staging-b4c7103521d97ef91f482db729da9584-0va8i
Namespace:          default
Image(s):           gcr.io/jupiter-1068/jupiter:latest
Node:               gke-staging-4adcf7c5-node-ygf7/10.240.251.174
Labels:             app=jupiter,deployment=f400f87308696febbe567614f3cc3428,version=1
Status:             Running
Reason:
Message:
IP:             10.8.0.24
Replication Controllers:    staging (1/1 replicas created)
Containers:
  jupiter:
    Image:  gcr.io/jupiter-1068/jupiter:latest
    Limits:
      cpu:      100m
    State:      Running
      Started:      Tue, 15 Sep 2015 21:08:32 -0500
    Ready:      True
    Restart Count:  1
Conditions:
  Type      Status
  Ready     True
Events:
  FirstSeen             LastSeen            Count   From                        SubobjectPath               Reason      Message
  Tue, 15 Sep 2015 21:07:05 -0500   Tue, 15 Sep 2015 21:07:05 -0500 1   {scheduler }                                        scheduled   Successfully assigned staging-b4c7103521d97ef91f482db729da9584-0va8i to gke-staging-4adcf7c5-node-ygf7
  Tue, 15 Sep 2015 21:07:05 -0500   Tue, 15 Sep 2015 21:07:05 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    implicitly required container POD   pulled      Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine
  Tue, 15 Sep 2015 21:07:05 -0500   Tue, 15 Sep 2015 21:07:05 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    implicitly required container POD   created     Created with docker id 13cd80e199a4
  Tue, 15 Sep 2015 21:07:05 -0500   Tue, 15 Sep 2015 21:07:05 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    implicitly required container POD   started     Started with docker id 13cd80e199a4
  Tue, 15 Sep 2015 21:07:05 -0500   Tue, 15 Sep 2015 21:07:05 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    spec.containers{jupiter}        created     Created with docker id 724fdedd11be
  Tue, 15 Sep 2015 21:07:05 -0500   Tue, 15 Sep 2015 21:07:05 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    spec.containers{jupiter}        started     Started with docker id 724fdedd11be
  Tue, 15 Sep 2015 21:08:32 -0500   Tue, 15 Sep 2015 21:08:32 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    spec.containers{jupiter}        created     Created with docker id 2022b9f5f054
  Tue, 15 Sep 2015 21:08:32 -0500   Tue, 15 Sep 2015 21:08:32 -0500 1   {kubelet gke-staging-4adcf7c5-node-ygf7}    spec.containers{jupiter}        started     Started with docker id 2022b9f5f054

kubernetes google-cloud-platform docker google-kubernetes-engine google-container-registry
person tmandry    schedule 16.09.2015    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

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

person Jeffrey van Gogh    schedule 16.09.2015
comment
Полезно знать, спасибо. Но даже после отправки без тега и непрерывного обновления до :latest я получаю более старую версию. То же самое касается выполнения непрерывного обновления без тега. - person tmandry; 16.09.2015

arrow_upward
1
arrow_downward

Чтобы выяснить, что происходит, попробуйте запустить kubectl describe rc staging, который покажет вам подробную информацию о контроллере репликации, в том числе о том, какой образ, по его мнению, он работает, и любые события, относящиеся к нему. Если вывод говорит, что rc запускает новый образ, проверьте модули (используя kubectl describe pods <pod-name>), чтобы увидеть, какой образ они запускают, и есть ли какие-либо события.

Мы надеемся, что эти две команды должны пролить свет на то, что происходит, но если нет, ответьте выводом!

person Alex Robinson    schedule 16.09.2015
comment
Образ, который, по мнению RC, он запускает, содержится в deployment? Потому что я не узнаю ни одной из строк, которые были в этом селекторе. Я также не узнаю ни одной из строк идентификатора докера, которые находятся в модуле, описывающем выходные данные. Другими словами, ни один из идентификаторов, которые я видел в выводе команд describe, не совпадает с идентификаторами, которые я видел в выводе gcloud docker push. - person tmandry; 16.09.2015
comment
Изображение, которое он запускает, находится в поле «Изображение». Хэш изображения не предоставляется через API. - person Alex Robinson; 16.09.2015
comment
Понял, тогда на выходе все выглядит правильно. Я обновил вопрос с этим выводом. Я проверил, что локальный запуск образа дает мне правильную версию кода, так что это тоже не проблема. - person tmandry; 16.09.2015
comment
Вручную удалил и воссоздал rc/pod, и теперь все работает, включая обновления. Не уверен, что изменилось. Если служба поддержки Google сообщит мне что-нибудь интересное, я добавлю это сюда. - person tmandry; 16.09.2015

arrow_upward
0
arrow_downward

Я вручную удалил и заново создал rc/pod, и теперь все работает, включая обновления. От поддержки:

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

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

person tmandry    schedule 16.09.2015