Zum Inhalt

VMware Tanzu 2026: TKG-Ende, VKS und Alternativen

VMware Tanzu nach Broadcom: TKG 2.5.4 ist final, TKGi endet im Oktober 2027, VKS bringt 24 Monate Support. Lizenzlage, Migration und Alternativen in Deutschland.

Aktualisiert 9 Min. LesezeitFakten geprüft am 28. Oktober 2026

TL;DR

VMware Tanzu ist nach der Übernahme durch Broadcom kein eigenständiges Kubernetes-Produkt mehr. Tanzu Kubernetes Grid endet mit Version 2.5.4, TKGi verliert im Oktober 2027 den Support. Weiter geht es nur mit dem vSphere Kubernetes Service (VKS) in VMware Cloud Foundation. Wer die Lizenzbindung meiden will, prüft Rancher, OpenShift, Talos auf Proxmox oder Managed Kubernetes.

Was ist von VMware Tanzu 2026 noch übrig?

Von den früheren Tanzu-Kubernetes-Produkten lebt 2026 nur der in vSphere integrierte Teil weiter, heute als vSphere Kubernetes Service (VKS). Tanzu Kubernetes Grid (TKG) als Standalone-Produkt hat sein letztes Release erhalten, TKGi hat ein festes Support-Ende. Für Bestandskunden ist das keine Feature-Frage mehr, sondern eine Migrationsfrage mit Termin.

Die drei Linien im Überblick:

Produkt Stand Oktober 2026 Was Broadcom empfiehlt
Tanzu Kubernetes Grid (TKG, Standalone) v2.5.4 vom 25.06.2025 ist das letzte Enterprise-Release, Kubernetes 1.26 bis 1.33 Migration zu vSphere Supervisor und VKS
Tanzu Kubernetes Grid Integrated (TKGi) End of Support im Oktober 2027, inkompatibel mit VCF 9.1 und NSX 9.1 Paralleles VKS-Cluster, Umzug mit Velero
vSphere Kubernetes Service (VKS) VKS 3.6 mit Kubernetes 1.35, 24 Monate Support pro Minor-Version Zielplattform innerhalb von VCF

Die Release Notes zu TKG 2.5 sagen es wörtlich: v2.5.4 ist “the final enterprise release of TKG”. Kunden sollen mit dem Broadcom-Account-Team klären, wie sie Workloads auf vSphere Supervisor und VKS migrieren. Schon TKG 2.5 legte keine Standalone-Management-Cluster mehr auf AWS und Azure an. Damit ist der Multi-Cloud-Anspruch, mit dem TKG einmal startete, praktisch aufgegeben: Kubernetes von VMware ist heute Kubernetes auf vSphere.

Kubernetes 1.33, die höchste Version in TKG 2.5.4, liegt vier Minor-Versionen hinter dem aktuellen Upstream-Stand 1.37.1 laut kubernetes.io/releases. Wer heute noch TKG betreibt, fährt also eine Kubernetes-Version ohne Community-Patches.

Was bedeutet das Ende von TKGi für Bestandskunden?

TKGi-Kunden haben bis Oktober 2027 Zeit, aber nicht für ein Infrastruktur-Update. Broadcom stuft TKGi als vollständig inkompatibel mit VCF 9.1 und NSX 9.1 ein. Wer vSphere und NSX aktualisieren will, muss TKGi vorher ablösen. Einen In-place-Weg von TKGi zu VKS gibt es nicht; Broadcom beschreibt einen Parallelaufbau mit Datenumzug.

Der Broadcom-Knowledge-Base-Artikel 446224 nennt die Reihenfolge:

  1. vSphere und NSX nicht auf 9.1 heben, solange TKGi noch läuft.
  2. Eine separate Container-Plattform mit VKS aufbauen.
  3. Anwendungen und Daten mit Standardwerkzeugen wie Velero in die VKS-Cluster umziehen.
  4. TKGi abschalten.
  5. Erst danach die Infrastruktur auf VCF 9.1 oder NSX 9.1 aktualisieren.

