Ingress de GKE para balanceadores de carga de aplicaciones

En esta página se ofrece una descripción general de Ingress para balanceadores de carga de aplicación externos y de cómo funciona.

En esta página se da por hecho que conoces Kubernetes.

Google Kubernetes Engine (GKE) proporciona un controlador Ingress integrado y gestionado llamado GKE Ingress. Cuando creas un recurso Ingress en GKE, el controlador configura automáticamente un balanceador de carga HTTPS que permite que el tráfico HTTP o HTTPS llegue a tus servicios.

Esta página está dirigida a especialistas en redes que diseñan y desarrollan la red de su organización, así como instalan, configuran y ofrecen asistencia para los equipos de red. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas de usuario habituales de GKE.Trusted Cloud by S3NS

Información general

En GKE, un objeto Ingress define reglas para dirigir el tráfico HTTP(S) a las aplicaciones que se ejecutan en un clúster. Un objeto Ingress está asociado a uno o varios objetos Service, cada uno de los cuales está asociado a un conjunto de pods. Para obtener más información sobre cómo expone Ingress las aplicaciones mediante Servicios, consulta la descripción general de la red de servicios.

Cuando creas un objeto Ingress, el controlador de Ingress de GKE crea un Trusted Cloud by S3NS balanceador de carga HTTP(S) y lo configura según la información de Ingress y sus servicios asociados.

Para usar Ingress, debes tener habilitado el complemento de balanceo de carga HTTP. Los clústeres de GKE tienen habilitado el balanceo de carga HTTP de forma predeterminada, por lo que no debes inhabilitarlo.

Ingress para el tráfico externo e interno

Los recursos de Ingress de GKE son de dos tipos:

• Ingress para balanceadores de carga de aplicación externos despliega el balanceador de carga de aplicación clásico. Este balanceador de carga accesible desde Internet se despliega a nivel mundial en la red perimetral de Google como un conjunto gestionado y escalable de recursos de balanceo de carga. Consulta cómo configurar y usar Ingress para balanceadores de carga de aplicaciones externos.

• Ingress para balanceadores de carga de aplicación internos despliega el balanceador de carga de aplicación interno. Estos balanceadores de carga de aplicaciones internos se basan en sistemas de proxy Envoy fuera de tu clúster de GKE, pero dentro de tu red de VPC. Consulta cómo configurar y usar Ingress para balanceadores de carga de aplicaciones internos.

Comportamiento del controlador de Ingress de GKE

En los clústeres que ejecutan las versiones 1.18 y posteriores de GKE, el controlador de Ingress de GKE procesa o no un objeto Ingress en función del valor de la anotación kubernetes.io/ingress.class:

En 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 que tenga la anotación con el valor gce o gce-internal.

kubernetes.io/ingress.class anotación obsoleta

Aunque la anotación kubernetes.io/ingress.class está obsoleta en Kubernetes, GKE sigue usándola.

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

Características de los balanceadores de carga de aplicación externos

Un balanceador de carga de aplicaciones externo, configurado por Ingress, incluye las siguientes funciones:

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

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

Métodos de balanceo de carga

GKE admite el balanceo de carga nativo de contenedores y los grupos de instancias.

Balanceo de carga nativo de contenedores

El balanceo de carga nativo de contenedores es la práctica de balancear la carga directamente a los endpoints de los pods en GKE. El balanceo de carga nativo de contenedores es un tipo de grupos de endpoints de red (NEGs).

Con los NEGs, el tráfico se balancea de carga desde el balanceador de carga directamente a la IP del pod, en lugar de atravesar la IP de la VM y la red de kube-proxy. Además, se implementan puertas de disponibilidad de pods para determinar el estado de los pods desde la perspectiva del balanceador de carga y no solo las comprobaciones de estado en el clúster de Kubernetes. De esta forma, se mejora la estabilidad general del tráfico, ya que la infraestructura del balanceador de carga tiene en cuenta los eventos del ciclo de vida, como el inicio, la pérdida o la pérdida de máquinas virtuales de los pods. Estas funciones resuelven las limitaciones anteriores y dan como resultado una red más estable y con mejor rendimiento.

