Comprender cómo funcionan las arquitecturas híbridas y multinube es fundamental para orquestar cargas de trabajo de manera eficiente, sin importar dónde se ejecuten. A continuación se desglosan los componentes clave que permiten conectar entornos on-premise con la nube de Google y con otras nubes públicas, manteniendo un único plano de visibilidad y administración.
¿Cómo funciona una arquitectura de referencia híbrida?
La arquitectura de referencia parte de dos columnas principales. Del lado izquierdo se encuentra Google Kubernetes Engine (GKE) en la nube, y del lado derecho su contraparte local: GKE On-Prem (Google Kubernetes Engine On-Premise) [01:00]. Aunque comparten el mismo modelo operativo una vez desplegados, los retos son distintos porque en el entorno local no se puede alcanzar el mismo nivel de automatización que ofrece la nube. Esto se enmarca en el modelo de responsabilidad compartida, donde el proveedor gestiona ciertas capas y el usuario se encarga de otras.
Entre ambos entornos aparece el marketplace de Google Cloud [01:42], un catálogo de aplicaciones especializadas y de industria ya habilitadas para correr como contenedor. Una vez que dispones de despliegues tanto on-prem como en la nube, puedes lanzar cualquiera de estas soluciones con un solo clic en el entorno que prefieras.
¿Qué opciones existen para la conectividad híbrida?
Por encima del marketplace se ubica el componente de interconnect [02:08]. Enviar tráfico entre el entorno local y la nube por internet público sería una mala idea, así que se recurre a mecanismos de conectividad híbrida:
- VPN tradicionales: se recomienda un esquema de alta disponibilidad con al menos dos túneles.
- Enlaces dedicados o parcialmente dedicados: ideales cuando las necesidades de ancho de banda son considerables.
- Enlaces parcialmente dedicados: permiten contratar solo el ancho de banda necesario e ir creciendo conforme la demanda lo requiera.
¿Qué papel juegan el repositorio de políticas y el GKE Hub?
El repositorio de políticas [03:12] suele vivir on-premise para que, si el enlace híbrido falla, se puedan seguir aplicando cambios en los clústeres locales. En la nube existe el config management operator, que vigila ese repositorio y aplica automáticamente cambios de configuración: creación de namespaces, deployments, políticas de red y de seguridad, todo gestionado con un modelo orientado a Git [03:52].
El GKE Hub [04:02] es el servicio donde registras tus clústeres para que formen parte de un único plano de visibilidad. En el entorno local se despliega el GKE Connect Agent, capaz de atravesar firewalls, NAT y proxies porque la comunicación siempre se origina desde el on-prem hacia la nube, nunca al revés. Solo se envían datos de telemetría y salud de los servicios; Google no accede a datos aplicativos.
¿Qué es Kubeception y cómo se estructura un despliegue on-premise?
Al desplegar GKE sobre un entorno virtualizado como vSphere o VMware [05:10], aparece un patrón conocido informalmente como Kubeception: un clúster de Kubernetes dentro de otro clúster de Kubernetes. La estructura se compone de varias piezas:
- Admin Workstation: imagen OVA preempaquetada desde la que se origina todo el despliegue; contiene herramientas de instalación, escalamiento y actualización [05:52].
- Jump host: puede ser tu laptop o desktop; administra el ciclo de vida de la admin workstation y soporta Linux, Windows y próximamente Mac [06:12].
- Admin cluster: administra el ciclo de vida de los clústeres de usuario, monitorea la salud del plano de control y ejecuta addons de sistema como seguridad, logging y monitoring [06:22].
- User clusters: ejecutan las cargas de trabajo reales: aplicaciones, APIs, jobs. Cada admin cluster soporta hasta diez user clusters con cien nodos cada uno [06:42].
- Load balancer: balancea tanto el tráfico del API server como el de las aplicaciones. El recomendado es Bontle LB, basado internamente en ZISO, un balanceador open source que Google usa a escala global. También se soportan balanceadores F5 y opciones propias con configuración manual [07:02].
¿Qué cambia en un esquema multinube?
El esquema multinube replica la misma lógica, pero introduce el GKE Management Service [07:45], desplegado dentro de la misma VPC que los clústeres que administra. Este servicio se comunica con las APIs de AWS o Azure para aprovisionar máquinas virtuales, discos de almacenamiento y balanceadores de carga de forma automática.
En Amazon Web Services, por ejemplo, se despliegan instancias EC2 y un network load balancer en distintas zonas de disponibilidad [08:10]. Para alta disponibilidad, el plano de control se distribuye en cada zona y los node pools se reparten donde corren las aplicaciones. El Connect Agent sigue reportando la salud del entorno de vuelta a Google Cloud.
Anthos engloba todo esto como una solución end to end para la entrega de aplicaciones modernas [08:52]. Incluye herramientas de experiencia de desarrollador como Cloud Code, soluciones de migración, pipelines de CI/CD, ejecución con Cloud Run y GKE, exposición de APIs con Apigee en su versión híbrida sobre Kubernetes, y servicios de operaciones para mejorar progresivamente la calidad de servicio.
El siguiente paso es comprender cómo la malla de servicio (service mesh) conecta y protege la comunicación entre microservicios en estos entornos distribuidos. Si ya has trabajado con despliegues híbridos o multinube, comparte tu experiencia y los retos que has enfrentado.
