Развертывание | Cdc
Войти Регистрация
Download

Версия:

latest
Руководство по установке Развертывание

Развертывание

Tarantool CDC может быть развернут:

  • При помощи инструментов Tarantool ATE. В случае развертывания при помощи инструментов Tarantool ATE необходимо ознакомиться с информацией об Универсальном Обработчике и о том, как его конфигурировать.

  • В кластере Kubernetes при помощи Helm-чарта.

При развертывании Tarantool CDC важно соблюдать требования к окружению.

Порядок работы с Helm-чартом

Helm-чарт – это пакет конфигурации, который позволяет развертывать приложение Tarantool CDC в Kubernetes. Архив с Helm-чартом входит в главный архив пакета поставки и именуется по шаблону cdc-helm-chart-x.x.x.tar.gz.

Этот Helm-чарт обеспечивает согласованную работу приложений, входящих в состав Tarantool CDC, и упрощает процесс управления ими в кластере Kubernetes. Он позволяет:

  • развернуть Tarantool CDC в необходимой конфигурации и обеспечить подключение к внешней БД;

  • удалить Tarantool CDC при необходимости.

В архив Helm-чарта входят различные файлы и папки, среди которых есть 2 файла yaml:

  • Chart.yaml. В этом файле находится описсание Helm-чарта, а так же указаны две версии:

    • version - версия Helm-чарта;

    • appVersion - версия Tarantool CDC.

  • values.yaml. Этот файл является основным местом конфигурирования настроек Helm-чарта.

Версии указаны в формате x.y.z, где x - мажорная (major) версия, y — минорная (minor) версия, а z - версия патча (patch). Версии Helm-чарта и Tarantool CDC могут отличаться по номеру патча. Мажорная и минорная части обеих версий должны совпадать.

Порядок работы с Helm-чартом при развертывании Tarantool CDC следующий:

  1. Распакуйте главный архив и локально сохраните входящий в него архив с Helm-чартом.

  2. Сконфигурируйте Helm-чарт.

  3. Запустите Helm-чарт.

Конфигурация Helm-чарта

Конфигурация Helm-чарта задается с помощью файла values.yml. Этот файл должен содержать конфигурацию всех источников и приемников данных, а так же дополнительные настройки передачи данных между ними.

Файл values.yaml состоит из нескольких разделов:

  • global – содержит глобальные параметры образа: реестр, политика извлечения и секреты;

  • securityContext – позволяет задать дополнительные параметры безопасности, такие как запуск от имени пользователя, не являющегося root, uid пользователя и т.д.;

  • image – содержит параметры, указывающие где и как извлекать образы для развертываний Обработчиков;

  • livenessProbe – описывает параметры проверок жизнеспособности. См. документацию k8s о пробах;

  • startupProbe – описывает параметры проверок запуска (startup probes). См. документацию k8s о пробах;

  • persistence – описывает параметры поддержки постоянного хранения для всех Обработчиках под управлением Helm-чарта;

  • sources – описывает все источники, к которым необходимо подключить коннектор для источника данных. Для каждого источника необходимо указать раздел common. Параметры раздела common соответствуют параметрам раздела sources в файле application.yaml Универсального Обработчика. Раздел configs содержит массив объектов с индивидуальными параметрами, которые дополняют или переопределяют настройки из раздела common. Так, если configs является пустым массивом, то конфигурация из common будет использоваться как единственная конфигурация. В противном случае каждый объект из configs будет объединен с конфигурацией из common и использован как отдельный экземпляр конфигурации источника данных.

  • sinks – описывает все приемники, к которым необходимо подключить коннектор для приемника данных. Для каждого приемника необходимо указать раздел common. Параметры раздела common соответствуют параметрам раздела sink в файле application.yaml Универсального Обработчика. Раздел configs содержит массив объектов с индивидуальными параметрами, которые дополняют или переопределяют настройки из раздела common. Так, если configs является пустым массивом, то конфигурация из common будет использоваться как единственная конфигурация. В противном случае каждый объект из configs будет объединен с конфигурацией из common и использован как отдельный экземпляр конфигурации приемника данных.

  • offset – настройки работы с контрольными точками. Cоответствуют описанию раздела offset в файле application.yaml Универсального Обработчика;

  • flow – список конвейеров от источника данных к приемнику данных. Каждый элемент списка должен соответствовать структуре:

    • source – имя источника данных, указанное в разделе sources;

    • sink – имя приемника данных, указанное в разделе sinks;

    • throttle – настройки для ограничителя трафика. Cоответствуют описанию раздела throttle в файле application.yaml Универсального Обработчика;

    • resources – декларация ресурсов;

    • affinity – декларация правил размещения;

    • nodeSelector – декларация селектора узлов (нод);

    • tolerations – декларация допусков;

    • matchLabels – декларация меток для селектора;

    • templateLabels – декларация меток для шаблона.

Cтруктура файла values.yaml представлена в примере ниже:

global:
  imagePullSecrets:
    - name: argocd-tarantool

securityContext: {}

image:
  repository: registry-gitlab.corp.mail.ru/tarantool/cdc/v9/tarantool-cdc/cdc-worker-all
  tag: 0.10.0
  pullPolicy: IfNotPresent

livenessProbe:
  timeoutSeconds: 15
  failureThreshold: 15
  successThreshold: 1

startupProbe:
  timeoutSeconds: 15
  failureThreshold: 15
  successThreshold: 1

persistence:
  enabled: false
  storageClassName: ""
  storageSize: ""
  mountPath: "/data"

