Aggiornare su Kubernetes

Aggiorna un deployment Kubernetes di Ayakaleaf Pro, con una o più repliche.

Un aggiornamento sostituisce il tag dell’immagine. La nuova versione esegue la migrazione del database al suo avvio, e queste migrazioni devono essere eseguite una sola volta, da un solo pod, mentre nessun pod precedente è in esecuzione. Su Kubernetes questo esclude un semplice rolling update di uno StatefulSet scalato.

Esegui un backup coerente prima di ogni aggiornamento, con Ayakaleaf Pro arrestato. Leggi le note di rilascio per i passaggi specifici della versione a cui stai aggiornando.

Prima di iniziare, su ogni nodo che esegue Ayakaleaf Pro, scarica con sudo docker pull ogni immagine TeX Live elencata dalla nuova versione o dalla tua nuova configurazione.

Una replica

1. Arresta Ayakaleaf Pro

   kubectl -n overleaf scale deployment/overleaf --replicas=0
   kubectl -n overleaf wait --for=delete pod -l app=overleaf --timeout=5m
   
2. Esegui il backup

   MongoDB, da un membro qualsiasi:

   kubectl -n overleaf exec mongo-0 -- mongodump --quiet --archive --gzip \
     --uri 'mongodb://mongo-0.mongo:27017,mongo-1.mongo:27017,mongo-2.mongo:27017/sharelatex?replicaSet=overleaf' \
     > sharelatex-$(date +%F).archive.gz
   

   Il volume dei dati, tramite un pod di breve durata che lo monta (viene pianificato sul nodo del volume):

   kubectl -n overleaf run backup --image=busybox --restart=Never --overrides='
   {"spec":{"containers":[{"name":"backup","image":"busybox","command":["sleep","3600"],
    "volumeMounts":[{"name":"d","mountPath":"/data"}]}],
    "volumes":[{"name":"d","persistentVolumeClaim":{"claimName":"overleaf-data"}}]}}'
   kubectl -n overleaf wait --for=condition=Ready pod/backup
   kubectl -n overleaf exec backup -- tar czf - -C /data . > overleaf-data-$(date +%F).tar.gz
   kubectl -n overleaf delete pod backup
   

   Fai lo stesso per il volume di git-bridge (data-git-bridge-0) e conserva una copia del Secret overleaf-secrets. Se il tuo storage supporta i VolumeSnapshot, uno snapshot dei volumi ottiene lo stesso risultato.

3. Cambia la versione e avvia

   Imposta il nuovo tag in 40-overleaf.yaml (e in 45-git-bridge.yaml, che deve usare lo stesso tag), poi:

   kubectl apply -f 40-overleaf.yaml -f 45-git-bridge.yaml
   kubectl -n overleaf scale deployment/overleaf --replicas=1
   kubectl -n overleaf rollout status deployment/overleaf --timeout=20m
   kubectl -n overleaf logs deployment/overleaf | grep 'Finished migrations'
   

   Il Deployment usa strategy: Recreate, quindi anche con un tag modificato non vengono mai eseguite due versioni contemporaneamente.

Più repliche

Per la configurazione descritta in Scalabilità orizzontale.

1. Arresta tutte le repliche

   kubectl -n overleaf scale statefulset/overleaf --replicas=0
   kubectl -n overleaf wait --for=delete pod -l app=overleaf-ha --timeout=10m
   
2. Esegui il backup

   MongoDB come nella scheda con una replica, i tuoi bucket S3 con gli strumenti del tuo provider, il volume di git-bridge (data-git-bridge-0) e i Secret. La directory /srv/overleaf-ha delle repliche contiene solo l’output delle compilazioni e non richiede backup.

3. Avvia una replica con la nuova versione

   Imposta il nuovo tag in 70-overleaf.yaml e 75-git-bridge.yaml, e replicas: 1:

   kubectl apply -f 70-overleaf.yaml -f 75-git-bridge.yaml
   kubectl -n overleaf rollout status statefulset/overleaf --timeout=20m
   kubectl -n overleaf logs overleaf-0 | grep 'Finished migrations'
   

   Verifica di poter accedere, aprire un progetto e compilare.

4. Avvia le altre repliche

   Reimposta replicas: 3 e applica. OrderedReady le avvia una dopo l’altra.

   kubectl apply -f 70-overleaf.yaml
   kubectl -n overleaf rollout status statefulset/overleaf --timeout=20m
   

Non cambiare l’immagine di uno StatefulSet scalato in esecuzione con kubectl set image o kubectl apply: il rolling update avvierebbe la nuova versione, e le sue migrazioni, mentre le repliche precedenti servono ancora gli utenti. Le modifiche alla configurazione senza una nuova versione vanno bene come rolling restart: kubectl -n overleaf rollout restart statefulset/overleaf.

​

MongoDB e Redis

Aggiornali separatamente da Ayakaleaf Pro. Per MongoDB, segui Aggiornare MongoDB (una versione principale alla volta, featureCompatibilityVersion dopo ogni passaggio); un replica set adotta la nuova immagine un membro alla volta quando cambi l’immagine in 10-mongo.yaml, perché lo StatefulSet sostituisce a turno mongo-2, mongo-1 e mongo-0.

​

Tornare alla versione precedente

Arresta Ayakaleaf Pro come sopra, ripristina MongoDB dall’archivio (mongorestore --drop --archive --gzip) e i volumi o i bucket dal backup, imposta il vecchio tag e riavvia. Altrimenti, le migrazioni della nuova versione non possono essere annullate.

​

Q&A

Una replica resta non pronta e le altre repliche non si avviano mai

Risposta: Con podManagementPolicy: OrderedReady, overleaf-1 si avvia solo quando overleaf-0 è pronto, e un rolling update non sostituisce un pod che non è mai diventato pronto. Dopo aver risolto la causa, ad esempio un’impostazione errata nella ConfigMap, elimina il pod bloccato in modo che lo StatefulSet lo ricrei dal template corrente:

kubectl -n overleaf delete pod overleaf-0
kubectl -n overleaf rollout status statefulset/overleaf --timeout=20m

Ci è capitato sul nostro cluster di test dopo che un’impostazione aveva impedito a overleaf-0 di diventare pronto; eliminare il pod ha permesso a tutte e tre le repliche di avviarsi.