Der Grund liegt im Netzwerk: Das NSX Container Plugin (NCP) 9.1 unterstützt TKGi nicht mehr. Für Teams bedeutet das doppelte Kapazität während der Migration, doppelte Cluster-Konfiguration und einen Freeze auf der Infrastrukturseite. Genau diese Phase ist der natürliche Prüfpunkt, ob das Ziel wirklich VKS heißt oder eine Plattform außerhalb von VMware. Der Aufwand eines Umzugs mit Velero ist in beiden Fällen ähnlich: Manifeste, Persistent Volumes, Ingress und Secrets wandern ohnehin neu.

Ein Velero-Backup und Restore zwischen zwei Clustern sieht im Kern so aus:

# Quell-Cluster (TKGi): Namespace sichern
velero backup create shop-migration --include-namespaces shop

# Ziel-Cluster (VKS oder andere Plattform), gleicher Object-Storage-Bucket
velero restore create --from-backup shop-migration
kubectl get pods -n shop

Storage-Klassen, Load Balancer und Ingress-Controller unterscheiden sich zwischen NSX-basiertem TKGi und dem Ziel. Diese Abbildung ist der eigentliche Projektaufwand, nicht der Velero-Befehl.

Was kann der vSphere Kubernetes Service (VKS)?

VKS ist der Kubernetes-Dienst im vSphere Supervisor und Broadcoms Nachfolger für alle Tanzu-Kubernetes-Linien. Er liefert 24 Monate Support pro Kubernetes-Minor-Version, länger als der Upstream-Zyklus. Kubernetes 1.35 kam mit VKS 3.6 im Februar 2026, RHEL 9 ist seitdem als Node-Betriebssystem möglich. Der Preis dafür ist die Bindung an VMware Cloud Foundation.

Die wichtigsten Fakten aus Broadcoms eigenen Ankündigungen:

  • VKS 3.5 (29.10.2025): VKr 1.34, ab dieser Version 24 Monate Support pro Minor-Version, mehr als 35 einstellbare Parameter für kubelet, API-Server und etcd, etcd-Datenbankgröße 2 bis 8 GiB, Cluster API v1beta2 (VMware Blog).
  • VKS 3.6 (11.02.2026): Kubernetes 1.35, RHEL 9 für Control Plane und Worker neben Photon OS 5, Ubuntu 22.04 und 24.04 sowie Windows Server 2022, unterschiedliche Betriebssysteme pro Node-Pool im selben Cluster (VMware Blog).

Zum Vergleich mit Upstream: Kubernetes 1.34 hat am 27.10.2026 sein End of Life erreicht, 1.35 folgt am 28.02.2027. Die 24 Monate bei VKS sind damit ein echtes Argument für Teams, die nur einmal im Jahr upgraden wollen. Wie andere Anbieter den Versionssupport regeln, zeigt unser Vergleich zum Kubernetes-Versionssupport.

Der Wechsel auf 1.35 verlief allerdings holprig. Broadcom hat VKR 1.35.0 deaktiviert; neue Cluster, Node-Pools und Upgrades auf 1.35.0 sind gesperrt, Cluster auf 1.34 dürfen nur auf 1.35.2 springen (KB 436733). Zusätzlich blieben Upgrades von 1.34 auf 1.35 mit Antrea oder Calico bis VKS 3.6.2 hängen; behoben ist das erst in VKS 3.6.3 (KB 444946). Vor dem Upgrade prüfen Sie deshalb beide Stände:

# Im Supervisor-Kontext: verfügbare Kubernetes Releases (TKr) auflisten
kubectl get tkr | grep 1.35

# Zielversion im Cluster-Manifest setzen (1.35.2, nicht 1.35.0)
kubectl edit cluster shop-prod -n team-a

Die genaue Versionskennung entnehmen Sie der Ausgabe von kubectl get tkr in Ihrer Umgebung. Taucht eine Version dort nicht auf, ist sie meist noch nicht mit der Content Library synchronisiert.

