Коротко. Документы в S3, база вне кластера, в кластере только небольшие тома предпросмотра и веб-клиента, для них хватает NFS. Ingress-nginx ставится из Helm-чарта с сохранением адреса клиента, сжатием, увеличенным размером загрузки и таймаутами под долгие соединения. Под etcd быстрые диски, иначе кластер будет замирать.

Directum RX умеет работать в Kubernetes: в поставку входят Helm-чарты для сервисов, конвертации и обновления базы. Сам кластер вендор не поставляет и не настраивает: его надо подготовить. Обычно его собирают по первой попавшейся инструкции, и через месяц выясняется, что тома не переживают перезапуск узла, адреса пользователей в журналах подменены адресом балансировщика, а веб-клиент грузится по несколько секунд. Разбираем минимальный набор, на котором RX живёт спокойно.

Симптом

  • Под сервиса хранилищ после перезапуска узла не стартует: том привязан к узлу, которого нет, или не подключается.
  • В журналах RX и в событиях безопасности вместо адресов пользователей один внутренний адрес.
  • Загрузка веб-клиента заметно медленнее, чем на виртуальных машинах с тем же железом.
  • Загрузка большого файла обрывается с ошибкой 413.
  • Кластер время от времени «замирает»: команды kubectl отвечают по десять секунд, поды перезапускаются без причины.

Почему так

Kubernetes это конструктор. Чарты RX предполагают, что в кластере уже есть три вещи: класс хранилища, контроллер ingress и доступ к базе. Как именно они устроены, решаете вы, и каждый выбор по умолчанию где-то стреляет.

Хранилище

По документации вендора томам требуют три сервиса: сервис хранилищ (если документы хранятся в файловом хранилище), хранилище файлов предпросмотра и веб-клиент (веб-справка и файлы решений). Для них в config.yml задаются размер и класс хранилища. При установке через Directum Launcher в Kubernetes поддерживается только объектное хранилище документов.

Отсюда первое решение: документы держать в объектном хранилище S3, а не на томе в кластере. Тогда в кластере остаются небольшие тома предпросмотра и веб-клиента, а самое ценное лежит в отдельной системе со своим бэкапом и репликацией.

Для оставшихся томов выбирают между двумя подходами.

NFS (провайдер томов поверх NFS-сервера) Longhorn
Как устроено каждый том это папка на внешнем NFS-сервере блочные тома с копиями на дисках узлов кластера
Доступ с нескольких узлов да, из коробки через встроенный NFS, с оговорками
Отказоустойчивость как у NFS-сервера: он одна точка отказа, если не кластерный копии на нескольких узлах
Что нужно на узлах клиент NFS iSCSI, свободные диски, регистрация дисков в Longhorn
Сложность сопровождения низкая заметная: восстановление копий, обновления, нагрузка на сеть и диски

Для RX с документами в S3 обычно хватает NFS: тома небольшие, потеря кэша предпросмотра не страшна, а NFS-сервер у вас, скорее всего, уже есть и бэкапится. Longhorn оправдан, когда внешнего хранилища нет вовсе и команда готова его сопровождать: следить за копиями, дисками и тем, как он ведёт себя при перезапуске узлов.

Ingress

Пользователи попадают в RX через контроллер ingress. Ставить его стоит из официального Helm-чарта ingress-nginx, а не манифестами из чужих инструкций: в манифестах половина настроек зашита как попало, а обновление превращается в ручное сравнение файлов. В чарте всё задаётся значениями и обновляется одной командой.

Что настроить сразу:

  • Адрес клиента. Если перед кластером балансировщик, по умолчанию трафик на узлах проходит через ещё одну трансляцию адресов, и RX видит адрес узла, а не пользователя. У сервиса контроллера ставится externalTrafficPolicy: Local: адрес сохраняется, но балансировщик должен проверять живость узлов, на которых есть под контроллера. Если между пользователем и кластером есть свой прокси, адрес передаётся заголовком, и контроллеру разрешают ему доверять только от этого прокси.
  • Сжатие. Веб-клиент RX это одностраничное приложение с объёмными скриптами. Без сжатия браузер при первом входе качает несколько мегабайт, со сжатием в разы меньше. В ingress-nginx это use-gzip: "true" в настройках контроллера. На одной из наших инсталляций начальная загрузка веб-клиента уменьшилась с 5,75 до 1,52 МБ.
  • Размер загружаемых файлов. По умолчанию ingress-nginx принимает тело запроса до 1 МБ. Документы больше получат ошибку 413. Предел задаётся аннотацией nginx.ingress.kubernetes.io/proxy-body-size или в настройках контроллера. Ошибка разобрана в справочнике.
  • Долгие соединения. Обновления в веб-клиенте приходят через постоянное соединение. Таймауты чтения и отправки у прокси должны быть больше интервала, с которым соединение проверяется.
  • Сертификат. HTTPS настраивается на ingress, вендор прямо указывает это в инструкции. Срок сертификата ставится под наблюдение.

Что оставить снаружи кластера

  • База данных. PostgreSQL для RX надёжнее держать на отдельных серверах: ей нужны предсказуемые диски, своя схема бэкапа и реплика. В кластере она делит ресурсы с остальным и зависит от хранилища кластера.
  • Документы. В S3, как сказано выше.
  • Полнотекстовый поиск и брокер сообщений можно держать и в кластере, но при первой установке проще вне его: меньше движущихся частей. Настройки для них считают калькуляторы Elasticsearch и RabbitMQ.

Сам кластер

  • Ресурсы. Вендор рекомендует выделить пространству имён RX не меньше 30 ГБ памяти и 15 ядер. Версии инструментов на узле администрирования: kubectl от 1.29.1, Helm от 3.13.3.
  • Диски etcd. Хранилище состояния кластера чувствительно к задержкам записи. На медленном или перегруженном диске etcd не успевает, и кластер «замирает»: kubectl отвечает секундами, лидер переизбирается, поды перезапускаются. Под etcd нужны быстрые диски, на которых не работает ничего тяжёлого. Отдельно стоит проверить, что на узлах управления не запускаются тяжёлые фоновые задачи вроде сканирования образов.
  • Наблюдение. Метрики узлов, подов и etcd, плюс сбор журналов RX из подов. Сбор журналов в Kubernetes описан и в справке вендора, а как разбирать журналы RX, рассказано в статье про Vector.

Чего не делать

  • Не держать документы на томе Longhorn без отдельного бэкапа. Копии внутри кластера защищают от потери диска, но не от удаления, сбоя самого Longhorn или ошибки администратора.
  • Не ставить ingress манифестами из чужой статьи. Обновлять их потом некому.
  • Не оставлять размер загрузки по умолчанию. Первый же договор на 5 МБ упрётся в 413.
  • Не размещать etcd на тех же дисках, что и тяжёлую нагрузку.
  • Не переносить в кластер базу данных ради единообразия.