Google Anthos (GKE Enterprise) im Fokus: Multi-Cloud-Versprechen versus Lock-in

Mit der Vorstellung von Google Anthos, das heute unter dem Namen Google Kubernetes Engine (GKE) Enterprise geführt wird, vollzog Google Cloud einen strategischen Kurswechsel. Nachdem Hyperscaler jahrelang versucht hatten, Unternehmenskunden von einer kompletten Abschaltung eigener Rechenzentren zu überzeugen, erkannte Google die hybride Realität europäischer Großunternehmen an.

Das Versprechen an CIOs und Chefarchitekten klingt verlockend: Anwendungen werden einmal als Container-Workloads definiert und anschließend über eine zentrale Google-Konsole wahlweise in der Google Cloud, auf AWS, auf Microsoft Azure oder auf Bare-Metal-Servern im eigenen Rechenzentrum orchestriert.

Unter der Oberfläche offener Komponenten wie Kubernetes und Istio verbirgt sich jedoch eine subtile Kontrollarchitektur. Wer seine unternehmensweite Container-Flotte über GKE Enterprise steuert, macht einen US-Hyperscaler zur obersten Leitinstanz über sämtliche Dritt-Clouds und lokalen Rechenzentren. Dieser Leitfaden analysiert die Architektur, die Lizenzkosten und souveräne CNCF-Alternativen.

Architektur-Analyse: Wie GKE Enterprise und der Fleet Hub funktionieren

Die Bindungswirkung von Google Anthos ergibt sich aus dem engen Zusammenspiel seiner vier Kernsäulen. Das Fundament bildet die Laufzeitschicht aus Google Distributed Cloud Virtual (GKE On-Prem für VMware vSphere) und Bare Metal sowie den Multi-Cloud-Adaptern für AWS und Azure.

Darüber liegen das Anthos Service Mesh (ASM) auf Istio-Basis und das Anthos Config Management (ACM), das Sicherheitsrichtlinien, Namensräume und Zugriffsregeln aus einem Repository auf alle Cluster synchronisiert. Verklammert werden diese Schichten durch den zentralen Fleet Hub in der Google Cloud.

Jedes angeschlossene Cluster, selbst auf gekaufter Bare-Metal-Hardware im eigenen europäischen Rechenzentrum, muss einen proprietären Connect-Agenten ausführen. Dieser hält einen permanenten TLS-Tunnel zu Google-API-Endpunkten offen, über den Flottenregistrierung, Richtlinienabgleich und Lizenzabrechnung laufen.

Zwar starten einzelne Container-Pods weiterhin lokal, doch die betriebliche Logik für rollenbasierte Zugriffskontrolle (RBAC), Policy-Enforcement, mTLS-Zertifikatsrotation und zentrales Logging bleibt fest mit dem Google-Backend verdrahtet. Weiterführende Analysen bietet unser Dossier zur Souveränen IT-Infrastruktur und Cloud-Exit-Architektur.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Computing-Services im Enterprise-Einsatz sowie zu Cloud-Migration Risiken im Enterprise-Einsatz.

Operative Fallstricke: Sidecar-Overhead, Telemetrie-Pflicht und die vCPU-Steuer

Im produktiven Großbetrieb zeigen sich drei gravierende Belastungsfaktoren. Erstens injiziert das Istio-basierte Anthos Service Mesh in der klassischen Architektur in jeden Applikations-Pod einen Envoy-Sidecar-Proxy, der den gesamten Netzwerkverkehr abfängt, verschlüsselt und telemetrisch auswertet.

In großen Enterprise-Clustern mit tausenden Microservices summiert sich dieser Sidecar-Ansatz zu einem erheblichen Ressourcenverlust. Allein für die Envoy-Proxies und das ständige Verteilen der Routing-Tabellen gehen in der Praxis 15 bis 25 Prozent der CPU- und RAM-Kapazität verloren.

Warum lokale Server plötzlich monatliche Cloud-Gebühren pro Prozessorkern kosten

Zweitens berechnet Google für GKE Enterprise laufende monatliche Abonnementsgebühren pro verwaltetem virtuellen Prozessorkern (vCPU). Dieser Aufschlag fällt auch für Cluster an, die auf AWS, auf Azure oder auf längst bezahlten Bare-Metal-Servern im eigenen Rechenzentrum laufen.

