vSphere with Tanzu - Architektur - Vergleich

In diesem Blogbeitrag geht es um das Thema Architektur von vSphere with Tanzu. Außerdem finden Sie hier ein Vergleich von verschiedenen Produkten aus dem Tanzu-Portfolio.

Tanzu – Portfolio

 

Tanzu besitzt eine breite Produkt-Palette, die sich sowohl funktional (je nach Version) als auch technologisch voneinander abweicht. Die Hauptaufgabe von Tanzu ist die Bereitstellung der Kubernetes-basierten Microservices-Architektur auf Basis der VMware-Plattform.

  • Tanzu Kubernetes Grid (TKG)
  • Tanzu Kubernetes Grid Integrated (TKGi)
  • vSphere with Tanzu
  • Tanzu Kubernetes Grid Services

 

Tanzu Kubernetes Grid (TKG)

 

Wenn Sie eine Kubernetes-Infrastruktur benötigen, die den Multi-Cloud-Einsatz verfolgt, dann wäre Tanzu Kubernetes Grid eine richtige Lösung für Sie. TKG kann auf einem lokalen SDDC und in einer Public Cloud (Azure und AWS) betrieben werden. Als Basis für die Bereitstellung der Management-, Worker-VMs dienen entweder Photon oder Ubuntu OVAs. Diese Templates beinhalten spezielle und ausschließlich mit dem TKG kompatiblen Versionen.

Die initiale Bereitstellung, sowie die weitere Administration der TKG-Infrastruktur wird eine Docker-basierte CLI verwendet.

TKG lässt sich auch perfekt mit vSphere with Tanzu und Tanzu Mission Control kombinieren.

  • aktuelle Version ist TGK 1.4
  • Unterstützung für Kubernetes 1.21.2, basiert auf einer eigenen Kubernetes-Distribution

Tanzu Kubernetes Grid  - Architektur Übersicht

Quelle: VMware

 

Tanzu Kubernetes Grid Integrated (TKGi)

 

TKGi (früher VMware PKS, Pivotal Kubernetes Service) ist ein gemeinsames Produkt von VMware und Pivotal Software. Pivotal Software wurde im Jahr 2019 von VMware übernommen. TKGi verwendet einige Komponenten, die in den anderen Tanzu-Produkten nicht existieren:  Ops Manager, BOSH Director. 

Ops Manager ist ein Softwaretool, welches zur Verwaltung/Erweiterung von Software- Produkten dient. Diese Produkte werden in der Benutzeroberfläche (UI) als tile (Kachel) dargestellt. Ops Manager wird standardmäßig mit der BOSH Director bereitgestellt.

BOSH - ist ein Open Source Produkt, mit dem Sie das Deployment und Lifecycle-Management von Software vereinfachen können. BOSH kann die gewünschte Software über Hunderte von VMs bereitstellen, überwachen, aktualisieren und die Fehlerbehebung durchführen. BOSH Director unterstützt verschiedene IaaS-Provider, darunter AWS, Azure, GCP, OpenStack und vSphere.

Analog zu TKG wurde TKGi für die Multi-Cloud-Umgebungen entwickelt und unterstütz alle führende Public Cloud Provider: Google Cloud Platform (GCP), Amazon Web Services (AWS) und Azure.

VMware Tanzu Kubernetes Grid Integrated Edition ist eine speziell entwickelte Container-Lösung, die hauptsächlich zur Kubernetes-Bereitstellung in den Multi-Cloud-Umgebungen und bei den Service Provider vorgesehen war.

TKGi nutzt die neueste stabile native Kubernetes-Version der Open-Source-Community, ohne eine eigene Abstraktionsschicht. Unteranderen sind in TKGi einige Zusatzkomponenten intergiert, um die Stabilität, Hochverfügbarkeit und Sicherheit zu erhöhen.

TKGi benötigt eine separate Lizenz.

Tanzu Kubernetes Grid  Intergrated - Architektur Übersicht

Quelle: VMware

 

vSphere with Tanzu

 