El balanceo de carga nativo de contenedores está habilitado de forma predeterminada para los servicios cuando se cumplen todas las condiciones siguientes:

• Para los servicios creados en clústeres de GKE 1.17.6-gke.7 y versiones posteriores
• Usar clústeres nativos de VPC
• No usar una red de VPC compartida
• No usar 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 reflejar las IPs de los pods en el servicio. El NEG es lo que permite que los balanceadores de carga de Compute Engine se comuniquen directamente con los pods. Ten en cuenta que los servicios creados antes de GKE 1.17.6-gke.7 no se anotarán automáticamente con el controlador de servicios.

En GKE 1.17.6-gke.7 y versiones anteriores, donde la anotación NEG es automática, es posible inhabilitar los NEGs y forzar que el balanceador de carga externo de Compute Engine use un grupo de instancias como backend si es necesario. Para ello, anota explícitamente los servicios con cloud.google.com/neg: '{"ingress": false}'. No es posible inhabilitar los NEGs con Ingress para los balanceadores de carga de aplicaciones internos.

En los clústeres en los que los NEG no son el valor predeterminado, se recomienda encarecidamente usar el balanceo de carga nativo de contenedores, pero debe habilitarse explícitamente en cada servicio. La anotación debe aplicarse a los servicios de la siguiente manera:

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

Grupos de instancias

Cuando se usan grupos de instancias, los balanceadores de carga de Compute Engine envían tráfico a las direcciones IP de las VMs como back-ends. Al ejecutar contenedores en máquinas virtuales, en los que los contenedores comparten la misma interfaz de host, se producen las siguientes limitaciones:

• Se producen dos saltos de balanceo de carga: un salto del balanceador de carga a la VM NodePort y otro salto a través del enrutamiento de kube-proxy a las direcciones IP de los pods (que pueden residir en otra VM).
• Los saltos adicionales aumentan la latencia y hacen que la ruta del tráfico sea más compleja.
• El balanceador de carga de Compute Engine no tiene visibilidad directa de los pods, lo que provoca un balanceo de carga subóptimo.
• Es más probable que los eventos ambientales, como la pérdida de una máquina virtual o un pod, provoquen una pérdida de tráfico intermitente debido al doble salto de tráfico.

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 carga nativo de contenedores con GCE_VM_IP_PORT grupos de puntos finales de red (NEGs). En su lugar, el controlador Ingress usa back-ends de grupos de instancias no gestionados que incluyen todos los nodos de todos los grupos de nodos. Si estos grupos de instancias no gestionados también los usan los servicios de LoadBalancer, pueden surgir problemas relacionados con la limitación de un solo grupo de instancias con balanceo de carga.

Algunos objetos Ingress externos antiguos creados en clústeres nativos de VPC pueden usar backends de grupos de instancias en los servicios de backend de cada balanceador de carga de aplicaciones externo que creen. Esto no es relevante para Ingress interno porque los recursos de Ingress interno siempre usan GCE_VM_IP_PORT NEGs y requieren clústeres nativos de VPC.

Para saber cómo solucionar errores 502 con Ingress externo, consulta Ingress externo genera errores HTTP 502.

VPC compartida

Los recursos Ingress y MultiClusterIngress se admiten en VPC compartida, pero requieren una preparación adicional.

El controlador Ingress se ejecuta en el plano de control de GKE y hace llamadas a la API de Trusted Cloud by S3NS con 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 utiliza una red de VPC compartida, el controlador de entrada no puede usar la cuenta de servicio de GKE del proyecto de servicio para crear y actualizar reglas de cortafuegos de entrada permitidas en el proyecto host.