Ein Unternehmen investiert somit zunächst hohes Kapital (CAPEX) in eigene Server-Hardware, zahlt danach jedoch Monat für Monat eine laufende Lizenzgebühr pro lokalem vCPU-Kern an Google, nur um seine eigenen Rechenzentrums-Cluster über die Anthos-Ebene zu verwalten.

„Wer seine Multi-Cloud-Steuerungsebene in die proprietäre Plattform eines einzelnen US-Hyperscalers legt, baut keine Unabhängigkeit auf, sondern bezahlt eine monatliche vCPU-Steuer für die zentrale Fernsteuerung seiner eigenen Rechenzentren.“

Drittens kollidiert die permanente Rückverbindung zur Google Cloud mit den Sicherheitsanforderungen streng isolierter Netze (Air-Gapped-Zonen) in Industrie, Energieversorgung und öffentlichem Sektor, in denen ein kontinuierlicher Abfluss von Konfigurations- und Telemetriedaten unzulässig ist.

Der souveräne Gegenentwurf: Multi-Cloud-Orchestrierung mit reinen CNCF-Standards

Sämtliche Funktionen, die Google unter GKE Enterprise kostenpflichtig paketiert, stehen im Ökosystem der Cloud Native Computing Foundation (CNCF) als herstellerneutrale Open-Source-Projekte bereit. Eine souveräne Architektur hält die Meta-Control-Plane vollständig unter eigener Hoheit.

Cluster-API, Rancher und Gardener statt Google Fleet Hub

Den Grundstein für das Lebenszyklus-Management heterogener Flotten bildet die Kubernetes Cluster-API (CAPI). Über deklarative Custom Resource Definitions (CRDs) provisioniert und aktualisiert ein interner Management-Cluster beliebige Ziel-Cluster auf Bare Metal, Proxmox, OpenStack, europäischen Clouds sowie AWS oder Azure.

Für eine zentrale grafische Leitwarte inklusive Mandanten- und RBAC-Verwaltung ergänzen SUSE Rancher Prime oder das für Großflotten konzipierte Projekt Gardener den Stack. In Kombination mit dem unveränderbaren, API-gesteuerten Container-Betriebssystem Talos Linux entfällt zudem der Wartungsaufwand für SSH-Zugänge und Paketmanager auf Host-Ebene.

Cilium eBPF Service Mesh sowie GitOps mit ArgoCD und Kyverno

Auf der Netzwerkschicht ersetzt Cilium mit seiner direkt im Linux-Kernel arbeitenden eBPF-Technologie das ressourcenhungrige Istio-Mesh. Über Cilium Cluster Mesh werden Standorte und Clouds sidecar-frei gekoppelt, per WireGuard oder mTLS nach IETF RFC 8446 (TLS 1.3) verschlüsselt und über Hubble in Echtzeit überwacht.

Das Richtlinien- und Konfigurationsmanagement übernehmen ArgoCD oder Flux im Zusammenspiel mit Kyverno beziehungsweise OPA Gatekeeper. Sicherheitsregeln, Netzwerk-Policies und Ressourcenquoten werden als Code im eigenen Git-Repository versioniert und automatisch auf allen Clustern durchgesetzt.

Architektur- und Lizenzvergleich: Google Anthos versus Souveräner CNCF-Stack

Für eine fundierte Vorlage im Architekturboard müssen technische Komponenten und Lizenzmechanik direkt gegenübergestellt werden. Die nachfolgende Bloomberg-Radar-Matrix vergleicht Google Anthos (GKE Enterprise) mit dem souveränen CNCF-Stack anhand der fünf zentralen Entscheidungsdimensionen:

Die Matrix verdeutlicht den strukturellen Unterschied: Während GKE Enterprise die Portabilität auf Container-Ebene mit einer engen Bindung auf Management-Ebene erkauft, garantiert der CNCF-Stack volle Austauschbarkeit aller Ziel-Umgebungen ohne Umbau der GitOps- und Sicherheitsarchitektur.

Vollkostenrechnung über 60 Monate: Warum die vCPU-Metrik das IT-Budget sprengt

