Container-Orchestrierung einfach, sicher, kostengünstig und von VMware

Die Beta-Version der VMware Kubernetes Engine

| Redakteur: Ulrike Ostler

VMware nimmt mit „VKE“ Kubernetes-as-a-Service ins Programm, die „VMware Kubernetes Engine“ steht zunächst auf AWS zur Verfügung.
VMware nimmt mit „VKE“ Kubernetes-as-a-Service ins Programm, die „VMware Kubernetes Engine“ steht zunächst auf AWS zur Verfügung. (Bild: gemeinfrei - Julius_Silver/Pixabay/VMware / CC0)

Gegen Ende Juni stellte VMware seine „VMware Kubernetes Engine“ (VKE) in der Beta-Version vor. Es handelt sich um ein Kubernetes-as-a-Service-Angebot und ergänzt somit Cloud Services-Portfolio des Herstellers. Noch sammelt er Verbesserungsvorschläge.

Für die Orchestrierung von Software-Containern gibt es im Wesentlichen zwei Tools, die den Markt beherrschen „Docker Swarm“ und „Kubernetes“. Um Container laufen zu lassen, sie über viele Clouds zu verteilen, braucht es keine Virtualisierung, die bringen Container quasi per Definition mit. Doch, wer mag, braucht auf Virtualisierung nicht zu verzichten. Das gilt für OpenStack-Implementierungen genauso wie für VMware-Umgebungen.

Nun nimmt VMware mit der VMware Kubernetes Engine ein Kubernetes-as-a-Service in sein SaaS-basierten Angebote für den Enterprise-Bereich auf, um den Betrieb über Clouds hinweg zu unterstützen. Diese verfügen über eine gemeinsame, einmalige Anmeldung, gemeinsame Abrechnung und bieten weltweiten Support. http://cloud.vmware.com zugänglich.

Die Handhabung soll einfach sein, „secure by default“ und eine kostengünstige Kubernetes-Umgebung darstellen. VKE startet zunächst auf Amazon Web Services (AWS). Künftig soll der Service auch auf „Azure“ und weiteren Cloud-Umgebungen laufen können.

Vereinfachung

Kubernetes ist eine sehr umfangreiche Laufzeit-Umgebung und verbreitet sich noch immer schnell. Doch die Herausforderung an die Komplexität ist kaum zu unterschätzen. Damit gehen die Anwender unterschiedlich um. Die einen haben eine Größenordnung und eine Stratgeie, die er erlaubt. Eine engagiertes Kubernetes-Team aufzubauen. Andere sehen darin einen klassischen Fall für eine SaaS-Nutzung: Sie wollen auf diese Weise vom Mehrwert des wachsenden Ökosystems profitieren und sich gleichzeitig auf die Entwicklung ihrer Anwendungen konzentrieren können. Dafür aber muss Die Handhabung einfach sein.

Zum einen hat VMware eine Abstraktion entwickelt, die die Bezeichnung „VMware Smart Cluster“ trägt. Dahinter verbirgt sich eine Sammlung an Richtlinien, die den gewünschten Zustand eines konformen Kubernetes-Cluster erfassen. Eine Smart Cluster-Implementierung nimmt also die Richtlinien auf, bewertet kontinuierlich Sicherheit, Zustand und Größe der Kubernetes-Cluster und beseitigt eventuelle Abweichungen.

Darauf aufbauend gibt es zunächst zwei stark typisierten Smart-Cluster-Typen: Developer und Production. Mit deren Hilfe lassen sich, so VMware, zunächst über 50 verschiedene Konfigurationsentscheidungen für die Gewährleistung von Sicherheit und Verfügbarkeit für Kubernetes und AWS fällen, unter Berücksichtigung der jeweiligen Service-Level-Vorgaben. Die Entscheidungen etwa hinsichtlich Master Nodes, Etcd und der Zusammensetzung des Worker Node sowie Netzwerk- und Storage-Konfigurationen werden von VKE verwaltet.

Und drittens können die Anwender über den Abstraktionsgrad entscheiden:

  • 1. Keine Abstraktion.
  • 2. Lediglich die Steuerungsebene (Master Nodes und Etcd) wird abstrahiert und jeder Kunde verwaltet selbst Hunderte von Worker Nodes
  • 3. Komplette Abstraktion, bei der sowohl die Steuerungsebene als auch die Worker Nodes als Teil des Service nicht gemanaged werden.

