Ejecuta Collabora Online en nodos de Kubernetes.

Para una implementación de Collabora Online con varios nodos, utilice el gráfico Helm de Kubernetes de Collabora detrás de un Ingress o un proxy inverso que mantenga todas las solicitudes del mismo documento en el mismo pod de Collabora. Esta afinidad de sesión es esencial: el balanceo round-robin convencional puede enviar las solicitudes de edición y portapapeles de un usuario a diferentes pods e interrumpir la edición colaborativa. El ejemplo siguiente utiliza tres réplicas, NGINX Ingress y un número fijo de réplicas; reemplace los nombres de host y el secreto TLS del ejemplo con los suyos.

¿Qué necesitas antes de añadir réplicas?

Necesitas un clúster de Kubernetes en funcionamiento con al menos dos nodos de trabajo, Helm, un controlador de entrada que admita la regla de afinidad requerida, un nombre DNS como office.example.comy un certificado TLS para ese nombre. Nextcloud debe ser accesible para cada pod de Collabora en su origen WOPI público, por ejemplo https://cloud.example.com. CODE y Nextcloud son servicios separados; esta guía configura el nivel de Collabora y luego conecta su URL pública a Nextcloud Office.

Utilice la configuración de réplicas múltiples documentada del gráfico de Collabora en lugar de colocar varios contenedores Docker independientes detrás de un balanceador de carga genérico. Un balanceador de carga que distribuye cada solicitud sin tener en cuenta el origen WOPI del documento puede interrumpir las sesiones. Esta guía sigue las instrucciones oficiales del gráfico Helm de Collabora disponibles el 10 de octubre de 2026. Los valores del gráfico pueden cambiar, así que verifique los valores para la versión exacta del gráfico que planea instalar.

1. Configure las réplicas, la afinidad de entrada y el host WOPI.

Agregue el repositorio de gráficos, actualice su índice e inspeccione la configuración predeterminada actual del gráfico antes de escribir su archivo de anulación:

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

Cree la aplicación my_values.yamlcon la configuración básica que se muestra a continuación. El ejemplo utiliza la anotación NGINX Ingress que se muestra en el archivo README del gráfico de Collabora. Utiliza hash para WOPISrcque las solicitudes vinculadas a un documento lleguen al mismo pod. Además, finaliza la conexión TLS pública en el Ingress; la configuración del servidor de Collabora que se muestra corresponde a este patrón de TLS con terminación por proxy.

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

La aliasgroupsentrada corresponde al host WOPI de Nextcloud, no al nombre de host de Collabora. Manténgalo específico y utilice el esquema, el nombre de host y el puerto exactos que proporciona Nextcloud. El secreto TLS de entrada debe existir en el espacio de nombres de entrada y contener un certificado válido office.example.com. Si TLS finaliza en otro lugar, siga el patrón de proxy correspondiente en la documentación del gráfico en lugar de copiar las dos extra_paramsbanderas sin más.

Existe una advertencia sobre el escalado automático que depende de la versión: el ejemplo del archivo README del gráfico desactiva el escalado automático y advierte que este puede interrumpir la edición colaborativa y la función de copiar/pegar, mientras que el archivo de valores publicado actualmente lo tiene habilitado por defecto. Para obtener un clúster inicial predecible, desactívelo explícitamente y elija un número fijo de réplicas. Reconsidere el escalado automático solo después de consultar las instrucciones de la versión exacta del gráfico y probar el escalado ascendente y descendente con sesiones de edición reales.

2. Instale el gráfico y verifique la ubicación de los pods.

Instale el gráfico en un espacio de nombres dedicado. El repositorio oficial de gráficos documenta este patrón de comando:

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

Luego, verifique que el despliegue haya alcanzado el número de réplicas deseado y vea qué nodos de trabajo alojan los pods:

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

Confirme que los tres pods estén listos, que el ingress tenga el host esperado y que las réplicas estén distribuidas entre los nodos de trabajo si se requiere resiliencia a nivel de nodo. El número de réplicas por sí solo no garantiza que Kubernetes coloque los pods en nodos separados. La plantilla oficial del gráfico expone la configuración de selección de nodos, afinidad y tolerancia; configure reglas de programación adecuadas para su clúster y valide el gráfico generado antes de utilizarlas. Si su versión del gráfico no expone la política que necesita, utilice una extensión de gráfico compatible o una personalización de la implementación de Kubernetes en lugar de asumir que los pods están distribuidos.

3. Conecta Nextcloud y verifica la afinidad de los documentos.

En Nextcloud, instale o habilite la aplicación Nextcloud Office y, a continuación, abra la configuración de administración → Office . Seleccione el servidor externo de Collabora e introduzca https://office.example.comla URL del servidor. Esta URL es el punto final TLS público al que pueden acceder tanto el servidor de Nextcloud como los navegadores de los usuarios; no introduzca una dirección IP de pod ni una dirección de servicio interna.

Abra un archivo DOCX u ODT de prueba desde Nextcloud. Edítelo desde dos sesiones de usuario distintas y confirme que ambos usuarios vean los cambios. Compruebe también las herramientas para desarrolladores del navegador o los registros de Ingress en busca de errores de WebSocket; Ingress debe mantener abierta la conexión de edición de larga duración. Si las solicitudes de un archivo se distribuyen entre pods, verifique que el WOPISrcparámetro de consulta esté presente donde Ingress aplica la regla hash y que el controlador de Ingress instalado respete la anotación.

¿Qué demuestra un grupo saludable?

Una prueba exitosa confirma que Nextcloud puede acceder al punto final de Collabora y que se puede editar un documento a través del ingress configurado. Sin embargo, no demuestra que todas las sesiones activas sobrevivan a un fallo de pod o nodo. El estado de edición lo gestiona el pod que sirve ese documento, por lo que un fallo puede requerir que los usuarios se reconecten o vuelvan a abrir un archivo, incluso si otras réplicas siguen disponibles. Pruebe los escenarios de mantenimiento y fallos con documentos no críticos y planifique las actualizaciones de forma que las sesiones WebSocket de larga duración se gestionen de manera específica.

Para conocer la sintaxis actual y las advertencias, consulte el archivo README y los valores oficiales del gráfico Helm de Kubernetes de Collabora , el archivo de valores del gráfico publicado y el manual de configuración de Office de Nextcloud . Verifique la configuración con la versión del gráfico que instale, ya que los ejemplos y valores predeterminados del repositorio pueden no ser idénticos.