GKE Ingress para balanceo de cargas HTTP(S)

En esta página se proporciona una descripción general del funcionamiento de Ingress para el balanceo de cargas HTTP(S). 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 a 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:

Características del balanceo de cargas de HTTP(S)

El balanceo de cargas de HTTP(S) configurado por Ingress incluye las características siguientes:

  • 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 Funciones 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 de forma automática 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 de servicios 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+ en los que la anotación de NEG es automática, es posible inhabilitar los NEG y forzar al balanceador de cargas 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}'.

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 las topologías de VPC compartida, pero requieren una preparación anticipada para trabajar. Los controladores de Ingress de GKE usan una cuenta de servicio de Google Cloud para implementar y administrar recursos de Google Cloud. Cuando un clúster de GKE reside en un proyecto de servicio de una VPC compartida, esta cuenta de servicio no tiene los derechos para administrar los recursos de red que posee el proyecto host. El controlador Ingress administra de forma activa las reglas de firewall para proporcionar acceso entre los balanceadores de cargas y los Pods, y también entre los verificadores de estado centralizados y los Pod.

Sin embargo, en una VPC compartida, el controlador de Ingress de GKE no tiene los derechos para administrar reglas de firewall. Puedes agregar derechos si aprovisionas reglas de firewall de forma manual desde el proyecto host o si proporcionas permiso al controlador de Ingress de GKE para administrar las reglas de firewall del proyecto host.

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

Un enfoque automatizado es proporcionar a la cuenta de servicio del controlador de Ingress de GKE los permisos para actualizar las reglas de firewall. Crea una función IAM personalizada que proporcione la capacidad de administrar reglas de firewall directamente y otorga esta función a la cuenta de servicio de Ingress de GKE.

  1. En tu proyecto host, otorga una función personalizada con los permisos compute.firewalls.* y compute.networks.updatePolicy a la cuenta de servicio de GKE del proyecto de servicio:

    gcloud iam roles create ROLE_NAME \
       --project PROJECT_ID \
       --title ROLE_TITLE \
       --description ROLE_DESCRIPTION \
       --permissions=compute.networks.updatePolicy,compute.firewalls.*\
       --stage GA
    

    Reemplaza lo siguiente:

    • ROLE_NAME: es el nombre de la función.
    • PROJECT_ID: el ID del proyecto host.
    • ROLE_TITLE: el título de la función que deseas crear.
    • ROLE_DESCRIPTION: la descripción de la función que deseas crear.
  2. Aplica esta función personalizada a la cuenta de servicio de Ingress de GKE:

    gcloud projects add-iam-policy-binding my-project \
       --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com  \
       --role=roles/gke-ingress-fw-management
    

    Reemplaza PROJECT_NUMBER con el número de proyecto de tu servicio.

Servicios de backend múltiples

Cada balanceador de cargas de HTTP(S) externo o 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/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Cuando creas el Ingress, el controlador de Ingress de GKE crea y configura un balanceador de cargas de HTTP(S) externo o interno según la información en el Ingress y los Services 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 si proporcionas un campo backend en el manifiesto de Ingress. Todas las solicitudes que no coincidan con las rutas del campo rules se enviarán al servicio y al puerto especificados en el campo backend. Por ejemplo, en el siguiente Ingress, toda solicitud que no coincida con / ni /discounted se enviará a un servicio llamado my-products en el puerto 60001.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-products
    servicePort: 60001
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

Si no especificas un backend predeterminado, GKE proporciona uno que muestra 404.

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. Conocer estas asignaciones de recursos te ayuda con la planificación, el diseño y la solución de problemas.

El manifiesto my-ingress que aparece en la sección Servicios de backend múltiples especifica un recurso Ingress externo con dos coincidencias de rutas de URL que hacen referencia a dos Services de Kubernetes diferentes. Estos son algunos de los recursos de Compute Engine creados en nombre de my-ingress:

  • 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. En el siguiente diagrama, se proporciona una descripción general de las asignaciones de recursos de Ingress a Compute Engine.

Diagrama de asignación de recursos de Ingress a Compute Engine

Opciones para proporcionar certificados SSL

Existen tres maneras de proporcionar certificados SSL a un balanceador de cargas de HTTP(S):

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 secreto 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 servicios a través de un Ingress con el controlador de Ingress predeterminado, GKE crea un balanceador de cargas de HTTP(S) externo de Google Cloud o un balanceador de cargas de HTTP(S) interno de Google Cloud. 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 Anthos 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 Anthos 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
Puerto
especificado por número
  • para NEG zonales: el port del Service
  • para grupos de instancias: la nodePort del Service
Si el backend.servicePort del objeto Ingress hace referencia al port del Service, se usa ese puerto, siempre que se defina lo siguiente:
  • El sondeo de preparación del pod de entrega debe especificar un puerto:
    spec.containers[].readinessProbe.httpGet.port
  • El targetPort del Service hace referencia al containers[].spec.ports.containerPort del pod de entrega
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 Anthos, 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 Anthos: El controlador de Ingress de Anthos 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 los pods de entrega tienen varios contenedores con sondeos de preparación únicos: si los pods de entrega de un Service tienen más de un contenedor y cada contenedor tiene una configuración de sondeo de preparación diferente, debes definir la verificación de estado del servicio de backend correspondiente mediante una referencia de CRD BackendConfig en el Service correspondiente. GKE no te permite elegir un sondeo de preparación específico del que inferirá los parámetros de verificación de estado si hay varios sondeos de preparación presentes en un pod de entrega.

  • 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 HTTP(S) externo o un balanceador de cargas de HTTP(S) interno de Google Cloud creado por un Ingress. Consulta Características 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

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 (serviceName, servicePort) 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 en GitHub.

  • 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 comentario sobre el problema.

  • Los cambios en readinessProbe de un pod no afectan el Ingress después de que se crea.

  • Un balanceador de cargas de HTTP(S) 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 unacontrolador 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 HTTP(S) externos.

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”.

¿Qué sigue?