© Ultimagaina, 123RF

Eigentlich kann der Erfolg der Konkurrenten Linux-Container und Kubernetes VMware kaum gefallen – doch mit seinem Projekt Tanzu baut es geradezu einen Supertanker für Container. Was steckt dahinter?

In den vergangenen Monaten geisterte immer wieder eine Meldung durch die Medien, die man im ersten Moment nur schwer glauben konnte: Docker soll sich angeblich in finanziellen Schwierigkeiten befinden. Wie soll das denn gehen? Schließlich war es Docker, das vor ein paar Jahren das Thema Container unter Linux aus der Schmuddelecke geholt hat. Versehen mit einem brauchbaren Ökosystem schickte sich die Docker-Umgebung schnell an, zu Admins Liebling zu werden.

Mittlerweile ist der Containerzirkus allerdings weitergezogen: Schnell merkten die Admins, dass das bloße Betreiben von Containern allein im Alltag nicht genügt. Stattdessen ist auch eine auf den jeweiligen Einsatzzweck ausgelegte Orchestrierung für Container nötig, und da war Docker anfangs blank. Das bei Google entstandene Kubernetes sprang in die Bresche und entwickelte fernab von Docker ein umtriebiges Eigenleben. Heute frisst die Revolution ihre Kinder: Offene Containerformate und offene Container-Runtimes kaufen Docker den Schneid ab. Schnell wird klar: Es zählt keineswegs die Docker-Funktionalität per se, die Wertschöpfung findet stattdessen in Kubernetes statt. Und genau deshalb ist es tatsächlich nicht unmöglich, dass bei Docker in absehbarer Zeit die Lichter ausgehen.

Branchenprimus in Schockstarre

Docker ist ein Beispiel dafür, wie eine technologische Revolution ein ganzes Geschäftsmodell zu Fall bringen kann. Zu einem weiteren, noch viel größeren Fall hätte ein anderes Unternehmen werden können: VMware, der Branchenprimus der Virtualisierung. Hier verdiente man über Jahrzehnte gutes Geld damit, dass man eine Virtualisierungsumgebung aus einem Guss anbot. VMware vSphere lässt sich ja problemlos an andere VMware-Produkte andocken, etwa VMware vSAN oder NSX für Software Defined Networking. Sogar auf den OpenStack-Zug ist man bei VMware zwischenzeitlich aufgesprungen und bietet in Form von VIO, VMware Integrated OpenStack, eine Art Übersetzungskomponente zwischen den offiziellen OpenStack-APIs und vSphere an.

All diese Ansätzen haben allerdings gemeinsam, dass sie auf Vollvirtualisierung oder Paravirtualisierung setzen. Das VMware-Kernprodukt ESX oder ESXi, der Hypervisor, der als kleinster gemeinsamer Nenner im VMware-Universum gilt, kommt in all diesen Ansätzen weiter zum Einsatz. Da war es schon seltsam, dass VMware den Kubernetes-Hype über eine lange Zeit hinweg zu verschlafen schien. Denn letztlich stellt Kubernetes mit seinen Containern im Hintergrund – ganz gleich, welche Runtime die nutzen – einen zentralen Angriff auf den Kern des VMware-Geschäfts dar, eben Voll- und Paravirtualisierung. Wenn immer weniger Virtualisierung klassische Hypervisors nutzt, wird der Kuchen, von dem Vmware traditionell ein großes Stück für sich reklamiert, kontinuierlich kleiner.

Mit dem Schlaf in Sachen Kubernetes ist es jetzt allerdings vorbei: Projekt Tanzu schickt sich an, die VMware-Werkzeugsammlung für Kubernetes zu werden, mit der sich Kubernetes nahtlos in das bestehende VMware-Framework einfügen soll. Ein Teil der Werkzeuge, die in Tanzu zum Einsatz kommen, steht bereits unter einer Open-Source-Lizenz; weitere Komponenten sollen in den kommenden Monaten folgen. Da lohnt sich ein genauerer Blick: Wie sieht VMwares Taktik im Hinblick auf Kubernetes aus? Was werden VMware-Nutzer in Sachen Kubernetes erwarten dürfen, und wo hört die Liebe für die Container-Orchestrierung bei VMware auf?

Integration: nicht einfach

Auch wenn es auf den ersten Blick anders aussieht: Ganz einfach ist es für VMware nicht, Kubernetes nebst möglicher Zusatzprogramme irgendwie in das eigene Portfolio zu integrieren. Auf den ersten Blick kommt Kubernetes ganz hervorragend ohne echte Virtualisierer wie VMware oder KVM aus – gerade das ist ja ein Kernversprechen der Software.

