Diese Seite erklärt, wie eine vollständige digitale Arbeitsplatz-Suite (openDesk) auf einem einzelnen Server betrieben wird. Kein Cluster aus vielen Maschinen — ein Node trägt alles: Portal, Mail, Dateien, Office, Chat, Video, Projekte und Monitoring.
openDesk bündelt die wichtigsten Arbeitswerkzeuge in einer Suite. Üblicherweise läuft sie auf mehreren Servern. Dieser Aufbau zeigt: Ein einzelner Server kann die Suite vollständig betreiben.
Ein Contabo-VPS mit 12 Cores, 47 GiB RAM und 415 GiB Disk trägt die gesamte Suite. Keine getrennten Maschinen für Datenbank, Storage oder Monitoring — alles läuft auf einem Node.
k0s ist eine schlanke Kubernetes-Distribution. Sie bringt alle Kubernetes-Fähigkeiten auf einen einzigen Server: Deployments, Services, Ingress, TLS und Rolling Updates.
Jede Komponente ist als Helm-Release oder Manifest beschrieben. Der gesamte Aufbau ist dokumentiert und per Skript reproduzierbar — ein Neubau des Systems ist jederzeit möglich.
Kubernetes bringt normalerweise mehrere Maschinen mit. k0s kann auch mit genau einer: Der Server ist gleichzeitig Steuerung (Control-Plane) und Arbeitsrechner (Worker) für alle Dienste.
Der Ingress-Controller (HAProxy) nimmt allen Web-Verkehr entgegen. Er leitet jede Adresse an den richtigen Dienst. Zertifikate stellt Let's Encrypt automatisch aus — HTTPS ist überall Standard.
Alle Dienste laufen als Container (Pods). Die meisten gehören zur openDesk-Suite, der Rest zur Infrastruktur:
openDesk vereint die Arbeitswerkzeuge unter einer gemeinsamen Identität. Ein Login (Keycloak/SSO) gilt für alle Dienste.
| Adresse | Dienst |
|---|---|
| portal.od.ap14.de | Portal (Startseite) |
| webmail.od.ap14.de | Webmail (OX App Suite) |
| files.od.ap14.de | Dateien (Nextcloud) |
| dav.od.ap14.de | WebDAV |
| office.od.ap14.de | Office (Collabora Online) |
| pad.od.ap14.de | Etherpad (Cryptpad) |
| notes.od.ap14.de | Notizen (Impress) |
| chat.od.ap14.de | Chat (Matrix/Synapse) |
| meet.od.ap14.de | Video (Jitsi Meet) |
| wiki.od.ap14.de | Wiki (XWiki) |
| projects.od.ap14.de | Projekte (OpenProject) |
| objectstorage.od.ap14.de | S3-Objektspeicher (SeaweedFS) |
| id.od.ap14.de | Identität (Keycloak/SSO) |
| matrix-federation.od.ap14.de | Matrix-Föderation |
| adminbot.od.ap14.de | Admin-Bot |
| ics.od.ap14.de | Kalender (ICS) |
Entwickelt von ZenDiS. Bündelt Groupware, Dateien, Office, Chat, Video, Projekte, Wiki und Notizen in einer Plattform.
Keycloak stellt die zentrale Anmeldung (SSO). Verzeichnis-Dienste (LDAP/UDM) liefern die Benutzerkonten und Gruppen.
Dateien, Mail und Datenbanken liegen auf der lokalen Disk des Servers. Kein externer Cloud-Anbieter — die Daten bleiben im System.
Der Aufbau ist vollständig als Code dokumentiert. Alle Änderungen landen zuerst im Repo, dann im Cluster. Dieses Kapitel zeigt die drei Ebenen: System-Bootstrap, k0s-Controller-Config und openDesk-Overrides.
Der offizielle Installer lädt k0s auf den Node. Danach installiert k0s install controller --single den Controller als Systemd-Dienst (aktiviert, startet automatisch).
Die Firewall erlaubt nur die nötigen Ports: SSH, HTTP, HTTPS und die Kubernetes-API. Alles andere ist standardmäßig gesperrt.
Das Verzeichnis für lokale Volumes (/var/openebs/localpv) wird angelegt. Ein Tailscale-Exit-Node stellt den Netzzugang für Dienste außerhalb des Clusters bereit.
Die Basis-Dienste kommen per Helm: Ingress-Controller, cert-manager, OpenEBS (Storage) und das Monitoring. Ein idempotentes Skript bringt alle Releases in den dokumentierten Zustand.
Die Live-Config weicht an zwei Stellen vom k0s-Default ab. Beide sind im Repo dokumentiert (opendesk/k0s-controller.yaml).
Der Cluster-State liegt in einer SQLite-Datei (kine) statt in etcd. Das spart Ressourcen auf dem Single-Node. Wichtig: Ein generierter k0s-Default setzt etcd — das würde den State „verlieren". Die Config behält storage: kine.
Der NodePort-Bereich ist auf 25-32767 erweitert. Grund: Postfix soll den Standard-SMTP-Port 25 direkt nutzen können. Der Ingress (80/443) läuft über hostNetwork und ist davon unberührt.
openDesk wird per helmfile deployed. Die Abweichungen vom Standard liegen in opendesk/env/values.yaml.gotmpl (ohne Secrets):
Ein helmfile apply bringt alle ~35 Releases in diesen Zustand. Der Lauf dauert 15–25 Minuten — jeder Release einzeln aktualisiert, Wiederholungen setzen fort.
Ein einzelner Server ist einfach zu betreiben — vorausgesetzt, man sieht, was passiert. Deshalb gehört ein vollständiges Monitoring dazu.
Prometheus sammelt Metriken aller Dienste. Grafana zeigt sie in Dashboards: Auslastung, Fehlerraten, Latenzen.
Alle Dienst-Logs laufen zentral in Loki. Fehler lassen sich über die Zeit verfolgen — auch pro Web-Adresse (Route).
Ein CronJob misst die echte Belegung jedes Volumes. Das Dashboard zeigt den Füllstand in Prozent plus IOPS und Bandbreite der Disk — Engpässe sind früh sichtbar.
Updates laufen über Skripte aus dem Repo. Der Ablauf ist dokumentiert und jederzeit wiederholbar. Bei Last-Problemen gilt: System-Update + Neustart zuerst — meist behebt das die Ursache.
Ein Node ist kein Hochverfügbarkeits-Cluster. Ausfallzeiten bei Wartung sind eingeplant. Volumes lassen sich nicht im laufenden Betrieb vergrößern — die Kapazitätsplanung zählt.