Actualizar en Kubernetes

Actualiza un despliegue de Ayakaleaf Pro en Kubernetes, con una réplica o con varias.

Una actualización sustituye la etiqueta de la imagen. La nueva versión migra la base de datos al arrancar, y estas migraciones deben ejecutarse una sola vez, desde un único pod, mientras no se esté ejecutando ningún pod antiguo. En Kubernetes, esto descarta una simple actualización progresiva (rolling update) de un StatefulSet escalado.

Haz una copia de seguridad coherente antes de cada actualización, con Ayakaleaf Pro detenido. Lee las notas de la versión para conocer los pasos de la versión a la que actualizas.

Antes de empezar, en cada nodo que ejecute Ayakaleaf Pro, descarga con sudo docker pull cualquier imagen de TeX Live que indique la nueva versión o tu nueva configuración.

Una réplica

1. Detener Ayakaleaf Pro

   kubectl -n overleaf scale deployment/overleaf --replicas=0
   kubectl -n overleaf wait --for=delete pod -l app=overleaf --timeout=5m
   
2. Hacer una copia de seguridad

   MongoDB, desde cualquier miembro:

   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
   

   El volumen de datos, mediante un pod de corta duración que lo monta (se ubica en el nodo del volumen):

   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
   

   Haz lo mismo con el volumen de git-bridge (data-git-bridge-0) y guarda una copia del Secret overleaf-secrets. Si tu almacenamiento admite VolumeSnapshots, una instantánea de los volúmenes cumple la misma función.

3. Cambiar la versión e iniciar

   Establece la nueva etiqueta en 40-overleaf.yaml (y en 45-git-bridge.yaml, que debe usar la misma etiqueta) y, después:

   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'
   

   El Deployment usa strategy: Recreate, por lo que incluso con una etiqueta cambiada nunca se ejecutan dos versiones a la vez.

Varias réplicas

Para la configuración de Escalado horizontal.

1. Detener todas las réplicas

   kubectl -n overleaf scale statefulset/overleaf --replicas=0
   kubectl -n overleaf wait --for=delete pod -l app=overleaf-ha --timeout=10m
   
2. Hacer una copia de seguridad

   MongoDB como en la pestaña de una réplica, tus buckets de S3 con las herramientas de tu proveedor, el volumen de git-bridge (data-git-bridge-0) y los Secrets. El /srv/overleaf-ha de las réplicas solo contiene resultados de compilación y no necesita copia de seguridad.

3. Iniciar una réplica con la nueva versión

   Establece la nueva etiqueta en 70-overleaf.yaml y 75-git-bridge.yaml, y 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'
   

   Comprueba que puedes iniciar sesión, abrir un proyecto y compilar.

4. Iniciar las demás réplicas

   Vuelve a establecer replicas: 3 y aplica. OrderedReady las inicia una tras otra.

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

No cambies la imagen de un StatefulSet escalado en ejecución con kubectl set image ni con kubectl apply: la actualización progresiva iniciaría la nueva versión, y sus migraciones, mientras las réplicas antiguas siguen atendiendo a los usuarios. Los cambios de configuración sin una versión nueva pueden aplicarse sin problema con un reinicio progresivo: kubectl -n overleaf rollout restart statefulset/overleaf.

​

MongoDB y Redis

Actualízalos por separado de Ayakaleaf Pro. Para MongoDB, sigue Actualizar MongoDB (una versión principal cada vez, featureCompatibilityVersion después de cada paso); un replica set adopta la nueva imagen de miembro en miembro cuando cambias la imagen en 10-mongo.yaml, porque el StatefulSet reemplaza mongo-2, mongo-1 y mongo-0 sucesivamente.

​

Revertir

Detén Ayakaleaf Pro como se indica arriba, restaura MongoDB desde el archivo (mongorestore --drop --archive --gzip) y los volúmenes o buckets desde la copia de seguridad, establece la etiqueta antigua e inicia de nuevo. Las migraciones de la nueva versión no se pueden deshacer de otro modo.

​

Preguntas y respuestas

Una réplica no llega a estar lista y las demás réplicas nunca se inician

Respuesta: Con podManagementPolicy: OrderedReady, overleaf-1 solo se inicia cuando overleaf-0 está listo, y una actualización progresiva no reemplaza un pod que nunca llegó a estar listo. Después de corregir la causa, por ejemplo un ajuste incorrecto en el ConfigMap, elimina el pod bloqueado para que el StatefulSet lo vuelva a crear a partir de la plantilla actual:

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

Nos ocurrió en nuestro clúster de prueba después de que un ajuste impidiera que overleaf-0 llegara a estar listo; eliminar el pod permitió que se iniciaran las tres réplicas.