Ingress para balanceadores de carga de aplicación internos

En esta página se explica cómo funciona Ingress para los balanceadores de carga de aplicaciones internos en Google Kubernetes Engine (GKE). También puede consultar cómo configurar y usar Ingress para balanceadores de carga de aplicaciones internos.

En GKE, el balanceador de carga de aplicaciones interno es un balanceador de carga regional de capa 7 basado en proxy que te permite ejecutar y escalar tus servicios mediante una dirección IP de balanceo de carga interna. Los objetos Ingress de GKE admiten de forma nativa el balanceador de carga de aplicaciones interno mediante la creación de objetos Ingress en clústeres de GKE.

Para obtener información general sobre el uso de Ingress para el balanceo de carga en GKE, consulta Balanceo de carga HTTP(S) con Ingress.

Ventajas de usar Ingress para balanceadores de carga de aplicaciones internos

Usar Ingress de GKE con balanceadores de carga de aplicaciones internos ofrece las siguientes ventajas:

  • Un controlador Ingress de alta disponibilidad gestionado por GKE.
  • Balanceo de carga para la comunicación interna entre servicios.
  • Balanceo de carga nativo de contenedores con grupos de endpoints de red (NEG).
  • Enrutamiento de aplicaciones con compatibilidad con HTTP y HTTPS.
  • Comprobaciones del estado de alta fidelidad de Compute Engine para servicios resilientes.
  • Proxies basados en Envoy que se implementan bajo demanda para satisfacer las necesidades de capacidad de tráfico.

Compatibilidad con las funciones de Trusted Cloud

Ingress para balanceadores de carga de aplicaciones internos admite varias funciones adicionales.

Entorno de red necesario para los balanceadores de carga de aplicaciones internos

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

Un balanceador de carga de aplicación interno de una región usa la subred de solo proxy de esa región en tu red de VPC para asignar direcciones IP internas a cada proxy creado por Trusted Cloud.

De forma predeterminada, la dirección IP asignada a la regla de reenvío de un balanceador de carga procede del intervalo de la subred del nodo asignado por GKE, en lugar de la subred de solo proxy. También puede especificar manualmente una dirección IP para la regla de reenvío de cualquier subred al crearla.

En el siguiente diagrama se muestra un resumen del flujo de tráfico de un balanceador de carga de aplicaciones interno, tal como se describe en el párrafo anterior.

imagen

Así funciona el balanceador de carga de aplicaciones interno:

  1. Un cliente establece una conexión con la dirección IP y el puerto de la regla de reenvío del balanceador de carga.
  2. Un proxy recibe y finaliza la conexión de red del cliente.
  3. El proxy establece una conexión con el endpoint (Pod) adecuado de un NEG, según lo determinado por el mapa de URLs del balanceador de carga y los servicios de backend.

Cada proxy escucha en la dirección IP y el puerto especificados por la regla de reenvío del balanceador de carga correspondiente. La dirección IP de origen de cada paquete enviado desde un proxy a un endpoint es la dirección IP interna asignada a ese proxy desde la subred solo para proxies.

HTTPS (TLS) entre el balanceador de carga y tu aplicación

Un balanceador de carga de aplicaciones interno actúa como proxy entre tus clientes y tu aplicación. Los clientes pueden usar HTTP o HTTPS para comunicarse con el proxy del balanceador de carga. La conexión del proxy del balanceador de carga a tu aplicación usa HTTP de forma predeterminada. Sin embargo, si tu aplicación se ejecuta en un pod de GKE y puede recibir solicitudes HTTPS, puedes configurar el balanceador de carga para que use HTTPS cuando reenvíe solicitudes a tu aplicación.

Para configurar el protocolo que se usa entre el balanceador de carga y tu aplicación, usa la anotación cloud.google.com/app-protocols en el manifiesto de tu servicio.

El siguiente manifiesto de Service especifica dos puertos. La anotación especifica que un balanceador de carga de aplicaciones interno debe usar HTTP cuando se dirige al puerto 80 del servicio y HTTPS cuando se dirige al puerto 443 del servicio.

Debe usar el campo name del puerto en la anotación. No utilices otro campo, como targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

Siguientes pasos