Ingress de GKE para balanceadores de cargas de aplicaciones

En esta página, se proporciona una descripción general de qué es Ingress para los balanceadores de cargas de aplicaciones externos y cómo funciona. Google Kubernetes Engine (GKE) proporciona un controlador Ingress integrado y administrado llamado GKE Ingress. Este controlador implementa recursos de Ingress como balanceadores de cargas de Google Cloud para cargas de trabajo HTTP(S) en GKE.

Descripción general

En GKE, un objeto Ingress define las reglas para enrutar el tráfico HTTP(S) a las aplicaciones que se ejecutan en un clúster. Un objeto Ingress se asocia con uno o más objetos Service, y cada uno está asociado con un conjunto de pods. Para obtener más información sobre cómo Ingress expone aplicaciones mediante el uso de Services, consulta Descripción general de herramientas de redes de Service.

Cuando creas un objeto Ingress, el controlador GKE Ingress crea un balanceador de cargas de HTTP(S) de Google Cloud y lo configura según la información en el Ingress y sus objetos Service asociados.

Para usar Ingress, debes tener habilitado el complemento de balanceo de cargas de HTTP. Los clústeres de GKE tienen habilitado el balanceo de cargas de HTTP de forma predeterminada; no debes inhabilitarlo.

Ingress para tráfico interno y externo

Los recursos de GKE Ingress se dividen en dos tipos:

Comportamiento del controlador de Ingress de GKE

Para los clústeres que ejecutan versiones 1.18 y posteriores de GKE, sin importar 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.

Para los clústeres que ejecutan versiones anteriores de GKE, el controlador de GKE procesa cualquier Ingress que no tenga la anotación kubernetes.io/ingress.class o tenga la anotación con el valor gce o gce-internal.

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.

No puedes usar el campo ingressClassName para especificar un Ingress de GKE. Debes usar la anotación kubernetes.io/ingress.class.

Características de los balanceadores de cargas de aplicaciones externos

Un balanceador de cargas de aplicaciones externo, configurado por Ingress, incluye las siguientes características:

  • Configuración flexible para Services Un Ingress define cómo llega el tráfico a tus Services y la forma en que se enruta a tu aplicación. Además, un Ingress puede proporcionar una sola dirección IP para varios Services en tu clúster.
  • Integración en los servicios de red de Google Cloud
  • Compatibilidad con múltiples certificados TLS Un Ingress puede especificar el uso de varios certificados TLS para la finalización de solicitudes.

Para obtener una lista completa, consulta Configuración de Ingress.

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 mediante grupos de extremos de red (NEG).

