vCluster: Wie es verwendet wird und ein Vergleich mit NKE

Was ist vCluster?

Ein virtueller Cluster ist ein vollumfänglicher Kubernetes-Cluster, der auf einem anderen Kubernetes-Cluster läuft. Der Fokus liegt dabei einzig auf Kernkomponenten. Dazu gehören der API-Server und Controller Manager sowie ein flexibles Speicher-Backend. Standardmässig verwendet vCluster zum Speichern Embedded SQLite, was sowohl Sicherheit als auch Effizienz garantiert. Abhängig von individuellen Bedürfnissen können sich Nutzer jedoch auch für Alternativen wie etwa PostgreSQL, MySQL, MariaDB oder etcd entscheiden. Ausserdem bietet vCluster die Flexibilität eines integrierten Schedulers.

Während vCluster standardmässig k3s als virtuellen Kubernetes-Cluster verwendet, ist das Tool nicht von einer bestimmten Distribution abhängig. Dadurch ist vCluster mit anderen zertifizierten Kubernetes-«Flavors» wie etwa Vanilla k8s oder k0s kompatibel. Diese Flexibilität ermöglicht es Nutzern, genau die Distribution auszuwählen, die ihre Bedürfnisse am besten erfüllt, ohne dabei Abstriche machen zu müssen, was die Simplizität und Effizienz betrifft, die von der minimalistischen Architektur des vClusters geboten wird.

vClusters laufen als eigene Pods mit zwei notwendigen Containern: Control Plane und Syncer. Mit der Control Plane werden die Kubernetes-Hauptkomponenten orchestriert. Der Syncer synchronisiert Daten zwischen dem virtuellen Cluster und dem Host-Cluster. Da vCluster auf einem anderen Kubernetes-Cluster – dem sogenannten Host-Cluster – läuft, nutzt der virtuelle Cluster dessen Infrastruktur, bietet aber gleichzeitig eine eigene, isolierte Umgebung für kontainerisierte Workloads. Er wird einfach als reguläres StatefulSet in einem ihm zugeordneten Namespace des Host-Clusters deployed. Beachtenswert ist dabei, dass alles, was im vCluster erstellt wird, entweder dort oder im Namespace des Host-Clusters liegt, was eine klare Abgrenzung ermöglicht.

Minimalistische Architektur

Synchronisierte Ressourcen

Wenn Pods im virtuellen Cluster initiiert werden, findet zunächst eine Umwandlung statt, bevor sie im Namespace landen, der dem virtuellen Cluster im Host-Cluster zugeordnet ist. Bei diesem Prozess werden die Pod-Spezifikationen angepasst, um mit den Namespace-Konventionen des Host-Clusters übereinzustimmen. Der Name des Pods wird dadurch länger. Beispielsweise wird der Pod nginx-76d6c9b8c-57xk5, der im Namespace nginx im vCluster my-vcluster erstellt wurde, im Host-Cluster zu nginx-76d6c9b8c-57xk5-x-nginx-x-my-vcluster. Ähnlich werden auch Services und Endpoints des virtuellen Clusters angepasst und im entsprechenden Namespace des Host-Clusters deployed.

Bei der Koordination zwischen virtuellen und Host-Clustern werden auch Service-Cluster-IPs geteilt. Diese gemeinsame Infrastruktur vereinfacht die Netzwerkkonfiguration und verbessert das Zusammenspiel.

Da der Syncer des virtuellen Clusters alle Pods mit dem Host-Cluster synchronisiert, können Nutzer problemlos die Speicherklassen des Host-Clusters nutzen, um PVCs zu erstellen und PersistentVolumes hinzuzufügen. Standardmässig ermöglicht vCluster Zugriff auf die Speicherklassen des Hosts, ohne dass diese in der vCluster-Umgebung dupliziert werden müssen, was das Speichermanagement verbessert und die Flexibilität erhöht.

Bestimmte Ressourcen werden synchronisiert, während andere auf den virtuellen Cluster beschränkt werden. ConfigMaps und Secrets gehen etwa nahtlos auf den Host-Cluster über, insofern sie zu Pods hinzugefügt werden. Alle anderen ConfigMaps oder Secrets verbleiben jedoch allein im virtuellen Cluster, um sicherzustellen, dass sie isoliert und eingekapselt sind. Beachtenswert ist, dass Deployments, StatefulSets, Custom Resource Definitions (CRDs), ServiceAccounts und ähnliche Ressourcen nicht synchronisiert werden und eigenständig bleiben. Diese selektive Synchronisationsstrategie ermöglicht eine effiziente Ressourcennutzung und hält die Abgrenzung zwischen virtuellem und Host-Cluster aufrecht. Eine vollständige Liste aller Ressourcen, die von vCluster (aktuell) synchronisiert oder widergespiegelt werden können, findet sich in der Dokumentation.

