Come costringo Kubernetes a ritirare un'immagine?

Ho il seguente controller di replica in Kubernetes su GKE:

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 2
  selector:
    app: myapp
    deployment: initial
  template:
    metadata:
      labels:
        app: myapp
        deployment: initial
    spec:
      containers:
      - name: myapp
        image: myregistry.com/myapp:5c3dda6b
        ports:
        - containerPort: 80
      imagePullPolicy: Always
      imagePullSecrets:
        - name: myregistry.com-registry-key

Ora, se lo dico

kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b

viene eseguito l'aggiornamento progressivo, ma non è necessario ripetere l'operazione. Perché?

Kubernetes tirerà su Creazione pod se uno dei due (vedi documento di aggiornamento delle immagini ):

• Utilizzando le immagini taggate :latest
• imagePullPolicy: Always è specificato

Questo è fantastico se vuoi sempre tirare. Ma cosa succede se si desidera farlo su richiesta : ad esempio, se si desidera utilizzare some-public-image:latestma si desidera estrarre manualmente una versione più recente solo quando viene richiesta. Al momento puoi:

• Set imagePullPolicyper IfNotPresento Nevere pre-pull : le immagini manualmente tirare ogni nodo del cluster in modo che il più recente viene memorizzato nella cache, poi fare una kubectl rolling-updateo simile per riavviare Pods (brutto hack facilmente rotto!)
• Cambia temporaneamenteimagePullPolicy , fai un kubectl apply, riavvia il pod (ad es. kubectl rolling-update), Ripristina imagePullPolicy, ripeti un kubectl apply(brutto!)
• Tirare e spingere some-public-image:latest nel proprio repository privato e fare un kubectl rolling-update(pesante!)

Nessuna buona soluzione per pull on demand. Se ciò cambia, si prega di commentare; Aggiornerò questa risposta.

Uno deve raggruppare imagePullPolicyall'interno dei dati del contenitore anziché all'interno dei dati delle specifiche. Tuttavia, ho presentato un problema a riguardo perché lo trovo strano. Inoltre, non vi è alcun messaggio di errore.

Quindi, questo frammento di specifica funziona:

spec:
  containers:
  - name: myapp
    image: myregistry.com/myapp:5c3dda6b
    ports:
    - containerPort: 80
    imagePullPolicy: Always
  imagePullSecrets:
    - name: myregistry.com-registry-key

Il mio hack durante lo sviluppo è quello di cambiare il mio manifest Deployment per aggiungere l'ultimo tag e tirare sempre così

image: etoews/my-image:latest
imagePullPolicy: Always

Quindi cancello manualmente il pod

kubectl delete pod my-app-3498980157-2zxhd

Poiché è una distribuzione, Kubernetes ricrea automaticamente il pod e estrae l'immagine più recente.

Una soluzione popolare è correggere la distribuzione con un'annotazione fittizia (o etichetta):

kubectl patch deployment <name> -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

Supponendo che la tua distribuzione soddisfi questi requisiti , ciò farà sì che i K8 estraggano qualsiasi nuova immagine e ridistribuiscano.

Ci sarà un nuovo comando per farlo direttamente:

Creare un nuovo kubectl rollout restartcomando che esegue un riavvio a rotazione di una distribuzione.

La richiesta pull è stata unita. Farà parte della versione 1.15( log delle modifiche )

Apparentemente ora quando si esegue un aggiornamento continuo con l' --imageargomento uguale all'immagine contenitore esistente, è necessario specificare anche un --image-pull-policy. Il comando seguente dovrebbe forzare un pull dell'immagine quando è uguale all'immagine del contenitore:

kubectl rolling-update myapp --image=us.gcr.io/project-107012/myapp:5c3dda6b --image-pull-policy Always

# Linux

kubectl patch deployment <name> -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"

# windows

kubectl patch deployment <name> -p (-join("{\""spec\"":{\""template\"":{\""metadata\"":{\""annotations\"":{\""date\"":\""" , $(Get-Date -Format o).replace(':','-').replace('+','_') , "\""}}}}}"))

Ora, il comando kubectl rollout restart deploy YOUR-DEPLOYMENTcombinato con una imagePullPolicy: Alwayspolitica ti permetterà di riavviare tutti i tuoi pod con una versione più recente della tua immagine.

Il comando di aggiornamento progressivo, quando viene fornito un argomento di immagine, presuppone che l'immagine sia diversa da quella attualmente presente nel controller di replica.

È possibile definire imagePullPolicy: Alwaysnel file di distribuzione.

La politica di pull delle immagini aiuterà sempre effettivamente a estrarre l'immagine ogni volta che viene creato un nuovo pod (questo può essere in ogni caso come ridimensionare le repliche o il pod muore e viene creato un nuovo pod)

Ma se desideri aggiornare l'immagine del pod corrente, la distribuzione è il modo migliore. Ti lascia un aggiornamento impeccabile senza alcun problema (principalmente quando hai un volume persistente collegato al pod) :)