vSphere with Tanzu scheint für mich die einfachste und populärste Tanzu-Bereitstellung zu sein. vSphere with Tanzu – bietet die Möglichkeit einen „klassischen“ Kubernetes-Cluster in einer gewöhnlichen vSphere-Infrastruktur bereitzustellen, wobei der Kubernetes-Cluster weiterhin mit dem Admin Tool (kubectl) von dem Softwareentwickler (DevOps) verwalten werden kann. Die niedrigere Eintrittsschwelle für die VMware-Admins macht die Einführung von Tanzu im Vergleich zu der Open Source Kubernetes-Version besonders attraktiv.

 Im Vergleich zu den oben beschriebenen Tanzu Versionen ist vSphere with Tanzu in vSphere 7 (VMware vCenter) nahtlos intergiert. Somit wird ein Großteil der Komplexität, die mit der Kubernetes-Bereitstellung verbunden ist, beseitigt. Auch die Möglichkeit die VMs und Container nebeneinander auf derselben Plattform laufen zu lassen, vereinfacht die Verwaltung erheblich.

vSphere with Tanzu Architecture Diagramm

 

Tanzu Kubernetes Grid Services

 

Tanzu Kubernetes Grid Service (TKGS) ermöglicht die native Bereitstellung eines Open-Source-kompatible Kubernetes-Clusters in einem Namespace im Supervisor Cluster. TKGS gibt in ersten Linien den Entwicklern die Möglichkeit, ihren eigenen isolierten Kubernetes-Cluster zu installieren und zu verwalten.

 Tanzu Kubernetes Grid Services Architecture Diagramm

 

vSphere with Tanzu – Architektur

 

Supervisor Cluster

Der Supervisor Cluster ist die höchste logische Verwaltungseinheit. Der Supervisor Cluster beinhaltet drei Control Node VMs, alle ESXi-Hosts als Worker Nodes, sowie eine oder mehrere Steuerungsebene: Namespaces. Innerhalb eines vSphere Clusters kann nur einen Supervisor Cluster existieren.

Tanzu Supervisor Cluster Architecture

 

Namespaces

Ein Namespace definiert eine logische Grenze zwischen den Clusterressourcen. Direkt nach der Erstellung verfügt der erstellte Namespace über alle Ressourcen eines Clusters. Bietet aber die Möglichkeit, folgende Grenzwerte festzulegen:

  • CPU, Arbeitsspeicher, Storage
  • Anzahl der Kubernetes-Objekte
  • Speicherkontingente

Außerdem können Sie die Zugriffsrechte für die einzelnen Benutzer oder Benutzergruppen anhand der verknüpften Identitätsquelle steuern. In vielerlei Hinsicht ähnelt der Namespace einer vSphere-Ressourcengruppe.

Tanzu Namespace Supervisor Cluster

 

Control Plane VM

Die Control Plane VMs sind in ihrer Funktion den Master Nodes eines Vanille Kubernetes Clusters identisch.  Die VMs werden durch den ESX Agent Manager (EAM) erstellt und direkt mit den folgenden Regeln verbunden:

  • DRS, steuert die Platzierung dieser VMs und migriert diese bei Bedarf
  • VM-Anti-Affinity Regeln

Bei der Erstellung des Clusters durch den Workload-Management Wizard können Sie die Größe der VM festlegen:

  • Tiny - 2 CPUs, 8 GB Memory, 32 GB Storage
  • Small - 4 CPUs, 16 GB Memory, 32 GB Storage
  • Medium - 8 CPUs, 24 GB Memory, 32 GB Storage
  • Large - 16 CPUs, 32 GB Memory, 32 GB Storage

Der Supervisor-Cluster verwenden wie auch Vanille Kubernetes-Cluster ein Aktiv-Passiv-Multi-Master-Modell. In diesem Falls ist nur ein Master-Knoten aktiv und nimmt die Änderungen im Cluster vor.  Wenn die primäre VM ausfällt, wählen die sekundären VMs eine neue primäre VM im Cluster.