Wie teuer ist Kubernetes auf VMware nach Broadcom?

Konkrete Listenpreise für VMware Cloud Foundation haben wir auf Broadcoms öffentlichen Seiten nicht gefunden. Belegbar sind die Zählregeln: mindestens 16 Kerne pro CPU und, so berichtet heise, seit dem 10.04.2025 eine Mindestbestellmenge von 72 Kernen. Für kleine Kubernetes-Umgebungen ist diese Untergrenze oft größer als die tatsächliche Hardware.

Die Regeln im Detail:

  • 16 Kerne pro CPU: Broadcoms KB 313548 schreibt vor, mindestens 16 physische Kerne pro CPU zu lizenzieren. Ein Host mit 2 CPUs zu je 8 Kernen zählt also als 32 Kerne.
  • 72 Kerne pro Bestellung: Laut heise/iX gilt seit dem 10.04.2025 eine Mindestbestellmenge von 72 Kernen, für Neukäufe und Verlängerungen. Ein einzelner 16-Kern-Server muss demnach mit 72 Kernen lizenziert werden, 56 mehr als vorhanden. Heise stützt sich auf das Reseller-Pricebook, Broadcom selbst hat die Regel nicht öffentlich kommentiert.
  • Verspätete Verlängerung: Wer den Verlängerungstermin verpasst, zahlt nach demselben Bericht eine Reinstatement-Gebühr von 20 % des Preises für das erste Lizenzjahr.

Wie sich das gegen Alternativen rechnet, zeigt die Tabelle. Sie vergleicht nur, was öffentlich belegt ist:

Plattform Lizenzmodell Öffentlicher Preis (netto)
VMware VCF mit VKS Subskription pro Kern, min. 16 pro CPU, 72 pro Bestellung (heise) k. A.
Proxmox VE + Kubernetes-Distribution Subskription pro CPU-Sockel, Kerne egal 120 / 370 / 550 / 1.100 € pro Sockel und Jahr
IONOS Managed Kubernetes Pay-as-you-go für Nodes, Control Plane kostenfrei Dedicated Core 0,04 € / Std., RAM 0,0045 € / GB / Std.

Rechenbeispiel Proxmox: 3 Hosts mit je 2 Sockeln brauchen 6 Subskriptionen. Im Standard-Tarif mit 4 Stunden Reaktionszeit sind das 6 × 550 € = 3.300 € netto pro Jahr (Proxmox-Preise). Kubernetes selbst kommt dann über eine Distribution dazu, Details im Beitrag zu Kubernetes auf Proxmox.

Rechenbeispiel IONOS: 3 Worker mit je 4 Dedicated Cores und 16 GB RAM kosten 12 × 0,04 € + 48 × 0,0045 € = 0,696 € pro Stunde, also 501,12 € netto pro Monat bei 720 Stunden, ohne Storage und Traffic (IONOS Managed Kubernetes).

Welche Alternativen zu VMware Tanzu gibt es in Deutschland?

Es gibt drei Richtungen: eine Kubernetes-Plattform auf dem vorhandenen vSphere weiterbetreiben, den Hypervisor gleich mit wechseln oder den Betrieb an einen Managed-Kubernetes-Anbieter mit deutschem Rechenzentrum abgeben. Welche passt, hängt davon ab, ob die VMware-Lizenz ohnehin verlängert wird und wie viel Plattformbetrieb Ihr Team selbst tragen will.

1. Andere Plattform auf vSphere. Wer VCF für VMs behält, kann Kubernetes trotzdem unabhängig von VKS betreiben. SUSE Rancher Prime legt laut Rancher-Doku VMs über die vCenter-API an und installiert Kubernetes darauf. OpenShift hat eigene vSphere-Installationswege (Installer-provisioned, User-provisioned, Assisted und Agent-based Installer). Die Kubermatic Kubernetes Platform führt vSphere ab 6.5 und VMware Cloud Director als Tier-1-Provider (Kubermatic Doku). Vorteil: Ein späterer Hypervisor-Wechsel betrifft dann nur noch die Infrastruktur, nicht die Kubernetes-Schicht.