Hinzu kommt, dass man bei “K8s” viele Themen bewusst ausgeklammert hat, die anderen Ansätzen wie OpenStack zum Verhängnis wurden: Mandantenfähigkeit sieht Kubernetes etwa gar nicht erst vor. Stattdessen, so der Vorschlag, solle man pro Kunde einfach einzelne Kubernetes-Cluster ausrollen. Das führt zwar zu etwas Overhead auf der Ebene von Kubernetes, dafür tummeln sich im Setup aber wesentlich weniger Technologien wie SDN, um Mandantentrennung zu erreichen. Will VMware in diesem Konstrukt eine Lücke für sich finden, ist klar: Ganz einfach wird das nicht.

Auf der Suche nach einem Ausweg aus dem Dilemma stieß VMware auf einen Ansatz, den viele andere Anbieter auch schon für sich auserkoren haben: Wenn der Trend dahin geht, viele Kubernetes-Instanzen gleichzeitig zu betreiben, dann braucht der Admin ein Werkzeug, das ihm diese Aufgaben abnimmt. Ein eben solches Werkzeug wird nun quasi zum Kern der Strategie, mit der VMware sich im Kubernetes-Markt einnisten möchte.

Projekt Tanzu am Horizont

Vorgestellt hat der Konzern, der mittlerweile zur Dell-EMC-Gruppe gehört, sein Konzept auf seiner Hausmesse VMware World Ende August in San Francisco. Unter dem Projektnamen Tanzu kündigte das Unternehmen gleich mehrere Tools an, die Admins den Betrieb von Kubernetes erleichtern sollen und die zugleich auch die Entwicklung in Kubernetes vereinfachen [1].

Tanzu besteht im Kern aus drei Konzepten: Tanzu Mission Control erlaubt die effiziente Verwaltung mehrerer Kubernetes-Cluster. Die Enterprise PKS und Essential PKS ermöglichen es, in privaten sowie öffentlichen Umgebungen die nun zu VMware gehörende Kubernetes-Distribution Pivotal auszurollen.

Kubernetes nach Belieben steuern

VMware hat sich in den vergangenen Jahrzehnten auch dadurch einen Namen gemacht, dass es seine Produkte stets mit opulenten grafischen Tools ausstattete. Komplexe Technik verschwand in aller Regel hinter diesen Tools. Selbst technisch vielschichtige Vorgänge ließen sich über simple GUIs steuern, und quasi als Sahnehäubchen gab es aussagekräftige Statistiken in Form von Charts gleich noch dazu.

Praktisch ist das also Teil des VMware-Geschäftsmodells, und auch bei Tanzu weicht der Hersteller von diesem Ansatz nicht ab: Das auf den Namen Tanzu Mission Control getaufte Werkzeug (Abbildung 1) ist in erster Linie ein Tool, um verschiedene Kubernetes-Instanzen an verschiedenen Zielorten miteinander zu verbinden und zentral zu steuern.

Abbildung 1: VMware Tanzu Mission Control unterteilt Kubernetes in Cluster und richtet sich momentan bevorzugt an Instanzen in Public Clouds. Quelle: VMware

Grundsätzlich unterscheidet Tanzu Mission Control zwischen Cluster-Gruppen und Clustern, wobei ein Cluster stets eine Kubernetes-Instanz ist. Legt der Admin Gruppen an, geschieht das anhand verschiedener Parameter wie der Art des Clusters – also, ob dieser aus AWS heraus ausgerollt worden ist, ob es sich um einen Azure-Kubernetes-Cluster handelt oder um eine separate On-Premises-Lösung. Auch aus Tanzu MC heraus lassen sich neue Cluster starten; wer also schon laufende Kubernetes-Instanzen hat, integriert diese auf Wunsch auch in eine neue Instanz von Tanzu.

Vereinfacht dargestellt legt sich Tanzu wie eine große Klammer um die ihm unterstellten Kubernetes-Instanzen. Die klassische VMware-Nomenklatur der verschiedenen Ebenen, wie sie Admins von vSphere gewohnt sind, bietet Tanzu auch für Kubernetes: Beispielhaft erwähnt sei die Integration eines umfassenden Policy-Frameworks samt Nutzerverwaltung, über die sich spezifische Permissions bis auf die Ebene einzelner konkreter Aktionen definieren lassen.

