Ingress de GKE para balanceadores de cargas de aplicaciones

Autopilot estándar

En esta página, se proporciona una descripción general de Ingress de Google Kubernetes Engine (GKE) para los balanceadores de cargas de aplicaciones y se explica cómo el controlador de Ingress aprovisiona balanceadores de cargas de aplicaciones para exponer aplicaciones al tráfico de HTTP(S) desde el interior o el exterior de tu red de VPC.

Esta página sirve como punto de entrada principal para comprender cómo funcionan los objetos Ingress de GKE. Para examinar con mayor detalle la arquitectura de redes subyacente, los patrones de enrutamiento del tráfico y las implementaciones de seguridad, consulta Acerca del enrutamiento y la seguridad de GKE Ingress.

En esta página, se supone que conoces los siguientes temas:

Esta página está dirigida a especialistas en redes que diseñan la red para su organización y que instalan, configuran y brindan asistencia técnica para el equipo de redes. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes del usuario de GKE.

Descripción general

GKE proporciona un controlador de Ingress integrado y administrado llamado GKE Ingress. Cuando creas un recurso Ingress en GKE, el controlador configura automáticamente un balanceador de cargas HTTPS que permite que el tráfico HTTP o HTTPS llegue a tus Services. El controlador de Ingress configura el balanceador de cargas y enruta el tráfico a las aplicaciones que se ejecutan en tu clúster según las reglas especificadas en tu manifiesto Ingress y los objetos Service asociados.

Un objeto Ingress se asocia con uno o más objetos Service, que, a su vez, se asocian con un conjunto de Pods. Para obtener más información sobre cómo Ingress expone aplicaciones con Services, consulta Descripción general de las redes de Service.

Para usar Ingress, debes habilitar el complemento de balanceo de cargas de HTTP. Los clústeres de GKE habilitan este complemento de forma predeterminada; no debes inhabilitarlo.

Diferencia entre el servicio de Kubernetes y el Google Cloud servicio de backend

El objeto Service de Kubernetes y el objeto Google Cloud servicio de backend cumplen propósitos similares, pero distintos. Si bien están muy relacionados, la relación no siempre es de uno a uno.

El controlador de Ingress de GKE actúa como traductor entre estos dos conceptos. Cuando creas un recurso Ingress, el controlador aprovisiona unGoogle Cloud balanceador de cargas. Luego, el controlador crea un servicio de backendGoogle Cloud dedicado para cada combinación única (service.name, service.port) a la que se hace referencia en el manifiesto Ingress.

Por ejemplo, un manifiesto de Ingress podría tener el mismo nombre de servicio de Kubernetes, pero apuntar a un service.port diferente para dos reglas de host o path separadas. En este caso, el controlador de Ingress de GKE crea dos servicios de backend separados. Por lo tanto, un objeto Service de Kubernetes puede estar relacionado con varios servicios de backend Google Cloud .

Ingress para tráfico interno y externo

Existen dos tipos de recursos de GKE Ingress:

Ingress para balanceadores de cargas de aplicaciones externos implementa el balanceador de cargas de aplicaciones clásico. Este balanceador de cargas orientado a Internet se implementa de forma global en la red perimetral de Google como un grupo administrado y escalable de recursos de balanceo de cargas. Obtén más información para configurar y usar Ingress para balanceadores de cargas de aplicaciones externos.
Ingress para balanceadores de cargas de aplicaciones internos implementa el balanceador de cargas de aplicaciones interno. Estos balanceadores de cargas de aplicaciones internos se basan en sistemas proxy de Envoy fuera de tu clúster de GKE, pero dentro de tu red de VPC. Obtén más información para configurar y usar Ingress para balanceadores de cargas de aplicaciones internos.