Designprinzipien von vCluster

Der Architektur von vClusters liegen ausgeklügelte Designprinzipien zugrunde, die jeweils darauf abzielen, eine effiziente Kubernetes-Erfahrung zu bieten. Ein Hauptargument für vCluster ist, dass es so leichtgewichtig wie möglich ist. Um dies zu erreichen, ist der gesamte vCluster in einem einzigen Pod enthalten, während k3s als Control Plane genutzt wird. Dieser minimalistische Ansatz stellt sicher, dass die Verwendung eines virtuellen Clusters die zugrundeliegende Infrastruktur kaum belastet und gleichzeitig eine maximale Ressourcennutzung ermöglicht.

Egal, ob Workloads in einem vCluster oder in verschachtelten vClusters laufen, sie benötigen immer die gleiche Rechenleistung und ermöglichen den gleichen Zugang zu Persistent Storage und Netzwerkleistung wie Workloads, die direkt auf dem Host-Cluster laufen.

Ausserdem reduziert vCluster die Belastung des Kubernetes API Servers des Host-Clusters, da High-Level-Ressourcen im vCluster verbleiben. Es wird ein separater API-Server und Datenspeicher einzig für den vCluster verwendet, während nur wichtige Low-Level-Ressourcen mit dem darunter liegenden Cluster synchronisiert werden. Dadurch reduziert vCluster API-Server-Requests auf ein Minimum und optimiert Leistung und Skalierbarkeit.

Zu guter Letzt priorisiert vCluster flexible Bereitstellungs- und Cleanup-Prozesse und bietet damit eine ganze Reihe an Deployment-Optionen wie etwa vCluster CLI, Helm oder kubectl (mehr Informationen dazu im Artikel Deploy vCluster). Mithilfe eines simplen StatefulSet + Service Deployment-Modells kann vCluster nahtlos in bestehende Kubernetes-Tools integriert werden und in verschiedenen Umgebungen sämtliche Prozesse für Nutzer vereinfachen.

Interesssante Fakten

vCluster bietet einige interessante Eigenschaften, mit denen sich das Tool von klassischen Cluster-Management-Lösungen abhebt. Ein beachtenswertes Feature ist die Möglichkeit, einen vCluster innerhalb eines weiteren vClusters zu betreiben. Diese Verschachtelung nennt sich vCluster Nesting. Sie ermöglicht die Erstellung hierarchischer Kubernetes-Umgebungen und bietet somit mehr Flexibilität und Skalierbarkeit denn je zuvor. Mit vCluster Nesting können Nutzer mehrere Ebenen von Kubernetes-Clustern in einer einzigen Infrastruktur deployen und verwalten. Dies erleichtert komplexe Deployments und ermöglicht innovative Anwendungsmöglichkeiten. Bei Interesse an diesem Thema empfehle ich, mit diesem Artikel zu beginnen: Running Nested clusters in Kubernetes using vCluster.

Interessant ist auch, wie vCluster Ressourcen auflistet: Dies geschieht aktuell nach Alter. Warum? k3s verwendet Kine (etcdshim übersetzt dabei etcd API in z. B. SQLite). Kine sortiert die Keys dabei nicht auf die gleiche Weise wie etcd, aber ich glaube nicht, dass das irgendwo garantiert wird (siehe GitHub Thread Results of kubectl commands not sorted). So ist zumindest der aktuelle Stand. Allerdings wird im Moment an der Umsetzung des Implicit Kubernetes-ETCD Contract gearbeitet (weitere Infos: On the Hunt for Etcd Data Inconsistencies – Marek Siarkowicz, Google). Vielleicht erwarten uns daher in Zukunft coole Updates in diesem Bereich. Aktuell ist der Vorschlag für die Anzeige von Ressourcen jedoch folgender: Objekte, die als Antwort aufgelistet werden, müssen lexikalisch nach ihrem Namen geordnet werden. Meiner Meinung nach sollte diese Regel ab sofort befolgt werden. 😉

Tipps

Mit einigen Tipps kann die Leistungsfähigkeit bei Verwendung einer vCluster-Umgebung optimiert werden. Zunächst besteht die Möglichkeit, einen separaten vCluster Scheduler zu nutzen. Dieses Feature ist zwar verfügbar, es sollte aber deaktiviert werden – besonders wenn Autoscaling genutzt wird. Die Deaktivierung hat zwar auch Nachteile, aber der Erhalt der Autoscaling-Funktion ist in den meisten Fällen wichtiger als die Vorteile eines separaten Schedulers. Weitere Einblicke in dieses Thema finden sich in der Dokumentation zu Virtual Schedulers.

