Управление миграцией БД в кластере Kubernetes

Question

У меня есть приложение на основе Kubernetes, состоящее из нескольких служб (и модулей), управляемых с помощью рулевой диаграммы.

Postgres используется в качестве базы данных для всех сервисов.

Когда приложение обновляется до более новой версии, я запускаю сценарий переноса БД через initContainers.

Проблема возникает, когда скрипты миграции требуют монопольного доступа к БД (все остальные соединения должны быть разорваны), в противном случае скрипт блокируется.

Идеальным решением было бы остановить все модули, запустить миграцию и воссоздать их. Но я не уверен, как правильно добиться этого с Кубернетом.

Tnx

Answer 1

Идеальным решением было бы остановить все модули, запустить миграцию и воссоздать их. Но я не уверен, как правильно добиться этого с Kubernetes.

Это во многом зависит от вашего подхода, в частности от ваших инструментов CI / CD. Есть несколько стратегий, которые вы можете применить, но, в качестве иллюстрации, если предположить, что у вас есть конвейер Gitlab (Дженкинс может сделать то же самое, терминология отличается и т. Д.), Вот шаги:

• Сделайте следующие шаги в gitlab-ci.yaml:
  • Сборка (где вы создаете все необходимые образы и подготавливаете миграции до того, как что-либо развернуто)
  • Остановить все затронутые активы - развертывание, службы, наборы состояний (это можно сделать как довольно простой kubectl delete -f all_required_assets.yaml, где в одном манифесте вы определили все ресурсы, которые вы хотите полностью остановить. Вы также можно установить льготный период или принудительное завершение, и вам не нужно удалять статические активы - только связанные с остановкой. Обратите внимание, что для остановки модулей вам нужно удалить их ресурс создания верхнего уровня, будь то модуль, развертывание, контроллер репликации или набор состояний чтобы остановить их полностью, а не просто перезапустить)
  • Миграция реализована как Job или как Pod, которая будет обрабатывать миграции с базой данных (скажем, kubectl create -f migrate_job.yaml). Предпочтительное задание для отслеживания ошибок после его завершения.
  • Запустить все активов (тот же файл манифеста с определениями затронутых ресурсов, что и для этапа остановки, скажем, kubectl create -f all_required_assets.yaml, и все ресурсы запуска / остановки обрабатываются через один файл. Если порядок запуска важно по любой причине, тогда требуется отдельный файл, но с осторожностью следует рассмотреть один файл для большинства сценариев)

Этот же принцип может быть реализован и в других инструментах оркестровки / развертывания, и вы даже можете создать простой скрипт для непосредственного запуска этих команд kubectl, если предыдущая была успешной.

Answer 2

Идеальным решением было бы остановить все модули, запустить миграцию и воссоздать их.Но я не уверен, как добиться этого правильно с Kubernetes.

Я вижу из одного из комментариев, что вы используете Helm, поэтому я хотел бы предложить решение, использующее хуки Helm:

Helm предоставляет механизм подключения, позволяющий разработчикам диаграмм вмешиваться в определенные моменты жизненного цикла выпуска.Например, вы можете использовать ловушки для:

• Загрузка ConfigMap или Secret во время установки перед загрузкой любых других диаграмм.

• Выполните задание для резервного копирования базы данных перед установкой новой диаграммы, а затем выполните второе задание после обновления, чтобы восстановить данные.

• Запустите задание перед удалением выпуска, чтобы аккуратно вывести службу из ротации перед ее удалением.

https://github.com/kubernetes/helm/blob/master/docs/charts_hooks.md

Вы можете упаковать свою миграцию как k8s Job и использовать хук pre-install или pre-upgrade для запуска задания,Эти перехваты запускаются после рендеринга шаблонов, но до создания любых новых ресурсов в Kubernetes.Таким образом, ваши миграции будут выполняться до развертывания ваших модулей.

Чтобы удалить развертывания перед запуском миграций, создайте второй хук перед установкой / обновлением с меньшим значением helm.sh/hook-weight, который удаляет целевые развертывания:

apiVersion: batch/v1
kind: Job
metadata:
  name: "pre-upgrade-hook1"
  annotations:
    "helm.sh/hook": pre-upgrade
    "helm.sh/hook-weight": "-1"
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    metadata:
      name: "pre-upgrade-hook1"
    spec:
      restartPolicy: Never
      serviceAccountName: "<an SA with delete RBAC permissions>"
      containers:
      - name: kubectl
        image: "lachlanevenson/k8s-kubectl:latest"
        command: ["delete","deployment","deploy1","deploy2"]

Нижнийвес крюка обеспечит выполнение этой работы до выполнения миграции.Это обеспечит следующую серию событий:

1. Вы запускаете helm upgrade
2. Крюк штурвала с наименьшим весом крюка запускается и удаляет соответствующие развертывания
3. Второй хук запускает и запускает ваши миграции
4. Ваша Диаграмма будет установлена ​​с новыми развертываниями, модулями и т. Д.

Просто убедитесь, что все соответствующие развертывания находятся в одной и той же диаграмме.

Answer 3

С точки зрения автоматизации / оркестровки, я чувствую, что подобные проблемы предназначены для решения с операторами, с использованием недавно выпущенной платформы Operator Framework:

https://github.com/operator-framework

Идея заключается в том, что существует оператор миграции Postgres, который, насколько мне известно, еще не существует, который будет бездействовать в ожидании пользовательского определения ресурса, описывающего миграцию, которая будет опубликована в кластере / пространстве имен.

Оператор проснется, поймет, что входит в предполагаемую миграцию, выполнит некоторый анализ кластера, чтобы построить план миграции, а затем выполнит шаги, которые вы описали-

• переводит приложение в какой-то видимый пользователю режим обслуживания
• снять существующие капсулы
• запустить миграцию
• проверить
• воссоздать модули приложения
• тест
• вывести приложение из режима обслуживания

Это вам сейчас не поможет.