Esta arquitectura de referencia proporciona una solución de alta disponibilidad y escalable que usa Cloud Service Mesh y puertas de enlace de Envoy para gestionar el tráfico de red de las aplicaciones de Windows que se ejecutan en Google Kubernetes Engine (GKE). En él se explica cómo gestionar ese tráfico de red mediante un servicio que puede enrutar el tráfico a los pods y a un proxy compatible con xDS de código abierto. Usar una arquitectura como esta puede ayudar a reducir los costes y mejorar la gestión de la red.
Este documento está dirigido a arquitectos de la nube, administradores de redes y profesionales de TI responsables de diseñar y gestionar aplicaciones de Windows que se ejecutan en GKE.
Arquitectura
En el siguiente diagrama se muestra una arquitectura para gestionar la red de aplicaciones de Windows que se ejecutan en GKE mediante Cloud Service Mesh y pasarelas de Envoy:
La arquitectura incluye los siguientes componentes:
- Un clúster de GKE regional con grupos de nodos de Windows y Linux.
- Dos aplicaciones de Windows que se ejecutan en dos pods de GKE independientes.
- Cada aplicación se expone mediante un servicio de Kubernetes de tipo
ClusterIP
y un grupo de endpoints de red (NEG).
- Cada aplicación se expone mediante un servicio de Kubernetes de tipo
- Cloud Service Mesh crea y gestiona las rutas de tráfico a los NEGs de cada pod de GKE. Cada ruta se asigna a un
scope
específico. Estescope
identifica de forma única una pasarela de entrada de Cloud Service Mesh. - Rutas HTTP que se asignan a los servicios de backend de Cloud Service Mesh.
- Pods de contenedor Envoy que actúan como una puerta de enlace de Envoy al clúster de GKE.
- Pasarelas Envoy que se ejecutan en nodos Linux. Las pasarelas están configuradas para dirigir el tráfico a las aplicaciones de Windows a través de los servicios que corresponden a esas aplicaciones. Envoy se configura para usar el parámetro
scope
para cargar los detalles de configuración de los servicios de Cloud Service Mesh pertinentes. - Un balanceador de carga de aplicación interno que termina el tráfico SSL y dirige todo el tráfico entrante externo a las puertas de enlace de Envoy.
Productos usados
Esta arquitectura de referencia usa los siguientes productos de Google Cloud y de terceros:
Google Cloud productos
- Cloud Load Balancing: una cartera de balanceadores de carga de alto rendimiento, escalables, globales y regionales.
- Google Kubernetes Engine (GKE): un servicio de Kubernetes que puedes usar para desplegar y operar aplicaciones en contenedores a gran escala con la infraestructura de Google.
- Cloud Service Mesh: un conjunto de herramientas que te ayuda a monitorizar y gestionar una malla de servicios fiable on‐premise o en Google Cloud.
Productos de terceros
- Envoy Gateway: gestiona un proxy de Envoy como una pasarela de aplicaciones independiente o basada en Kubernetes.
- API Gateway: un proyecto oficial de Kubernetes centrado en el enrutamiento de las capas 4 y 7 en Kubernetes.
Caso práctico
El principal caso práctico de esta arquitectura de referencia es gestionar el tráfico de red de las aplicaciones de Windows que se ejecutan en GKE. Esta arquitectura ofrece las siguientes ventajas:
Gestión de redes simplificada: Cloud Service Mesh y las pasarelas de Envoy proporcionan una gestión de redes simplificada a través de un plano de control centralizado que gestiona el tráfico de red a las aplicaciones. Estas aplicaciones pueden ser de Linux o de Windows y se ejecutan en GKE o Compute Engine. Con este esquema de gestión de redes simplificado, no es necesario realizar configuraciones manuales.
Mayor escalabilidad y disponibilidad: para satisfacer tus necesidades cambiantes, usa Cloud Service Mesh y las pasarelas de Envoy para escalar tus aplicaciones Linux y Windows. También puedes usar las pasarelas Envoy para proporcionar alta disponibilidad a tus aplicaciones balanceando la carga del tráfico entre varios pods.
Seguridad mejorada: usa las pasarelas Envoy para añadir funciones de seguridad a tus aplicaciones Linux y Windows, como la terminación SSL, la autenticación y la limitación de frecuencia.
Costes reducidos: tanto Cloud Service Mesh como las pasarelas de Envoy pueden ayudar a reducir los costes de gestión del tráfico de red de las aplicaciones Linux y Windows.
Factores del diseño
En esta sección se ofrecen directrices para ayudarte a desarrollar una arquitectura que cumpla tus requisitos específicos de seguridad, fiabilidad, coste y eficiencia.
Seguridad
- Redes seguras: la arquitectura usa un balanceador de carga de aplicaciones interno para cifrar el tráfico entrante a los contenedores de Windows. El cifrado en tránsito ayuda a evitar las filtraciones de datos.
- Contenedores de Windows: los contenedores de Windows ayudan a proporcionar un entorno seguro y aislado para las aplicaciones en contenedores.
Fiabilidad
- Balanceo de carga: la arquitectura usa varias capas de Cloud Load Balancing para distribuir el tráfico entre las pasarelas de Envoy y los contenedores de Windows.
- Tolerancia a fallos: esta arquitectura es tolerante a fallos y no tiene ningún punto único de fallo. Este diseño ayuda a garantizar que siempre esté disponible, aunque falle uno o varios de los componentes.
- Autoescalado: la arquitectura usa el autoescalado para escalar automáticamente el número de gateways de Envoy y de contenedores de Windows en función de la carga. El autoescalado ayuda a asegurar que las pasarelas y las aplicaciones puedan gestionar los picos de tráfico sin experimentar problemas de rendimiento.
- Monitorización: la arquitectura usa Google Cloud Managed Service para Prometheus y Cloud Operations para monitorizar el estado de las pasarelas Envoy y los contenedores de Windows. La monitorización te ayuda a identificar problemas con antelación y, posiblemente, a evitar que afecten a tus aplicaciones.
Optimización de costes
- Elige los tipos de instancia adecuados para tus cargas de trabajo: ten en cuenta los siguientes factores a la hora de elegir los tipos de instancia:
- El número de vCPUs y la memoria que requieren tus aplicaciones
- La carga de tráfico prevista para tus aplicaciones
- La necesidad de que los usuarios tengan aplicaciones de alta disponibilidad
Usar el autoescalado: el autoescalado puede ayudarte a ahorrar dinero al escalar automáticamente tus cargas de trabajo de Windows vertical y horizontalmente.
El escalado vertical ajusta las solicitudes y los límites de los contenedores según el uso que hagan los clientes.
- Automatiza el escalado vertical con el autoescalado de pods vertical.
El escalado horizontal añade o elimina pods de Kubernetes para satisfacer la demanda.
- Automatiza el escalado horizontal con el autoescalado horizontal de pods.
Usa Cloud Service Mesh y las pasarelas de Envoy: Cloud Service Mesh y las pasarelas de Envoy pueden ayudarte a ahorrar dinero enrutando el tráfico de forma eficiente a tus aplicaciones Windows. Si usas un enrutamiento más eficiente, puedes reducir la cantidad de ancho de banda que debes comprar. También puede ayudar a mejorar el rendimiento de esas aplicaciones.
Usar redes de nube privada virtual (VPC) compartidas: las redes de nube privada virtual compartidas te permiten compartir una única VPC en varios proyectos. Compartir VPCs puede ayudarte a ahorrar dinero, ya que reduce el número de VPCs que tienes que crear y gestionar.
Eficiencia operativa
- Varios dominios con un solo balanceador de carga interno: la arquitectura usa balanceadores de carga de aplicaciones internos para derivar el tráfico SSL. Cada proxy HTTPS de destino puede admitir varios certificados SSL (hasta el máximo admitido) para gestionar varias aplicaciones con dominios diferentes.
- Infraestructura como código (IaC): para gestionar la infraestructura, la arquitectura se puede desplegar mediante IaC. La IaC ayuda a asegurar que tu infraestructura sea coherente y repetible.
Implementación
Para desplegar esta arquitectura, consulta Desplegar aplicaciones de Windows que se ejecutan en Kubernetes gestionado.
Siguientes pasos
- Consulta más información sobre los Google Cloud productos que se usan en esta guía de diseño:
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.
Colaboradores
Autor: Eitan Eibschutz | Asesor técnico de soluciones
Otros colaboradores:
- John Laham | Arquitecto de soluciones
- Kaslin Fields | Developers Advocate
- Maridi (Raju) Makaraju | Responsable técnico de asistencia
- Valavan Rajakumar | Arquitecto empresarial clave
- Victor Moreno | Product Manager, Cloud Networking