Um die kaufmännische Dimension für den CFO greifbar zu machen, kalkulieren wir ein repräsentatives Enterprise-Szenario mit 1.500 verwalteten vCPUs über 60 Monate (fünf Jahre), verteilt auf zwei eigene Rechenzentren und ergänzende Cloud-Kapazitäten.

Unter GKE Enterprise fallen für 1.500 vCPUs allein an Plattformlizenzen monatlich rund 22.500 Euro an. Zuzüglich Google-Connect-Traffic, Cloud-Logging und Enterprise-Support (monatlich rund 9.800 Euro) summieren sich die reinen Management-Gebühren über fünf Jahre auf 1.938.000 Euro exklusive Server-Hardware.

Beim souveränen CNCF-Stack (Vanilla Kubernetes, Cluster-API, ArgoCD, Kyverno, Cilium) liegen die vCPU-Lizenzgebühren bei 0 Euro. Ein europäischer 24/7-Enterprise-Supportvertrag kostet rund 4.500 Euro monatlich (270.000 Euro über fünf Jahre) plus 90.000 Euro Initialbudget für Aufbau und Schulung.

Mit Gesamtkosten von 360.000 Euro spart das Unternehmen über fünf Jahre 1.578.000 Euro (über 81 Prozent TCO-Reduktion) ein. Weitere Vergleichsdaten liefert unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche und Compliance nach EU Data Act und DORA

Um den offenen Multi-Cloud-Stack passend zur vorhandenen Teamstärke einzuführen, wählen europäische Unternehmen in der Praxis zwischen drei klar abgegrenzten Bereitstellungsmodellen:

Erstens (Eigenbetrieb): Organisationen mit eigenem Platform-Engineering-Team (ab vier bis sechs Spezialisten) betreiben Cluster-API, Talos Linux, Cilium und ArgoCD selbst in ihren Colocation-Racks und sichern sich über modulare Third-Level-Supportverträge ohne vCPU-Aufpreis ab.

Zweitens (Co-Managed): Unternehmen, die den Infrastruktur-Unterbau föderiert beziehen, aber GitOps-Policies selbst steuern wollen, nutzen Plattformen nach dem Sovereign Cloud Stack (SCS) oder betreiben ihre Cluster im Verbund einer Community Cloud auf Basis offener OpenStack- und CAPI-Standards.

Drittens (Managed Service): Mittelständler mit schlanker IT-Mannschaft beauftragen europäische Managed-Kubernetes-Partner (etwa auf Basis von Kubermatic, STACKIT, OVHcloud oder Hetzner) mit dem 24/7-Betrieb der Control-Plane, wobei sämtliche Git-Repositories und Manifeste im Eigentum des Kunden bleiben.

Regulatorisch erfüllt diese Entkopplung unmittelbar die Artikel 23 bis 31 des EU Data Act (Verordnung (EU) 2023/2854) zur Beseitigung technischer Cloud-Wechselhindernisse sowie Artikel 28 der Verordnung (EU) 2022/2554 (DORA), der Finanzinstituten und kritischen Dienstleistern einseitige US-Control-Plane-Konzentrationsrisiken untersagt.

Der 4-Phasen-Umsetzungsfahrplan: Schrittweise Ablösung proprietärer Control-Planes

Der Wechsel von einer proprietären Steuerungsschicht auf den offenen CNCF-Stack gelingt im laufenden Betrieb über vier strukturierte Phasen innerhalb von sechs bis neun Monaten:

Phase 1 (Monat 1 bis 2): Architektur-Audit, CRD-Inventur und Entkopplung der Identitäten

Erfassung aller genutzten Anthos-CRDs, Config-Sync-Regeln und Mesh-Annotationen. Parallel wird mit Keycloak oder Dex ein plattformneutraler OIDC-Identity-Broker aufgebaut, der die Cluster-Authentifizierung vom Google Cloud IAM löst.

Phase 2 (Monat 3 bis 4): Aufbau des CAPI-Management-Clusters und GitOps-Migration

Inbetriebnahme des selbstgehosteten Management-Clusters mit Cluster-API (optional mit Rancher oder Gardener) und ArgoCD. Übersetzung der bisherigen Sicherheitsregeln in standardisierte Kyverno- oder OPA-Gatekeeper-Policies im eigenen Git-Repository.

Phase 3 (Monat 5 bis 6): Einführung von Cilium eBPF und paralleler Cluster-Aufbau