Seit jeher punktet VMware bei seinen Kunden auch damit, dass es Compliance erleichtert und zentrale Regelwerke implementiert. Das kann es, weil ESX, vSphere & Co. sich in klassischen VMware-Setups über alle Ebenen der Installation erstrecken und diese entsprechend samt und sonders kontrollieren können.

Compliance-Überlegungen sind aber nicht die einzigen Elemente bei Tanzu, mit denen VMware auf Kundenfang geht. Komplementär dazu gesellt sich eine Art Orchestrierung für Kubernetes-Instanzen: Zentral hinterlegt der Admin in Tanzu Konfigurationen für den Container-Orchestrierer. Diese wendet Tanzu danach auf die ihm unterstellten Kubernetes-Instanzen an. Startet Tanzu selbst eine neue Kubernetes-Umgebung, geschieht das dort genauso.

Was Tanzu steuern kann

Wer sich schon einmal mit den verschiedenen Public-Cloud-Anbietern beschäftigt hat, der weiß: Alle relevanten Unternehmen am Markt zwingen ihre Kunden heute nicht mehr dazu, Kubernetes selbst auszurollen. Stattdessen gibt es bei AWS, Azure und Konsorten fertige Kubernetes-Ressourcen, die sich komplett in der jeweiligen Umgebung ausrollen lassen.

Zumindest im Augenblick scheint es, als seien eben diese Ressourcen die primäre Zielgruppe von Tanzu. Denn das Tool verbindet sich mit Google, AWS und Azure, sobald der Admin die passenden Credentials hinterlegt hat, und liest die bereits laufenden Cluster aus. Soll per Tanzu eine neue Kubernetes-Instanz gestartet werden, geschieht das ebenso über diese Ressourcen in der jeweiligen Cloud. Der Vorteil für den Admin liegt klar auf der Hand: Alle laufenden Instanzen in einem Projekt der eingegebenen Credentials werden sofort sichtbar und lassen sich auf Knopfdruck aus Tanzu heraus steuern.

Komplementär dazu lässt Tanzu sich, wie bereits erwähnt, auch mit laufenden Kubernetes-Instanzen direkt verbinden. Dazu gibt der Admin allerdings die API-Daten von Kubernetes direkt an. Möchte man also Kubernetes-Instanzen auf diese Weise mit Tanzu verbinden, geschieht das einzeln pro Instanz, was je nach vorhandener Menge einige Zeit in Anspruch nehmen kann.

Letztlich ist diese Art der Nutzung aber auch gar nicht die angepeilte in Tanzu: Dass man bei VMware nicht glücklich werden wird, wenn man nur die Public Clouds sinnvoll in das eigene Tooling einbindet, ist offensichtlich. Deshalb geht VMware nun auch mit eigenen Kubernetes-Produkten an den Start, und die sind freilich in Tanzu ebenso gut integriert – dazu gleich mehr. Zuvor sei noch erwähnt, dass das Tanzu-GUI sich nicht nur auf die Administration von Tanzu bezieht: Über ein GUI speziell für Admins und Entwickler lassen sich auch deren Wünsche ohne manuelle Intervention befriedigen.

Konkret bedeutet das: Wenn das Policy-Framework entsprechend gebaut ist, können auch Nicht-Admin-Nutzer aus Tanzu heraus Kubernetes-Cluster ohne Schwierigkeiten starten. Zusätzlich kennt Tanzu die Ressource “Workload”, die in Richtung CI/CD geht und Kubernetes impliziert.

Alte Bekannte: Pivotal

Zweifellos darf VMware als erfolgsverwöhnt gelten: Mit einer Vielzahl von großen Technologieunternehmen weltweit pflegt der Konzern seit Jahrzehnten solide Partnerschaften, die sich auch in wirtschaftlichem Erfolg ausdrücken. Freilich ist der VMware-Chefetage dabei klar, dass sie es mit bloßen Management-Werkzeugen für VMware nicht weit bringen wird.

Selbst wenn VMware die allertollste Container-Verwaltung auf der ganzen Welt hätte: Kommerzielle Kubernetes-Distributionen wie OpenShift bieten eigene GUIs und liefern gleich ein komplettes Kubernetes nach Herstellergeschmack mit. Kunden würden dieses zwar vielleicht noch mit Tanzu koppeln wollen, weil das die Verwaltung diverser Kubernetes-Cluster erlaubt. Aber zweifelsohne wären sie nicht bereit, dafür denselben Betrag zu zahlen, den VMware für seine Virtualisierungstools aufruft.

