Ingress para balanceadores de cargas de aplicaciones externos

En esta página, se explica cómo funciona Ingress para los balanceadores de cargas de aplicaciones externos en Google Kubernetes Engine (GKE). También puedes obtener información sobre cómo configurar y usar Ingress para el balanceo de cargas externo.

Si deseas obtener información general sobre cómo usar el balanceo de cargas en GKE, consulta Ingress para balanceadores de cargas de aplicaciones externos.

Las herramientas de redes de Google Kubernetes Engine (GKE) se basan en Cloud Load Balancing. Con Cloud Load Balancing, una sola dirección IP Anycast permite que el enrutamiento determine la ruta de menor costo al balanceador de cargas de Google Cloud más cercano.

Compatibilidad con funciones de Google Cloud

Puedes usar un BackendConfig para configurar un balanceador de cargas de aplicaciones externo para usar funciones como las siguientes:

BackendConfig es un recurso personalizado que contiene información de configuración para las funciones de Google Cloud. Para obtener más información sobre las funciones compatibles, consulta Configuración de Ingress.

Compatibilidad con WebSocket

Con los balanceadores de cargas de aplicaciones externos, el protocolo WebSocket funciona sin que tengas que configurarlo.

Si planeas usar el protocolo WebSocket, es posible que quieras usar un valor de tiempo de espera mayor que los 30 segundos predeterminados. Para el tráfico de WebSocket enviado mediante un balanceador de cargas de aplicaciones externo de Google Cloud, el tiempo de espera del servicio de backend se interpreta como la cantidad máxima de tiempo que una conexión de WebSocket puede permanecer abierta, ya sea que esté activa o no.

A fin de establecer el valor de tiempo de espera para un servicio de backend configurado a través de Ingress, debes crear un objeto BackendConfig y usar la anotación beta.cloud.google.com/backend-config en el manifiesto del Service.

Para obtener información sobre la configuración, consulta Tiempo de espera de la respuesta del backend.

Direcciones IP estáticas para balanceadores de cargas de HTTPS

Cuando creas un objeto Ingress, obtienes una dirección IP externa estable que los clientes pueden usar para acceder a tus Services y, a su vez, a tus contenedores en ejecución. La dirección IP es estable en el sentido de que dura toda la vida útil del objeto Ingress. Si borras tu Ingress y creas uno nuevo a partir del mismo archivo de manifiesto, no se garantiza que obtengas la misma dirección IP externa.

Configura HTTPS (TLS) entre el cliente y el balanceador de cargas

Un balanceador de cargas HTTP(S) actúa como un proxy entre tus clientes y tu aplicación. Si deseas aceptar solicitudes HTTPS de tus clientes, el balanceador de cargas debe contar con un certificado para que pueda demostrar su identidad a los clientes. También debe tener una clave privada para completar el protocolo de enlace HTTPS.

Cuando el balanceador de cargas acepta una solicitud HTTP(S) de un cliente, el tráfico entre el cliente y el balanceador de cargas se encripta mediante TLS. Sin embargo, el balanceador de cargas finaliza el cifrado TLS y reenvía la solicitud sin encriptación a la aplicación. Para obtener más información sobre cómo encriptar tráfico entre el balanceador de cargas y tu aplicación, consulta HTTPS entre el balanceador de cargas y tu aplicación.

Para proporcionar un balanceador de cargas HTTP(S) con un certificado y una clave que hayas creado tú, crea un objeto Secret de Kubernetes. El secreto contiene el certificado y la clave. Agrega el secreto al campo tls del manifiesto de Ingress, como se muestra en el siguiente ejemplo:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
spec:
  tls:
  - secretName: SECRET_NAME
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: SERVICE_NAME
            port:
              number: 60000

Este manifiesto incluye los siguientes valores:

  • SECRET_NAME: El nombre del Secret que creaste.
  • SERVICE_NAME: El nombre de tu servicio de backend.

Los cambios en los secretos se captan de manera periódica, así que, si modificas los datos dentro del secreto, esos cambios se aplicarán en el balanceador de cargas en un máximo de 10 minutos.

Para obtener más información, consulta Usa varios certificados SSL en el balanceo de cargas de HTTPS con Ingress.

Para proteger el Ingress encriptado con HTTPS en tus clústeres de GKE, consulta el ejemplo Ingress seguro.

Inhabilita HTTP

Si deseas que todo el tráfico entre el cliente y el balanceador de cargas HTTP(S) use HTTPS, puedes inhabilitar HTTP con la inclusión de la anotación kubernetes.io/ingress.allow-http en el manifiesto de Ingress. Establece el valor de la anotación en "false".

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

Este manifiesto incluye el SECRET_NAME que es el nombre del Secret que creaste.

Certificados ya compartidos para balanceadores de cargas

Como alternativa al uso de secretos de Kubernetes a fin de proporcionar certificados al balanceador de cargas para la finalización de HTTP(S), puedes usar certificados que hayas subido antes a tu proyecto de Google Cloud. Para obtener más información, consulta Usa certificados ya compartidos y Usa varios certificados SSL en el balanceo de cargas de HTTPS con Ingress.

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

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

Para configurar el protocolo que se usa entre el balanceador de cargas y tu aplicación, debes usar la anotación cloud.google.com/app-protocols en el manifiesto del Service. Este manifiesto de este Service debe incluir type: NodePort, a menos que uses el balanceo de cargas nativo del contenedor. Si usas el balanceo de cargas nativo del contenedor, usa type: ClusterIP.

El siguiente manifiesto del Service especifica dos puertos. La anotación indica que cuando un balanceador de cargas HTTP(S) se dirige al puerto 80 del servicio, se debe usar HTTP. Y cuando se dirige al puerto 443 del servicio, se debe usar HTTPS.

El manifiesto del Service debe incluir un valor name en la anotación del puerto. Solo puedes editar el puerto del Service si haces referencia a su name asignado, no a su valor targetPort.

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  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

¿Qué sigue?