Bei VMware selbst geht man davon aus, dass das maximale Kosten-Nutzen-Verhältnis beim Modell „Komplette Abstraktion“ erzielt wird (siehe: Video).

Das Demo-Video zeigt wie Cluster zu erstellen und Anwendungen bereitzustellen sind.

Kosteneffizienz

Ein weiterer Grund für die Kubernetes-Anwender auf die VKE zu setzen könnte laut VMware in der Begrenzung der Kosten liegen, sowohl was die Personalkosten als auch die zugrundeliegenden Berechnungskosten angeht. So heißt es:

Betriebskosten: „Wichtigstes Ziel der Vereinfachungen durch VKE ist es, den Einsatz von Kubernetes ohne zusätzliches, hochspezialisiertes Personal zu ermöglichen“, heißt es von VMware.

Ressourcenoptimierung: Vereinfachung hier bedeutet, dass der Bedarf an fundierten Schätzungen rund um die entsprechenden Instanzgrößen und die Cluster-Zusammensetzung fehlt – Instanz, nicht VM.

Denn ein Smart Cluster ist direkt auf „AWS EC2“ aufgebaut. Wenn also neue Instanzfamilien mit besserem Preis-Leistungs-Verhältnis von AWS eingeführt werden, identifiziert der Smart Cluster diese Einsparungsmöglichkeiten und migriert das Cluster beim nächsten Versions-Upgrade auf die neuesten Instanzfamilien.

Außerdem wächst und schrumpft der Smart Cluster auf die jeweils effizienteste Größe angesichts der aktuell eingesetzten Pods. Diese Optimierungen sind lediglich grundlegende und vernünftige Ressourcenoptimierungen. VMware will mithilfe von Kunden-feadback an weiteren Optimierungen arbeiten.

Es gilt das „Pay for what you use“-Prinzip. Noch ist nicht ganz klar, wie VMware abrechnen will, doch dieser Grundsatz für die Preisgestaltung steht: Die Kunden zahlen sekundengenau für das Kubernetes-Cluster und für die von ihnen genutzten vCPUs und RAMs.

Richtlinienbasiertes Management

Ist es schon schwierig, mehrere Cluster zu verwalten, scheitern viele Kubernetes-Anwender schlichtweg an der Verwaltung einiger Dutzend Kubernetes-Cluster mit Hunderten von Namespaces und Entwicklern auf der ganzen Welt. Nach VMware-Überlegenungen liegt der Grund unter anderem darin, dass es für jeden einzelnen Cluster zu viele sich wiederholende Einstellungen und Aktionen gibt. Demm will die VKE mit der globalen Kontroll- und Richtlinienebene entgegenwirken.

Ähnlich wie bei der „Google Cloud Platform“ stehen den Anwendern in VKE eine einfache Baumstruktur zur Verfügung, mit deren Hilfe sich die Ressourcen in logischen Containern organisieren lassen. Der Nutzer kann optional Richtlinien für ausgewählte Container (Knoten des Baums) festlegen, und diese Richtlinien werden rekursiv an untergeordnete Container weitergegeben:

  • Jede Kundenumgebung in VKE ist von sämtlichen anderen Kundenumgebungen isoliert, denn jede verfügt über ein eigenes AWS-Konto, genannt „orgs“. Jeder Org sind ein oder mehrere Ordner zugeordnet.
  • Ein Ordner wiederum ist ein logisches Konstrukt, das einen globalen Umfang hat. Jeder Ordner umfasst eines oder mehrere Projekte.
  • Bei diesen Projekten handelt es sich ebenso wie bei den Ordnern um logische Container mit globalem Umfang. Ein Projekt enthält einen oder mehrere Smart Cluster, die einer bestimmte AWS-Region zugeordnet sind, so dass die Kunden die Kontrolle darüber haben, wo Ihre Daten gespeichert werden.
  • Außerdem verfügt ein Smart Cluster über einen oder mehrere Namespaces. So ist es etwa möglich, VKE-Zugriffsrichtlinien an einem Knoten festzumachen und an untergeordnete Knoten weiterzugeben.

