Запуск Collabora Online на узлах Kubernetes

Для развертывания Collabora Online на нескольких узлах используйте Helm-диаграмму Kubernetes для Collabora за Ingress или обратным прокси-сервером, который направляет все запросы к одному и тому же документу в один и тот же под Collabora. Такая привязка сессий крайне важна: обычная балансировка нагрузки может отправлять запросы на редактирование и доступ к буферу обмена пользователя в разные поды и нарушать совместное редактирование. В приведенном ниже примере используются три реплики, NGINX Ingress и фиксированное количество реплик; замените приведенные в примере имена хостов и секрет TLS на свои собственные.

Что необходимо сделать перед добавлением реплик?

Для работы вам потребуется запущенный кластер Kubernetes как минимум с двумя рабочими узлами, Helm, контроллер входящего трафика, поддерживающий необходимое правило привязки, DNS-имя, например office.example.com, и TLS-сертификат для этого имени. Nextcloud должен быть доступен для каждого пода Collabora по его публичному WOPI-источнику, например https://cloud.example.com, . CODE и Nextcloud — это отдельные сервисы; в этом руководстве настраивается уровень Collabora, а затем подключается его публичный URL-адрес к Nextcloud Office.

Используйте описанную в диаграмме Collabora конфигурацию с несколькими репликами, а не размещайте несколько независимых контейнеров Docker за универсальным балансировщиком нагрузки. Балансировщик нагрузки, распределяющий каждый запрос без учета источника WOPI документа, может нарушить сессии. Это руководство соответствует официальным инструкциям по настройке Helm-диаграммы Collabora, доступным с 10 октября 2026 года. Значения диаграммы могут измениться, поэтому проверьте значения для конкретной версии диаграммы, которую вы планируете установить.

1. Настройте реплики, привязку входящего трафика и хост WOPI.

Добавьте репозиторий диаграмм, обновите его индекс и проверьте текущие настройки диаграммы по умолчанию, прежде чем писать файл переопределения:

helm repo add collabora https://collaboraonline.github.io/online/
helm repo update
helm show values collabora/collabora-online

Создайте конфигурацию my_values.yamlс указанными ниже основными настройками. В примере используется аннотация NGINX Ingress, показанная в файле README диаграммы Collabora. Она включает хеширование, WOPISrcблагодаря чему запросы, привязанные к одному документу, достигают одного и того же пода. Кроме того, она завершает публичный TLS на входе; указанные настройки сервера Collabora относятся к этому шаблону TLS с завершением через прокси.

replicaCount: 3
autoscaling:
  enabled: false

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/upstream-hash-by: "$arg_WOPISrc"
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
  hosts:
    - host: office.example.com
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls:
    - secretName: office-example-tls
      hosts:
        - office.example.com

collabora:
  aliasgroups:
    - host: "https://cloud.example.com:443"
  extra_params: --o:ssl.enable=false --o:ssl.termination=true

В aliasgroupsзаписи указывается хост Nextcloud WOPI, а не имя хоста Collabora. Старайтесь использовать точную схему, имя хоста и порт, указанные Nextcloud. Секрет TLS для входящего трафика должен существовать в пространстве имен входящего трафика и содержать действительный сертификат office.example.com. Если TLS завершается в другом месте, следуйте шаблону соответствующего прокси, описанному в документации к диаграмме, вместо того, чтобы слепо копировать два extra_paramsфлага.

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

2. Установите диаграмму и проверьте размещение капсулы.

Установите диаграмму в выделенное пространство имен. В официальном репозитории диаграмм описана следующая команда:

helm install --create-namespace \
  --namespace collabora \
  collabora-online collabora/collabora-online \
  -f my_values.yaml

Затем убедитесь, что развертывание достигло желаемого количества реплик, и посмотрите, на каких рабочих узлах размещены поды:

kubectl get pods -n collabora -o wide
kubectl get ingress -n collabora
helm status collabora-online -n collabora

Убедитесь, что все три пода готовы, что ingress имеет ожидаемый хост, и что реплики распределены по рабочим узлам, если требуется отказоустойчивость на уровне узлов. Одного количества реплик недостаточно, чтобы гарантировать размещение подов на отдельных узлах Kubernetes. Официальный шаблон диаграммы предоставляет параметры выбора узлов, привязки и допустимых отклонений; настройте подходящие правила планирования для вашего кластера и проверьте сгенерированную диаграмму, прежде чем полагаться на них. Если в вашей версии диаграммы отсутствует необходимая вам политика, используйте поддерживаемое расширение диаграммы или настройку развертывания Kubernetes, а не предполагайте, что поды распределены.

3. Подключите Nextcloud и проверьте соответствие документов.

В Nextcloud установите или включите приложение Nextcloud Office , затем откройте «Администрирование» → «Office» . Выберите внешний сервер Collabora и введите [ https://office.example.comадрес сервера]. URL-адрес сервера — это общедоступная конечная точка TLS, к которой могут получить доступ как сервер Nextcloud, так и браузеры пользователей; не вводите IP-адрес пода или внутренний адрес службы.

Откройте тестовый файл DOCX или ODT в Nextcloud. Отредактируйте его в двух разных пользовательских сессиях и убедитесь, что оба пользователя видят изменения. Также проверьте инструменты разработчика браузера или журналы Ingress на наличие ошибок WebSocket; Ingress должен поддерживать постоянное соединение с редактором открытым. Если запросы к одному файлу распределены между несколькими подами, убедитесь, что WOPISrcпараметр запроса присутствует там, где Ingress применяет правило хеширования, и что установленный контроллер Ingress учитывает аннотацию.

Что доказывает наличие здорового кластера?

Успешное тестирование подтверждает, что Nextcloud может связаться с конечной точкой Collabora и что документ можно редактировать через настроенный входной канал. Это не доказывает, что каждая активная сессия сохраняется после сбоя пода или узла. Состояние редактирования обрабатывается подом, обслуживающим данный документ, поэтому сбой может потребовать от пользователей переподключения или повторного открытия файла, даже если другие реплики остаются доступными. Протестируйте сценарии обслуживания и сбоев с некритичными документами и спланируйте обновления таким образом, чтобы длительные сессии WebSocket обрабатывались должным образом.

Актуальный синтаксис и особенности см. в официальном файле README и параметрах Helm-диаграммы Kubernetes от Collabora , опубликованном файле значений диаграммы и руководстве по настройке Office от Nextcloud . Проверьте настройки, сравнив их с версией диаграммы, которую вы устанавливаете, поскольку примеры и значения по умолчанию в репозитории могут отличаться.