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

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 следующий:

Распакуйте главный архив и локально сохраните входящий в него архив с Helm-чартом.
Сконфигурируйте Helm-чарт.
Запустите 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.

Version:

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

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

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

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

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

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