Configura Ingress para el balanceo de cargas externo

En esta página, se muestra cómo configurar un balanceador de cargas HTTP(S) externo mediante la creación de un objeto Ingress de Kubernetes. Un objeto Ingress debe estar asociado con uno o más objetos de servicio, cada uno de ellos está asociado con un conjunto de pods.

Un objeto de servicio tiene una o más estructuras servicePort. Cada servicePort que es objetivo de un Ingress está asociado a un recurso de servicio de backend de Google Cloud.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

Asegúrate de que habilitaste la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Asegúrate de que instalaste el SDK de Cloud.

Establece la configuración de gcloud predeterminada mediante uno de los siguientes métodos:

Usa gcloud init si deseas ver una explicación sobre cómo configurar parámetros predeterminados.
Usa gcloud config para establecer el ID, la zona y la región del proyecto de manera individual.

Usa gcloud init

Si recibes el error One of [--zone, --region] must be supplied: Please specify location, completa esta sección.

Ejecuta gcloud init y sigue las instrucciones:
```
gcloud init
```
Si usas SSH en un servidor remoto, usa la marca --console-only para evitar que el comando abra un navegador:
```
gcloud init --console-only
```
Sigue las instrucciones a fin de autorizar a gcloud para que use tu cuenta de Google Cloud.
Crea una configuración nueva o selecciona una existente.
Elige un proyecto de Google Cloud.
Elige una zona predeterminada de Compute Engine.

Nota: Puedes anular esta configuración predeterminada en los comandos de gcloud mediante las marcas --project, --zone y --region.

Usa gcloud config

Establece tu ID del proyecto predeterminado:
```
gcloud config set project PROJECT_ID
```
Si trabajas con clústeres zonales, establece tu zona de procesamiento predeterminada:
```
gcloud config set compute/zone COMPUTE_ZONE
```
Si trabajas con clústeres regionales, establece tu región de procesamiento predeterminada:
```
gcloud config set compute/region COMPUTE_REGION
```
Actualiza gcloud a la versión más reciente:
```
gcloud components update
```

Nota: Puedes anular esta configuración predeterminada en los comandos de gcloud mediante las marcas --project, --zone y --region.

Debes tener un clúster de GKE en tu proyecto con el complemento de balanceo de cargas HTTP(S) habilitado:

Console

Ve al menú de Google Kubernetes Engine en Cloud Console.

Ir al menú Google Kubernetes Engine
Haz clic en el nombre del clúster que deseas modificar.
En Herramientas de redes, en el campo Balanceo de cargas de HTTP, haz clic en Editar el balanceo de cargas de HTTP.
Selecciona la casilla de verificación Habilitar el balanceo de cargas de HTTP.
Haz clic en Guardar cambios.

gcloud

gcloud container clusters update cluster-name --update-addons=HttpLoadBalancing=ENABLED

En este ejemplo, cluster-name es el nombre de tu clúster.

Servicios de backend múltiples

Un balanceador de cargas HTTP(S) externo proporciona una dirección IP estable que puedes usar para enrutar solicitudes a una variedad de servicios de backend.

En este ejercicio, configurarás un balanceador de cargas HTTP(S) externo para enrutar las solicitudes a diferentes servicios de backend según la ruta de URL. Las solicitudes que tienen la ruta / se enrutan a un servicio de backend y las que tienen la ruta /kube se enrutan a otro servicio de backend distinto.

Este es el panorama general de los pasos que se deben seguir en este ejercicio:

Crear una implementación y exponerla con un servicio llamado hello-world.
Crear una segunda implementación y exponerla con un servicio llamado hello-kubernetes.
Crea un recurso de Ingress que especifique las reglas para enrutar solicitudes a un servicio o a otro, según la ruta de URL en la solicitud. Cuando creas el recurso de Ingress, el controlador de Ingress de GKE crea y configura un balanceador de cargas HTTP(S) externo.
Prueba el balanceador de cargas HTTP(S) externo.

Crea un Deployment

Este es un manifiesto para la primera implementación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-world-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: world
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        department: world
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"
        env:
        - name: "PORT"
          value: "50000"

Copia el manifiesto en un archivo llamado hello-world-deployment.yaml y crea la implementación:

kubectl apply -f hello-world-deployment.yaml

Crea un Service

Este es un manifiesto para un servicio que expone tu primera implementación:

apiVersion: v1
kind: Service
metadata:
  name: hello-world
