Questa pagina spiega come eseguire aggiornamenti in sequenza per le applicazioni in Google Kubernetes Engine (GKE).
Panoramica
Puoi eseguire un aggiornamento in sequenza per aggiornare immagini, configurazione, etichette, annotazioni e limiti/richieste di risorse dei carichi di lavoro nei cluster. Gli aggiornamenti in sequenza sostituiscono in modo incrementale i pod delle risorse con nuovi, che vengono poi pianificati sui nodi con risorse disponibili. Gli aggiornamenti in sequenza sono progettati per aggiornare i carichi di lavoro senza tempi di inattività.
I seguenti oggetti rappresentano i carichi di lavoro Kubernetes. Puoi attivare un aggiornamento in sequenza su questi carichi di lavoro aggiornando il modello di pod:
- DaemonSets
- Deployment
- StatefulSets
Ciascuno di questi oggetti ha un modello di pod rappresentato dal campo spec: template nel file manifest dell'oggetto. Il campo Modello di pod contiene una specifica per i pod creati dal controller al fine di realizzare lo stato o il comportamento desiderato. Puoi attivare un implementazione di aggiornamento aggiornando il spec: template dell'oggetto.
Il modello di pod include i seguenti campi:
Per saperne di più sul modello di pod, consulta la documentazione di PodTemplateSpec.
La scalabilità di una risorsa o l'aggiornamento dei campi al di fuori del modello di pod non attiva un'implementazione.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update.
Aggiornamento di un'applicazione
La sezione seguente spiega come aggiornare un'applicazione utilizzando la console Google Cloud o kubectl.
kubectl set
Puoi utilizzare kubectl set per apportare modifiche ai campi image, resources (risorsa di calcolo come CPU e memoria) o selector di un oggetto.
Ad esempio, per aggiornare un deployment dalla versione 1.7.9 alla 1.9.1 di nginx, esegui questo comando:
kubectl set image deployment nginx nginx=nginx:1.9.1
Il comando kubectl set image aggiorna l'immagine nginx dei pod del deployment uno alla volta.
Come ulteriore esempio, per impostare le richieste e i limiti di risorse del deployment:
kubectl set resources deployment nginx --limits cpu=200m,memory=512Mi --requests cpu=100m,memory=256Mi
In alternativa, per rimuovere le richieste di risorse del deployment:
kubectl set resources deployment nginx --limits cpu=0,memory=0 --requests cpu=0,memory=0
kubectl apply
Puoi utilizzare kubectl apply per aggiornare una risorsa applicando una configurazione nuova o aggiornata.
Per applicare una configurazione nuova o aggiornata a una risorsa, esegui questo comando:
kubectl apply -f MANIFEST
Sostituisci MANIFEST con il nome del file manifest.
Se il file non esiste, questo comando crea la risorsa e applica la configurazione; in caso contrario, viene applicata la configurazione aggiornata.
Console
Per modificare la configurazione in tempo reale di un'applicazione, segui questi passaggi:
Vai alla pagina Carichi di lavoro nella console Google Cloud.
Seleziona il carico di lavoro che vuoi aggiornare.
Nella pagina Dettagli deployment, fai clic su list Azioni > Aggiornamento in sequenza.
Nella finestra di dialogo Aggiornamento in sequenza, imposta l'immagine del carico di lavoro.
Fai clic su Update (Aggiorna).
Gestire l'implementazione di un aggiornamento
Puoi utilizzare kubectl rollout per esaminare un'implementazione in tempo reale, mettere in pausa e riprendere un'implementazione, eseguire il rollback di un aggiornamento e visualizzare la cronologia dell'implementazione di un oggetto.
Ispezione di un'implementazione con kubectl rollout status
Puoi controllare lo stato di un'implementazione usando il comando kubectl rollout status.
Ad esempio, puoi esaminare l'implementazione del deployment nginx eseguendo questo comando:
kubectl rollout status deployment nginx
L'output è simile al seguente:
Waiting for rollout to finish: 2 out of 3 newreplicas have been updated...
deployment "nginx" successfully rolled out
Una volta completata l'implementazione, esegui kubectl get deployment nginx per verificare che tutti i relativi pod siano in esecuzione. L'output è simile al seguente:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 36s
Mettere in pausa e riprendere un'implementazione
Puoi utilizzare kubectl rollout pause per mettere in pausa un'implementazione.
Ad esempio, per mettere in pausa l'implementazione del deployment nginx, esegui questo comando:
kubectl rollout pause deployment nginx
Per riprendere, esegui questo comando:
kubectl rollout resume deployment nginx
Visualizzazione della cronologia dell'implementazione con kubectl rollout history
Puoi utilizzare kubectl rollout history per visualizzare la cronologia dell'implementazione di un oggetto.
Ad esempio, per visualizzare la cronologia dell'implementazione del deployment nginx, esegui questo comando:
kubectl rollout history deployment nginx
Per visualizzare la cronologia della terza revisione, esegui questo comando:
kubectl rollout history deployment nginx --revision 3
Esegui il rollback di un aggiornamento con kubectl rollout undo
Puoi eseguire il rollback dell'implementazione di un oggetto utilizzando il comando kubectl rollout undo.
Ad esempio, per tornare alla versione precedente del deployment nginx, esegui questo comando:
kubectl rollout undo deployments nginx
Oppure, come ulteriore esempio, per eseguire il rollback alla terza revisione del deployment, esegui questo comando:
kubectl rollout undo deployment nginx --to-revision 3
Considerazioni sugli StatefulSet e DaemonSet
Gli oggetti StatefulSet a partire da Kubernetes 1.7 e DaemonSet a partire da Kubernetes 1.6 utilizzano una strategia di aggiornamento per configurare e disabilitare gli aggiornamenti in sequenza automatizzati per container, etichette, richieste/limiti di risorse e annotazioni per i relativi pod. La strategia di aggiornamento viene configurata utilizzando il campo spec.updateStrategy.
Il campo spec.updateStrategy.type accetta OnDelete o RollingUpdate come valori.
OnDelete è il comportamento predefinito quando non viene specificato spec.updateStrategy.type. OnDelete impedisce al controller di aggiornare automaticamente i propri pod. Devi eliminare manualmente i pod per fare in modo che il controller crei nuovi pod che riflettano le tue modifiche. OnDelete è utile se preferisci aggiornare
manualmente i pod.
RollingUpdate implementa aggiornamenti automatici in sequenza per i pod nello StatefulSet. RollingUpdate fa sì che il controller elimini e ricrea ogni pod e pod, uno alla volta. Attende che un pod aggiornato sia
in esecuzione e pronto prima di aggiornare il modello precedente.
Il controller StatefulSet aggiorna tutti i pod in ordine ordinale inverso, rispettando le garanzie StatefulSet.
Utilizzo della strategia RollingUpdate
Puoi utilizzare la strategia RollingUpdate per aggiornare automaticamente tutti i pod in uno StatefulSet o DaemonSet.
Ad esempio, per applicare la patch allo StatefulSet web e applicare la strategia RollingUpdate, esegui questo comando:
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'
Successivamente, modifica lo StatefulSet spec.template. Ad esempio, puoi utilizzare kubectl set per cambiare l'immagine container. Nell'esempio seguente, lo StatefulSet web è impostato in modo che il container nginx esegua l'immagine nginx-slim:0.7:
kubectl set image statefulset web nginx=nginx-slim:0.7
Per verificare che i pod nello StatefulSet che eseguono il container nginx vengano aggiornati, esegui questo comando:
kubectl get pods -l app=nginx -w
L'output è simile al seguente:
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 7m
web-1 1/1 Running 0 7m
web-2 1/1 Running 0 8m
web-2 1/1 Terminating 0 8m
web-2 1/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Terminating 0 8m
web-2 0/1 Pending 0 0s
web-2 0/1 Pending 0 0s
web-2 0/1 ContainerCreating 0 0s
web-2 1/1 Running 0 19s
web-1 1/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Terminating 0 8m
web-1 0/1 Pending 0 0s
web-1 0/1 Pending 0 0s
web-1 0/1 ContainerCreating 0 0s
web-1 1/1 Running 0 6s
web-0 1/1 Terminating 0 7m
web-0 1/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Terminating 0 7m
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 10s
I pod nello StatefulSet vengono aggiornati in ordine ordinale inverso. Il controller StatefulSet termina ogni pod e attende la transizione a In esecuzione e Pronto prima di aggiornare il pod successivo.
Partizionamento di un RollingUpdate
Puoi specificare un parametro partition per un campo RollingUpdate di uno StatefulSet.
Se specifichi un valore partition, vengono aggiornati tutti i pod con un numero ordinale maggiore o uguale al valore partition. Tutti i pod con un numero ordinale inferiore al valore di partition non vengono aggiornati e, anche se vengono eliminati, vengono ricreati nella versione precedente.
Se un valore partition è maggiore del numero di replicas, gli aggiornamenti non vengono propagati ai relativi pod. Il partizionamento è utile se vuoi posizionare temporaneamente un aggiornamento, implementare una versione canary o eseguire un'implementazione graduale.
Ad esempio, per eseguire la partizione dello StatefulSet web, esegui questo comando:
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
Questo fa sì che i pod con un numero ordinale maggiore o uguale a 3 vengano aggiornati.
Parametro maxUnavailable e maxSurge del DaemonSet
I parametri facoltativi maxUnavailable e maxSurge del DaemonSet sono elementi secondari del campo rollingUpdate del DaemonSet.
maxUnavailable determina il numero massimo di pod DaemonSet che possono essere
non disponibili durante gli aggiornamenti. Il valore predefinito, se omesso, è 1.
maxSurge è il numero massimo di pod di cui è possibile fare lo scale up durante gli aggiornamenti.
Il valore predefinito, se omesso, è 0.
Nessuno dei due valori può essere 0 se l'altro valore è 0. Entrambi i valori possono essere
un numero assoluto o una percentuale.
Per scoprire di più, consulta DaemonSetSpec.
Aggiornamento con la strategia OnDelete
Se preferisci aggiornare manualmente uno StatefulSet o un DaemonSet, puoi omettere il campo spec.updateStrategy, che indica al controller di utilizzare la strategia OnDelete.
Per aggiornare un controller che utilizza la strategia OnDelete, devi eliminare manualmente
i relativi pod dopo aver apportato modifiche al modello di pod.
Ad esempio, puoi impostare lo StatefulSet web in modo che utilizzi l'immagine nginx-slim:0.7:
kubectl set image statefulset web nginx=nginx-slim:0.7
Quindi, per eliminare il primo pod web, esegui questo comando:
kubectl delete pod web-0
Per osservare come il pod viene ricreato dallo StatefulSet e passa a Running and Ready, esegui questo comando:
kubectl get pod web-0 -w
L'output di questo comando è simile al seguente:
NAME READY STATUS RESTARTS AGE
web-0 1/1 Running 0 54s
web-0 1/1 Terminating 0 1m
web-0 0/1 Terminating 0 1m
web-0 0/1 Terminating 0 1m
web-0 0/1 Terminating 0 1m
web-0 0/1 Pending 0 0s
web-0 0/1 Pending 0 0s
web-0 0/1 ContainerCreating 0 0s
web-0 1/1 Running 0 3s
Aggiornamento di un job
Quando aggiorni la configurazione di un job, il nuovo job e i relativi pod vengono eseguiti con la nuova configurazione. Dopo l'aggiornamento di un job, devi eliminare manualmente il vecchio job e i relativi pod, se necessario.
Per eliminare un job e tutti i relativi pod, esegui questo comando:
kubectl delete job my-job
Per eliminare un job ma mantenere i relativi pod in esecuzione, specifica il flag --cascade=false:
kubectl delete job my-job --cascade=false
Puoi anche eseguire kubectl describe deployment nginx, che restituisce ancora più
informazioni sul deployment.