ZeusK8s
Google GKE

Google GKE, gestionado igual que todo lo demás.

Añade clústeres GKE a la misma consola, flujo y definiciones de servicio que ya usas — sin tooling aparte, sin otro modelo mental.

Un flujo que además también hace Google.

Cada cloud que añades suele significar una herramienta nueva, un set nuevo de conceptos IAM y alguien que tiene que aprender ambos. El resultado es ingenieros saliendo del modo pánico y fingiendo que no estaban googling “cómo montar networking de GKE”. ZeusK8s hace que GKE se sienta idéntico a EKS y a un clúster en tu rack, porque el flujo de arriba es el mismo — solo cambia la ejecución de abajo.

Vincula un proyecto de Google Cloud, provisiona GKE, mapea workloads a service accounts de Google con Workload Identity y únelo al mismo tejido global que tus clústeres AWS. Un servicio que definiste una vez corre en todos.

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

Conecta un proyecto de Google Cloud

Vincula proyectos con una service account acotada. Zeus gestiona GKE, DNS (Cloud DNS) y Workload Identity desde ahí.

02

Provisiona GKE

Elige región, node pools y arquitectura. Networking e identidad se alinean con tus otros clústeres, así GKE se comporta como todo lo demás.

03

Mapea Workload Identity

Vincula pods a service accounts de Google sin exportar claves: el equivalente GCP de IRSA, configurado en la misma UI de identidad.

04

Únete al tejido global

Conecta GKE al mismo overlay cifrado que tus clústeres EKS y privados. Los servicios se alcanzan entre nubes por nombre, por IP real.

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.

Modelo de cuentas
Vinculación multi-proyecto con service accounts acotadas
Networking
Overlay cifrado; una red privada entre nubes
Identidad
GCP Workload Identity: auth de pods sin claves
DNS
Google Cloud DNS gestionado junto a Route 53
Definiciones de servicio
Idénticas a EKS: una plantilla, ambas nubes
Observabilidad
Mismas vistas en vivo de pods / logs / métricas
Straight answers

Questions you’d actually ask.

¿GKE es ciudadano de primera o una ocurrencia tardía?

De primera. Todo el valor de ZeusK8s es que EKS, GKE y clústeres privados comparten una sola UX. Un servicio que defines se despliega a GKE igual que a EKS: misma pantalla, mismos pasos.

¿Pueden hablarse clústeres EKS y GKE?

Sí, ese es el punto del tejido global. Sobre el overlay cifrado, un pod en GKE alcanza un servicio en EKS por nombre e IP real, sin NAT y sin exposición pública.

¿Gestiono Google IAM por separado?

No. Las identidades de Google por servicio se configuran en la misma UI de identidad que AWS IRSA, así que los permisos cloud viven junto al servicio que los necesita.