Ausserdem können einige vCluster Ressourcen mit Ihrer «normalen» Infrastruktur geteilt werden, sodass strenge Kontrollen und Sicherheitsmassnahmen nötig werden. Dabei ist es von wesentlicher Bedeutung, dass sensible Daten oder Ressourcen nicht aus der vCluster Umgebung eingesehen werden können, um dem möglichen Risiko eines unbefugten Zugriffs oder einer Datensicherheitsverletzung entgegenzuwirken.

Vorteile

vCluster bietet Nutzern volle Admin-Zugriffsrechte, sodass sie etwa Custom Resource Definitions (CRDs) deployen oder Namespaces erstellen können. Dieses starke Mass an Kontrolle erleichtert eigene Konfigurationen und Tunings und unterstützt so eine Reihe an Deployment-Szenarien.

Durch die Leichtgewichtigkeit der virtuellen Cluster, die ihre Ressourcen mit dem zugrundeliegenden Host-Cluster teilen, können mit vCluster ausserdem erhebliche Kosteneinsparungen realisiert werden.

Im Vergleich zu Alternativen wie etwa KinD, K3d und Minikube zeigt sich die Überlegenheit von vCluster in den Punkten Schnelligkeit und Effizienz – besonders in lokalen Entwicklungsumgebungen. Dieses Thema wird im Artikel How Virtual Kubernetes Clusters Can Speed Up Your Local Development näher behandelt und das Potenzial von vCluster hervorgehoben, Entwicklungszyklen zu beschleunigen und Kubernetes–Workflows zu vereinfachen. Insgesamt bietet vCluster damit eine vollumfängliche Lösung für die Kubernetes-Orchestrierung, indem es eine starke Leistung, Effizienz und Sicherheit vereint, um auf die unterschiedlichen Bedürfnisse moderner Deployment-Umgebungen einzugehen.

Use Cases

vCluster ist eine vielseitige Lösung und eignet sich für eine ganze Reihe an Use Cases.

Ein häufiger Use Case ist dabei der Einsatz in Entwicklungsumgebungen – sowohl für lokale als auch für Remote-Anwendungsfälle. Durch die leichtgewichtigen und isolierten Cluster ermöglicht vCluster ein schnelles Iterieren und Experimentieren, sodass Entwickler-Applikationen leicht erstellen und testen können.

Ausserdem eigner sich vCluster hervorragend für End-to-End-Tests (E2E) und bietet damit eine gute Umgebung für die Überprüfung des Applikationsverhaltens und der Funktionalität bei verschiedenen Deployment-Konfigurationen.

Daneben hat sich vCluster beim Testen verschiedener Kubernetes-Versionen als wertvoll erwiesen. Denn Nutzer können damit die Kompatibilität und Leistung unterschiedlicher Releases bestimmen. Diese Vielseitigkeit ermöglicht es Unternehmen, ihre Applikationen und ihre Infrastruktur zukunftssicher zu machen, indem sie sicherstellen, dass diese mit zukünftigen Kubernetes-Updates kompatibel sein werden.

vCluster kann auch als wertvolles Tool für Trainings, Workshops und Demo-Cluster dienen. Durch die Leichtgewichtigkeit und einfache Bereitstellung bieten die virtuellen Cluster die ideale Plattform, um Kubernetes-Konzepte vorzustellen und praxisorientierte Schulungen durchzuführen.

vCluster geht auf die Herausforderungen der Multitenancy in Kubernetes-Umgebungen ein und stellt eine grossartige Alternative zu klassischen, Namespace-basierten Isolierungen dar. Wie der Artikel Why Namespaces aren’t Good Enough hervorhebt, bietet vCluster robuste Isolierungsmechanismen, die nicht den Beschränkungen von Namespaces unterliegen. So können sichere und effiziente Multitenant-Deployments garantiert werden.

vClusters erleichtern auch die Isolierung bestimmter Ressourcen, die sich global im Cluster befinden, wie der Artikel Why use Virtual Kubernetes Clusters? erläutert. Dadurch können Nutzer Ressourcen effektiv verwalten und sichern, die sich nicht mithilfe von Namespace-basierten Ansätzen isolieren lassen. Damit steigt die Sicherheit von Kubernetes-Deployments insgesamt.

vCluster im Vergleich zu NKE

vCluster bietet eine Alternative zu NKE-basierten Kubernetes-Clustern und eignet sich für verschiedene Use Cases, hat aber auch seine Grenzen. Mit vCluster können Kubernetes-Cluster preisgünstiger angeboten werden, auch wenn dabei einige Abstriche bei Verfügbarkeitsgarantien und Managed Add-ons gemacht werden müssen. Weitere Details (und ein detaillierterer Vergleich) finden Sie in unserer Dokumentation unter Kubernetes-Cluster als vCluster.