Schnell war bei VMware deshalb klar, dass man in Sachen Kubernetes selbst aus der Reserve kommen und schnell mit einem Produkt an den Start gehen musste. VMware ist durchaus nicht das einzige angestammte Unternehmen, das sich in die neuartige Kubernetes-Welt wagt: Seit einigen Monaten treten sogar Anbieter mit Kubernetes-Distributionen am Markt auf, von denen man das so gar nicht vermutet hätte, etwa NetApp.

Wer nun allerdings erwartet, dass VMware eine eigene Distribution für den Container-Orchestrierer gebaut hätte, sieht sich getäuscht. Weil VMware heute zu Dell-EMC gehört und man dort ein reges Interesse daran hat, dass VMware erfolgreich bleibt, um über diesen Kanal auch Hardware unters Volk zu bringen, ist die Firma mit einer soliden Kriegskasse ausgestattet. Und die zapfte man vor ein paar Monaten an, um einen der Pioniere in Sachen Container zu kaufen: Pivotal gehört mittlerweile zu VMware.

Entsprechend ist VMware heute mit zwei Kubernetes-Produkten am Start: Das VMware Essential PKS richtet sich an Kubernetes-Profis, die ein möglichst reines Kubernetes wollen. VMware Enterprise PKS hingegen adressiert die typische VMware-Klientel, die nicht nur die Lösung per se will, sondern auch Integration in Regelsysteme, die komplette NSX-Erfahrung und nahtlosen Support für die Integration von AWS & Co.

Hausmannskost oder volle Ladung

VMware Essential PKS sticht aus der Riege der VMware-Produkte insofern heraus, als dass es sich nahe am originalen Kubernetes orientiert. Im Grunde handelt es sich bei der Essential-Variante von PKS um eine grundlegende Kubernetes-Distribution, die in Sachen Netzwerk oder Storage allerdings nicht von den Standardvorgaben des Container-Orchestrierers abweicht. Obendrein gibt es Support sowohl im Hinblick auf das Produkt als auch im Hinblick auf Applikationen, die sich auf Basis des Produkts konstruieren lassen.

Wer hingegen das Wunschlos-glücklich-Paket gewohnt ist, fühlt sich eher bei der Enterprise-PKS-Variante (Abbildung 2) der VMware-Kubernetes-Distributionen wohl. Warum das so ist, zeigt ein Blick in das Ökosystem, das VMware seinen Kunden gerne baut: Hier spielt ja längst nicht mehr nur die Virtualisierung eine sehr entscheidende Rolle, sondern auch andere Komponenten.

Abbildung 2: Wer sich für VMware Enterprise PKS entscheidet, bekommt ein Pivotal unter neuem GUI, das bestens in NSX und andere VMware-Teile integriert ist. Quelle: VMware

Wer sich etwa schon einmal mit dem Objektspeicher Ceph beschäftigt hat, weiß: Es gibt keine sinnvolle Art, ihn mit VMware zu verbinden. Weil VMware aber selbst mittlerweile in Sachen Cloud aktiv ist und der eigenen Klientel skalierbare Lösungen verkaufen möchte, gibt es ein Alternativprodukt zu Ceph in VMware – vNAS. Diese proprietäre Implementierung eines nahtlos skalierbaren Speichers funktioniert zudem hyperconverged, macht also die Festplatten in den einzelnen Knoten zu einem großen, virtuellen Speicher. Darauf greifen die Clients dann von allen Knoten aus zu. Wichtig: Sie tun das transparent, zumindest aus Sicht des Nutzers. Der Nutzer legt für eine virtuelle Maschine also lediglich fest, dass diese persistenten Speicher haben soll – wie VMware das im Hintergrund technisch umsetzt, braucht ihn nicht zu interessieren.

Ähnlich verhält es sich in Sachen Netz: Wer das Cloud-Paket bei VMware sein Eigen nennt, hat implizit auch die VMware-eigene SDN-Lösung NSX im Haus. Die entstammt bekanntlich der Feder derselben Autoren wie Open vSwitch, das als Quasi-Standard in Sachen Open-Source-SDN gilt. NSX verfügt allerdings über einen viel größeren Funktionsumfang als klassisches Open vSwitch, und durch die Steuerung aus vSphere heraus wird es deutlich vielseitiger. Kein Problem sind beispielsweise Multi-Cloud-Ansätze, bei denen der Admin einzelne Teile des Workloads auf unterschiedliche Public Clouds oder eine On-Premises-Cloud verteilt. vSphere baut zwischen den einzelnen Teilen eines Setups ein nahtloses virtuelles Netz, ohne dass der Admin dafür irgend etwas Besonderes zu tun hätte.

