Ingress para el balanceo de cargas de HTTP(S) externo

En esta página, se explica cómo funciona Ingress para el balanceo de cargas de HTTP(S) externo 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 el balanceo de cargas de HTTP(S).

Descripción general

El balanceador de cargas de HTTP(S) externo de Google Cloud es un balanceador de cargas distribuido en todo el mundo que permite exponer las aplicaciones en Internet de manera pública. Se implementa en los puntos de presencia (PoP) de Google a nivel mundial y proporciona a los usuarios conexiones HTTP(S) con baja latencia. El enrutamiento Anycast se usa para las IP del balanceador de cargas, lo que permite que el enrutamiento de Internet determine la ruta de menor costo al balanceador de cargas de Google más cercano.

GKE Ingress implementa el balanceador de cargas de HTTP(S) externo a fin de proporcionar balanceo de cargas global de forma nativa para los pods como backends.

Compatibilidad con funciones de Google Cloud

Puedes usar un BackendConfig para configurar un balanceador de cargas de HTTP(S) externo a fin de usar funciones como las siguientes:

BackendConfig es un recurso personalizado que contiene información de configuración para las funciones de Google Cloud.

Compatibilidad con WebSocket

Con el balanceo de cargas de HTTP(S) externo, 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 HTTP(S) 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 más información, consulta la sección sobre cómo configurar un servicio de backend con un Ingress.

Direcciones IP estáticas para el balanceador de cargas HTTP(S)

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.

Si deseas que una dirección IP permanente permanezca igual cuando borres el Ingress y crees uno nuevo, debes reservar una dirección IP externa y estática global. Luego, en el manifiesto de Ingress, incluye una anotación que indique el nombre de la dirección IP estática que reservaste.

Por ejemplo, supongamos que reservaste una dirección IP externa estática global llamada my-static-address. En tu manifiesto de Ingress, debes incluir una anotación kubernetes.io/ingress.global-static-ip-name, como se muestra aquí:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: my-static-address

Si deseas obtener más información sobre cómo crear una dirección IP externa y estática para un Ingress, consulta la página Configura una dirección IP estática.

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. El balanceador de cargas 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.

Puedes usar certificados SSL administrados por Google (Beta) o certificados que administres tú. Para obtener más información sobre cómo crear un Ingress que use certificados administrados por Google, consulta Usa certificados SSL administrados por Google (Beta).

Para proporcionar un balanceador de cargas de HTTP(S) con un certificado y una clave que hayas creado tú, crea un objeto secreto 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/v1beta1
kind: Ingress
metadata:
  name: my-ingress-2
spec:
  tls:
  - secretName: secret-name
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: service-name
          servicePort: 60000

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 HTTP(S) con Ingress.

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/v1beta1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: secret-name
  ...

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 HTTP(S) 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.

En el manifiesto del servicio siguiente, se especifican 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.

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

La anotación cloud.google.com/app-protocols tiene el mismo propósito que la anotación service.alpha.kubernetes.io/app-protocols anterior. Los nombres de anotaciones antiguos y los nuevos pueden coexistir, como se muestra en el manifiesto de servicio siguiente. Cuando ambas anotaciones aparecen en el mismo manifiesto del Service, service.alpha.kubernetes.io/app-protocols tiene prioridad.

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

Próximos pasos