Die erste ControlPlaneVM ist immer die primäre Instanz. Standartmäßig werden immer drei VMs erstellt. Ab der Release vSphere 7.0 Update 3 gibt es die Möglichkeit, die Anzahl der VMs zu reduzieren. Dies konnte in einer Test-Umgebung sinnvoll sein. Hier finden Sie die Anleitung dazu.

SupervisioControlPlaneVM

Die ControlPlaneVMs benötigen insgesamt fünf IP-Adressen:

  • drei für VMs
  • eine für die Lastverteilung, bzw. Kommunikation zu dem Managementnetzwerk (Floating-IP)
  • die fünfte wird bei der Aktualisierung verwendet

 

vSphere Pod

Analog zu den Kubernetes Pods, erfüllen die vSphere Pods die gleiche Aufgabe, nämlich Ausführung und Bereitstellung der Container bereitzustellen und auszuführen.

Die vSphere-Pods werden nativ (nicht auf einem Linux Worker Node) auf dem ESXi-Host ausgeführt. Aus technischer Sicht ist ein vSphere Pod eine stark optimierte und verkleinerte virtuelle Maschine, die einen oder mehrere Container ausgeführt. Da es bei dem vSphere-Pod um eine auf Photon Linux OS basierten VM handelt, wird eine starke Ressourcen- und Sicherheitsisolierung gewährleistet.

Ein vSphere Pod bestehen aus mehreren Komponenten: CRX (wird weiter detailliert beschrieben), vmm, wmx.  Hier sind einige technische Daten:

  • die vSphere Pods sind bis zu 30 % schneller als die PODs, die auf einem Linux-System ausgeführt werden
  • das Ressourcenmanagement auf Basis von Distributed Resource Scheduler (DRS)
  • vSphere Pods sind nicht mit vSphere vMotion kompatibel
  • die Nutzung von NSX-T Data Center ist vorausgesetzt
  • vSphere Pods unterstützen mehrere Speichertypen, die auf verschiedenen Ebenen konfiguriert werden:
    • Ephemeral Virtual Machine Disks (VMDKs) (werden auf Cluster-Ebene konfiguriert)
    • Persistent Volume VMDKs (werden auf Namespace-Ebene konfiguriert)
    • Containers Image VMDKs (werden auf Cluster-Ebene konfiguriert)

Tanzu Kubernetes vSphere Pod Architecture Diagramm

  • VMX - Virtual Machine Runtime
  • VMM - Virtual Machine Monitor
  • HostD – kommuniziert mit dem Spherelet, schaltet die VM (VMX, VMM) ein und lädt den Linux-Kernel in den Speicheradressraum dieser virtuellen Maschine.

 

Spherelet

Der Spherelet ist nicht anders als eine angepasste Version von Kubelet, die in ESXi-Host integriert ist. Auch der Funktionsumfang des Spherelets ist dem Kubelet ähnlich: Kommunikation mit den Control Plane VMs, Steuerung der Knotenkonfiguration, Starten/Ausschalten/Überwachen von vSphere Pods.

 

CRX

CRX ist ein integrierter Bestandsteil des ESXi-Hosts bzw. vSphere Pods und steht für Container Runtime Executive (früher “Container Runtime for ESXi”). CRX ist eine Art virtuelle Maschine, die auf einem paravirtualisierten Photon Linux-Kernel basiert, welcher für die Ausführung von Containern speziell optimiert ist. Aus technischer Sicht sorgt Linux Application Binary Interface (ABI) für die Ausführung der Linux Container als würden sie direkt auf VMKernal laufen.

CRX beinhaltet kein BIOS, keine unnötigen Steuerungskomponenten (Tastatur, Maus, Video oder sonstige Hardware), kann dadurch schneller booten und den Linux-Kernel direkt ausführen. Alle CRX-Komponenten bilden eine CRX Instance.

CRX-Init – ist ein Prozess innerhalb der CRX-Instanz und sorgt für die Kommunikation zwischen der CRX-Instanz und VMkernel.

 

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.