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 wird auch in vielen Dokumenten TKGm (Tanzu Kubernetes Grid Multicloud) genannt. 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.

vCenter Console Übersicht

Unten sehen Sie die Komponenten auf der vCenter-Konsole, die teileweise unten beschrieben werden:

1. vCenter
2. Datacenter
3. vSphere Cluster
4. ESXi-Hosts
5. Supervisor Cluster Namespace - das Namespace ist eine logische Organisationseinheit, die alle Tanzu Komponenten beinhaltet.
6. vSphere Namespace - ist ein logisches Objekt, welches die Zuweisung von Ressourcen (Compute, Memory, Storage, Network) sowie die Zugriffskontrolle auf Kubernetes-Ressourcen und/oder virtuelle Maschinen bietet.
7. Tanzu Kubernetes-Cluster - wird oft auch Tanzu Kubernetes Grid Services (TKGs) oder Guest Cluster genannt.
8. Tanzu Kubernetes-Cluster Nodes - hier werden die einzelne Kubernetes Cluster Nodes (Contol Plane / Worker Nodes) angezeigt.
9. vSphere Pods - sind die direkt auf den ESXi-Hosts ausgeführt werden.
10. SupervisorControlPlaneVMs - sind die Management des SupervisorCluster. 

Tanzu Kubernetes Cluster

Tanzu Kubernetes Cluster (wird als Tanzu Kubernetes Grid Service (TKGS) bezeichnet) ermöglicht die native Bereitstellung eines Open-Source-kompatible Kubernetes-Clusters in einem Namespace im Supervisor Cluster. TKC gibt in ersten Linien den Entwicklern die Möglichkeit, ihren eigenen isolierten Kubernetes-Cluster zu installieren und zu verwalten. Ohne NSX-T ist die Nutzung von TKC nicht möglich.

In diesem Blogbeitrag finden Sie eine Beschreibung der Kubernetes-Architektur und derer Komponenten. 

Der dargestellte Guest Cluster aus drei Master Nodes und drei Worker Nodes ist nur ein Beispiel für eine mögliche Konfiguration. Die Anzahl der Komponente und deren Zusammensetzung wird ausschließlich anhand der geplanten Architektur festgelegt. Auch das hier dargestellte Photon OS darf in den zukünftigen Tanzu-Versionen durch Ubuntu ersetzt werden.

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.

Namespaces

Ein Namespace definiert eine logische Grenze zwischen den Clusterressourcen. Ein vSphere-Namespace wird auf dem Supervisor-Cluster von vSphere erstellt. 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.

In gewisser Hinsicht ist ein vSphere-Namespaces auch ein Kubernetes-Namespace, da Sie als Admin alle existierende Namespaces sehen dürfen (kubectl get namespace). Das vSphere-Namespaces hat keine Beziehung zu Kubernetes-Namespaces, die innerhalb eines vom Supervisor-Cluster erstellten Tanzu Kubernetes Cluster (TKC) erstellt würden. 

Jeder Namespace hat seinen eigenen Ressourcenpool (Ressourcenisolation mit Quoten für CPU-, Arbeitsspeicher- und/oder Disk-Speicher).

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

Die Größe der zugewiesenen Ressourcen lässt sich bei Bedarf anpassen. (Cmdlet Set-WMCluster, z.B. Set-WMCluster -SizeHint small)

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.

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. Es wird mittlerweile die Meinung verbreitet, dass vSphere Pods sehr selten genutzt werden und es dieser Hinsicht dem Untergang geweiht sind.

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)

• 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 von vSphere Pods
• Ü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.