Collabora Online uitvoeren op Kubernetes-nodes

Voor een Collabora Online-implementatie met meerdere knooppunten gebruikt u de Kubernetes Helm-grafiek van Collabora achter een ingress- of reverse-proxy die ervoor zorgt dat elk verzoek voor hetzelfde document binnen dezelfde Collabora-pod blijft. Deze sessie-affiniteit is essentieel: gewone round-robin-balancering kan de bewerkings- en klembordverzoeken van een gebruiker naar verschillende pods sturen en de samenwerking bij het bewerken verstoren. Het onderstaande voorbeeld gebruikt drie replica's, NGINX Ingress en een vast aantal replica's; vervang de voorbeeldhostnamen en het TLS-geheim door uw eigen gegevens.

Wat heb je nodig voordat je replica's toevoegt?

Je hebt een werkend Kubernetes-cluster nodig met ten minste twee worker-nodes, Helm, een ingress-controller die de vereiste affiniteitsregel ondersteunt, een DNS-naam zoals office.example.com, en een TLS-certificaat voor die naam. Nextcloud moet bereikbaar zijn voor elke Collabora-pod via de openbare WOPI-origin, bijvoorbeeld https://cloud.example.com. CODE en Nextcloud zijn aparte services; deze handleiding configureert de Collabora-laag en verbindt vervolgens de openbare URL ervan met Nextcloud Office.

Gebruik de gedocumenteerde multi-replica-configuratie van de Collabora-grafiek in plaats van meerdere onafhankelijke Docker-containers achter een generieke load balancer te plaatsen. Een load balancer die elk verzoek verdeelt zonder rekening te houden met de WOPI-bron van het document, kan sessies verbreken. Deze handleiding volgt de officiële instructies voor de Collabora Helm-grafiek die beschikbaar zijn op 10 oktober 2026. Grafiekwaarden kunnen veranderen, dus controleer de waarden voor de exacte grafiekversie die u wilt installeren.

1. Configureer replica's, ingress-affiniteit en de WOPI-host.

Voeg de grafiekrepository toe, werk de index bij en controleer de huidige standaardinstellingen van de grafiek voordat u uw overschrijvingsbestand schrijft:

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

Maak de applicatie aan my_values.yamlmet de onderstaande basisinstellingen. Het voorbeeld maakt gebruik van de NGINX Ingress-annotatie zoals weergegeven in de README van de Collabora-chart. Deze annotatie zorgt ervoor WOPISrcdat verzoeken die aan één document zijn gekoppeld, dezelfde pod bereiken. Ook wordt de openbare TLS-verbinding beëindigd bij de ingress; de getoonde Collabora-serverinstellingen zijn voor dit proxy-terminated TLS-patroon.

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

De aliasgroupsinvoer is de Nextcloud WOPI-host, niet de Collabora-hostnaam. Houd het beperkt en gebruik exact hetzelfde schema, dezelfde hostnaam en poort als Nextcloud. Het ingress TLS-geheim moet bestaan ​​in de ingress-namespace en een geldig certificaat bevatten office.example.com. Als TLS elders eindigt, volg dan het overeenkomende proxypatroon in de chart-documentatie in plaats van de twee extra_paramsvlaggen blindelings te kopiëren.

Er is een versieafhankelijke kanttekening met betrekking tot automatisch schalen: in het voorbeeld in de README van de chart is automatisch schalen uitgeschakeld en wordt gewaarschuwd dat schalen samenwerking bij het bewerken en kopiëren/plakken kan verstoren, terwijl in het momenteel gepubliceerde waardenbestand automatisch schalen standaard is ingeschakeld. Voor een voorspelbaar initieel cluster kunt u het beste automatisch schalen expliciet uitschakelen en een vast aantal replica's kiezen. Overweeg automatisch schalen pas opnieuw nadat u de richtlijnen van de betreffende chart-release hebt geraadpleegd en het opschalen en afschalen hebt getest met echte bewerkingssessies.

2. Installeer de grafiek en controleer de plaatsing van de pods.

Installeer de grafiek in een aparte naamruimte. De officiële grafiekrepository beschrijft dit commandopatroon:

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

Controleer vervolgens of de implementatie het gewenste aantal replica's heeft bereikt en bekijk welke worker-nodes de pods hosten:

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

Controleer of alle drie de pods gereed zijn, of de ingress de verwachte host heeft en of replica's over de worker-nodes zijn verdeeld als redundantie op node-niveau vereist is. Het aantal replica's alleen garandeert niet dat Kubernetes pods op verschillende nodes plaatst. De officiële chart-template toont instellingen voor node-selector, affiniteit en toleratie; configureer geschikte planningsregels voor uw cluster en valideer de gegenereerde chart voordat u erop vertrouwt. Als uw chart-release het benodigde beleid niet biedt, gebruik dan een ondersteunde chart-extensie of een aanpassing van de Kubernetes-implementatie in plaats van ervan uit te gaan dat pods verspreid zijn.

3. Verbind Nextcloud en controleer de documentkoppeling.

Installeer of activeer in Nextcloud de Nextcloud Office- app en open vervolgens de beheerdersinstellingen → Office . Selecteer de externe Collabora-server en voer de server-URL in https://office.example.com. De server-URL is het openbare TLS-eindpunt dat zowel de Nextcloud-server als de browsers van gebruikers kunnen bereiken; voer geen pod-IP-adres of intern serviceadres in.

Open een test-DOCX- of ODT-bestand vanuit Nextcloud. Bewerk het vanuit twee verschillende gebruikerssessies en controleer of beide gebruikers de wijzigingen zien. Controleer ook de ontwikkelaarstools van de browser of de ingress-logboeken op WebSocket-fouten; de Ingress moet de langdurige editorverbinding openhouden. Als de verzoeken voor één bestand over meerdere pods zijn verdeeld, controleer dan of de WOPISrcqueryparameter aanwezig is waar de ingress de hashregel toepast en of de geïnstalleerde ingress-controller de annotatie respecteert.

Wat bewijst een gezonde cluster?

Een succesvolle test bevestigt dat Nextcloud het Collabora-eindpunt kan bereiken en dat een document kan worden bewerkt via de geconfigureerde ingress. Het bewijst echter niet dat elke actieve sessie een pod- of nodefout overleeft. De bewerkingsstatus wordt beheerd door de pod die het document serveert, dus een storing kan vereisen dat gebruikers opnieuw verbinding maken of een bestand heropenen, zelfs als andere replica's beschikbaar blijven. Test onderhouds- en faalscenario's met niet-kritieke documenten en plan upgrades zo dat langlopende WebSocket-sessies weloverwogen worden afgehandeld.

Raadpleeg voor de actuele syntaxis en aandachtspunten de officiële README en waarden van de Kubernetes Helm-grafiek van Collabora , het gepubliceerde waardenbestand van de grafiek en de configuratiehandleiding van Nextcloud Office . Controleer de instellingen aan de hand van de grafiekversie die u installeert, aangezien de voorbeelden en standaardwaarden in de repository mogelijk niet identiek zijn.