Aggiorna un'image docker nella piattaforma Google Cloud

Pensavo di aver capito come fare gli aggiornamenti di un'image Docker nel motore di Google Container, ma ora ritorna solo alla versione originale dell'image. Ecco cosa ho fatto:

Immagine originale

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

v2

 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 

Questo ha funzionato. Ma poi ho provato ad aggiornare a v3 allo stesso modo di v2 e sembra che sia in esecuzione il codice di image originale. Cosa sta succedendo?

Aggiornare

Provato di nuovo con :latest . L'output di 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. 

L'output di 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 

Per capire cosa sta succedendo, provare a eseguire kubectl describe rc staging , che mostrerà i dettagli del controller di replica, tra cui l'image che pensa che sia in esecuzione e eventuali events pertinenti. Se l'output dice che il rc sta eseguendo la nuova image, quindi controllare i baccelli (usando kubectl describe pods <pod-name> ) per vedere l'image in esecuzione e se ci sono events.

Questi due comandi dovrebbero probabilmente illuminarli su cosa sta succedendo, ma se no, rispondi con l'output!

il tag: ultimamente nel docker è un po 'di confusione. non significa l'upload più recente, è un nome predefinito impostato quando non si specifica un tag.

Nel tuo scenario, i punti più recenti riguardano l'image originale in quanto è l'unico caricamento che non hai specificato un'etichetta.

Ho eliminato manualmente e ricreato il rc / pod e tutto ora funziona, inclusi gli aggiornamenti di rolling. Dal supporto:

Sembra che vi sia stato un problema nel Registro di contenitori che impediva la v2 dell'image da tirare, ma a causa dell'eliminazione dell'image e del pod, non saremo in grado di indagare ulteriormente.

Se si esegue questo problema, considera di contattarli affinché possano esaminare il problema prima di eliminare il pod.