Puedes conceder permisos a la cuenta de servicio de GKE del proyecto de servicio para crear y gestionar reglas de cortafuegos de VPC en el proyecto host. Al conceder estos permisos, GKE crea reglas de cortafuegos de entrada para lo siguiente:

• Proxies de Google Front End (GFE) y sistemas de comprobación de estado que usan los balanceadores de carga de aplicaciones externos para el Ingress externo. Para obtener más información, consulta la descripción general de los balanceadores de carga de aplicación externos.

• Sistemas de comprobación del estado de los balanceadores de carga de aplicación internos que usa Ingress interno.

Aprovisionar manualmente reglas de cortafuegos desde el proyecto host

Si tus políticas de seguridad solo permiten gestionar el cortafuegos desde el proyecto host, puedes aprovisionar estas reglas de cortafuegos manualmente. Cuando se implementa Ingress en una VPC compartida, el evento de recurso Ingress proporciona la regla de cortafuegos específica que debes añadir para proporcionar acceso.

Para aprovisionar una regla manualmente, sigue estos pasos:

1. Consulta el evento del recurso Ingress:

   kubectl describe ingress INGRESS_NAME
   

   Sustituye INGRESS_NAME por el nombre de tu Ingress.

   Debería ver un resultado similar al siguiente ejemplo:

   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 obligatoria sugerida aparece en la columna Message.

2. Copia y aplica las reglas de cortafuegos sugeridas del proyecto host. Al aplicar la regla, se proporciona acceso a tus pods desde el balanceador de carga y los comprobadores de estado deTrusted Cloud .

Conceder permiso al controlador de entrada de GKE para gestionar las reglas de cortafuegos del proyecto host

Si quieres que un clúster de GKE de un proyecto de servicio cree y gestione los recursos de cortafuegos de tu proyecto host, debes conceder a la cuenta de servicio de GKE del proyecto de servicio los permisos de IAM adecuados mediante una de las siguientes estrategias:

• Asigna a la cuenta de servicio de GKE del proyecto de servicio el rol Administrador de seguridad de Compute en el proyecto host. En el siguiente ejemplo se muestra esta estrategia.

• Para un enfoque más detallado, crea un rol de gestión de identidades y accesos personalizado que incluya solo los siguientes permisos: compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete y compute.subnetworks.list. Asigna a la cuenta de servicio de GKE del proyecto de servicio ese rol personalizado en el proyecto host.

Si tienes clústeres en más de un proyecto de servicio, debes elegir una de las estrategias y repetirla para cada 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.s3ns-system.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

Haz los cambios siguientes:

• HOST_PROJECT_ID: el ID de proyecto del proyecto host de VPC compartida.
• SERVICE_PROJECT_NUMBER: el número de proyecto del proyecto de servicio que contiene tu clúster.

Varios servicios de backend

Cada balanceador de carga de aplicaciones externo o interno usa un solo mapa de URLs, que hace referencia a uno o varios servicios de backend. Un servicio de backend corresponde a cada servicio al que hace referencia el Ingress.

Por ejemplo, puede configurar el balanceador de carga para que dirija las solicitudes a diferentes servicios de backend en función de la ruta de la URL. Las solicitudes enviadas a tu-tienda.ejemplo podrían enrutarse a un servicio de backend que muestre artículos a precio completo, y las solicitudes enviadas a tu-tienda.ejemplo/rebajados podrían enrutarse a un servicio de backend que muestre artículos rebajados.

También puedes configurar el balanceador de carga para que enrute las solicitudes según el nombre de host. Las solicitudes enviadas a tu-tienda.ejemplo podrían dirigirse a un servicio backend, mientras que las solicitudes enviadas a tu-tienda-experimental.ejemplo podrían dirigirse a otro servicio backend.

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

Si quieres configurar GKE Ingress con varios back-ends para el mismo host, debes tener una sola regla con un solo host y varias rutas. De lo contrario, el controlador de Ingress de GKE aprovisiona solo un servicio de backend.

