ZeusK8s
Google GKE

Google GKE — genauso managed wie alles andere.

GKE-Cluster zur selben Console, demselben Workflow und denselben Service-Definitionen hinzufügen, die Sie schon nutzen — kein separates Tooling, kein separates Mental Model.

Ein Workflow, der zufällig auch Google kann.

Jede Cloud, die Sie hinzufügen, bedeutet normalerweise ein neues Tool, ein neues Set IAM-Konzepte und jemanden, der beides lernen muss. Das Ergebnis: Engineers überall verlassen den Panic Mode und tun so, als hätten sie nicht gerade „how to set up GKE networking“ gegoogelt. ZeusK8s lässt GKE sich identisch anfühlen wie EKS und wie ein Cluster in Ihrem Rack — weil der Workflow darüber derselbe ist. Nur die Execution darunter unterscheidet sich.

Google-Cloud-Projekt verknüpfen, GKE provisionieren, Workloads mit Workload Identity auf Google Service Accounts mappen und ins selbe globale Fabric joinen wie Ihre AWS-Cluster. Ein Service, den Sie einmal definiert haben, läuft auf allen.

Zeus · Clusters
Clusters
6 clusters · 3 providers
Live New Cluster
NameProviderRegionVersionNodesStatus
production-usAWS EKSus-east-11.306Ready
production-euGKEeurope-west31.304Ready
stagingAWS EKSus-west-21.29→1.30 ⚠3Ready
edge-apacGKEasia-east11.302Ready
HQ Denverk3sDenver, COv1.35.55Ready
prox-test01ProxmoxProvo, UTv1.34.1Provisioning
How it works

From zero to running.

01

Google-Cloud-Projekt verbinden

Projekte mit scoped Service Account verknüpfen. Zeus managed GKE, DNS (Cloud DNS) und Workload Identity von dort aus.

02

GKE provisionieren

Region, Node Pools und Architecture wählen. Networking und Identity matchen Ihre anderen Cluster, sodass GKE sich wie alles andere verhält.

03

Workload Identity mappen

Pods an Google Service Accounts binden ohne exportierte Keys: das GCP-Äquivalent von IRSA, konfiguriert in derselben Identity-UI.

04

Ins globale Fabric joinen

GKE mit demselben verschlüsselten Overlay verbinden wie Ihre EKS- und Private-Cluster. Services erreichen sich cloud-übergreifend per Name, per echter IP.

The specifics

Built by people who run this in production.

No hand-waving. Here’s what’s actually under the hood: the kind of detail you’d expect from a platform you’re going to trust with production.

Account-Modell
Multi-Project Linking mit scoped Service Accounts
Networking
Verschlüsseltes Overlay; ein privates Netzwerk über Clouds
Identity
GCP Workload Identity: keyless Pod Auth
DNS
Google Cloud DNS managed neben Route 53
Service-Definitionen
Identisch zu EKS: ein Template, beide Clouds
Observability
Dieselben Live-Pods-/Logs-/Metrics-Views
Straight answers

Questions you’d actually ask.

Ist GKE First-Class Citizen oder Afterthought?

First-class. Der gesamte Wert von ZeusK8s ist, dass EKS, GKE und Private Cluster eine UX teilen. Ein Service, den Sie definieren, deployt auf GKE genauso wie auf EKS: derselbe Screen, dieselben Schritte.

Können EKS- und GKE-Cluster miteinander sprechen?

Ja, das ist der Punkt des globalen Fabrics. Über das verschlüsselte Overlay erreicht ein Pod in GKE einen Service in EKS per Name und echter IP — ohne NAT und ohne öffentliche Exposure.

Manage ich Google IAM separat?

Nein. Per-Service Google Identities werden in derselben Identity-UI wie AWS IRSA konfiguriert, sodass Cloud-Permissions neben dem Service leben, der sie braucht.