Bereitstellung der ersten produktiven Vanilla-Kubernetes-Cluster mit Cilium eBPF und standortübergreifendem Cilium Cluster Mesh. Schrittweiser Umzug von Staging- und Fachabteilungs-Workloads über ArgoCD ohne Envoy-Sidecar-Overhead.

Phase 4 (Monat 7 bis 9): Produktiver Schwenk, Deregistrierung und Game-Day-Exit-Test

Umschaltung des produktiven Ingress-Traffics auf die CNCF-Flotte, Entfernung der Google-Connect-Agenten und Kündigung der vCPU-Abonnements. Abschließender Game-Day-Test mit simuliertem Cloud-Regionsausfall für den DORA-Prüfnachweis.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur Multi-Cloud-Architektur

1. Bleibt Ihre lokale Container-Landschaft voll steuerbar, wenn die Verbindung zur US-Cloud ausfällt?

Lassen Sie sich im Live-Test demonstrieren, ob neue Deployments, Rollenzuweisungen, Zertifikatsrotationen und Richtlinien-Updates im eigenen Rechenzentrum auch dann noch reibungslos funktionieren, wenn sämtliche Verbindungen zu den API-Endpunkten von Google Cloud, AWS oder Azure an der zentralen Firewall getrennt sind.

2. Wie hoch ist der prozentuale Aufschlag, den Sie allein für die Verwaltungs-vCPUs über fünf Jahre zahlen?

Fordern Sie eine Vollkostenrechnung an, die die reinen Lizenzgebühren der Management-Ebene strikt von den eigentlichen Hardware- und Rechenzentrumskosten trennt. Prüfen Sie dabei insbesondere, wie sich eine Verdopplung Ihrer lokalen Container-Workloads auf die jährlichen Lizenzabflüsse auswirkt.

3. Wie viel Rechenleistung verlieren Ihre Server aktuell durch Sidecar-Proxies im Service Mesh?

Analysieren Sie gemeinsam mit Ihren Plattform-Architekten den realen CPU- und Speicherverbrauch Ihrer Service-Mesh-Schicht im Verhältnis zu den Anwendungs-Containern. Ein Wechsel von klassischen Istio-Sidecars auf Cilium eBPF setzt in großen Umgebungen sofort zweistellige Prozentsätze an Serverkapazität frei.

4. Können Sie einen angebundenen Cloud-Provider innerhalb der Fristen des EU Data Act wechseln?

Prüfen Sie, ob Ihre Cluster-Definitionen, Netzwerkkonfigurationen und Sicherheitsrichtlinien in anbieterneutralen Formaten wie Cluster-API, OpenTofu und Kyverno vorliegen oder ob proprietäre Cloud-CRDs einen schnellen Providerwechsel blockieren.

5. Welche telemetrischen Metadaten fließen über Management-Agenten in außereuropäische Rechtsräume ab?

Unterziehen Sie sämtliche Agenten, die lokale Cluster mit externen Cloud-Steuerungsebenen verbinden, einer präzisen Netzwerk- und Datenschutzprüfung nach BSI IT-Grundschutz (APP.4.4 Kubernetes), um den unkontrollierten Abfluss von Topologie- und IAM-Metadaten auszuschließen.

Strategisches Fazit: Wahre Multi-Cloud-Freiheit duldet keinen monopolistischen Zwischenhändler

Google Anthos und GKE Enterprise adressieren zwar zu Recht die hybride Realität moderner Unternehmens-IT, führen den Gedanken der Unabhängigkeit jedoch durch ihre zentrale US-Steuerungsebene ad absurdum. Wer seine Multi-Cloud-Kontrolle an einen einzelnen Hyperscaler bindet, tauscht lediglich den Laufzeit-Lock-in gegen einen noch teureren Management-Lock-in.

Organisationen, die ihre Container-Orchestrierung konsequent auf unverfälschten CNCF-Standards wie Vanilla Kubernetes, Cluster-API, Cilium eBPF und ArgoCD aufbauen, senken ihre Plattformkosten über fünf Jahre um mehr als 80 Prozent, erfüllen die strengen Vorgaben von EU Data Act und DORA und behalten die volle Souveränität über ihre Infrastruktur.

Häufig gestellte Fragen (FAQ) zu Google Anthos und Multi-Cloud-Kubernetes