Importante: Cuando GKE crea un balanceador de cargas de aplicaciones externo o un balanceador de cargas de aplicaciones interno a través de un objeto Ingress, evita cambiar la configuración del balanceador de cargas con métodos fuera de GKE. Tus personalizaciones en la configuración para los objetos del balanceador de cargas (reglas de reenvío, proxies de destino, mapas de URL, servicios de backend y verificaciones de estado) se reemplazan cuando se aplican cambios de recursos nuevos, durante sincronizaciones periódicas o actualizaciones del clúster. Si necesitas administrar un balanceador de cargas de aplicaciones externo o un balanceador de cargas de aplicaciones interno fuera de GKE, usa el balanceo de cargas nativo del contenedor para grupos de extremos de red (NEG) independientes en su lugar.

Entorno de red obligatorio para los balanceadores de cargas de aplicaciones externos

El balanceador de cargas de aplicaciones externo es un sistema administrado y distribuido a nivel global que usa proxies de Google Front End (GFE) implementados en la red perimetral de Google. Estos proxies no se encuentran dentro de tu red de VPC. Cuando un cliente envía una solicitud a la dirección IP externa del balanceador de cargas, la red de Anycast de Google enruta la solicitud al GFE más cercano. El GFE finaliza el tráfico del usuario (incluido TLS, si está configurado) y, luego, reenvía el tráfico a los Pods de backend en tu clúster de GKE.

Para que este flujo funcione, el controlador de Ingress de GKE crea automáticamente reglas de firewall para permitir que el tráfico de los GFE y de los sistemas de verificación de estado deGoogle Cloudllegue a tus Pods. Estas reglas permiten el tráfico de los rangos de direcciones IP conocidos de Google (130.211.0.0/22 y 35.191.0.0/16).

A continuación, te mostramos cómo funciona el balanceador de cargas de aplicaciones externo:

Un cliente envía una solicitud a la dirección IP y al puerto de la regla de reenvío del balanceador de cargas.
La solicitud se enruta a un proxy de Google Front End (GFE) en la red global de Google. Este proxy finaliza la conexión de red del cliente.
El proxy de GFE reenvía la solicitud al extremo del Pod de backend adecuado en tu clúster de GKE, según lo determinan los servicios de backend y el mapa de URL del balanceador de cargas.

A diferencia del balanceador de cargas de aplicaciones interno, no es necesario configurar una subred de solo proxy en tu red de VPC para un balanceador de cargas de aplicaciones externo.

Entorno de red obligatorio para los balanceadores de cargas de aplicaciones internos

El balanceador de cargas de aplicaciones interno proporciona un grupo de proxies para tu red. Los proxies evalúan dónde debe ir cada solicitud HTTP(S) en función de factores, como el mapa de URL, la afinidad de sesión de BackendService y el modo de balanceo de cada NEG de backend.

El balanceador de cargas de aplicaciones interno de una región usa la subred de solo proxy para esa región en tu red de VPC a fin de asignar direcciones IP internas a cada proxy creado por Google Cloud.

De forma predeterminada, la dirección IP asignada a la regla de reenvío de un balanceador de cargas proviene del rango de subred del nodo asignado por GKE en lugar de la subred de solo proxy. También puedes especificar de forma manual una dirección IP para la regla de reenvío desde cualquier subred cuando crees la regla.

En el siguiente diagrama, se proporciona una descripción general del flujo de tráfico para un balanceador de cargas de aplicaciones interno, como se describe en el párrafo anterior.

imagen

A continuación, te mostramos cómo funciona el balanceador de cargas de aplicaciones interno:

Un cliente establece una conexión a la dirección IP y al puerto de la regla de reenvío del balanceador de cargas.
Un proxy recibe y finaliza la conexión de red del cliente.
El proxy establece una conexión con el extremo (Pod) adecuado en un NEG, según lo determinan los servicios de backend y la asignación de URL del balanceador de cargas.