Este es el manifiesto de un Ingress llamado my-ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
 rules:
  - host: your-store.example
    http:
      paths:
      - path: /products
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted-products
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

Cuando creas el objeto Ingress, el controlador de Ingress de GKE crea y configura un balanceador de carga de aplicaciones externo o interno según la información del objeto Ingress y los servicios asociados. Además, el balanceador de carga recibe una dirección IP estable que puedes asociar a un nombre de dominio.

En el ejemplo anterior, supongamos que has asociado la dirección IP del balanceador de carga al nombre de dominio tu-tienda.example. Cuando un cliente envía una solicitud a tu-tienda.example, la solicitud se dirige 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 en el campo path de un Ingress es el carácter *. El carácter * debe ir después de una barra diagonal (/) y ser el último carácter del patrón. Por ejemplo, /*, /foo/* y /foo/bar/* son formatos válidos, pero *, /foo/bar* y /foo/*/bar no lo son.

Un patrón más específico tiene prioridad sobre un patrón menos específico. Si tienes /foo/* y /foo/bar/*, se considera que /foo/bar/bat coincide con /foo/bar/*.

Para obtener más información sobre las limitaciones de las rutas y la coincidencia de patrones, consulta la documentación de mapas de URLs.

El manifiesto del servicio my-products podría tener este aspecto:

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 de servicio, debes usar type: NodePort, a menos que utilices el balanceo de carga nativo de contenedores. Si usas el balanceo de carga nativo de contenedores, usa type: ClusterIP.

En el manifiesto de Service, el campo selector indica que cualquier pod que tenga tanto la etiqueta app: products como la etiqueta department: sales es miembro de este Service.

Cuando llega una solicitud al servicio en el puerto 60000, se dirige 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 del servicio my-discounted-products podría tener este aspecto:

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 Service, 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 en el 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 el manifiesto de Ingress. De esta forma, se gestionarán las solicitudes que no coincidan con las rutas definidas en el campo rules. Por ejemplo, en el siguiente Ingress, las solicitudes que no coincidan con /discounted se enviarán 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 especifica un backend predeterminado, GKE proporciona un backend predeterminado que devuelve el código 404. Se crea como un servicio default-http-backend NodePort en el clúster del 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 GKE Ingress con un backend predeterminado personalizado, consulta el artículo GKE Ingress con un backend predeterminado personalizado.

Asignaciones de recursos de Compute Engine de entrada

El controlador de Ingress de GKE implementa y gestiona los recursos del balanceador de carga de Compute Engine en función de los recursos de Ingress que se implementan en el clúster. La asignación de recursos de Compute Engine depende de la estructura del recurso Ingress.

El siguiente manifiesto 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 indica a GKE que cree los siguientes recursos de Compute Engine:

• Una regla de reenvío y una dirección IP.
• Reglas de cortafuegos de Compute Engine que permiten el tráfico de las comprobaciones de estado del balanceador de carga y el tráfico de la aplicación de Google Front Ends o de proxies Envoy.
• Un proxy HTTP de destino y un proxy HTTPS de destino, si has configurado TLS.
• Un mapa de URLs con una sola regla de host que hace referencia a un solo elemento de coincidencia de ruta. El comparador de rutas tiene dos reglas de ruta: una para /* y otra para /discounted. Cada regla de ruta se asigna a un servicio de backend único.
• NEGs que contienen una lista de direcciones IP de Pod de cada servicio como endpoints. Se crean como resultado de los servicios my-discounted-products y my-products.

Opciones para proporcionar certificados SSL

Puedes proporcionar certificados SSL a un balanceador de carga HTTP(S) mediante los siguientes métodos:

Certificados gestionados por Google

Los

certificados SSL gestionados por Google se aprovisionan, implementan, renuevan y gestionan para tus dominios. Los certificados gestionados no admiten dominios comodín.

Certificados autogestionados compartidos con Trusted Cloud

Puedes aprovisionar tu propio certificado SSL y crear un recurso de certificado en tu Trusted Cloud proyecto. A continuación, puedes enumerar el recurso de certificado en una anotación de un recurso Ingress para crear un balanceador de carga HTTP(S) que utilice el certificado. Consulta las instrucciones para los certificados precompartidos para obtener más información.

Certificados autogestionados como recursos Secret

Puedes aprovisionar tu propio certificado SSL y crear un secreto para almacenarlo. Después, puedes hacer referencia al secreto en una especificación de Ingress para crear un balanceador de carga HTTP(S) que use el certificado. Para obtener más información, consulta las instrucciones para usar certificados en Secrets.

Comprobaciones del estado

Cuando expones uno o varios servicios a través de un objeto Ingress mediante el controlador Ingress predeterminado, GKE crea un balanceador de carga de aplicaciones clásico o un balanceador de carga de aplicaciones interno. Ambos balanceadores de carga admiten varios servicios de backend en un único mapa de URLs. Cada uno de los servicios de backend corresponde a un servicio de Kubernetes y cada servicio de backend debe hacer referencia a una Trusted Cloud comprobación de estado. Esta comprobación del estado es diferente de una comprobación de actividad o de disponibilidad de Kubernetes, ya que se implementa fuera del clúster.

Las comprobaciones de estado del balanceador de carga se especifican por servicio de backend. Aunque es posible usar la misma comprobación del estado para todos los servicios de backend del balanceador de carga, la referencia de la comprobación del estado no se especifica para todo el balanceador de carga (en el propio objeto Ingress).

GKE crea comprobaciones del estado basadas en uno de los siguientes métodos:

• BackendConfig CRD: una definición de recurso personalizado (CRD) que te permite controlar con precisión cómo interactúan tus servicios con el balanceador de carga. BackendConfig Los CRDs te permiten especificar ajustes personalizados para la comprobación de estado asociada al servicio de backend correspondiente. Estos ajustes personalizados ofrecen más flexibilidad y control sobre las comprobaciones del estado tanto del balanceador de carga de aplicación clásico como del balanceador de carga de aplicación interno creado por un objeto Ingress.
• Sondeo de disponibilidad: comprobación de diagnóstico que determina si un contenedor de un pod está listo para atender el tráfico. El controlador de Ingress de GKE crea la comprobación del estado del servicio de backend del servicio en función de la sonda de preparación que utilizan los pods de servicio de ese servicio. Puedes obtener los parámetros de comprobación de estado, como la ruta, el puerto y el protocolo, de la definición de la sonda de preparación.
• Valores predeterminados: los parámetros que se usan cuando no se configura un CRD BackendConfig o no se definen atributos para la comprobación de disponibilidad.

GKE sigue este procedimiento para crear una comprobación del estado de cada servicio de backend correspondiente a un servicio de Kubernetes:

• Si el servicio hace referencia a un CRD de BackendConfig con información de healthCheck, GKE lo usa para crear la comprobación de estado. Tanto el controlador de Ingress de GKE Enterprise como el controlador de Ingress de GKE admiten la creación de comprobaciones de estado de esta forma.

• Si el servicio no hace referencia a un CRD de BackendConfig:

  • GKE puede inferir algunos o todos los parámetros de una comprobación de estado si los pods de servicio usan una plantilla de pod con un contenedor cuya sonda de disponibilidad tenga atributos que se puedan interpretar como parámetros de comprobación de estado. Consulte Parámetros de una sonda de disponibilidad para obtener información sobre la implementación y Parámetros predeterminados e inferidos para ver una lista de atributos que se pueden usar para crear parámetros de comprobación del estado. Solo el controlador de Ingress de GKE admite la inferencia de parámetros a partir de una sonda de disponibilidad.

  • Si la plantilla de Pod de los Pods de servicio no tiene un contenedor con una sonda de disponibilidad cuyos atributos se puedan interpretar como parámetros de comprobación del estado, se utilizarán los valores predeterminados para crear la comprobación del estado. Tanto el controlador de entradas de GKE Enterprise como el controlador de entradas de GKE pueden crear una comprobación de estado usando solo los valores predeterminados.

Parámetros predeterminados e inferidos

Los siguientes parámetros se utilizan cuando no especificas parámetros de comprobación de estado para el servicio correspondiente mediante un BackendConfig CRD.

Parámetros de una comprobación de preparación

Cuando GKE crea la comprobación de estado del servicio backend del servicio, puede copiar determinados parámetros de la comprobación de disponibilidad de un contenedor que usan los pods de servicio de ese servicio. Esta opción solo es compatible con el controlador de entrada de GKE.

Los atributos de la sonda de disponibilidad admitidos que se pueden interpretar como parámetros de comprobación de estado se indican junto con los valores predeterminados en Parámetros predeterminados e inferidos. Se usan valores predeterminados para los atributos que no se especifican en la sonda de disponibilidad o si no se especifica ninguna sonda de disponibilidad.

Si los pods de tu servicio contienen varios contenedores o si usas el controlador Ingress de GKE Enterprise, debes usar un BackendConfigCRD para definir los parámetros de comprobación de estado. Para obtener más información, consulta Cuándo usar un CRD de BackendConfig.

Cuándo usar CRDs de BackendConfig

En lugar de usar parámetros de las sondas de disponibilidad de pods, debes definir explícitamente los parámetros de comprobación de estado de un servicio backend creando un BackendConfig CRD para el servicio en estas situaciones:

• Si usas GKE Enterprise: el controlador de Ingress de GKE Enterprise no admite la obtención de parámetros de comprobación del estado de las sondas de disponibilidad de los pods de servicio. Solo puede crear comprobaciones del estado con parámetros implícitos o tal como se definen en un BackendConfig CRD.

• Si tienes más de un contenedor en los pods de servicio: GKE no tiene forma de seleccionar la sonda de preparación de un contenedor específico a partir del cual inferir los parámetros de comprobación de estado. Como cada contenedor puede tener su propia sonda de disponibilidad y esta no es un parámetro obligatorio para un contenedor, debes definir la comprobación del estado del servicio backend correspondiente haciendo referencia a un BackendConfigCRD en el servicio correspondiente.

• Si necesitas controlar el puerto que se usa para las comprobaciones del estado del balanceador de carga, GKE solo usa el containers[].readinessProbe.httpGet.port de la sonda de disponibilidad para la comprobación del estado del servicio backend cuando ese puerto coincide con el puerto de servicio del servicio al que se hace referencia en el recurso Ingress spec.rules[].http.paths[].backend.servicePort.

Parámetros de un CRD BackendConfig

Puede especificar los parámetros de comprobación de estado del servicio backend con el parámetro healthCheck de un BackendConfig CRD al que hace referencia el servicio correspondiente. De esta forma, tendrás más flexibilidad y control sobre las comprobaciones del estado de un balanceador de carga de aplicación clásico o de un balanceador de carga de aplicación interno creado por un objeto Ingress. Consulta la configuración de entrada para ver la compatibilidad con las versiones de GKE.

Este ejemplo de CRD BackendConfig define el protocolo de comprobación del estado (tipo), una ruta de solicitud, un puerto y un intervalo de comprobació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 al configurar una comprobación del estado BackendConfig, usa el ejemplo de configuración personalizada de comprobación del estado.

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

Usar varios certificados TLS

Supongamos que quieres que un balanceador de carga HTTP(S) sirva contenido de dos nombres de host: your-store.example y your-experimental-store.example. Además, quieres que el balanceador de carga use un certificado para tu-tienda.ejemplo y otro para tu-tienda-experimental.ejemplo.

Para ello, especifica varios certificados en un manifiesto de Ingress. El balanceador de carga 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 el artículo Usar varios certificados SSL en el balanceo de carga HTTPS con Ingress.

Comparación entre el servicio de Kubernetes y el servicio de backend Trusted Cloud

Un servicio de Kubernetes y un Trusted Cloud servicio de backend son dos cosas distintas. Existe una relación estrecha entre ambos, pero no es necesariamente una relación individual. El controlador de Ingress de GKE crea un Trusted Cloud servicio de backend para cada par (service.name, service.port) de un manifiesto de Ingress. Por lo tanto, es posible que un objeto de servicio de Kubernetes esté relacionado con varios servicios de backend. Trusted Cloud

Limitaciones

• En los clústeres que usan versiones anteriores a la 1.16, la longitud total del espacio de nombres y el nombre de un Ingress no debe superar los 40 caracteres. Si no sigues esta directriz, es posible que el controlador de entradas de GKE actúe de forma anómala. Para obtener más información, consulta este problema de GitHub sobre nombres largos.

• En los clústeres que usan NEGs, el tiempo de conciliación de entrada puede verse afectado por el número de entradas. Por ejemplo, un clúster con 20 entradas, cada una de las cuales contiene 20 back-ends de NEG distintos, puede provocar una latencia de más de 30 minutos para que se concilie un cambio de entrada. Esto afecta especialmente a los clústeres regionales debido al mayor número de NEGs que se necesitan.

• Se aplican las cuotas de los mapas de URLs.

• Se aplican las cuotas de recursos de Compute Engine.

• Si no usas NEGs con el controlador Ingress de GKE, los clústeres de GKE tienen un límite de 1000 nodos. Cuando los servicios se implementan con NEGs, no hay límite de nodos de GKE. Los servicios que no sean NEG expuestos a través de Ingress no funcionan correctamente en clústeres de más de 1000 nodos.

• Para que el controlador Ingress de GKE use tu readinessProbes como comprobaciones de estado, los pods de un Ingress deben existir en el momento de la creación del Ingress. Si tus réplicas se escalan a 0, se aplica la comprobación de estado predeterminada. Para obtener más información, consulta este comentario de GitHub sobre las comprobaciones del estado.

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

• Un balanceador de carga de aplicación externo termina la conexión TLS en ubicaciones distribuidas por todo el mundo para minimizar la latencia entre los clientes y el balanceador de carga. Si necesitas controlar geográficamente dónde se termina TLS, debes usar un controlador de entrada personalizado expuesto a través de un servicio de GKE de tipo LoadBalancer y terminar TLS en backends ubicados en regiones adecuadas para tus necesidades.

• No se pueden combinar varios recursos Ingress en un solo Trusted Cloud by S3NS balanceador de carga.

• Debes desactivar el protocolo TLS mutuo en tu aplicación porque no se admite en los balanceadores de carga de aplicaciones externos.

• Ingress solo puede exponer los puertos HTTP 80 y 443 para su frontend.

Detalles de la implementación

• El controlador de Ingress comprueba periódicamente los permisos de la cuenta de servicio. Para ello, obtiene un recurso de prueba de tu Trusted Cloud by S3NS proyecto. Verás esto como un GET del BackendService global (inexistente) con el nombre k8s-ingress-svc-acct-permission-check-probe. Como este recurso no debería existir normalmente, la solicitud GET devolverá el error "no encontrado". Es lo esperado, ya que el controlador comprueba que la llamada a la API no se rechace debido a problemas de autorización. Si creas un BackendService con el mismo nombre, la GET se realizará correctamente en lugar de devolver "no encontrado".

Plantillas para la configuración de Ingress

• En Recetas de redes de GKE, puedes encontrar plantillas proporcionadas por GKE sobre muchos usos habituales de Ingress en la sección Ingress.

Siguientes pasos

• Información sobre las recetas de redes de GKE
• Consulta más información sobre el balanceo de carga en Trusted Cloud.
• Consulta una descripción general de las redes en GKE.
• Consulta cómo configurar Ingress para balanceadores de carga de aplicaciones internos.
• Consulta cómo configurar objetos Ingress para balanceadores de carga de aplicaciones externos.