ZeusK8s
Multi-Cloud & Hybrid

AWS heute. GCP nächstes Quartal. Eigene Hardware für das Sensitive.

Die meisten Teams planen nicht Multi-Cloud — sie landen dort. Eine Acquisition, eine Compliance-Anforderung, ein Cost Spike. Zeus macht es zum Non-Event: Jeder Provider sieht aus der Console gleich aus, und der zweite Cluster kostet denselben operativen Effort wie der erste.

Eine zweite Cloud hinzuzufügen sollte nicht bedeuten, einen zweiten Stack zu adoptieren.

Das Problem mit Multi-Cloud sind nicht die Provider — es ist die operative Surface Area. Eine zweite Cloud bedeutet eine zweite CLI, eine zweite Console, ein zweites Set IAM-Conventions, ein zweites Networking-Modell und eine zweite Art, alles zu tun, was Sie auf der ersten schon können. Die meisten Teams, die „wir wollen Multi-Cloud sein“ sagen, rechnen die Betriebskosten nicht mit.

Zeus ändert die Gleichung. Jeder Cluster-Typ — EKS, GKE, k3s oder Proxmox — wird über denselben Fünf-Schritt-Wizard provisioniert, über dieselbe Service-Definition deployed und über dieselbe Surface betrieben. Einen GKE-Cluster zu einer EKS-Environment hinzuzufügen heißt nicht, GKE Operations zu lernen. Es heißt, einen Cluster hinzuzufügen.

Ihre Cluster laufen in Ihrem AWS-Account oder Ihrem GCP-Projekt — Zeus ist das Control Plane davor. Provider wechseln, hinzufügen oder einen ganz droppen. Die Infrastruktur ist Ihre; die Management Layer ist an keine Cloud locked.

Zeus · Deploy · api-gateway
Deploy to environment
One service definition · three clouds · identical manifests
service definition
api-gateway
EKS
production-us
Deployed
3/3 pods · same image
GKE
production-eu
Deployed
3/3 pods · same image
Proxmox
HQ Denver
Deployed
3/3 pods · same image
Only the image registry differs per cluster; Zeus resolves it.
Eine View

AWS, GCP und Ihre eigene Hardware in einer Liste.

Keine drei Consoles, keine drei Mental Models. Jeder Cluster — managed Cloud oder Bare Metal in Ihrem Rack — zeigt denselben Status, reagiert auf dieselben Actions und folgt demselben Workflow. Wenn die Infrastruktur darunter wechselt, ändert sich nicht, wie Ihr Team arbeitet.

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
Provider-Unterschiede

Was tatsächlich zwischen Providern abweicht — und wo.

Zeus versteckt Provider-Unterschiede nicht — es lokalisiert sie. Alles, was variiert, lebt an der Deploy-Naht, nicht in der Config, die Sie schreiben, oder im Workflow, dem Sie folgen.

Was gleich bleibt

Service-Definition, Environment Config, Build Pipeline, Deployment Tracking, Observability, IAM Setup, DNS und Networking Policy. Alles, was Sie day-to-day anfassen.

Was an der Naht variiert

Image-Registry-Endpoint, IAM-Identity-Mechanismus (IRSA vs. Workload Identity) und Node-Type-Naming. Zeus resolved alle drei automatisch zur Deploy-Zeit.

Was Sie nie schreiben

Provider-spezifisches YAML, if-AWS-then-Branching, per-Cloud Terraform Modules oder separate Helm Values Files. Eine Definition; Zeus handhabt die Translation.

Hybrid Cloud

Sensible Workloads on-prem behalten. Für Capacity in die Cloud bursten.

Manche Workloads können Ihr Gebäude nicht verlassen — PII, Financial Records, regulated Data. Andere brauchen nur Capacity, die günstiger zu kaufen als zu besitzen ist. Zeus betreibt beides in derselben Cluster-Liste, verbunden durch dasselbe verschlüsselte Overlay.

Proxmox- und k3s-Cluster auf Ihrer eigenen Hardware joinen dasselbe Fabric wie Ihre EKS- und GKE-Cluster. Ein Service on-prem kann einen Service in AWS aufrufen — verschlüsselt, per Name, ohne öffentliche Endpoints und ohne manuelles Wiring. Die Cluster sehen aus Service-Perspektive identisch aus, unabhängig davon, wo sie physisch laufen.

Regulated Data on-prem
Läuft auf Ihrer Hardware, verlässt Ihr Netzwerk nie. Joint das Mesh ohne öffentliche IP.
Burst Capacity in der Cloud
Auf EKS oder GKE aus-scalen, wenn Sie mehr Compute brauchen, ohne mehr Hardware zu kaufen.
Services sprechen über die Boundary
Cross-Cluster DNS und das verschlüsselte Overlay bedeuten: On-Prem- und Cloud-Services erreichen sich per Name.
Eine Operations Surface
Node Groups, Pod-Status, Logs und Upgrades sehen gleich aus — ob der Cluster in Ihrem Rack steht oder in AWS us-east-1.
Vendor Independence

Nicht an eine Cloud locked. Nicht an uns locked.

Ihre EKS-Cluster leben in Ihrem AWS-Account. Ihre GKE-Cluster leben in Ihrem GCP-Projekt. Zeus provisioniert und managed sie, besitzt sie aber nicht — entfernen Sie Zeus, und Ihre Cluster laufen weiter. Exportieren Sie Ihre kubeconfig und managen Sie mit jedem Tool, das Sie wollen.

Das bedeutet auch: Sie können Workloads zwischen Providern bewegen, wenn Pricing, Performance oder Compliance Sie dazu drängt. Die Service-Definition ändert sich nicht — der Target-Cluster schon. Clouds zu wechseln ist einen Cluster hinzufügen und einen Deploy bewegen, kein Migrationsprojekt.