Wer sich für die Enterprise-PKS-Edition der VMware-Kubernetes-Distribution entscheidet, bekommt ein Kubernetes, das in eben diese Systeme ebenso perfekt eingebunden ist wie eine reguläre VM. Über eigene Plugins integriert sich Kubernetes in einem solchen Setup beispielsweise in NSX, sodass Multi-Cloud-Workloads auch mit Kubernetes kein Problem darstellen. Wer also die klassische VMware-Experience will, ist bei diesem Produkt vermutlich besser aufgehoben. Im Gegenzug verlangt VMware für die Kombination aus Produkt und Support aber auch den Einwurf wesentlich größerer Münzen – das dürften VMware-Kunden allerdings gewohnt sein.

Integration in der Tiefe

Wer ohnehin ein VMware-Shop ist und beschließt, sich auch bei Kubernetes ins VMware-Bett zu legen, der bekommt im Gegenzug für viele Münzen eine tiefe Integration. Kein Wunder, lebt VMware doch gerade davon: Kunden, die es sich im VMware-Universum einmal gemütlich gemacht haben, sollen möglichst wenige Gründe haben, ihre Entscheidung zu überdenken. Das heißt ganz konkret: Wer einen Kubernetes-Cluster in seiner lokalen Umgebung ausrollen möchte, tut das per Tanzu Mission Control eben auch in bestehende vSphere-Cluster. Die Container laufen hinterher auf ESXi-Hosts und dort zumeist in virtuellen Maschinen.

Aus administrativer Sicht ergibt das Sinn: Den kompletten Lebenszyklus eines auf Kubernetes basierten Clusters möchte der Admin im Normalfall automatisch und ohne händisches Eingreifen managen. Über die normalen VMware-Schnittstellen und mittels der üblichen Tools geht das problemlos. Dieser Ansatz ist übrigens keineswegs VMware-spezifisch: Wer große Mengen Kubernetes-Cluster betreiben will, greift gelegentlich etwa zu OpenStack – denn virtuelle Maschinen in Clouds lassen sich schnell provisionieren. Echtes Blech auszurollen dauert im Gegensatz dazu merklich länger.

Dieser Ansatz geht allerdings auch mit einem erheblichen Overhead einher, was das Thema Ressourcen betrifft. Wer Kubernetes in echten VMs betreibt, hat ja einerseits den Overhead der VM und andererseits den des Containers noch dazu. Seit Jahren gilt es deswegen als Wunsch, Container auf echtem Blech statt in zwischengeschalteten VMs zu fahren und dabei auch die schon von Lösungen wie vSphere oder OpenStack bekannten Management-Lösungen zu erhalten.

Logisch: Auf einem ESXi-Host läuft am Ende ja auch ein Agent, der virtuelle Maschinen startet. Baute man diesen so um, dass er stattdessen Container aus dem Boden stampfen kann, wäre das Ziel erreicht. Um Probleme wie SDN oder die zentrale Verfügbarkeit von Speicher braucht VMware sich wie beschrieben ja ohnehin nicht zu kümmern, denn vSAN und NSX existieren – und könnten in solch einem Setup einfach weiterhin zum Einsatz kommen.

vSpherelet im Anflug

Da wundert es nicht, dass eine Ankündigung von VMware sich auf eben diesen Ansatz bezieht: Dem klassischen Kubelet stellt VMware künftig sogenannte vSpherelets zur Seite. Die ermöglichen es, einen Bare-Metal-Knoten für den Betrieb von Kubernetes-Containern in vSphere zu verwenden. Der eben beschriebene Overhead ist damit künftig Geschichte. VMware ist hier sogar etwas früher dran als Kubernetes selbst, das an ähnlichen, aber freilich nicht speziell auf VMware zugeschnittenen Ansätzen arbeitet.

Mit dem vSpherelet gestaltet sich die Integration von VMware und Kubernetes also noch enger, auch wenn sich dadurch freilich der Vendor-Lockin weiter verschärft. Betreibt man Kubernetes einmal im Rahmen eines solchen Setups, gibt es beinahe keine Chance mehr, aus der Sache wieder herauszukommen.

