En esta página, se describe cómo implementar objetos Service en Google Kubernetes Engine (GKE). Usa esta página como guía para comprender mejor las facetas de las herramientas de redes de Service y las funciones de la red de Service que existen en GKE.
Descripción general de la herramientas de redes de Service
Las Herramientas de redes de Service son la publicación de aplicaciones de una manera que abstrae la propiedad subyacente, la implementación o el entorno de la aplicación que los clientes consumen. En su forma más simple, un Service es un extremo seguro, coherente y disponible a través del cual se accede a una aplicación.
Los clientes y las aplicaciones diferentes necesidades en relación con cómo pueden y deben comunicarse. Puede ser tan simple como exponer tu aplicación en el clúster de Kubernetes para que los Pods las consuman, o tan complicado como enrutar el tráfico a tu aplicación desde clientes de Internet en todo el mundo. GKE proporciona muchas formas de exponer aplicaciones como objetos Service que se adaptan a tus casos de uso únicos.
Elementos de un Service
Para exponer una aplicación a los clientes, se deben tener tres elementos clave de un Service:
Frontend: El frontend del balanceador de cargas define el alcance en el que los clientes pueden acceder y enviar tráfico al balanceador de cargas. Esta es la ubicación de la red que escucha el tráfico. Tiene una red, una región específica (o subred dentro de la red), una o más direcciones IP en la red, puertos, protocolos específicos y certificados TLS que se presentan para establecer conexiones seguras.
Enrutamiento y balanceo de cargas: El enrutamiento y el balanceo de cargas definen cómo procesas y enrutas el tráfico. Puedes enrutar tráfico a Services según parámetros como protocolos, encabezados HTTP y rutas HTTP. Según el balanceador de cargas que uses, es posible que equilibre el tráfico para proporcionar una latencia más baja y una resiliencia mayor a tus clientes.
Backends: los backends del balanceador de cargas se definen según el tipo de extremos, la plataforma de la aplicación y la integración del descubrimiento de servicios de backend. GKE usa la integración de descubrimiento de servicios para actualizar los backends del balanceador de cargas de forma dinámica a medida que crecen los extremos de GKE.
En el siguiente diagrama, se ilustran estos conceptos para el tráfico interno y externo:
En este diagrama, el balanceador de cargas de aplicaciones externo escucha el tráfico en la Internet pública a través de cientos de puntos de presencia de Google en todo el mundo. Este frontend global permite que el tráfico finalice en el perímetro, cerca de los clientes, antes de que balancee la carga del tráfico a sus backends en un centro de datos de Google.
El balanceador de cargas de aplicaciones interno escucha dentro del alcance de la red de VPC, lo que permite que las comunicaciones privadas se realicen de forma interna. Estas propiedades de los balanceadores de cargas los hacen adecuados para diferentes tipos de casos de uso de aplicaciones.
Información sobre el balanceo de cargas de GKE
Para exponer aplicaciones fuera de un clúster de GKE, GKE proporciona un controlador de Ingress de GKE integrado y un controlador de Service de GKE integrado que implementan balanceadores de cargas por los usuarios de GKE. Esto es lo mismo que la infraestructura de balanceo de cargas de VM, con la excepción de que su ciclo de vida está completamente automatizado y controlado por GKE. Los controladores de red de GKE proporcionan balanceo de cargas de IP de Pod nativo del contenedor mediante interfaces responsivas y de nivel superior que cumplen con los estándares del servicio y de la API de Ingress.
En el siguiente diagrama, se ilustra cómo los controladores de red de GKE automatizan la creación de balanceadores de cargas:
Como se muestra en el diagrama, un administrador de infraestructura o de app implementa un manifiesto declarativo en su clúster de GKE. Los controladores de Ingress y Service supervisan los recursos de herramientas de redes de GKE (como los objetos Ingress) y, además, implementan balanceadores de cargas (además de direccionamiento IP, reglas de firewall, etc.) según el manifiesto.
El controlador continúa administrando el balanceador de cargas y los backends según los cambios del entorno y el tráfico. Debido a esto, el balanceo de cargas de GKE se convierte en un balanceador de cargas dinámico y autosustentable con una interfaz orientada al desarrollador.
Elige el método para exponer tu aplicación
Cuando eliges un método para exponer tu aplicación en GKE, la infraestructura, el protocolo y la regionalidad de la aplicación del cliente son los factores principales que debes tener en cuenta. Con el conjunto de controladores de Ingress y Service de GKE, puedes exponer tus aplicaciones con cada uno de estos factores.
Si bien las siguientes secciones no abarcan todos los aspectos de las herramientas de redes de aplicaciones, trabajar en cada uno de los siguientes factores puede ayudarte a determinar qué soluciones son mejores para tus aplicaciones. La mayoría de los entornos de GKE alojan muchos tipos diferentes de aplicaciones, todos con requisitos únicos, por lo que es probable que uses más de uno en un clúster determinado.
Para obtener una comparación detallada de las capacidades de Ingress, consulta Configuración de Ingress.
Red del cliente
Una red de cliente hace referencia a la red desde la que los clientes de tu aplicación acceden a la aplicación. Esto influye en dónde debe escuchar el frontend de tu balanceador de cargas. Por ejemplo, los clientes podrían estar dentro del mismo clúster de GKE que la aplicación. En este caso, accederían a la aplicación desde la red del clúster, lo que les permite utilizar el balanceo de cargas de ClusterIP nativo de Kubernetes.
Los clientes también pueden ser clientes de red interna, que acceden a tu aplicación desde la nube privada virtual (VPC) o desde una red local a través de Cloud Interconnect.
Los clientes también pueden ser externos y acceder a tu aplicación desde toda la Internet pública. Cada tipo de red dicta una topología de balanceo de cargas diferente.
En GKE, puedes elegir entre balanceadores de cargas internos y externos. Interno se refiere a la red de VPC que es una red privada interna a la que no se puede acceder directamente desde Internet. Externo se refiere a la Internet pública. Los objetos Service de ClusterIP son internos de un solo clúster de GKE, por lo que su alcance es de una red incluso menor que la red de VPC.
En la siguiente tabla, se proporciona una descripción general de las soluciones disponibles para redes internas y externas.
| Tipo de red | Soluciones disponibles |
|---|---|
| Interno |
Service ClusterIP
Service NodePort Service LoadBalancer interno Ingress interno |
| Externa |
Service NodePort1
Service LoadBalancer externo Ingress externo Ingress de varios clústeres |
1 Los clústeres de GKE públicos proporcionan direcciones IP públicas y privadas a cada nodo de GKE, por lo que se puede acceder a los Services NodePort de manera interna o externa.
Protocolo
Un protocolo es el lenguaje que usan tus clientes para comunicarse con la aplicación. Las aplicaciones de voz, de videojuegos y de baja latencia suelen usar TCP o UDP directamente, y requieren balanceadores de cargas que tengan control detallado en la capa 4. Otras aplicaciones usan HTTP, HTTPS, gRPC o HTTP2, y requieren balanceadores de cargas con compatibilidad explícita con estos protocolos. Los requisitos de protocolo definen con más precisión qué tipos de métodos de exposición de aplicaciones son los más adecuados.
En GKE, puedes configurar balanceadores de cargas de capa 4, que enrutan el tráfico según la información de la red como el puerto y el protocolo, y los balanceadores de cargas de capa 7, que reconocen la información de la aplicación, como las sesiones del cliente. Cada balanceador de cargas diferente tiene una compatibilidad con protocolos específica, como se muestra en la siguiente tabla:
| Capas | Protocolos | Soluciones disponibles |
|---|---|---|
| L4 | TCP UDP |
Service ClusterIP
Service NodePort Service LoadBalancer interno Service LoadBalancer externo |
| L7 |
HTTP
HTTPS HTTP2 |
Ingress interno
Ingress externo Ingress de varios clústeres |
Regionalidad de la aplicación
La regionalidad de la aplicación se refiere al grado en el que la aplicación se distribuye en más de una región de Google Cloud o de un clúster de GKE. Alojar una sola instancia de una aplicación tiene requisitos diferentes que alojar instancias redundantes de una aplicación en dos clústeres de GKE independientes. Alojar una aplicación distribuida geográficamente en cinco clústeres de GKE a fin de colocar las cargas de trabajo más cerca del usuario final para ofrecer una latencia más baja requiere que el balanceador tenga un conocimiento incluso mayor de varios clústeres y regiones.
Puedes dividir la regionalidad de las soluciones de balanceo de cargas de GKE en dos áreas:
Alcance del backend (o alcance del clúster): Este alcance se refiere a si un balanceador de cargas puede enviar tráfico a backends en varios clústeres de GKE. Ingress de varios clústeres tiene la capacidad de exponer una sola dirección IP virtual que dirige el tráfico a los Pods desde diferentes clústeres y diferentes regiones.
Alcance del frontend: Este alcance se refiere a si una IP del balanceador de cargas escucha en una sola región o en varias regiones. Todos los balanceadores de cargas externos escuchan en Internet, que es inherentemente multirregional, pero algunos balanceadores de cargas internos solo escuchan dentro de una región.
En la siguiente tabla, se desglosan las soluciones de balanceo de cargas de GKE en estas dos dimensiones.
| Alcance del backend (alcance del clúster) |
Soluciones disponibles |
|---|---|
| Un solo clúster |
Service ClusterIP
Service NodePort Service LoadBalancer interno Service LoadBalancer externo Ingress interno Ingress externo |
| Varios clústeres | Entrada de varios clústeres |
| Alcance del frontend | Soluciones disponibles |
|---|---|
| Regional |
Service ClusterIP
Ingress interno |
| Global |
Service ClusterIP
Service NodePort Service LoadBalancer interno Service LoadBalancer externo Ingress externo Ingress de varios clústeres |
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 complementos o reemplazos viables de los balanceadores de cargas de GKE.
Ingress en el clúster
Ingress en el clúster se refiere a los controladores de Ingress de software que tienen sus proxies de Ingress alojados dentro del propio clúster de Kubernetes. Esto es diferente de los controladores de Ingress de GKE, que alojan y administran su infraestructura de balanceo de cargas por separado del clúster de Kubernetes. Por lo general, el operador del clúster autoimplementa y autoadministra estas soluciones de terceros. istio-ingressgateway y nginx-ingress son dos ejemplos de controladores de Ingress en el clúster de código abierto y de uso frecuente.
Los controladores de Ingress en el clúster suelen cumplir con la especificación de Ingress de Kubernetes y proporcionan diversas capacidades y facilidad de uso. Es probable que las soluciones de código abierto requieran una administración más cercana y un nivel más alto de experiencia técnica, pero pueden satisfacer tus necesidades si proporcionan funciones específicas que requieran tus aplicaciones. También hay un amplio ecosistema de soluciones de Ingress empresariales creadas en torno a la comunidad de código abierto que proporciona funciones avanzadas y asistencia para empresas.
Grupos de extremos de red (NEG) independientes
Los controladores de Ingress y Service de GKE proporcionan métodos automatizados, declarativos y nativos de Kubernetes para implementar Cloud Load Balancing. También hay casos de uso válidos a fin de implementar balanceadores de cargas de forma manual para backends de GKE, por ejemplo, tener un control directo y más detallado sobre el balanceador de cargas, o el balanceo de cargas entre los backends del contenedor y de la VM.
Los NEG independientes proporcionan esta capacidad mediante la actualización dinámica de las IPs de backend del Pod para un NEG, pero permiten que el frontend del balanceador de cargas se implemente de forma manual. Esto proporciona control máximo y directo del balanceador de cargas, a la vez que se conservan los backends dinámicos que controla el clúster de GKE.
Malla de servicios
Las mallas de servicios proporcionan balanceo de cargas del cliente a través de un plano de control centralizado. Traffic Director y Anthos Service Mesh permiten balancear las cargas del tráfico interno en distintos clústeres de GKE, en distintas regiones, y entre los contenedores y las VM. Esto difumina la línea entre el balanceo de cargas interno (tráfico de este a oeste) y la exposición de la aplicación (tráfico de norte a sur). Con la flexibilidad y el alcance de los planos de control de la malla de servicios modernos, es más probable que nunca tener el cliente y el servidor dentro del mismo alcance de la malla de servicios. Por lo general, las soluciones anteriores de objetos Service y de Ingress de GKE implementan balanceadores de cargas de proxy intermedio para los clientes que no tienen sus propios proxies de sidecar. Sin embargo, si un cliente y un servidor están en la misma malla, la exposición tradicional de la aplicación se puede controlar a través de la malla, en lugar del balanceo de cargas de proxy intermedio.
¿Qué sigue?
- Más información sobre las funciones de Ingress.
- Más información sobre Ingress externo.
- Más información sobre Ingress interno.
- Usa objetos Service LoadBalancer externos.
- Usa objetos Service LoadBalancer internos.