Schließlich werden diese VKE-Zugriffsrichtlinien in das native „Kubernetes RBAC“, das native rollenbasierte Zugriffskontrollsystem für Kubernetes, übertragen. Die daraus resultierenden Kubernetes-RBAC-Rollen verlagern sich auf einen der Master-Knoten, wo sie auf alle anderen Master übertragen werden.

Um sicherzustellen, dass diese Kubernetes RBAC-Rollen mit dem VKE konsistent sind, implementieren VMware einen eigenen „Admission Controller“, der jede Abweichung zwischen den VKE-Richtlinien und den Kubernetes-Clustern verhindert. Dazu ein Beispiel: Wenn eine Richtlinie für den Root Node eines Org festgelegt wird, die die Berechtigungen für eine Identität oder Gruppe von Identitäten enthält, wird jeder Zugriff von diesen Identitäten auf einen beliebigen Cluster (bestehende oder neu erstellte) überall auf der Welt durch diese einzige Zugriffsrichtlinie geregelt. Dabei handelt es sich um das grundlegende Konzept „Many-as-one“.

VMware plant, im Laufe der Zeit zusätzliche Richtlinientypen hinzuzufügen, um Kosten-Management, Konfiguration, Konnektivitätsrichtlinien zwischen Clustern und Namespaces sowie andere Governance- und Kontrollanwendungen zu ermöglichen.

Multi-Cloud Ready

Kubernetes bringt eine der wichtigsten Voraussetzungen für den Multi-Cloud-betrieb schon mit: Es ermöglicht eine Standardisierung. Um diese nicht zu zerstören beabsichtigt VMware, für die VKE nur natives Upstream-zertifizierte Kubernetes zu verwenden. So sollen auch die Verwaltungs-Tools mit allen anderen Standard-Kubernetes-Umgebungen kompatibel bleiben.

Im Falle von „Pivotal Container Service „ (PKS), dem gemeinsamen Angebot von Pivotal und VMware, wird noch weitergedacht. „Wir bauen auf eine gemeinsame, unterstützte Version und stellen sicher, dass auch Unterschiede zwischen Kubernetes-Versionen keine Probleme verursachen“, heißt es in einem VMware-Blog-Post.

VKE auf AWS

Die VMware Kubernetes Engine selbst wird auf AWS betrieben und unterstützt die Erstellung von Clustern auf nativen „EC2“-Instanzen und ist in drei AWS-Regionen allgemein verfügbar: US-Ost1, US-West2 und EU-West1. Allerdings bietet VKE wie oben erläutert, einen einzigen Endpoint für den Service über die Regionen hinweg. Denn der VKE-Service und die Einstellungen werden über alle Regionen hinweg repliziert, wobei eine lockere Kopplung beibehalten wird.

Das erlaubt, im Falle eines regionalen Ausfalls oder einer Netzwerkpartitionierung einer Region von den anderen, die Regionen unabhängig voneinander zu betreiben. Das Konzept soll auch mit der Unterstützung weiterer Hyper-Clouds beibehalten werden.

Die Funktion „VKE Connections“ bietet eine native Integration mit der „VPC-Peering“-Funktion von AWS für Kunden, die über private Netzwerkverbindungen auf ihre bestehenden AWS-Workloads und AWS-Dienste zugreifen möchten. Sie können VPC-Peering-Anfragen für jeden VKE-Produktions-Smart Cluster direkt von der Konsole oder CLI aus starten, um die Verbindungen zu einem oder mehreren AWS-VPCs in Ihren Konten einzurichten.

Nachdem die Peering-Anfrage akzeptiert wurde, wird die Verbindung hergestellt und die Peer-VPCs-Dienste können direkt von jedem Kubernetes-Pod im Smart Cluster aus aufgerufen werden. VPC-Peering-Verbindungen bieten eine einfache und sichere Möglichkeit für die Integration der Kubernetes-Anwendungen in bestehende AWS-Konten.

Standardmäßig Sicherheit

Die VMware Kubernetes Engine gewährleistet Sicherheit für die Kunden, indem sie (a) sicherstellt, dass alle Komponenten vollständig mit allen Patches einer produktionsreifen Kubernetes-Umgebung ausgestattet sind, (b) die Kommunikation verschlüsselt und (c) das Netzwerk isoliert ist.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45415000 / Virtualisierung)