Da immer mehr Developer mit dem Deployment auf Kubernetes vertraut sind, steigt das Bedürfnis nach einer besseren Isolierung zwischen Tenants. Reicht es aus, einfach nur Zugriff auf einen Namespace in einem Cluster zu haben?
Ich würde sagen, dass es in den meisten Anwendungsfällen für das Deployment von Apps in die Produktionsumgebung genügt. Wenn Sie aber dynamische Test-Umgebungen wollen oder Ihre GitLab Builds auf einem bestimmten Set an Nodes planen, kann es schnell relativ komplex werden, dies sicher auf dem gleichen Cluster wie Ihre Produktions-Apps aufzusetzen. Es ist zwar möglich, einen komplett separaten Cluster dafür zu nutzen, aber das Setup dauert lange und ist bei Nutzung eines komplett gemanagten Clusters üblicherweise recht teuer.
Die Kubernetes Mutli-Tenancy SIG (Special Interest Group) testet seit einiger Zeit Prototypen einer virtuellen Kubernetes Cluster Implementierung. Diese sind allerdings immer experimentell und begrenzt geblieben. Das vcluster Projekt hat zum Ziel, diese Mängel anzusprechen, indem es eine ähnliche Architektur verwendet, aber bereits seit der frühesten Realisierung umfangreiche Features bietet und eine sehr gute Dokumentation hat.
Das Grundkonzept eines vclusters ist, dass er einen kube-apiserver innerhalb eines Pods auf dem Host-Cluster startet. Eine Syncer-Komponente stellt dann sicher, dass bestimmte Ressourcen zwischen dem vcluster und dem Host-Cluster synchronisiert werden, damit die bestehende Infrastruktur und vorhandenen Services auf dem Host-Cluster wiederverwendet werden können. Wenn Sie zum Beispiel ein Speichervolumen (PVC) auf dem vcluster anfragen, wird dieser mit dem Host-Cluster synchronisiert, auf dem die bestehende Speicher-Implementierung die Erstellung des tatsächlichen Volumens übernimmt, ohne dass dafür komplizierte CSI-Treiber auf Ihrem vcluster installiert werden müssen. Sie erhalten die dynamische Volumen-Bereitstellung praktisch „umsonst“. Dies gilt auch für andere Aspekte wie etwa Load Balancers, Ingresses, etc. Ihre auf dem vcluster erstellten Workloads (Pods) können ausserdem die auf dem Host-Cluster bestehenden Nodes nutzen. Es besteht allerdings ebenso die Option, die Workloads noch weiter zu isolieren. Dazu werden alle im vcluster bestehenden Workloads auf dedizierten Nodes des Host-Clusters ausgeführt. Auch bei Nine werden vcluster auf diese Weise aufgesetzt. Sie müssen sich also keine Sorgen machen, dass Sie sich einen Node mit anderen Tenants teilen müssen.
Bildquelle vcluster: vcluster.com
Anwendungsfälle für vcluster
Wie Sie vcluster verwenden, ist natürlich ganz Ihnen überlassen. Hier finden Sie einige Anwendungsfälle, die uns eingefallen sind:
Bei Nine suchen wir kontinuierlich nach neuen Software-Tools, die uns bei der Lösung bestimmter Probleme helfen können. Das bedeutet, dass wir oft etwas auf einen Kubernetes-Cluster deployen müssen und ihn nach dem Testen wieder zerstören müssen. In der Vergangenheit haben wir dazu lokale Cluster wie kind oder Minikube genutzt. Bei einer grossen Menge an Software müssen dazu allerdings Workarounds verwendet werden. So muss man das üblicherweise versteckte Flag „allow insecure TLS“ finden, da es nicht einfach ist, ein vertrauenswürdiges TLS-Zertifikat in den temporären kind-Cluster zu bekommen. Oder man will seinen Prototyp mit anderen Team-Mitgliedern teilen. Dabei wird es recht schwierig, die lokal laufenden Applikationen im Internet sichtbar zu machen. Hier bietet ein vcluster die Vorteile beider Welten, da man innerhalb weniger Sekunden einen (fast) kompletten Cluster erhält.
Ein weiterer Anwendungsfall ist der Betrieb der Staging-Umgebung für unsere API und Controller. Wir machen starken Gebrauch von CRDs, wobei es dadurch schwierig ist, einen mehrfach genutzten Cluster zu verwenden. Da wir aber nur einige Pods für die Controller betreiben, wäre auch ein kompletter Cluster unwirtschaftlich.
Wir sehen vcluster als ergänzendes Tool zu unseren Fully Managed NKE Clustern. Der API Server eines vclusters hat nicht die gleiche Ausfallsicherheit wie ein vollständiger Kubernetes Cluster wie NKE. Ein kurzer Ausfall des API Servers bringt aber in der Regel keinen Ausfall Ihrer Applikation mit sich. Diese Vergleichstabelle sollte Ihnen eine Übersicht über die wesentlichen Unterschiede bieten:
NKE | vcluster | |
---|---|---|
Service Type Load Balancer | ✓ | ✓ |
Persistent Storage (RWO) | ✓ | ✓ |
Ingress | ✓ | ✓ |
Autoscaling | ✓ | ✓ |
Argo CD Integration | ✓ | ✓ |
NKE Maschinentypen | ✓ | ✓ |
Dedizierte Worker Nodes | ✓ | ✓ |
Dedizierte HA Control-Plane Nodes | ✓ | ✗ |
Cluster Add-ons | ✓ | ✗ |
Automatisches Backup | ✓ | ✗ |
Verfügbarkeitsgarantie (SLA) | ✓ | ✗ |
Cluster-Gebühr | ✓ | ✗ |
Schnelle Erstellungszeit (<~2 min) | ✗ | ✓ |
Cluster Admin | ✗ | ✓ |
vcluster können im Cockpit erstellt werden, aber wir haben sie auch zu unserer CLI Utility hinzugefügt, um Ihnen eine ähnliche User-Erfahrung wie bei kind zu bieten und CI/CD-Workflows zu unterstützen. Sie können einen neuen vcluster mit nur einem Befehl erstellen.
$ nctl create vcluster
✓ created vcluster "grown-velocity"
✓ waiting for vcluster to be ready ⏳
✓ vcluster ready 🐧
✓ added grown-velocity/nine to kubeconfig 📋
✓ logged into cluster grown-velocity/nine 🚀
$ nctl get clusters
NAME NAMESPACE PROVIDER NUM_NODES
grown-velocity nine vcluster 1
Standardmässig wird Ihrem vcluster ein zufällig ausgewählter Name verliehen und ein einzelner Node erstellt, der diesem vcluster spezifisch zugeteilt ist. All das kann mithilfe von Flags konfiguriert werden. Nutzen Sie nctl create vcluster -h
, um einen Überblick aller verfügbarer Flags zu erhalten.
Nun können Sie beginnen, Ihren vcluster genauso wie jeden anderen Kubernetes Cluster zu nutzen.
$ kubectl get ns
NAME STATUS AGE
kube-system Active 47s
kube-public Active 47s
kube-node-lease Active 47s
default Active 47s
Wenn Sie fertig sind, ist das Aufräumen ebenso leicht:
$ nctl delete vcluster grown-velocity
do you really want to delete the vcluster "grown-velocity/nine"? [y|n]: y
✓ vcluster deletion started
✓ vcluster deleted 🗑
Haben Sie weitere Fragen?