spec:
  type: NodePort
  selector:
    greeting: hello
    department: world
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

Para los fines de este ejercicio, a continuación se presentan los puntos importantes a fin de comprender este servicio:

Cualquier pod que tenga las etiquetas greeting: hello y department: world es miembro del servicio.
Cuando se envía una solicitud al servicio en el puerto TCP 60000, esta se reenvía a uno de los pods miembros en el puerto TCP 50000.

Copia el manifiesto en un archivo llamado hello-world-service.yaml y crea el Service:

kubectl apply -f hello-world-service.yaml

Crea un segundo Deployment

Este es el manifiesto de una segunda implementación:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-kubernetes-deployment
spec:
  selector:
    matchLabels:
      greeting: hello
      department: kubernetes
  replicas: 3
  template:
    metadata:
      labels:
        greeting: hello
        department: kubernetes
    spec:
      containers:
      - name: hello-again
        image: "gcr.io/google-samples/node-hello:1.0"
        env:
        - name: "PORT"
          value: "8080"

Copia el manifiesto en un archivo llamado hello-kubernetes-deployment.yaml y crea la implementación:

kubectl apply -f hello-kubernetes-deployment.yaml

Crea un segundo Service

Este es el manifiesto de un servicio que expone la segunda implementación:

apiVersion: v1
kind: Service
metadata:
  name: hello-kubernetes
spec:
  type: NodePort
  selector:
    greeting: hello
    department: kubernetes
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Para los fines de este ejercicio, a continuación se presentan los puntos importantes a fin de comprender este servicio:

Cualquier pod que tenga las etiquetas greeting: hello y department: kubernetes es miembro del servicio.
Cuando se envía una solicitud al puerto TCP 80 del servicio, se reenvía al puerto TCP 8080 de uno de los pods miembros.

Copia el manifiesto en un archivo llamado hello-kubernetes-service.yaml y crea el servicio:

kubectl apply -f hello-kubernetes-service.yaml

Crea un Ingress

Este es el manifiesto de un Ingress:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    # If the class annotation is not specified it defaults to "gce".
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: hello-world
          servicePort: 60000
      - path: /kube
        backend:
          serviceName: hello-kubernetes
          servicePort: 80

Para los fines de este ejercicio, aquí se presentan los puntos importantes a fin de comprender sobre este manifiesto de Ingress:

Hay dos clases de Ingress disponibles en GKE Ingress. La clase gce implementa un balanceador de cargas externo y la clase gce-internal implementa un balanceador de cargas interno. Recursos de Ingress no tienen una clase especificada predeterminada como gce.
El único carácter comodín admitido para el campo path de un Ingress es el carácter *. El carácter * debe estar después de una barra diagonal (/) y debe ser el último carácter del patrón. Por ejemplo, /*, /foo/* y /foo/bar/* son patrones válidos, pero *, /foo/bar* y /foo/*/bar no lo son.

