ZeusK8s
Google GKE

Google GKE, géré comme tout le reste.

Ajoutez des clusters GKE à la même console, au même workflow et aux mêmes définitions de service que vous utilisez déjà — pas d'outillage séparé, pas de modèle mental séparé.

Un workflow qui se trouve aussi faire Google.

Chaque cloud que vous ajoutez signifie normalement un nouvel outil, un nouvel ensemble de concepts IAM, et quelqu'un qui doit apprendre les deux. Le résultat : des ingénieurs partout qui sortent du mode panique en prétendant qu'ils n'étaient pas en train de googler « comment configurer le réseau GKE ». ZeusK8s fait que GKE se sente identique à EKS et à un cluster dans votre rack, parce que le workflow au-dessus est le même — seule l'exécution en dessous diffère.

Liez un projet Google Cloud, provisionnez GKE, mappez les workloads vers des comptes de service Google avec Workload Identity, et joignez-le au même maillage global que vos clusters AWS. Un service que vous avez défini une fois tourne sur tous.

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

Connectez un projet Google Cloud

Liez des projets avec un compte de service scopé. Zeus gère GKE, le DNS (Cloud DNS) et Workload Identity à partir de là.

02

Provisionnez GKE

Choisissez région, node pools et architecture. Réseau et identité correspondent à vos autres clusters, pour que GKE se comporte comme tout le reste.

03

Mappez Workload Identity

Liez les pods à des comptes de service Google sans clés exportées : l'équivalent GCP d'IRSA, configuré dans la même UI d'identité.

04

Joignez le maillage global

Connectez GKE au même overlay chiffré que vos clusters EKS et privés. Les services s'atteignent entre clouds par nom, par IP réelle.

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.

Modèle de compte
Liaison multi-projet avec comptes de service scopés
Réseau
Overlay chiffré ; un réseau privé multi-cloud
Identité
GCP Workload Identity : auth de pods sans clé
DNS
Google Cloud DNS géré aux côtés de Route 53
Définitions de service
Identiques à EKS : un template, les deux clouds
Observabilité
Mêmes vues live pods / logs / métriques
Straight answers

Questions you’d actually ask.

GKE est-il un citoyen de première classe ou une réflexion après coup ?

Première classe. Toute la valeur de ZeusK8s est que EKS, GKE et les clusters privés partagent une UX. Un service que vous définissez se déploie sur GKE comme sur EKS : même écran, mêmes étapes.

Les clusters EKS et GKE peuvent-ils se parler ?

Oui, c'est le but du maillage global. Sur l'overlay chiffré, un pod dans GKE atteint un service dans EKS par nom et IP réelle, sans NAT et sans exposition publique.

Est-ce que je gère l'IAM Google à part ?

Non. Les identités Google par service sont configurées dans la même UI d'identité qu'IRSA AWS, pour que les permissions cloud vivent à côté du service qui en a besoin.