5.1 KiB
| title | date | draft | authors | tags | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Die Zukunft von Matrix | 2024-08-28 | true |
|
|
Zunächst, ich bin eine private Person und stehe nicht in Verbindung zu Element oder der Matrix Foundation. Daher kann ich nicht die Zukunft vorhersagen, sondern lediglich die ganzen Alphas und Betas bewerten und technisch hier einmal zusammensetzen.
Ein weiteres Wort vorweg, Element setzt sehr viel Energie daran, den Grundstock von Element auf eine moderne Technik zu setzen (sogar mit ein kompletten Rewrite der Clients, der gerade Element-X genannt wird). Dieses Vorgehen ist löblich, doch zieht einige Änderungen im Betrieb nach sich und besteht nicht mehr nur aus einem Synapse-Server.
Die folgenden Artikel werden die einzelnen Komponenten und deren technisches Zusammenspiel einzeln erläutern. Diese Artikel plane ich:
- Element-Call der folgende Komponenten beschreibt:
- Element-Web / Element-X
- Element-Call
- Livekit JWT - Service
- Livekit
- Synapse
- Sliding-Sync: neu Client API, die 6000x schneller ist.
- Matrix-Authentification-Server (MAS): neu OIDC-Anbindung
Deployments
Wie ihr bereits sieht, sind es ganz schön viele neue Komponenten, da entsteht schnell die Frage, wie soll man diese alle orchestrieren. Meine berufliche Laufbahn hat mich zu Kubernetes geführt, den Weg der Element auch gerade geht. Doch aus Sicht eines privaten Betreibers bin ich unglücklich von den Ideen:
Zu letzteren möchte ich hier ein paar Worte verlieren.
Für Applikation in ein Kubernetes-Cluster sollten Operatoren vermieden werden.
Hier erst mal eine kurze Begriffserklärung:
- Ein Controller greift auf der Kubernetes-API zu und "kontrolliert" den Workload. Dabei kann er mittels eines ServiceAccounts und eine entsprechende RBAC-Rolle auf notwendig ConfigMap, Secrets und Deployments (usw.) zugreifen (durch die Rolle kann diese wunderbar in Namespaces eingesperrt werden).
- Ein Operator ist ein Controller, dessen Logik auf eigene CustomResourceDefinition (CRDs) basieren. Damit ist es eine Cluster-weite Erweiterung der API.
Warum?
Genau das ist das Problem, in vielen Kontexten möchte man nicht für jede Anwendung (und deren Version) ein ganzen Kubernetes Cluster hinstellen.
Operatoren verursachen folgende Probleme, die aus meiner Sicht beim Betrieb von Anwendungen benötigt werden:
- Staging, auch wenn die CRDs apiVersion vorsieht, ist nur im geringen Maße ein Staging möglich. Der Operator muss alle apiVersion unterstützen und daher den aktuellen Stand entsprechen.
- Separierung ein Operator wird über die CRDs angesprochen, daher muss es für ihn möglich sein, in allen Namespaces Ressourcen verwalten können.
Dieses ist mit Vorsicht zu genießen. Immerhin ist es damit fast der ganze Cluster (wie für ihn unnötige Namespace und Pods und Secrets andere Applikation).
- Shared Hosting ist in Kubernetes generelle möglich, durch die erwähnte Separierung mittels Namespaces und RBAC-Regeln können Benutzer voneinander getrennt (siehe Rancher-Project oder Capsule) werden. Da ein Operator mindestens für die Installation der CRDs clusterweite Rechte benötigt, schließt man einen solchen Kunden aus. PS: Das Teilen eines Clusters könnte nicht nur innerhalb eines Unternehmens (in Abteilungen oder Teams), sondern auch für private Personen, wenn wir an Uberspace denken.
Somit ist ein Operator zwar sinnvoll für die Erweiterung aus Infrastruktur-Sicht (Logging, Monitoring usw.), aber nicht aus Anwendungssicht.
Lösung
Neben den typischen Tools:
- Helm-Chart mit Jobs usw. (Meine sind hier)
- Helmfile für komplexere Orchestrierung
- GitOps Operatoren ala FluxCD oder ArgoCD (gilt ja als Infrastruktur) (Meine sind hier)
Hiermit der Tipp: Schreibt gerne Controller, der mittels Labels ConfigMaps und Secrets sich eure Anwendung konfigurieren lassen. So ist es möglich feingranular, in Namespaces:
- Zu Stagen (mehrere verschiede Versionen des Controllers und der Anwendung)
- Auf Kubernetes-Ebene Berechtigungen mittels RBAC-Rollen innerhalb eines Namespaces zu beschränken.