Das Ganze vermarktet VMware übrigens unter dem Namen Project Pacific (Abbildung 3): Das zentrale Ziel dabei ist es, vSphere zu einer “zentralen Applikations-Plattform der Zukunft” zu machen. Völker, hört die Signale: Offensichtlich geht man auch bei VMware davon aus, dass sich künftig viel weniger Unternehmen für klassisches IaaS interessieren werden und dass PaaS, SaaS & Co. stattdessen den Ton angeben.

Abbildung 3: Statt Container auf ESX zu betreiben, soll Kubernetes künftig ein gleichberechtigter Hypervisor im VMware-Universum werden – daran arbeitet VMware unter dem Codenamen Project Pacific. Quelle: VMware

Auch Open Source spielt eine Rolle

Interessant ist im Kontext von Tanzu bei VMware übrigens noch ein weiterer Faktor: Die Firma hat parallel mit dem offiziellen Tanzu-Launch auch ein neues GitHub-Repository [2] gestartet, in dem sie diverse Open-Source-Komponenten aus Tanzu unter einer offenen Lizenz zur Verfügung stellt. Bisher gilt VMware nicht gerade als Open-Source-Pionier – Grund genug also, sich die feilgebotenen Komponenten einmal genauer anzusehen. Schnell wird klar: Die Tools bieten auch außerhalb von VMware-Setups sinnvolle Funktionen.

Unter dem Namen Velero vertreibt VMware beispielsweise ein Produkt, das sich um das Sichern von Kubernetes-Instanzen und die Migration von kompletten Kubernetes-Installationen kümmert. Weil quasi aller Container-Workload ohnehin virtualisiert läuft, sind solche Migrationen nicht selten: Wer etwa bei AWS bessere Konditionen als bei Azure bekommt, möchte vielleicht alle laufenden Kubernetes-Instanzen umziehen. Wer Disaster Recovery braucht, interessiert sich für den Teil, der Daten von A nach B kopiert. Genau diese Aufgabe eines General-Purpose-Tools für Backups und Migration in Kubernetes übernimmt Velero. Obendrein liefert VMware sogar ein Plugin, mit dem Velero sich direkt in die Backup-Funktionen von Googles Container Platform integrieren lässt; Plugins für die anderen Anbieter dürften bald folgen.

Nicht minder praktisch ist Octant (Abbildung 4): Das bietet Admins die Möglichkeit, sich in Form einer grafischen Konsole schnell über den Zustand einer Instanz von Kubernetes zu informieren. Offensichtlich dient Octant als Fundament für Tanzu Mission Control, denn einige Ansichten in der Tanzu-MC tauchen in Octant fast identisch auf. Verändern lässt sich in Octant allerdings nichts, die Devise lautet also: nur schauen, aber nicht anfassen. Kein Problem: Schnell liefert Octant eine bessere Übersicht als manch anderes Tool am Markt, und wer auf der Suche nach guter Visualisierung seiner Kubernetes-Instanzen ist, sollte sich Octant genauer ansehen.

Abbildung 4: Octant ist ein VMware-Werkzeug für Kubernetes, mit dem der Admin sich schnell einen Überblick verschafft – auch über mehrere Kubernetes-Setups gleichzeitig. Quelle: VMware

Zu guter Letzt soll auch Sonobuoy (Abbildung 5) nicht fehlen – die “Sonartonne” heißt nicht zufällig so. Auch Sonobuoy informiert den Admin über den Zustand einer Kubernetes-Instanz; hier geht es aber nicht um die bloßen Fakten, sondern eher um Metrikdaten wie die Performance einzelner Dienste. Diese Daten erhebt Sonobuoy ad hoc und auf Basis vorhandener Kubernetes-Tests, um dem Admin am Ende des Vorgangs eine Übersicht zu präsentieren.

Abbildung 5: Sonobuoy ist die “Sonartonne” für Kubernetes: Per Plugin-Framework lassen sich Tests definieren, die Sonobuoy dann abarbeitet. Quelle: VMware

Nota bene: Alle drei vorgestellten Komponenten kommunizieren ausschließlich mit der Kubernetes-API oder der API des Cloud-Anbieters, der Kubernetes als Ressource betreibt. Irgendwelche VMware-Produkte sind also nicht nötig, und so empfiehlt es sich für jeden Kubernetes-Admin, einen genaueren Blick auf eben diese Tools zu werfen. (jcb)