Cada proxy escucha en la dirección IP y el puerto que especifica la regla de reenvío del balanceador de cargas correspondiente. La dirección IP de origen de cada paquete enviado desde un proxy a un extremo es la dirección IP interna que se asignó a ese proxy desde la subred de solo proxy.

Comportamiento del controlador de Ingress de GKE

Si el controlador de Ingress de GKE procesa un Ingress depende del valor de la anotación kubernetes.io/ingress.class:

Valor `kubernetes.io/ingress.class`	Valor `ingressClassName`	Comportamiento del controlador de Ingress de GKE
No establecido	No establecido	Procesa el manifiesto de Ingress y crea un balanceador de cargas de aplicaciones externo
No establecido	Cualquier valor	No se realiza ninguna acción. Un controlador de Ingress de terceros podría procesar el manifiesto de Ingress si se implementó uno.
`gce`	Cualquier valor. Este campo se ignora.	Procesa el manifiesto de Ingress y crea un balanceador de cargas de aplicaciones externo
`gce-internal`	Cualquier valor. Este campo se ignora.	Procesa el manifiesto de Ingress y crea un balanceador de cargas de aplicaciones externo.
Establece un valor distinto de `gce` o `gce-internal`.	Cualquier valor	No se realiza ninguna acción. Un controlador de Ingress de terceros podría procesar el manifiesto de Ingress si se implementó uno.

Baja de la anotación `kubernetes.io/ingress.class`

Aunque la anotación kubernetes.io/ingress.class está obsoleta en Kubernetes, GKE continúa usando esta anotación. Debes usar esta anotación para identificar la clase de Ingress.

Cuando apliques la configuración, es posible que aparezca una advertencia de baja. Esta advertencia indica que la anotación dejó de estar disponible y te indica que uses el campo ingressClassName en su lugar. Puedes ignorar la advertencia de forma segura porque GKE Ingress sigue dependiendo exclusivamente de la anotación kubernetes.io/ingress.class.

Asignaciones de recursos de Ingress a Compute Engine

El controlador GKE Ingress implementa y administra recursos del balanceador de cargas de Compute Engine según los recursos de Ingress que se implementan en el clúster. La asignación de los recursos de Compute Engine depende de la estructura del recurso de Ingress.

En el siguiente manifiesto, se describe un Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Este manifiesto de Ingress le indica a GKE que cree los siguientes recursos de Compute Engine:

Una regla de reenvío y una dirección IP
Reglas de firewall de Compute Engine que permiten el tráfico para las verificaciones de estado del balanceador de cargas y el tráfico de las aplicaciones de Google Front End o los proxies de Envoy.
Un proxy HTTP de destino y un proxy HTTPS de destino, si configuraste TLS.
Un mapa de URL que con una sola regla de host que hace referencia a un solo comparador de rutas. El comparador de rutas de acceso tiene dos reglas de ruta, una para /* y otra para /discounted. Cada regla de ruta se asigna a un servicio de backend único.
NEG que contienen una lista de direcciones IP de pod de cada Service como extremos. Estos se crean como resultado de los Services my-discounted-products y my-products.

Métodos de balanceo de cargas

GKE admite el balanceo de cargas nativo de contenedores y los grupos de instancias.

Balanceo de cargas nativo del contenedor

El balanceo de cargas nativo del contenedor es la práctica de realizar el balanceo de cargas directamente en extremos de Pod en GKE. El balanceo de cargas nativo del contenedor usa grupos de extremos de red (NEG) de tipo GCE_VM_IP_PORT, en los que los extremos son las direcciones IP de los Pods.

El balanceo de cargas nativo del contenedor siempre se usa para Ingress de GKE interno y es opcional para Ingress externo. El controlador de Ingress crea el balanceador de cargas, incluidas la dirección IP virtual, las reglas de reenvío, las verificaciones de estado y las reglas de firewall.

El balanceo de cargas nativo del contenedor admite la afinidad de sesión basada en Pods.

GKE habilita automáticamente el balanceo de cargas nativo del contenedor cuando se cumplen todas las siguientes condiciones:

El clúster es nativo de la VPC.
El clúster no usa una red de VPC compartida.
El clúster no usa la política de red de GKE.
El clúster tiene habilitado el complemento HttpLoadBalancing. Los clústeres de GKE tienen el complemento HttpLoadBalancing habilitado de forma predeterminada. No debes inhabilitarlo.

Cuando GKE habilita el balanceo de cargas nativo del contenedor, los Services se anotan automáticamente con cloud.google.com/neg: '{"ingress": true}'. Esta anotación activa la creación de un NEG que refleja las IPs de los Pods, lo que permite que los balanceadores de cargas de Compute Engine se comuniquen directamente con los Pods.

Para los clústeres en los que los NEG no son la configuración predeterminada, aún se recomienda usar el balanceo de cargas nativo del contenedor, pero se debe habilitar explícitamente para cada Service.

Para obtener más flexibilidad, también puedes crear NEG independientes. En este caso, eres responsable de crear y administrar todos los aspectos del balanceador de cargas.

Beneficios

Con el uso de NEG, el balanceo de cargas nativo del contenedor ofrece una red más estable y con mejor rendimiento:

Rendimiento de red mejorado: Sin el balanceo de cargas nativo del contenedor, el tráfico viaja a los grupos de instancias de nodo y, luego, depende de las reglas de iptables configuradas por kube-proxy para el enrutamiento al Pod de destino. Con el balanceo de cargas nativo del contenedor, el tráfico se balancea directamente a los Pods, lo que evita la necesidad de enrutar a través de la IP de la VM y las redes de kube-proxy en el nodo. Este flujo elimina los saltos de red adicionales y mejora la latencia y la capacidad de procesamiento.

Verificaciones de estado mejoradas: Se implementan puertas de preparación de Pods para determinar el estado de los Pods desde la perspectiva del balanceador de cargas, en lugar de depender únicamente de los sondeos de estado en el clúster. Esta función crítica hace que el balanceador de cargas reconozca los eventos del ciclo de vida del Pod (inicio, pérdida, etcétera) y mejora la estabilidad del tráfico. Para obtener más información sobre cómo se usan las puertas de preparación de pods para determinar el estado de los pods, consulta Preparación de pods.

Mayor visibilidad: Con el balanceo de cargas nativo del contenedor, tienes visibilidad de la latencia desde el balanceador de cargas de aplicaciones directamente hacia cada Pod. Como la latencia ya no se agrega a nivel de la IP del nodo, se facilita la solución de problemas de tus servicios a nivel del NEG.

Compatibilidad con Cloud Service Mesh: Se requiere el modelo de datos NEG para usar Cloud Service Mesh, el plano de control de tráfico completamente administrado de Google Cloudpara la malla de servicios.

Limitaciones de los balanceadores de cargas nativos del contenedor

Los balanceadores de cargas nativos de contenedores a través de Ingress en GKE tienen las siguientes limitaciones:

Los balanceadores de cargas nativos del contenedor no admiten balanceadores de cargas de red de transferencia externos.
No debes cambiar ni actualizar de forma manual la configuración del balanceador de cargas de aplicaciones que crea GKE. GKE reemplazará todos los cambios que realices.

Precios de los balanceadores de cargas nativos del contenedor

Se te cobrará por el balanceador de cargas de aplicaciones que aprovisiona el Ingress que creas en esta guía. Para obtener información sobre los precios del balanceador de cargas, consulta Balanceo de cargas y reglas de reenvío en la página de precios de VPC.

Grupos de instancias

Cuando se usan grupos de instancias, los balanceadores de cargas de Compute Engine envían tráfico a direcciones IP de VM como backends. Cuando se ejecutan contenedores en VMs, en las que los contenedores comparten la misma interfaz del host, se presentan las siguientes limitaciones:

Se generan dos saltos de balanceo de cargas: un salto del balanceador de cargas al NodePort de la VM y otro salto a través del enrutamiento de kube-proxy a las direcciones IP del Pod (que pueden residir en una VM diferente).
Los saltos adicionales agregan latencia y hacen que la ruta de tráfico sea más compleja.
El balanceador de cargas de Compute Engine no tiene visibilidad directa de los pods, lo que da como resultado un balanceo de tráfico que no es óptimo.
Los eventos de entorno, como la VM o la pérdida de pods, tienen más probabilidades de causar una pérdida de tráfico intermitente debido al salto de tráfico doble.

Ingress externo y clústeres basados en rutas

Si usas clústeres basados en rutas con Ingress externo, el controlador de Ingress de GKE no puede usar el balanceo de cargas nativo del contenedor con grupos de extremos de red (NEG) de GCE_VM_IP_PORT. En su lugar, el controlador de Ingress usa backends de grupos de instancias no administrados que incluyen todos los nodos en todos los grupos de nodos. Si los Services LoadBalancer también usan estos grupos de instancias no administrados, se pueden causar problemas relacionados con la limitación de un solo grupo de instancias con balanceo de cargas.

Algunos objetos Ingress externos más antiguos creados en clústeres nativos de la VPC pueden usar backends de grupos de instancias en los servicios de backend de cada balanceador de cargas de aplicaciones externo que crean. Esto no es relevante para Ingress interno porque los recursos de Ingress internos siempre usan NEG GCE_VM_IP_PORT y requieren clústeres nativos de la VPC.

Para aprender a solucionar errores 502 con Ingress externo, consulta Ingress externo produce errores HTTP 502.

Limitaciones del controlador de Ingress de GKE

GKE Ingress no admite certificados administrados por el Administrador de certificados. Para usar certificados administrados por Certificate Manager, usa la API de Gateway.
En los clústeres que usan NEG, el tiempo de conciliación de entrada puede verse afectado por la cantidad de recursos de entrada. Por ejemplo, un clúster con 20 entradas, cada uno con 20 backends de NEG distintos, puede dar como resultado una latencia de más de 30 minutos para que se concilie un cambio de entrada. Esto afecta a los clústeres regionales debido al aumento de la cantidad de NEG que se necesitan.
Se aplican cuotas para los mapas de URL.
Se aplican cuotas para los recursos de Compute Engine.
Si no usas NEG con el controlador de entrada de GKE, los clústeres de GKE tienen un límite de 1,000 nodos. Cuando los servicios se implementan con NEG, no hay límite de nodos de GKE. Los Services ajenos a NEG expuestos a través de Ingress no funcionan correctamente en clústeres que tienen más de 1,000 nodos.
A fin de que el controlador GKE Ingress use tus readinessProbes como verificaciones de estado, los pods para un Ingress deben existir en el momento de la creación de este. Si tus réplicas se escalan a 0, se aplicará la verificación de estado predeterminada. Para obtener más información, consulta este comentario de problemas de GitHub sobre las verificaciones de estado.
Los cambios en readinessProbe de un pod no afectan el Ingress después de que se crea.
Un balanceador de cargas de aplicaciones externo finaliza la TLS en ubicaciones distribuidas de manera global a fin de minimizar la latencia entre los clientes y el balanceador de cargas. Si necesitas control geográfico sobre la ubicación en la que se finaliza la TLS, debes usar unacontrolador de entrada personalizado expuesto a través de un servicio de GKE del tipo LoadBalancer en su lugar, y finaliza la TLS en backends ubicados en regiones adecuadas para tus necesidades.
No se admite la combinación de varios recursos Ingress en un solo balanceador de cargas Google Cloud .
Debes desactivar la TLS mutua en tu aplicación porque no es compatible con balanceadores de cargas de aplicaciones externos.
Ingress solo puede exponer los puertos HTTP 80 y 443 para su frontend.