Ein sehr interessanter Anwendungsfall ist in dieser Anleitung zum Deployen eines Monoliten beschrieben. Ich habe angefangen, über einen vcluster operator zum Deployen von Vcluster für die Massen nachzudenken. Tatsächlich ist die Hauptbereitstellungsmethode von vcluster ein Helm Chart (welches grundsätzlich ein Statefulset deployt, in dem K3s läuft), und Crossplane hat einen Helm Provider.
Crossplane ist ein Werkzeug zum Erweitern der Kubernetes API mit eigenen Resourcen, wie kind: vcluster. Diese Resourcen können genauso verwaltet werden wie Kubernetes Resourcen:
$ kubectl get vclusters.caas.telekom.de
NAME SYNCED READY COMPOSITION AGE
kunde2 True True vcluster.caas.telekom.de 52m
kunde1 True True vcluster.caas.telekom.de 24m
Wie erreicht man das?
Mit einer Crossplane Composition beschreiben wir, was passieren soll, wenn eine unserer neuen Resourcen erstellt wird. Es ist der Crossplane Helm provider, so definieren wir zwei Helm Charts und die erforderlichen Werte. Unter Umständen sollten diese Werte in den Resourcen definiert sein. Auf der anderen Seite haben wir einen zentralen Weg um die Chart Version und das Repo zu definieren. Das erste Helm Chart wird den vcluster deployen. Es ist das normale offizielle Chart. Das zweite Chart ist ein einfacher Batch Job zum Importieren des Vcluster in Rancher. Wir brauchen dazu die Rancher URL und den API Admin Token.
Mit einer Crossplane CompositeResourceDefinition erweitern wir die Kubernetes API mit unserem eigenen Zeug. Wir geben dem einen Namen, eine API Version und wir können Specs definieren. Es ist nichts anderes erforderlich. Crossplane wird das alles im Hintergrund erledigen wie CRDs erstellen usw.
Nachzulesen in der Crossplane Dokumentation
Am Ende ist es sehr einfach, einen Vcluster zu deployen
Und wir haben den Vcluster in Rancher:
$ vcluster list
NAME NAMESPACE STATUS CONNECTED CREATED AGE CONTEXT
kunde2-vcluster kunde2 Running 2022-12-14 16:56:33 +0100 CET 1h14m26s local
kunde1-vcluster kunde1 Running 2022-12-14 17:25:07 +0100 CET 45m52s local
Das ist alles. Hier ist das Gist with required resources:
Vom Sicherheitsstandpunkt sind VCluster 1 und Vcluster 2 in zwei Namespaces separiert. Wenn wir wollen,
können wir noch 2 unterschiedliche Rancher Projekte verwenden. In diesen Projekten kkann man Rollen definieren wie
vcluster operator für Leute, die Vcluster betreiben sollen. Als Project Owner sollte das funktionieren.
Für den Kunden des Vcluster 1 kann man seinen Account als Cluster Owner über Rancher hinzufügen, manuell oder automatisiert.
Vielleicht in einem dritten Teil dieser Reihe beschrieben.