En esta página se describe cómo puedes desplegar servicios en Google Kubernetes Engine (GKE). Usa esta página como guía para entender mejor las facetas de las redes de servicios y las funciones de redes de servicios que hay en GKE.
Información general sobre las redes de servicios
La conexión en red de servicios es la publicación de aplicaciones de forma que se abstraiga la propiedad, la implementación o el entorno subyacentes de la aplicación que consumen los clientes. En su forma más sencilla, un servicio es un endpoint seguro, coherente y disponible a través del cual se accede a una aplicación.
Los clientes y las aplicaciones tienen necesidades diferentes en cuanto a cómo pueden y deben comunicarse. Puede ser tan sencillo como exponer tu aplicación en el clúster de Kubernetes para que los pods la consuman o tan complicado como enrutar el tráfico a tu aplicación desde clientes de Internet de todo el mundo. GKE ofrece muchas formas de exponer aplicaciones como servicios que se ajusten a tus casos prácticos.
Elementos de un Servicio
Para exponer una aplicación a los clientes, se necesitan tres elementos clave de un servicio:
Frontend: el frontend del balanceador de carga define el ámbito en el que los clientes pueden acceder al balanceador de carga y enviarle tráfico. Es la ubicación de red que está escuchando el tráfico. Tiene una red, una región específica (o una subred dentro de la red), una o varias IPs en la red, puertos, protocolos específicos y certificados TLS que se presentan para establecer conexiones seguras.
Enrutamiento y balanceo de carga: definen cómo procesas y enrutas el tráfico. Puedes dirigir el tráfico a Servicios en función de parámetros como protocolos, encabezados HTTP y rutas HTTP. En función del balanceador de carga que utilices, puede que equilibre el tráfico para ofrecer una latencia más baja y una mayor resiliencia a tus clientes.
Backends: los backends del balanceador de carga se definen por el tipo de endpoints, la plataforma de aplicaciones y la integración de la detección de servicios de backend. GKE usa la integración del descubrimiento de servicios para actualizar los backends del balanceador de carga de forma dinámica a medida que los endpoints de GKE se activan y desactivan.
En el siguiente diagrama se ilustran estos conceptos para el tráfico interno y externo:
En este diagrama, el balanceador de carga de aplicación externo está atento al tráfico de Internet público a través de cientos de puntos de presencia de Google en todo el mundo. Este frontend global permite que el tráfico se termine en el perímetro, cerca de los clientes, antes de que se balancee la carga del tráfico a sus backends en un centro de datos de Google.
El balanceador de carga de aplicaciones interno escucha en el ámbito de tu red de VPC, lo que permite que las comunicaciones privadas se produzcan internamente. Estas propiedades de los balanceadores de carga los hacen adecuados para diferentes tipos de casos prácticos de aplicaciones.
Información sobre el balanceo de carga de GKE
Para exponer aplicaciones fuera de un clúster de GKE, GKE proporciona un controlador de Ingress de GKE y un controlador de servicio de GKE integrados que despliegan balanceadores de carga en nombre de los usuarios de GKE. Es igual que la infraestructura de balanceo de carga de VMs, pero su ciclo de vida está totalmente automatizado y controlado por GKE. Los controladores de red de GKE proporcionan balanceo de carga de IPs de pods nativo de contenedores mediante interfaces de nivel superior con opiniones que cumplen los estándares de las APIs Ingress y Service.
En el siguiente diagrama se muestra cómo los controladores de red de GKE automatizan la creación de balanceadores de carga:
Como se muestra en el diagrama, un administrador de infraestructura o de aplicaciones implementa un manifiesto declarativo en su clúster de GKE. Los controladores de entrada y de servicio monitorizan los recursos de red de GKE (como los objetos Ingress) e implementan balanceadores de carga (además de direcciones IP, reglas de cortafuegos, etc.) en función del manifiesto.
El controlador sigue gestionando el balanceador de carga y los backends en función de los cambios en el entorno y el tráfico. Por este motivo, el balanceo de carga de GKE se convierte en un balanceador de carga dinámico y autónomo con una interfaz orientada a los desarrolladores.
Elegir el método para exponer tu aplicación
Cuando elijas un método para exponer tu aplicación en GKE, los factores principales que debes tener en cuenta son la red del cliente, el protocolo y la regionalidad de la aplicación. Con el conjunto de controladores Ingress y Service de GKE, puedes exponer tus aplicaciones teniendo en cuenta cada uno de estos factores.
Aunque en las siguientes secciones no se abordan todos los aspectos de las redes de aplicaciones, analizar cada uno de los siguientes factores puede ayudarte a determinar qué soluciones son las más adecuadas para tus aplicaciones. La mayoría de los entornos de GKE alojan muchos tipos de aplicaciones diferentes, todas ellas con requisitos únicos, por lo que es probable que uses más de uno en cualquier clúster.
Para ver una comparación detallada de las funciones de Ingress, consulta Configuración de Ingress.
Red de clientes
Una red de cliente es la red desde la que los clientes de tu aplicación acceden a la aplicación. Esto influye en el lugar en el que debe escuchar el frontend de tu balanceador de carga. Por ejemplo, los clientes podrían estar en el mismo clúster de GKE que la aplicación. En este caso, accederían a tu aplicación desde la red del clúster, lo que les permitiría usar el balanceo de carga de ClusterIP nativo de Kubernetes.
Los clientes también pueden ser clientes de la red interna que accedan a tu aplicación desde la nube privada virtual (VPC) o desde una red on-premise a través de Cloud Interconnect.
Los clientes también pueden ser externos y acceder a tu aplicación a través de Internet público. Cada tipo de red determina una topología de balanceo de carga diferente.
En GKE, puedes elegir entre balanceadores de carga internos y externos. Interna hace referencia a la red de VPC, que es una red privada interna a la que no se puede acceder directamente desde Internet. Externo hace referencia a Internet público. Los servicios ClusterIP son internos de un solo clúster de GKE, por lo que se limitan a una red aún más pequeña que la red VPC.
En la siguiente tabla se ofrece un resumen de las soluciones disponibles para redes internas y externas.
| Tipo de red | Soluciones disponibles |
|---|---|
| Interno |
Servicio ClusterIP
Servicio NodePort Servicio de balanceador de carga interno Ingress interno |
| Externo |
Servicio NodePort1
Servicio LoadBalancer externo Entrada externa Entrada multiclúster |
Los clústeres de GKE que usan la marca --no-enable-private-nodes1 pueden tener nodos con direcciones IP públicas y privadas, por lo que se puede acceder a los servicios NodePort de forma interna y externa.
Protocolo
Un protocolo es el idioma que hablan tus clientes con la aplicación. Las aplicaciones de voz, juegos y baja latencia suelen usar TCP o UDP directamente, por lo que requieren balanceadores de carga que tengan un control granular en la capa 4. Otras aplicaciones usan HTTP, HTTPS, gRPC o HTTP/2, y requieren balanceadores de carga con compatibilidad explícita con estos protocolos. Los requisitos del protocolo definen qué tipos de métodos de exposición de aplicaciones son los más adecuados.
En GKE, puedes configurar balanceadores de carga de capa 4, que enrutan el tráfico en función de la información de la red, como el puerto y el protocolo, y balanceadores de carga de capa 7, que tienen en cuenta la información de la aplicación, como las sesiones de cliente. Cada balanceador de carga tiene compatibilidad con protocolos específicos, tal como se muestra en la siguiente tabla:
| Capas | Protocolos | Soluciones disponibles |
|---|---|---|
| L4 | TCP UDP |
Servicio ClusterIP
Servicio NodePort Servicio de balanceador de carga interno Servicio de balanceador de carga externo |
| L7 |
HTTP
HTTPS HTTP2 |
Entrada interna
Entrada externa Entrada de varios clústeres |
Regionalidad de las aplicaciones
La regionalidad de una aplicación hace referencia al grado en que se distribuye por más de una región o clúster de GKE. Alojar una sola instancia de una aplicación tiene requisitos diferentes a los de alojar instancias redundantes de una aplicación en dos clústeres de GKE independientes. Para alojar una aplicación distribuida geográficamente en cinco clústeres de GKE y colocar las cargas de trabajo más cerca del usuario final para reducir la latencia, el balanceador de carga necesita tener aún más en cuenta los aspectos de multi-clúster y multirregión.
Puedes dividir la regionalidad de las soluciones de balanceo de carga de GKE en dos áreas:
Ámbito de backend (o ámbito de clúster): se refiere a si un balanceador de carga puede enviar tráfico a backends de varios clústeres de GKE. Multi Cluster Ingress puede exponer una única dirección IP virtual que dirige el tráfico a pods de diferentes clústeres y regiones.
Ámbito del frontend: se refiere a si una IP de balanceador de carga escucha en una sola región o en varias. Todos los balanceadores de carga externos escuchan en Internet, que es multirregional por naturaleza, pero algunos balanceadores de carga internos solo escuchan en una región.
En la siguiente tabla se desglosan las soluciones de balanceo de carga de GKE en función de estas dos dimensiones.
| Permiso de backend (permiso de clúster) |
Soluciones disponibles |
|---|---|
| Un solo clúster |
Servicio ClusterIP
Servicio NodePort Servicio de balanceador de carga interno Servicio de balanceador de carga externo Ingress interno Ingress externo |
| Varios clústeres | Entrada multi-clúster |
| Ámbito del frontend | Soluciones disponibles |
|---|---|
| Regional |
Servicio ClusterIP
Ingress interno |
| Global |
Servicio ClusterIP
Servicio NodePort Servicio de balanceador de carga interno Servicio de balanceador de carga externo Entrada externa Entrada multiclúster |
Otras soluciones para la exposición de aplicaciones
Las soluciones anteriores no son las únicas disponibles para exponer aplicaciones. Las siguientes soluciones también pueden ser sustitutos o complementos viables de los balanceadores de carga de GKE.
Ingress en el clúster
Ingress en el clúster hace referencia a los controladores Ingress de software que tienen sus proxies Ingress alojados en el propio clúster de Kubernetes. Esto es diferente de los controladores de Ingress de GKE, que alojan y gestionan su infraestructura de balanceo de carga de forma independiente al clúster de Kubernetes. El operador del clúster suele implementar y gestionar estas soluciones de terceros por sí mismo. istio-ingressgateway y nginx-ingress son dos ejemplos de controladores de entrada de código abierto que se usan con frecuencia en los clústeres.
Los controladores Ingress del clúster suelen cumplir la especificación Ingress de Kubernetes y ofrecen diferentes funciones y facilidad de uso. Es probable que las soluciones de código abierto requieran una gestión más exhaustiva y un mayor nivel de conocimientos técnicos, pero pueden adaptarse a tus necesidades si ofrecen funciones específicas que requieren tus aplicaciones. También hay un amplio ecosistema de soluciones de Ingress empresariales creadas en torno a la comunidad de código abierto que ofrecen funciones avanzadas y asistencia empresarial.
Grupos de puntos de conexión de red (NEGs) independientes
Los controladores Ingress y Service de GKE proporcionan métodos automatizados, declarativos y nativos de Kubernetes para desplegar Cloud Load Balancing. También hay casos prácticos válidos para implementar balanceadores de carga manualmente para back-ends de GKE, como tener un control directo y más granular sobre el balanceador de carga o balancear la carga entre back-ends de contenedores y de máquinas virtuales.
Los NEGs independientes proporcionan esta función actualizando las IPs de backend de los pods de forma dinámica para un NEG, pero permiten que el frontend del balanceador de carga se implemente manualmente. De esta forma, se obtiene el control máximo y directo del balanceador de carga, al tiempo que se conservan los back-ends dinámicos controlados por el clúster de GKE.
Service Mesh
Las mallas de servicios proporcionan balanceo de carga del lado del cliente a través de un plano de control centralizado. Cloud Service Mesh y Cloud Service Mesh permiten equilibrar la carga del tráfico interno entre clústeres de GKE, entre regiones y también entre contenedores y VMs. De esta forma, se difumina la línea entre el balanceo de carga interno (tráfico este-oeste) y la exposición de aplicaciones (tráfico norte-sur). Gracias a la flexibilidad y al alcance de los planos de control de las mallas de servicios modernas, es más probable que nunca que tanto el cliente como el servidor se encuentren en el mismo ámbito de la malla de servicios. Las soluciones de GKE Ingress y Service anteriores suelen implementar balanceadores de carga de proxy intermedio para clientes que no tienen sus propios proxies sidecar. Sin embargo, si un cliente y un servidor están en la misma malla, la exposición de la aplicación se puede gestionar mediante la malla en lugar del balanceo de carga de proxy intermedio.
Siguientes pasos
- Más información sobre las funciones de Ingress
- Consulta más información sobre Ingress externo.
- Más información sobre Ingress interno
- Usa servicios de balanceadores de carga externos.
- Usa servicios LoadBalancer internos.