Оновлення в Kubernetes

Оновіть розгортання Ayakaleaf Pro в Kubernetes з однією чи кількома репліками.

Оновлення замінює тег образу. Нова версія під час запуску виконує міграцію бази даних, і ці міграції мають виконуватися один раз, з одного пода, коли не працює жоден старіший под. У Kubernetes це виключає звичайне поступове оновлення (rolling update) масштабованого StatefulSet.

Перед кожним оновленням створюйте узгоджену резервну копію, зупинивши Ayakaleaf Pro. Ознайомтеся з примітками до випуску щодо кроків для версії, до якої ви оновлюєтеся.

Перш ніж почати, на кожному вузлі, де працює Ayakaleaf Pro, завантажте командою sudo docker pull усі образи TeX Live, перелічені в новій версії або у вашій новій конфігурації.

Одна репліка

1. Зупиніть Ayakaleaf Pro

   kubectl -n overleaf scale deployment/overleaf --replicas=0
   kubectl -n overleaf wait --for=delete pod -l app=overleaf --timeout=5m
   
2. Створіть резервну копію

   MongoDB — з будь-якого учасника:

   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
   

   Том даних — через короткочасний под, який його монтує (він опиняється на вузлі тому):

   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
   

   Зробіть те саме для тому git-bridge (data-git-bridge-0) і збережіть копію Secret overleaf-secrets. Якщо ваше сховище підтримує VolumeSnapshots, знімок томів дасть той самий результат.

3. Змініть версію та запустіть

   Укажіть новий тег у 40-overleaf.yaml (і в 45-git-bridge.yaml, який має використовувати той самий тег), а потім:

   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'
   

   Deployment використовує strategy: Recreate, тож навіть після зміни тегу дві версії ніколи не працюють одночасно.

Кілька реплік

Для конфігурації з розділу Горизонтальне масштабування.

1. Зупиніть усі репліки

   kubectl -n overleaf scale statefulset/overleaf --replicas=0
   kubectl -n overleaf wait --for=delete pod -l app=overleaf-ha --timeout=10m
   
2. Створіть резервну копію

   MongoDB — як на вкладці з однією реплікою, ваші бакети S3 — інструментами вашого постачальника, а також том git-bridge (data-git-bridge-0) і Secret. /srv/overleaf-ha реплік містять лише результати компіляції й не потребують резервного копіювання.

3. Запустіть одну репліку з новою версією

   Укажіть новий тег у 70-overleaf.yaml і 75-git-bridge.yaml, а також 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'
   

   Переконайтеся, що можете ввійти, відкрити проєкт і скомпілювати його.

4. Запустіть інші репліки

   Знову встановіть replicas: 3 і застосуйте. OrderedReady запускає їх одну за одною.

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

Не змінюйте образ запущеного масштабованого StatefulSet через kubectl set image чи kubectl apply: поступове оновлення запустило б нову версію та її міграції, поки старіші репліки ще обслуговують користувачів. Зміни конфігурації без нової версії цілком можна застосовувати поступовим перезапуском: kubectl -n overleaf rollout restart statefulset/overleaf.

​

MongoDB і Redis

Оновлюйте їх окремо від Ayakaleaf Pro. Для MongoDB дотримуйтеся розділу Оновлення MongoDB (по одній мажорній версії за раз, featureCompatibilityVersion після кожного кроку); коли ви змінюєте образ у 10-mongo.yaml, набір реплік отримує новий образ по одному учаснику, бо StatefulSet по черзі замінює mongo-2, mongo-1 і mongo-0.

​

Відкат

Зупиніть Ayakaleaf Pro, як описано вище, відновіть MongoDB з архіву (mongorestore --drop --archive --gzip), а томи чи бакети — з резервної копії, встановіть старий тег і запустіть знову. Інакше міграції нової версії скасувати не можна.

​

Q&A

Репліка залишається неготовою, а інші репліки так і не запускаються

Відповідь: З podManagementPolicy: OrderedReady overleaf-1 запускається лише після того, як overleaf-0 стане готовим, а поступове оновлення не замінює под, який так і не став готовим. Після того як ви усунули причину, наприклад неправильне налаштування в ConfigMap, видаліть завислий под, щоб StatefulSet створив його знову з поточного шаблону:

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

Ми зіткнулися з цим у нашому тестовому кластері, коли налаштування не давало overleaf-0 стати готовим; видалення пода дозволило запуститися всім трьом реплікам.