Un patrón más específico tiene prioridad sobre uno menos específico. Si tienes /foo/* y /foo/bar/*, entonces se considera que /foo/bar/bat coincide con /foo/bar/*. Para obtener más información sobre las limitaciones de ruta y la coincidencia de patrones, consulta la documentación de mapas de URL.
El manifiesto de Ingress tiene dos pares (serviceName y servicePort). Cada uno (serviceName, servicePort) está asociado a un servicio de backend de Google Cloud.

Copia el manifiesto en un archivo llamado my-ingress.yaml y crea el Ingress:

kubectl apply -f my-ingress.yaml

Cuando crees el Ingress, el controlador de Ingress de GKE creará un balanceador de cargas HTTP(S) externo y lo configurará como se muestra a continuación:

Cuando un cliente envía una solicitud al balanceador de cargas con la ruta de URL /, la solicitud se reenvía al servicio hello-world en el puerto 60000.
Cuando un cliente envía una solicitud al balanceador de cargas mediante la ruta de URL /kube, la solicitud se reenvía al servicio hello-kubernetes en el puerto 80.

Espera unos cinco minutos para que se configure el balanceador de cargas.

Prueba el balanceador de cargas de HTTP(S) externo

Para probar el balanceador de cargas HTTP(S) externo, sigue estos pasos:

Ve el Ingress:

kubectl get ingress my-ingress --output yaml

El resultado muestra la dirección IP del balanceador de cargas HTTP(S) externo:

status:
  loadBalancer:
    ingress:
    - ip: 203.0.113.1

Prueba la ruta /:
```
curl load-balancer-ip/
```
Reemplaza load-balancer-ip por la dirección IP externa del balanceador de cargas.

El resultado muestra un mensaje Hello, world!:
```
Hello, world!
Version: 2.0.0
Hostname: ...
```
Prueba la ruta /kube:
```
curl load-balancer-ip/kube
```
El resultado muestra un mensaje Hello Kubernetes!:
```
Hello Kubernetes!
```

HTTPS entre el cliente y el balanceador de cargas

Un balanceador de cargas HTTP(S) externo actúa como un proxy entre tus clientes y tu aplicación. Si deseas aceptar solicitudes HTTPS de los 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. Para obtener más información, consulte:

Inhabilita HTTP

Puedes inhabilitar HTTP si deseas que todo el tráfico entre el cliente y el balanceador de cargas use HTTPS. Para obtener más información, consulta Inhabilita HTTP.

HTTPS entre el balanceador de cargas y la aplicación

Si tu aplicación que se ejecuta en un pod de GKE es capaz de recibir solicitudes HTTPS, puedes configurar el balanceador de cargas para que use HTTPS cuando reenvíe solicitudes a tu aplicación. Para obtener más información, consulta HTTPS (TLS) entre el balanceador de cargas y la aplicación.

HTTP/2 entre el cliente y el balanceador de cargas

Los clientes pueden usar HTTP/2 para enviar solicitudes al balanceador de cargas. No se requiere configuración.

HTTP/2 entre el balanceador de cargas y la aplicación

Si la aplicación, que se ejecuta en un pod de GKE, puede recibir solicitudes HTTP/2, puedes configurar el balanceador de cargas para que use HTTP/2 cuando reenvíe las solicitudes a la aplicación. Si necesitas más información, consulta Usa HTTP/2 para el balanceo de cargas con Ingress.

Grupos de extremos de red

Si tu clúster admite el balanceo de cargas nativo del contenedor, se recomienda usar grupos de extremos de red (NEG). Para los clústeres de GKE 1.17 y versiones posteriores, y en ciertas condiciones, el balanceo de cargas nativo del contenedor viene configurado como predeterminado y no requiere una anotación de Service cloud.google.com/neg: '{"ingress": true}' explícita.

Resumen de las anotaciones de Ingress externas

Anotaciones de Ingress

Anotación	Descripción
kubernetes.io/ingress.allow-http	Especifica si se debe permitir el tráfico HTTP entre el cliente y el balanceador de cargas de HTTP(S). Los valores posibles son “true” y “false”. El valor predeterminado es "true". Consulta Inhabilitar HTTP.
ingress.gcp.kubernetes.io/pre-shared-cert	Puedes subir certificados y claves a tu proyecto de Google Cloud. Usa esta anotación para hacer referencia a los certificados y claves. Consulta Usa varios certificados SSL en el balanceo de cargas de HTTP(S).
kubernetes.io/ingress.global-static-ip-name	Usa esta anotación para especificar que el balanceador de cargas debe usar la dirección IP externa y estática que creaste antes. Consulta Direcciones IP estáticas para el balanceador de cargas de HTTP(S).
networking.gke.io/v1beta1.FrontendConfig	Usa esta anotación para personalizar la configuración orientada al cliente del balanceador de cargas. Para obtener más información, consulta Funciones de Ingress.

Anotaciones de Service relacionadas con Ingress

Anotación	Descripción
service.alpha.kubernetes.io/app-protocols	Usa esta anotación a fin de configurar el protocolo para la comunicación entre el balanceador de cargas y la aplicación. Los protocolos posibles son HTTP, HTTPS y HTTP/2. Consulta HTTPS entre el balanceador de cargas y la aplicación y HTTP/2 para el balanceo de cargas con Ingress.
beta.cloud.google.com/backend-config	Usa esta anotación para configurar el servicio de backend asociado con un servicePort. Para obtener más información, consulta Funciones de Ingress.
cloud.google.com/neg	Usa esta anotación para especificar que el balanceador de cargas debe usar grupos de extremos de red. Consulta Usa el balanceo de cargas nativo del contenedor.

¿Qué sigue?

Lee una descripción general conceptual de Ingress para el balanceo de cargas de HTTP(S) en GKE.
Realiza el instructivo en Configura el balanceo de cargas de HTTP con Ingress.
Consulta una descripción general conceptual de los servicios en GKE.