2. Hypervisor und Kubernetes wechseln. Proxmox VE mit Talos, k3s oder kubeadm ist der häufigste Weg weg von der Kernlizenz. Die Kosten hängen an Sockeln, nicht an Kernen. Grenzen: Proxmox bringt keinen Kubernetes-Dienst mit, CSI, Load Balancer und Upgrades liegen beim eigenen Team. Einen Überblick über Distributionen gibt Talos Linux, den Gesamtvergleich der Plattformen Kubernetes on premise.

3. Managed Kubernetes in Deutschland. Hier betreibt der Anbieter Control Plane und Upgrades. IONOS berechnet keine Control-Plane-Gebühr, nur Nodes. Weitere Anbieter mit deutschen Regionen, BSI-C5-Testaten und Preisen vergleicht unsere Übersicht Managed Kubernetes Deutschland. Grenze: Workloads mit Hardware-Bindung, etwa an Speichersysteme im eigenen Rechenzentrum, lassen sich nicht ohne Umbau verschieben.

Kriterium VKS auf VCF Rancher/OpenShift/Kubermatic auf vSphere Proxmox + Distribution Managed Kubernetes DE
VMware-Lizenz nötig ja ja (für vSphere) nein nein
Kubernetes-Support 24 Monate pro Minor (Broadcom) je nach Hersteller je nach Distribution je nach Anbieter
Betrieb Control Plane eigenes Team eigenes Team eigenes Team Anbieter
Migrationsaufwand von TKGi Parallelaufbau, kein In-place Parallelaufbau Parallelaufbau plus VM-Umzug Parallelaufbau, Netz und Storage neu

Für wen passt welcher Weg?

Die Entscheidung folgt der VMware-Lizenz, nicht dem Kubernetes-Feature-Katalog. Wer VCF für Hunderte VMs ohnehin weiter lizenziert, bekommt mit VKS den kürzesten Weg und lange Supportfenster. Wer die Verlängerung vor allem wegen Kubernetes zahlt, rechnet Proxmox oder Managed Kubernetes dagegen. Teams mit wenig Personal profitieren am stärksten von Managed Kubernetes.

Konkret:

  • VKS passt, wenn VCF für die VM-Landschaft gesetzt ist, das Team NSX und vSphere kennt und Upgrades selten sein sollen. Grenze: Kosten und Roadmap bestimmt Broadcom allein, und der Start von 1.35 zeigte, dass auch Hersteller-Releases zurückgezogen werden.
  • Eine Plattform auf vSphere passt, wenn Sie VMware mittelfristig verlassen wollen, aber nicht alles gleichzeitig. Die Kubernetes-Schicht wird so hypervisor-neutral. Grenze: Sie zahlen VMware und den Plattformhersteller parallel.
  • Proxmox plus Distribution passt, wenn Lizenzkosten der Treiber sind und eigenes Know-how für Storage, Netzwerk und Upgrades vorhanden ist. Grenze: Kein Hersteller übernimmt die Kubernetes-Schicht; das Support-Paket von Proxmox deckt den Hypervisor ab.
  • Managed Kubernetes passt, wenn das Team Anwendungen betreiben will, keine Cluster. Grenze: Datenresidenz und Anbindung an bestehende Systeme sind vorab zu prüfen; die SLA-Unterschiede zwischen Control Plane und Nodes ebenso.

FAQ

Gibt es VMware Tanzu noch?

Als eigenständige Kubernetes-Produktlinie kaum noch. Tanzu Kubernetes Grid endet mit v2.5.4 vom 25.06.2025, TKGi verliert im Oktober 2027 den Support. Weitergeführt wird Kubernetes von VMware als vSphere Kubernetes Service (VKS) im vSphere Supervisor, aktuell VKS 3.6 mit Kubernetes 1.35.