sources:
  source-1:
    common:
      connector:
        class: io.tarantool.connector.MockSourceConnector
        mock.schema.string: |
          [
            {   "weight": 1,
                "name": "User",
                "type": "record",
                "fields": [
                    {
                        "name": "id",
                        "type": {
                            "type": "int",
                            "arg.properties": {
                                "range": {
                                    "min": 0,
                                    "max": 2147483647
                                }
                            }
                        }
                    },
                    {
                        "name": "name",
                        "type": {
                            "type": "string",
                            "arg.properties": {
                                "regex": "[a-zA-Z]{5,255}"
                            }
                        }
                    }
                ]
            }
          ]
    configs:
      - connector:
          task.id: task-1
      - connector:
          task.id: task-2

sinks:
  sink-1:
    common:
      connector:
        class: io.tarantool.connector.MockSinkConnector
        task.id: task-1
        tasks.max: 1
  sink-2:
    common:
      connector:
        class: io.tarantool.connector.MockSinkConnector
        task.id: task-2
        tasks.max: 1

offset:
  storage:
    type: file
    file.name: "/data/offsets.dat"

flow:
  - source: source-1
    sink: sink-1
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 500m
        memory: 1024Mi
    throttle:
      throttler.max.rps: 1000
  - source: source-1
    sink: sink-2
    resources:
      requests:
        cpu: 500m
      limits:
        cpu: 500m
        memory: 1024Mi
    throttle:
      throttler.max.rps: 1000

Примечание

Каждый элемент из списка flow фактически является запросом на создание Универсального Обработчика в кластере Kubernetes. Если один и тот же ресурс (база данных или очередь) используется одновременно как приемник, и как источник данных в рамках одного Helm-чарта, его необходимо указать в обоих разделах конфигурации sink и source. Это означает, что такой ресурс должен фигурировать в двух разных элементах flow: в одном в качестве sink, а в другом — в качестве source.

Запуск Helm-чарта

После того как конфигурация Helm-чарта задана, можно разворачивать Tarantool CDC с помощью утилиты helm:

helm install <release_name> <path_to_chart> --namespace <namespace> --values <path_to_values.yml>

где:

  • <release_name> – название установки, например cdc;

  • <path_to_chart> – путь к локально сохраненному архиву с Helm-чартом;

  • <namespace> – название пространства имен (namespace);

  • <path_to_values.yml> – путь к конфигурации Helm-чарта.

Пример:

helm install cdc ./helm-chart-cdc/ --namespace my-namespace --values my-values.yml

Примечание

Для отладки в данном примере можно использовать следующую команду:

  • helm template cdc ./helm-chart-cdc/ --values my-values.yml.

Мониторинг кластера Tarantool CDC

После развертывания можно отслеживать состояние:

  • Обработчиков Tarantool CDC с помощью панели мониторинга Grafana. Файл конфигурации для Grafana входит в пакет поставки и имеет название вида tarantool-cdc-dashboard_revX.json.

  • Кластера Tarantool TQE на Stateboard в Tarantool Cluster Manager. Для этого нужно:

    1. В Kubernetes настроить форвардинг HTTP-портов, указав номер порта из параметра tqe.tarantool.tcm.parameters.http.port в конфигурации Helm-чарта:

      kubectl port-forward <pod_name> 8081:8081

      Список запущенных подов можно посмотреть командой kubectl get pods. Название нужного пода имеет вид <cdc>-tcm-<code>, где:

      • cdc – название релиза, указанное при запуске команды helm install;

      • code - случайный набор букв, сгенерированный Kubernetes при запуске пода.

      Пример названия пода: cdc-tcm-dblkjdflgskndbglks.

    2. В конфигурации Helm-чарта указать следующие параметры (секция tqe.tarantool):

      • ttConfigEtcdPrefix – префикс для подключения к кластеру ETCD. Рекомендуется задавать то же значение, что и для параметра storage.etcd.prefix в конфигурации ТСМ.

      • ttConfigEtcdHttpRequestTimeout – время ожидания HTTPS-запросов (в сек) от узлов Tarantool к ETCD. Рекомендуется задавать то же значение, что и для параметра storage.etcd.dial-timeout в конфигурации ТСМ.

      Пример:

      tqe:
  tarantool:
    ttConfigEtcdPrefix: "/cdc"
    ttConfigEtcdHttpRequestTimeout: 3

    3. В интерфейсе ТСМ выбрать кластер, название которого задано в параметре tqe.tarantool.tcm.initialSettings.cluster в конфигурации Helm-чарта. См. список Cluster в левом верхнем углу интерфейса.

Решение возможных проблем при развертывании Tarantool CDC

Проблема

Журнал

Решение

Экземпляры router и storage застряли в статусе Pending, gRPC в статусе CrashLoopBackOff

-

Не создались PV и PVC, неверно указан storage class в конфигурации Helm-чарта.

Экземпляры etcd застряли в статусе Pending, экземпляры tarantool в статусе CrashLoopBackOff

-

Не создались PV и PVC. Либо неверно указан storage class, либо не удалились PVC с предыдущего запуска.

Экземпляры router и storage находятся в статусе CrashLoopBackOff

2024-10-03 07:25:34.371 [1] main utils.c:679 E> LuajitError: builtin/config/applier/app.lua:18: module „app.vshard_bootstrapper“ not found:

Вероятно, неверно задана конфигурация tarantool. Некоторые элементы конфигурации tarantool могут добавляться в текущую конфигурацию. Проверьте, нет ли лишних полей в charts/tqe/charts/tarantool/values.yml в блоке config.

Экземпляр cdc source переходит в статус CrashLoopBackOff, потом перезапускается и снова падает

io.grpc.StatusRuntimeException: INTERNAL: RST_STREAM closed stream. HTTP/2 error code: INTERNAL_ERROR

Проверьте состояние кластера. Вероятно, не выполнен vshard bootstrap.
Нашли ответ на свой вопрос?
Обратная связь
Установка
Обновление
Single-page version