Cuando se usan grupos de instancias, los balanceadores de cargas de Compute Engine envían tráfico a IP de VM como backends. Cuando se ejecutan contenedores en VM, en las que los contenedores comparten la misma interfaz del host, se presentan algunas 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 la IP del Pod (que puede 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.

Con los NEG, el tráfico tiene balanceo de cargas desde el balanceador de cargas directamente a la IP del pod, en lugar de desviar la red de VM y las Herramientas de redes de kube-proxy. Además, las puertas de preparación de Pods se implementan para determinar el estado de los Pods desde la perspectiva del balanceador de cargas, y no solo los sondeos de estado de Kubernetes en el clúster. Esto mejora la estabilidad general del tráfico y hace que la infraestructura del balanceador de cargas reconozca los eventos del ciclo de vida, como el inicio de Pods, la pérdida de Pods o la pérdida de VM. Estas capacidades resuelven las limitaciones anteriores y dan como resultado una red más eficaz y estable.

El balanceo de cargas nativo del contenedor está habilitado de forma predeterminada para los objetos Service cuando se cumplen todas las condiciones a continuación:

  • Para Services creados en clústeres de GKE 1.17.6-gke.7 y versiones posteriores
  • Se usan clústeres nativos de la VPC
  • No se usa una VPC compartida
  • No se usa la política de red de GKE

En estas condiciones, los servicios se anotarán automáticamente con cloud.google.com/neg: '{"ingress": true}', lo que indica que se debe crear un NEG para duplicar las IP del Pod dentro del servicio. El NEG es lo que permite que los balanceadores de cargas de Compute Engine se comuniquen directamente con los Pods. Ten en cuenta que el controlador del servicio no anotará automáticamente los servicios existentes creados antes de GKE 1.17.6-gke.7.

Para los clústeres de GKE 1.17.6-gke.7 y anteriores en los que la anotación de NEG es automática, es posible inhabilitar los NEG y forzar al balanceador de cargas externo de Compute Engine a usar un grupo de instancias como backends si es necesario. Esto se puede hacer mediante la anotación explícita de los servicios con cloud.google.com/neg: '{"ingress": false}'. No es posible inhabilitar los NEGs con Ingress para balanceadores de cargas de aplicaciones internos.

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. La anotación se debe aplicar a los Services de la siguiente manera:

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

VPC compartida

Los recursos Ingress y MultiClusterIngress son compatibles con la VPC compartida, pero requieren una preparación adicional.

El controlador de Ingress se ejecuta en el plano de control de GKE y realiza llamadas a la API hacia Google Cloud a través de la cuenta de servicio de GKE del proyecto del clúster. De forma predeterminada, cuando un clúster ubicado en un proyecto de servicio de VPC compartida usa una red de VPC compartida, el controlador de Ingress no puede usar la cuenta de servicio de GKE del proyecto de servicio para crear y actualizar las reglas de firewall de permiso de entrada en el proyecto host.

Puedes otorgar los permisos de la cuenta de servicio de GKE del proyecto de servicio para crear y administrar las reglas de firewall de VPC en el proyecto host. Si otorgas estos permisos, GKE crea reglas de firewall de permiso de entrada para lo siguiente:

Aprovisiona de forma manual las reglas de firewall del proyecto host

Si tus políticas de seguridad solo permiten la administración de firewall del proyecto host, puedes aprovisionar estas reglas de firewall de forma manual. Cuando implementas Ingress en una VPC compartida, el evento de recursos de Ingress proporciona la regla de firewall específica que necesitas agregar para brindar acceso.

Para aprovisionar una regla de forma manual, haz lo siguiente:

  1. Ve el evento de recursos Ingress:

    kubectl describe ingress INGRESS_NAME

    Reemplaza INGRESS_NAME por el nombre de tu Ingress.

    Deberías ver un resultado similar al siguiente:

    Events:
Type    Reason  Age                    From                     Message
----    ------  ----                   ----                     -------
Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`

    La regla de firewall requerida y sugerida aparece en la columna Message.

  2. Copia y aplica las reglas de firewall sugeridas desde el proyecto host. La aplicación de la regla proporciona acceso a los Pod desde el balanceador de cargas y los verificadores de estado de Google Cloud.

Otorga permiso al controlador de Ingress de GKE para administrar las reglas de firewall del proyecto host

Si deseas que un clúster de GKE en un proyecto de servicio cree y administre los recursos de firewall en tu proyecto host, a la cuenta de servicio de GKE del proyecto de servicio se le debe otorgar los permisos de IAM adecuados mediante una de las siguientes estrategias:

  • Otorga a la cuenta de servicio de GKE del proyecto de servicio el rol de administrador de seguridad de Compute al proyecto host. En el siguiente ejemplo, se muestra esta estrategia.

  • Para un enfoque más detallado, crea una función de IAM personalizada que incluya solo los siguientes permisos: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update y compute.firewalls.delete. Otorga a la cuenta de servicio de GKE del proyecto de servicio esa función personalizada para el proyecto host.

Si tienes clústeres en más de un proyecto de servicio, debes elegir una de las estrategias y repetirla para la cuenta de servicio de GKE del proyecto de servicio.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

Reemplaza lo siguiente:

Servicios de backend múltiples

Cada balanceador de cargas de aplicaciones externo o balanceador de cargas de aplicaciones interno usa un solo mapa de URL, que hace referencia a uno o más servicios de backend. Un servicio de backend corresponde a cada servicio al que se hace referencia en el Ingress.

Por ejemplo, puedes configurar el balanceador de cargas para enrutar solicitudes a diferentes servicios de backend según la ruta de URL. Las solicitudes enviadas a your-store.example se pueden enrutar a un servicio de backend que muestra artículos a precio completo; las solicitudes enviadas a your-store.example/discounted se pueden enrutar a un servicio de backend que muestra artículos con descuento.

También puedes configurar el balanceador de cargas para enrutar solicitudes según el nombre de host. Las solicitudes enviadas a your-store.example pueden ir a un servicio de backend y las solicitudes enviadas a your-experimental-store.example pueden ir a otro.

En un clúster de GKE, puedes crear un objeto Ingress de Kubernetes para crear y configurar un balanceador de cargas HTTP(S). Un objeto Ingress debe estar asociado con uno o más objetos Service, cada uno de los cuales está asociado con un conjunto de pods.

A continuación, se detalla un manifiesto para un Ingress llamado my-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

Cuando creas el Ingress, el controlador de Ingress de GKE crea y configura un balanceador de cargas de aplicaciones externo o un balanceador de cargas de aplicaciones interno según la información en el Ingress y los servicios asociados. Además, se le asigna una dirección IP estable al balanceador de cargas que puedes asociar con un nombre de dominio.

En el ejemplo anterior, supón que asociaste la dirección IP del balanceador de cargas con el nombre de dominio your-store.example. Cuando un cliente envía una solicitud a your-store.example, la solicitud se enruta a un servicio de Kubernetes llamado my-products en el puerto 60000. Cuando un cliente envía una solicitud a your-store.example/discounted, la solicitud se enruta a un servicio de Kubernetes llamado my-discounted-products en el puerto 80.

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 para el Service my-products podría verse así:

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

En el manifiesto del Service, debes usar 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.

En el manifiesto de servicio, el campo selector indica que cualquier pod que tenga las etiquetas app: products y department: sales es miembro de este servicio.

Cuando llega una solicitud al Service en el puerto 60000, se enruta a uno de los pods miembros en el puerto TCP 50000.

Cada pod miembro debe tener un contenedor que escuche en el puerto TCP 50000.

El manifiesto para el servicio my-discounted-products podría verse así:

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

En el manifiesto de servicio, el campo selector indica que cualquier pod que tenga las etiquetas app: discounted-products y department: sales es miembro de este servicio.

Cuando llega una solicitud al servicio del puerto 80, se enruta a uno de los pods miembros en el puerto TCP 8080.

Cada pod miembro debe tener un contenedor que escuche en el puerto TCP 8080.

Backend predeterminado

Puedes especificar un backend predeterminado para tu Ingress proporcionando un campo spec.defaultBackend en tu manifiesto de Ingress. Esto controlará cualquier solicitud que no coincida con las rutas definidas en el campo rules. Por ejemplo, en el siguiente Ingress, toda solicitud que no coincida con /discounted se enviará a un servicio llamado my-products en el puerto 60001.

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

Si no especificas un backend predeterminado, GKE proporciona uno que muestra 404. Esto se crea como un servicio NodePort default-http-backend en el clúster en el espacio de nombres kube-system.

La respuesta HTTP 404 es similar a la siguiente:

response 404 (backend NotFound), service rules for the path non-existent

Para configurar Ingress de GKE con un backend predeterminado de cliente, consulta Ingress de GKE con backend predeterminado personalizado.

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.

Opciones para proporcionar certificados SSL

Puedes proporcionar certificados SSL a un balanceador de cargas de HTTP(S) a través de los siguientes métodos:

Certificados administrados por Google
Los certificados SSL administrados por Google se aprovisionan, implementan, renuevan y administran para tus dominios. Los certificados administrados no admiten dominios de comodín.
Certificados autoadministrados compartidos con Google Cloud
Puedes aprovisionar tu propio certificado SSL y crear un recurso de certificado en tu proyecto de Google Cloud. Luego, puedes enumerar el recurso de certificado en una anotación en un Ingress para crear un balanceador de cargas de HTTP(S) que use el certificado. Consulta las instrucciones para certificados ya compartidos a fin de obtener más información.
Certificados autoadministrados como recursos secretos
Puedes aprovisionar tu propio certificado SSL y crear un Secret para retenerlo. Luego, puedes hacer referencia al secreto en una especificación Ingress para crear un balanceador de cargas HTTP(S) que use el certificado. Para obtener más información, consulta las instrucciones para usar certificados en secretos.

Verificaciones de estado

Cuando expones uno o más objetos de servicio a través de un Ingress mediante el controlador de Ingress predeterminado, GKE crea un balanceador de cargas de aplicaciones clásico o un balanceador de cargas de aplicaciones interno. Ambos balanceadores de cargas admiten varios servicios de backend en un solo mapa de URL. Cada uno de los servicios de backend corresponde a un servicio de Kubernetes, y cada servicio de backend debe hacer referencia a una verificación de estado de Google Cloud. Esta verificación de estado es diferente de una prueba de funcionamiento o disponibilidad de Kubernetes porque la verificación de estado se implementa fuera del clúster.

GKE usa el siguiente procedimiento a fin de crear una verificación de estado para cada servicio de backend que corresponda a un Service de Kubernetes:

  • Si el Service hace referencia a una CRD de BackendConfig con información healthCheck, GKE usa esa información para crear la verificación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE admiten la creación de verificaciones de estado de esta manera.

  • Si el Service no hace referencia a una CRD de BackendConfig, haz lo siguiente:

    • GKE puede inferir algunos o todos los parámetros para una verificación de estado si los Pod de entrega usan una plantilla de Pod con un contenedor cuya prueba de disponibilidad tiene atributos que se pueden interpretar como parámetros de verificación de estado. Consulta Parámetros de una prueba de disponibilidad para obtener detalles sobre la implementación y Parámetros inferidos y predeterminados a fin de obtener una lista de atributos que se pueden usar con el fin de crear una verificación de estado. Solo el controlador de Ingress de GKE admite la inferencia de parámetros de una prueba de disponibilidad.

    • Si la plantilla de pod para los pods de entrega del Service no tiene un contenedor con un sondeo de preparación cuyos atributos se pueden interpretar como parámetros de una verificación de estado, se usan los valores predeterminados para crear la verificación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE pueden crear una verificación de estado solo con los valores predeterminados.

Parámetros inferidos y predeterminados

Los siguientes parámetros se usan cuando no especificas parámetros de verificación de estado para el Service correspondiente con una CRD de BackendConfig.

Parámetro de verificación de estado Valor predeterminado Valor inferible
Protocol HTTP si está presente en la anotación del servicio cloud.google.com/app-protocols
Ruta de la solicitud / si está presente en el spec del pod de entrega:
containers[].readinessProbe.httpGet.path
Encabezado de Host de solicitud Host: backend-ip-address si está presente en el spec del pod de entrega:
containers[].readinessProbe.httpGet.httpHeaders
Respuesta esperada HTTP 200 (OK) No se puede cambiar
HTTP 200 (OK)
Intervalo de verificación
  • para NEG zonales: 15 segundos
  • Para grupos de instancias: 60 segundos
 si está presente en el spec del pod de entrega:
  • Para NEG zonales:
    containers[].readinessProbe.periodSeconds
  • Para grupos de instancias:
    containers[].readinessProbe.periodSeconds + 60 seconds
Tiempo de espera de verificación 5 segundos si está presente en el spec del pod de entrega:
containers[].readinessProbe.timeoutSeconds
Umbral de buen estado 1 1
No se puede modificar.
Umbral de mal estado
  • Para NEG zonales: 2
  • Para grupos de instancias: 10
 Igual que la configuración predeterminada:
  • Para NEG zonales: 2
  • Para grupos de instancias: 10
Especificación de puerto
  • para NEG zonales: el port del Service
  • para grupos de instancias: la nodePort del Service
 Los sondeos de verificación de estado se envían al número de puerto especificado por spec.containers[].readinessProbe.httpGet.port, siempre que se cumplan todas las siguientes condiciones:
  • El número de puerto del sondeo de preparación debe coincidir con el containers[].spec.ports.containerPort del Pod de entrega
  • El containerPort del Pod de entrega coincide con el targetPort del Service
  • La especificación del puerto del backend del servicio de Ingress hace referencia a un puerto válido del spec.ports[] del servicio. Estas son las dos formas de hacerlo:
    • spec.rules[].http.paths[].backend.service.port.name en el Ingress coincide con spec.ports[].name definido en el Service correspondiente
    • spec.rules[].http.paths[].backend.service.port.number en el Ingress coincide con spec.ports[].port definido en el Service correspondiente
Dirección IP de destino
  • Para NEG zonales: la dirección IP del pod
  • Para grupos de instancias: la dirección IP del nodo
 Igual que la configuración predeterminada:
  • Para NEG zonales: la dirección IP del pod
  • Para grupos de instancias: la dirección IP del nodo

Parámetros de una prueba de disponibilidad

Cuando GKE crea la verificación de estado para el servicio de backend del servicio, GKE puede copiar ciertos parámetros de prueba de disponibilidad de un contenedor que usan los Pod de entrega del servicio. Esta opción solo es compatible con el controlador de Ingress de GKE.

Los atributos de sondeo de preparación admitidos que se pueden interpretar como parámetros de verificación de estado se enumeran junto con los valores predeterminados en Parámetros predeterminados e inferidos. Los valores predeterminados se usan para los atributos no especificados en el sondeo de preparación o si no especificas ninguno.

Si los pods de entrega para tu Service contienen varios contenedores, o si usas el controlador de Ingress de GKE Enterprise, debes usar una CRD de BackendConfig para definir los parámetros de verificación de estado. Para obtener más información, consulta Cuándo usar un CRD de BackendConfig en su lugar.

Cuándo usar CRD de BackendConfig en su lugar

En lugar de depender de parámetros de sondeos de preparación de pods, debes definir explícitamente los parámetros de verificación de estado para un servicio de backend mediante la creación de una CRD de BackendConfig para el Service en estas situaciones:

  • Si usas GKE Enterprise: El controlador de Ingress de GKE Enterprise no admite la obtención de parámetros de verificación de estado de los sondeos de preparación de los pods de entrega. Solo puede crear verificaciones de estado con parámetros implícitos o como se define en una CRD de BackendConfig.

  • Si tienes más de un contenedor en los Pods de entrega: GKE no tiene una forma de seleccionar el sondeo de preparación de un contenedor específico desde el cual inferir los parámetros de verificación de estado. Debido a que cada contenedor puede tener su propio sondeo de preparación, y debido a que un sondeo de preparación no es un parámetro obligatorio para un contenedor, debes definir la verificación de estado del servicio de backend correspondiente mediante una referencia a BackendConfig en el Service correspondiente.

  • Si necesitas control sobre el puerto usado para las verificaciones de estado del balanceador de cargas: GKE solo usa la containers[].readinessProbe.httpGet.port del sondeo de preparación para la verificación de estado del servicio de backend cuando ese puerto coincide con el puerto de servicio para el Service al que se hace referencia en el spec.rules[].http.paths[].backend.servicePort de Ingress.

Parámetros de una CRD de BackendConfig

Puedes especificar los parámetros de verificación de estado del servicio de backend con el parámetro healthCheck de una BackendConfig CRD al que hace referencia el Service correspondiente. Esto te brinda más flexibilidad y control sobre las verificaciones de estado para un balanceador de cargas de aplicaciones clásico o un balanceador de cargas de aplicaciones interno creado por un Ingress. Consulta Configuración de Ingress para conocer la compatibilidad con la versión de GKE.

Este CRD de BackendConfig de ejemplo define el protocolo de verificación de estado (tipo), una ruta de solicitud, un puerto y un intervalo de verificación en su atributo spec.healthCheck:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

Para configurar todos los campos disponibles cuando configuras una verificación de estado BackendConfig, usa el ejemplo de configuración de verificación de estado personalizada.

Para configurar Ingress de GKE con una verificación de estado HTTP personalizada, consulta Ingress de GKE con verificación de estado HTTP personalizada.

Usa varios certificados TLS

Supongamos que quieres usar un balanceador de cargas de HTTP(S) para entregar contenido de dos nombres de host: your-store.example y your-experimental-store.example. Además, quieres que el balanceador de cargas use un certificado con your-store.example y uno diferente con your-experimental-store.example.

Puedes hacerlo mediante la especificación de varios certificados en un manifiesto de Ingress. El balanceador de cargas elige un certificado si el nombre común (CN) del certificado coincide con el nombre de host usado en la solicitud. Para obtener información detallada sobre cómo configurar varios certificados, consulta Usa varios certificados SSL en el balanceo de cargas de HTTPS con Ingress.

El Service de Kubernetes en comparación con el Service de backend de Google Cloud

Un servicio de Kubernetes y un servicio de backend de Google Cloud son elementos diferentes. Existe una relación fuerte entre los dos, pero esta no tiene por qué ser de uno a uno. El controlador GKE Ingress crea un servicio de backend de Google Cloud para cada par (service.name, service.port) en un manifiesto de Ingress. Por lo tanto, es posible que un objeto Service de Kubernetes esté relacionado con varios servicios de backend de Google Cloud.

Limitaciones

  • En los clústeres que usan versiones anteriores a 1.16, la longitud total del espacio de nombres y el nombre de un Ingress no deben exceder los 40 caracteres. Si incumples esta pauta, puede que el controlador GKE Ingress actúe de forma anormal. Para obtener más información, consulta este problema de GitHub sobre los nombres largos.

  • 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 GKE Ingress, 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 de forma correcta en clústeres de 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 comentarios 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 una controlador 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 de Google Cloud.

  • Debes desactivar la TLS mutua en tu aplicación porque no es compatible con balanceadores de cargas de aplicaciones externos.

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.

Detalles de la implementación

  • El controlador Ingress realiza comprobaciones periódicas de los permisos de la cuenta de servicio mediante la recuperación de un recurso de prueba desde tu proyecto de Google Cloud. Verás esto como GET de la BackendService global (no existente) con el nombre k8s-ingress-svc-acct-permission-check-probe. Como este recurso, por lo general, no debería existir, la solicitud GET mostrará “no encontrado”. Esto es normal; el controlador verifica que la llamada a la API no se rechace debido a problemas de autorización. Si creas un BackendConfig con el mismo nombre, la GET se realizará correctamente en lugar de mostrar “no encontrado”.

Plantillas para la configuración de Ingress

¿Qué sigue?