Was kostet VMware Tanzu bzw. VKS?

Öffentliche Listenpreise haben wir nicht gefunden. VKS läuft im Rahmen von VMware Cloud Foundation, lizenziert pro Kern mit mindestens 16 Kernen pro CPU. Heise berichtet seit dem 10.04.2025 zusätzlich von einer Mindestbestellmenge von 72 Kernen. Den konkreten Preis nennt nur Broadcom oder ein Reseller im Angebot.

VMware Tanzu vs Rancher: Was ist der Unterschied?

VKS ist an vSphere und VMware Cloud Foundation gebunden und erhält 24 Monate Support pro Kubernetes-Version. SUSE Rancher kann VMs in vSphere anlegen und Kubernetes darauf installieren, ist aber nicht an VMware gebunden und läuft auch auf anderer Infrastruktur. Rancher ist damit der flexiblere Weg aus VMware heraus, VKS der kürzere innerhalb von VMware.

Kann ich TKGi direkt auf VKS upgraden?

Nein. Broadcom beschreibt keinen In-place-Weg. Sie bauen VKS-Cluster parallel auf, ziehen Anwendungen und Daten zum Beispiel mit Velero um, schalten TKGi ab und aktualisieren erst danach vSphere und NSX auf 9.1, denn TKGi ist mit VCF 9.1 und NSX 9.1 inkompatibel.

Wie lange unterstützt VKS eine Kubernetes-Version?

24 Monate pro Minor-Version, eingeführt mit VKr 1.33 und als Standard ab VKr 1.34 mit VKS 3.5. Upstream erhält eine Minor-Version deutlich kürzer Patches: Kubernetes 1.34 hat am 27.10.2026 das End of Life erreicht.

Welche Kubernetes-Version sollte ich auf VKS für 1.35 wählen?

VKR 1.35.2 oder neuer. Broadcom hat 1.35.0 deaktiviert, Cluster auf 1.34 dürfen nur auf 1.35.2 aktualisieren. Prüfen Sie außerdem, dass der VKS-Supervisor-Service mindestens auf 3.6.3 steht, sonst kann das Upgrade mit Antrea oder Calico hängen bleiben.

Quellen

  1. Broadcom TechDocs: Tanzu Kubernetes Grid v2.5.x Release Notes (abgerufen 28. Oktober 2026)
  2. Broadcom KB 446224: Incompatibility between TKGi and VCF 9.1 / NSX 9.1 (abgerufen 28. Oktober 2026)
  3. VMware Blog: vSphere Kubernetes Service 3.5 mit 24 Monaten Support (29.10.2025) (abgerufen 28. Oktober 2026)
  4. VMware Blog: vSphere Kubernetes Service 3.6 (11.02.2026) (abgerufen 28. Oktober 2026)
  5. Broadcom KB 436733: VKR 1.35.0 deaktiviert (abgerufen 28. Oktober 2026)
  6. Broadcom KB 444946: VKS-Upgrade auf 1.35.x hängt (abgerufen 28. Oktober 2026)
  7. Broadcom KB 313548: Counting cores for VMware Cloud Foundation and vSphere Foundation (abgerufen 28. Oktober 2026)
  8. heise online / iX: VMware, 72 statt 16 Kerne (01.04.2025) (abgerufen 28. Oktober 2026)
  9. Kubernetes: Releases (abgerufen 28. Oktober 2026)
  10. Proxmox VE: Subskriptionspreise (abgerufen 28. Oktober 2026)
  11. IONOS Cloud: Managed Kubernetes (abgerufen 28. Oktober 2026)
  12. Rancher Doku: Creating a vSphere Cluster (abgerufen 28. Oktober 2026)
  13. Red Hat Doku: OpenShift 4.20 Installing on VMware vSphere (abgerufen 28. Oktober 2026)
  14. Kubermatic Doku: Supported Providers (abgerufen 28. Oktober 2026)

Weiterlesen