Configuración de Ingress

Información general

En esta página se ofrece una descripción general completa de lo que puedes configurar a través de Ingress de Kubernetes enGoogle Cloud. En el documento también se comparan las funciones compatibles con Ingress enGoogle Cloud y se proporcionan instrucciones para configurar Ingress mediante el controlador predeterminado, los parámetros de FrontendConfig y los parámetros de BackendConfig.

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.Google Cloud

Comparación de funciones

En la siguiente tabla se muestra una lista de las funciones compatibles con Ingress en Google Cloud. También se indica la disponibilidad de la función (disponibilidad general o beta).

Clase de Ingress Entrada externa Entrada interna Entrada multi-clúster
Controlador de entrada Controlador de Ingress alojado en Google
Google Cloud Tipo de balanceador de carga Balanceo de carga de HTTP y HTTPS externas Balanceo de carga de HTTP y HTTPS internas Balanceo de carga de HTTP y HTTPS externas
Ámbito de clúster Un solo clúster Un solo clúster Varios clústeres
Ámbito del balanceador de carga Global Regional Global
Asistencia para el entorno GKE GKE GKE
Compatibilidad con VPC compartida GA GA GA
Anotaciones de servicio
Balanceo de carga nativo de contenedores (NEGs) GA GA GA
HTTPS del balanceador de carga a los backends GA GA GA
HTTP/2 GA GA
Solo TLS		 GA
Anotaciones de Ingress
Direcciones IP estáticas GA GA GA
Certificados basados en secretos de Kubernetes GA GA GA
Certificados de SSL autogestionados GA GA GA
Certificados SSL gestionados por Google GA GA
FrontendConfig
Política de SSL GA GA con pasarela GA
Redireccionamiento de HTTP a HTTPS GA
1.17.13-gke.2600+GA		 GA
BackendConfig
Tiempo de espera del servicio de backend GA GA GA
Cloud CDN GA GA
Tiempo de espera de purga de conexión GA GA GA
Configuración personalizada de la comprobación del estado del balanceador de carga GA GA GA
Política de seguridad de Google Cloud Armor GA
1.19.10-gke.700G		 GA
Configuración del registro de acceso HTTP GA GA GA
Identity‑Aware Proxy GA GA GA
Afinidad de sesión GA GA GA
Encabezados de solicitud definidos por el usuario GA GA
Encabezados de respuesta personalizados GA
1.25-gke+G		 GA
1.25-gke+G

BEsta función está disponible en versión beta a partir de la versión especificada. Las funciones sin una versión específica son compatibles con todas las versiones de GKE disponibles.

GEsta función está disponible de forma general a partir de la versión especificada.

Configurar Ingress con el controlador predeterminado

No puedes configurar manualmente las funciones de LoadBalancer con el SDK de Google Cloud ni con la Google Cloud consola. Debes usar recursos de Kubernetes BackendConfig o FrontendConfig.

Cuando creas un objeto Ingress con el controlador predeterminado, puedes elegir el tipo de balanceador de carga (un balanceador de carga de aplicaciones externo o interno) mediante una anotación en el objeto Ingress. Puedes elegir si GKE crea NEGs zonales o si usa grupos de instancias mediante una anotación en cada objeto Service.

Las definiciones de recursos personalizados (CRDs) FrontendConfig y BackendConfig te permiten personalizar aún más el balanceador de carga. Estos CRDs te permiten definir funciones adicionales del balanceador de carga de forma jerárquica y más estructurada que las anotaciones. Para usar Ingress (y estas CRDs), debes tener habilitado el complemento de balanceo de carga de HTTP. Los clústeres de GKE tienen habilitado el balanceo de carga HTTP de forma predeterminada, por lo que no debes inhabilitarlo.

Se hace referencia a los FrontendConfigs en un objeto Ingress y solo se pueden usar con objetos Ingress externos. Los BackendConfigs se referencian mediante un objeto Service. Se puede hacer referencia a los mismos CRDs desde varios objetos Service o Ingress para mantener la coherencia de la configuración. Los CRDs FrontendConfig y BackendConfig comparten el mismo ciclo de vida que sus recursos Ingress y Service correspondientes, y a menudo se implementan juntos.

En el siguiente diagrama se muestra cómo:

  • Una anotación en un objeto Ingress o MultiClusterIngress hace referencia a un CRD FrontendConfig. El CRD FrontendConfig hace referencia a una Google Cloudpolítica de SSL.

  • Una anotación en un objeto Service o MultiClusterService hace referencia a un CRD BackendConfig. El CRD BackendConfig especifica ajustes personalizados para la comprobación de estado del servicio de backend correspondiente.

Información general sobre BackendConfig y FrontendConfig
Figura: Resumen de BackendConfig y FrontendConfig

Asociar FrontendConfig a tu Ingress

FrontendConfig solo se puede usar con Ingresses externos.

Puedes asociar un FrontendConfig a un Ingress o a un MultiClusterIngress.

Entrada

Usa la anotación networking.gke.io/v1beta1.FrontendConfig:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"
...

Sustituye FRONTENDCONFIG_NAME por el nombre de tu FrontendConfig.

MultiClusterIngress

Usa la anotación networking.gke.io/frontend-config:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  annotations:
    networking.gke.io/frontend-config: "FRONTENDCONFIG_NAME"
...

Sustituye FRONTENDCONFIG_NAME por el nombre de tu FrontendConfig.

Asociar BackendConfig con tu Ingress

Puedes usar la anotación cloud.google.com/backend-config o beta.cloud.google.com/backend-config para especificar el nombre de un BackendConfig.

Mismo BackendConfig para todos los puertos de Service

Para usar el mismo BackendConfig en todos los puertos, usa la clave default en la anotación. El controlador de Ingress usa el mismo BackendConfig cada vez que crea un servicio de backend de balanceador de carga para hacer referencia a uno de los puertos del servicio.

Puedes usar la clave default tanto para recursos Ingress como MultiClusterIngress.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

Un BackendConfig único por puerto de servicio

Tanto en Ingress como en MultiClusterIngress, puede especificar un BackendConfig personalizado para uno o varios puertos mediante una clave que coincida con el nombre o el número del puerto. El controlador de Ingress usa el BackendConfig específico cuando crea un servicio de backend de balanceador de carga para un puerto de servicio referenciado.

GKE 1.16-gke.3 y versiones posteriores

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "SERVICE_REFERENCE_A":"BACKENDCONFIG_REFERENCE_A",
    "SERVICE_REFERENCE_B":"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Todas las versiones admitidas

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
      PORT_NAME_1:"BACKENDCONFIG_REFERENCE_A",
      PORT_NAME_2:"BACKENDCONFIG_REFERENCE_B"
    }}'
spec:
  ports:
  - name: PORT_NAME_1
    port: PORT_NUMBER_1
    protocol: TCP
    targetPort: 50000
  - name: PORT_NAME_2
    port: PORT_NUMBER_2
    protocol: TCP
    targetPort: 8080
...

Haz los cambios siguientes:

  • BACKENDCONFIG_REFERENCE_A: nombre de un BackendConfig.
  • BACKENDCONFIG_REFERENCE_B: nombre de un BackendConfig.
  • SERVICE_REFERENCE_A: usa el valor de PORT_NUMBER_1 o PORT_NAME_1. Esto se debe a que la anotación BackendConfig de un servicio puede hacer referencia al nombre del puerto (spec.ports[].name) o al número del puerto (spec.ports[].port).
  • SERVICE_REFERENCE_B: usa el valor de PORT_NUMBER_2 o PORT_NAME_2. Esto se debe a que la anotación BackendConfig de un servicio puede hacer referencia al nombre del puerto (spec.ports[].name) o al número del puerto (spec.ports[].port).

Cuando hagas referencia al puerto del servicio por número, debes usar el valor port en lugar del valor targetPort. El número de puerto que se usa aquí solo sirve para vincular el BackendConfig. No controla el puerto al que el balanceador de carga envía el tráfico o las comprobaciones del estado:

  • Cuando se usa el balanceo de carga nativo de contenedores, el balanceador de carga envía el tráfico a un endpoint de un grupo de endpoints de red (que coincide con una dirección IP de un pod) en el targetPort del puerto del servicio referenciado (que debe coincidir con un containerPort de un pod de servicio). De lo contrario, el balanceador de carga envía el tráfico a la dirección IP de un nodo en el puerto del servicio referenciadonodePort.

  • Cuando se usa un BackendConfig para proporcionar una comprobación del estado del balanceador de carga personalizada, el número de puerto que se usa para la comprobación del estado del balanceador de carga puede ser diferente del número de spec.ports[].port del servicio. Para obtener más información sobre los números de puerto de las comprobaciones del estado, consulta el artículo Configuración personalizada de las comprobaciones del estado.

Configurar funciones de Ingress mediante parámetros de FrontendConfig

En la siguiente sección se muestra cómo definir FrontendConfig para habilitar funciones de Ingress específicas.

Políticas de SSL

Las políticas de SSL le permiten especificar un conjunto de versiones de TLS y cifrados que el balanceador de carga usa para finalizar el tráfico HTTPS de los clientes. Primero debes crear una política de SSL fuera de GKE. Una vez creado, puedes hacer referencia a él en un CRD FrontendConfig.

El campo sslPolicy de FrontendConfig hace referencia al nombre de una política de SSL en el mismo proyecto que el clúster de GKE. Google Cloud Asocia la política de SSL al proxy HTTPS de destino, que ha creado el objeto Ingress para el balanceador de carga HTTP(S) externo. Se puede hacer referencia al mismo recurso FrontendConfig y a la misma política de SSL desde varios recursos Ingress. Si se cambia una política de SSL a la que se hace referencia, el cambio se propaga a los front-ends de Google (GFEs) que proporcionan la infraestructura de tu balanceador de carga HTTP(S) externo creado por el objeto Ingress.

El siguiente manifiesto de FrontendConfig habilita una política de SSL llamada gke-ingress-ssl-policy:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

Redirecciones de HTTP a HTTPS

Un balanceador de carga HTTP externo puede redirigir las solicitudes HTTP sin cifrar a un balanceador de carga HTTPS que utilice la misma dirección IP. Cuando creas un Ingress con la redirección de HTTP a HTTPS habilitada, ambos balanceadores de carga se crean automáticamente. Las solicitudes a la dirección IP externa del Ingress en el puerto 80 se redirigen automáticamente a la misma dirección IP externa en el puerto 443. Esta función se basa en las redirecciones de HTTP a HTTPS que proporciona Cloud Load Balancing.

Para admitir la redirección de HTTP a HTTPS, se debe configurar un Ingress para que sirva tráfico HTTP y HTTPS. Si se inhabilita HTTP o HTTPS, la redirección no funcionará.

Las redirecciones de HTTP a HTTPS se configuran mediante el campo redirectToHttps de un recurso personalizado FrontendConfig. Las redirecciones se habilitan para todo el recurso Ingress, por lo que todos los servicios a los que haga referencia Ingress tendrán habilitadas las redirecciones HTTPS.

El siguiente manifiesto FrontendConfig habilita las redirecciones de HTTP a HTTPS. Define el campo spec.redirectToHttps.enabled como true para habilitar las redirecciones HTTPS. El campo spec.responseCodeName es opcional. Si se omite, se usa una redirección 301 Moved Permanently.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: RESPONSE_CODE

Sustituye RESPONSE_CODE por una de las siguientes opciones:

  • MOVED_PERMANENTLY_DEFAULT para devolver un código de respuesta de redirección 301 (valor predeterminado si no se especifica responseCodeName).
  • FOUND para devolver un código de respuesta de redirección 302.
  • SEE_OTHER para devolver un código de respuesta de redirección 303.
  • TEMPORARY_REDIRECT para devolver un código de respuesta de redirección 307.
  • PERMANENT_REDIRECT para devolver un código de respuesta de redirección 308.

Cuando las redirecciones están habilitadas, el controlador Ingress crea un balanceador de carga, tal como se muestra en el siguiente diagrama:

Un balanceador de carga HTTP externo solo de redirección que consta de una regla de reenvío, un proxy HTTP de destino y un mapa de URLs con una redirección a un balanceador de carga HTTPS completo con servicios de backend

Para comprobar que la redirección funciona, usa un comando curl:

curl http://IP_ADDRESS

Sustituye IP_ADDRESS por la dirección IP de tu Ingress.

La respuesta muestra el código de respuesta de redirección que has configurado. Por ejemplo, el siguiente ejemplo es para un FrontendConfig configurado con una redirección 301: MovedPermanently:

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://35.244.160.59/">here</A>.</BODY></HTML>

Configurar funciones de Ingress mediante parámetros de BackendConfig

En las siguientes secciones se muestra cómo configurar BackendConfig para habilitar funciones de Ingress específicas. Los cambios en un recurso BackendConfig se reconcilian constantemente, por lo que no es necesario eliminar y volver a crear el Ingress para que se reflejen los cambios de BackendConfig.

Para obtener información sobre las limitaciones de BackendConfig, consulta la sección Limitaciones.

Tiempo de espera del servicio de backend

Puede usar un BackendConfig para definir un periodo de tiempo de espera del servicio de backend en segundos. Si no especificas ningún valor, el valor predeterminado es de 30 segundos.

El siguiente manifiesto de BackendConfig especifica un tiempo de espera de 40 segundos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

Puedes habilitar Cloud CDN mediante un BackendConfig.

El siguiente manifiesto de BackendConfig muestra todos los campos disponibles al habilitar Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: CDN_ENABLED
    cachePolicy:
      includeHost: INCLUDE_HOST
      includeProtocol: INCLUDE_PROTOCOL
      includeQueryString: INCLUDE_QUERY_STRING
      # Specify only one of queryStringBlacklist and queryStringWhitelist.
      queryStringBlacklist: QUERY_STRING_DENYLIST
      queryStringWhitelist: QUERY_STRING_ALLOWLIST
    cacheMode: CACHE_MODE
    clientTtl: CLIENT_TTL
    defaultTtl: DEFAULT_TTL
    maxTtl: MAX_TTL
    negativeCaching: NEGATIVE_CACHING
    negativeCachingPolicy:
      code: NEGATIVE_CACHING_CODE
      ttl: NEGATIVE_CACHING_TTL
    requestCoalescing: REQ_COALESCING
    # Time, in seconds, to continue serving a stale version after request expiry.
    serveWhileStale: SERVE_WHILE_STALE
    signedUrlCacheMaxAgeSec: SIGNED_MAX_AGE
    signedUrlKeys:
      keyName: KEY_NAME
      keyValue: KEY_VALUE
      secretName: SECRET_NAME

Haz los cambios siguientes:

  • CDN_ENABLED: Si se define como true, Cloud CDN se habilita para este backend de Ingress.
  • INCLUDE_HOST: si se define en true, las solicitudes a diferentes hosts se almacenan en caché por separado.
  • INCLUDE_PROTOCOL: si se define en true, las solicitudes HTTP y HTTPS se almacenan en caché por separado.
  • INCLUDE_QUERY_STRING: si se define como true, los parámetros de cadena de consulta se incluyen en la clave de caché según queryStringBlacklist o queryStringWhitelist. Si no se define ninguno de los dos, se incluye toda la cadena de consulta. Si se le asigna el valor false, toda la cadena de consulta se excluye de la clave de caché.
  • QUERY_STRING_DENYLIST: especifica una matriz de cadenas con los nombres de los parámetros de cadena de consulta que se van a excluir de las claves de caché. Se incluyen todos los demás parámetros. Puede especificar queryStringBlacklist o queryStringWhitelist, pero no ambos.
  • QUERY_STRING_ALLOWLIST: especifica un array de cadenas con los nombres de los parámetros de cadena de consulta que se incluirán en las claves de caché. Todos los demás parámetros se excluyen. Puedes queryStringBlacklist o queryStringWhitelist, pero no ambas.

Los siguientes campos solo se admiten en las versiones 1.23.3-gke.900 y posteriores de GKE con GKE Ingress. No se admiten con Ingress de varios clústeres:

Amplía la siguiente sección para ver un ejemplo que implementa Cloud CDN a través de Ingress y, a continuación, valida que el contenido de la aplicación se almacena en caché.

Tiempo de espera de purga de conexión

Puedes configurar el tiempo de espera de purga de conexiones mediante un BackendConfig. El tiempo de espera de purga de conexión es el tiempo, en segundos, que se espera a que se purguen las conexiones. Durante el tiempo de espera especificado, las solicitudes existentes al backend eliminado tienen tiempo para completarse. El balanceador de carga no envía nuevas solicitudes al backend eliminado. Cuando se alcanza el tiempo de espera, se cierran todas las conexiones restantes con el backend. La duración del tiempo de espera puede ser de 0 a 3600 segundos. El valor predeterminado es 0, lo que también inhabilita el drenaje de conexiones.

El siguiente manifiesto de BackendConfig especifica un tiempo de espera hasta la desconexión de 60 segundos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

Configuración personalizada de comprobación del estado

GKE configura de varias formas las comprobaciones de estado del balanceador de carga al implementar a través de Ingress.Google Cloud Para obtener más información sobre cómo implementa GKE Ingress las comprobaciones del estado, consulta Comprobaciones del estado de Ingress.

BackendConfig te permite controlar con precisión los ajustes de comprobación de estado del balanceador de carga.

Puede configurar varios servicios de GKE para que hagan referencia al mismo BackendConfig como plantilla reutilizable. En el caso de los parámetros healthCheck, se crea unaGoogle Cloud comprobación de estado única para cada servicio de backend correspondiente a cada servicio de GKE.

El siguiente manifiesto de BackendConfig muestra todos los campos disponibles al configurar una comprobación de estado de BackendConfig:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    # Time, in seconds, between prober checks. Default is `5`.
    checkIntervalSec: INTERVAL
    # Probe timeout period. Must be less than or equal to checkIntervalSec.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTH_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    # Protocol to use. Must be `HTTP`, `HTTP2`, or `HTTPS`.
    type: PROTOCOL
    # Path for probe to use. Default is `/`.
    requestPath: PATH
    # Port number of the load balancer health check port. Default is `80`.
    port: PORT

Haz los cambios siguientes:

  • INTERVAL: especifica el check-interval, en segundos, de cada comprobador de estado. Es el tiempo que transcurre desde el inicio de la comprobación de un prober hasta el inicio de la siguiente. Si omite este parámetro, se usará el valor predeterminado de 5 segundos. Google Cloud Para obtener más información sobre la implementación, consulta Varias sondas y frecuencia.
  • TIMEOUT: especifica el tiempo que Google Cloud espera una respuesta a una petición. El valor de TIMEOUT debe ser inferior o igual a INTERVAL. Las unidades son segundos. Cada sonda requiere que se envíe un código de respuesta HTTP 200 (OK) antes de que se agote el tiempo de espera de la sonda.
  • HEALTH_THRESHOLD y UNHEALTHY_THRESHOLD: especifica el número de intentos de conexión secuenciales que deben completarse correctamente o fallar, en al menos una sonda, para cambiar el estado de salud de la instancia de VM de correcto a incorrecto o viceversa. Si omite uno de estos parámetros,Google Cloud usará el valor predeterminado 2.
  • PROTOCOL: especifica un protocolo que usan los sistemas de sondeo para comprobar el estado. BackendConfig solo admite la creación de comprobaciones de estado con los protocolos HTTP, HTTPS o HTTP2. Para obtener más información, consulta Criterios de éxito de HTTP, HTTPS y HTTP/2. No puedes omitir este parámetro.
  • PATH: en el caso de las comprobaciones de estado de HTTP, HTTPS o HTTP2, especifique el request-path al que debe conectarse el sistema de sondeo. Si omite este parámetro, Google Cloud utiliza el valor predeterminado /.

  • PORT: BackendConfig solo admite que se especifique el puerto de comprobación de estado del balanceador de carga mediante un número de puerto. Si omite este parámetro, Google Cloud usará el valor predeterminado 80.

    • Cuando uses el balanceo de carga nativo de contenedor, debes seleccionar un puerto que coincida con un containerPort de un pod de servicio (independientemente de si ese containerPort está referenciado por un targetPort del servicio). Como el balanceador de carga envía sondeos directamente a la dirección IP del pod, no está limitado a los containerPorts a los que hace referencia el targetPort de un servicio. Los sistemas de sondeo de comprobación de estado se conectan a la dirección IP de un Pod de servicio en el puerto que especifiques.

    • En el caso de los backends de grupos de instancias, debes seleccionar un puerto que coincida con un nodePort expuesto por el servicio. Los sistemas de sondeo de comprobación de estado se conectan a cada nodo de ese puerto.

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.

Política de seguridad de entrada de Google Cloud Armor

Las políticas de seguridad de Google Cloud Armor te ayudan a proteger tus aplicaciones con balanceo de carga frente a ataques web. Una vez que hayas configurado una política de seguridad de Google Cloud Armor, puedes hacer referencia a ella mediante un BackendConfig.

Añade el nombre de tu política de seguridad a BackendConfig. El siguiente manifiesto de BackendConfig especifica una política de seguridad llamada example-security-policy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

Dos fuentes de información veraz

Aunque se configura a través de GKE, las APIs de BackendService de Compute Engine subyacentes se pueden seguir usando para modificar directamente qué política de seguridad se aplica. Esto crea dos fuentes de información veraz: GKE y Compute Engine. El comportamiento del controlador de entrada de GKE en respuesta al campo securityPolicy de BackendConfig se describe en la tabla de abajo. Para evitar conflictos y comportamientos inesperados, te recomendamos que uses GKE BackendConfig para gestionar qué política de seguridad se debe usar.

Campo BackendConfig Valor Comportamiento
spec.securityPolicy.name CloudArmorPolicyName El controlador de Ingress de GKE asigna la política de Cloud Armor llamada CloudArmorPolicyName al balanceador de carga. El controlador de Ingress de GKE sobrescribe la política que se haya definido anteriormente.
spec.securityPolicy.name Cadena vacía ("") El controlador de Ingress de GKE elimina cualquier política de Cloud Armor configurada del balanceador de carga.
spec.securityPolicy nil El controlador Ingress de GKE usa la configuración definida en el objeto BackendService configurado a través de la API de Compute Engine mediante la consola Google Cloud , la CLI de gcloud o Terraform.

Para configurar Ingress de GKE con la protección de Google Cloud Armor, consulta Ingress habilitado para Google Cloud Armor.

Registro de acceso HTTP

La entrada puede registrar todas las solicitudes HTTP de los clientes en Cloud Logging. Puedes habilitar e inhabilitar el registro de acceso mediante BackendConfig, así como definir la frecuencia de muestreo del registro de acceso.

Para configurar el registro de acceso, usa el campo logging en tu BackendConfig. Si se omite logging, el registro de acceso tendrá el comportamiento predeterminado. Esto depende de la versión de GKE.

Puedes configurar los siguientes campos:

  • enable: Si se define como true, se habilitará el registro de acceso para este Ingress y los registros estarán disponibles en Cloud Logging. De lo contrario, el registro de acceso estará inhabilitado para este Ingress.
  • sampleRate: especifica un valor entre 0,0 y 1,0, donde 0,0 significa que no se registran paquetes y 1,0 significa que se registra el 100% de los paquetes. Este campo solo es relevante si se asigna el valor true a enable. sampleRate es un campo opcional, pero si se configura, también se debe definir enable: true. De lo contrario, se interpretará como enable: false.

El siguiente manifiesto de BackendConfig habilita el registro de acceso y define la frecuencia de muestreo en el 50% de las solicitudes HTTP de un recurso Ingress determinado:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

Identity-Aware Proxy

Para configurar BackendConfig para Identity-Aware Proxy (IAP), debes especificar los valores enabled y secretName en el bloque iap de BackendConfig. Para especificar estos valores, asegúrate de que el agente de servicio de GKE tenga el permiso compute.backendServices.update.

El siguiente manifiesto de BackendConfig habilita Identity-Aware Proxy:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

Habilitar IAP con el cliente de OAuth gestionado por Google

A partir de GKE 1.29.4-gke.1043000, IAP se puede configurar para usar el cliente de OAuth gestionado por Google mediante un BackendConfig. Para decidir si quieres usar el cliente de OAuth gestionado por Google o un cliente de OAuth personalizado, consulta la sección Cuándo usar una configuración de OAuth personalizada de la documentación de IAP.

Para habilitar IAP con el cliente de OAuth gestionado por Google, no proporciones OAuthCredentials en BackendConfig. Los usuarios que ya hayan configurado IAP con OAuthCredentials no podrán cambiar al cliente de OAuth gestionado por Google. Deberán volver a crear el backend (quitar el servicio del Ingress y volver a adjuntarlo). Te recomendamos que realices esta operación durante una ventana de mantenimiento, ya que provocará un tiempo de inactividad. También se puede hacer la migración en sentido contrario, es decir, cambiar del cliente de OAuth gestionado por Google a OAuthCredentials.

El siguiente manifiesto de BackendConfig habilita Identity-Aware Proxy con el cliente de OAuth gestionado por Google:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true

Para ver las instrucciones completas, consulta el artículo Habilitar IAP en GKE de la documentación de IAP.

Identity-Aware Proxy con Ingress interno

Para configurar el Ingress interno de IAP, debes usar el nivel Premium. Si no usas el nivel Premium, no puedes ver ni crear balanceadores de carga de aplicaciones internos con Identity-Aware Proxy. También debes tener una suscripción a Chrome Enterprise Premium para usar el acceso interno para IAP.

Para configurar un Ingress de GKE seguro con autenticación basada en Identity-Aware Proxy, consulta el ejemplo Ingress habilitado para IAP.

Afinidad de sesión

Puedes usar un BackendConfig para definir la afinidad de sesión con la IP del cliente o con una cookie generada.

Afinidad de IP de cliente

Para usar un BackendConfig para definir la afinidad de IP de cliente, asigna el valor "CLIENT_IP" a affinityType, como se muestra en el siguiente ejemplo:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

Para usar un BackendConfig para definir la afinidad de cookies generada, asigna el valor affinityType a GENERATED_COOKIE en el manifiesto de BackendConfig. También puedes usar affinityCookieTtlSec para definir el periodo durante el que la cookie permanecerá activa.

El siguiente manifiesto define el tipo de afinidad como cookie generada y asigna a las cookies un TTL de 50 segundos:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

Encabezados de solicitud definidos por el usuario

Puedes usar un BackendConfig para configurar encabezados de solicitud definidos por el usuario. El balanceador de carga añade los encabezados que especifiques a las solicitudes que reenvía a los backends.

El balanceador de carga añade encabezados de solicitud personalizados solo a las solicitudes de los clientes, no a las comprobaciones del estado. Si tu backend requiere un encabezado específico para la autorización que falta en el paquete de comprobación del estado, es posible que la comprobación del estado falle.

Para habilitar los encabezados de solicitud definidos por el usuario, especifique una lista de encabezados en la propiedad customRequestHeaders del recurso BackendConfig. Especifica cada encabezado como una cadena header-name:header-value.

El siguiente manifiesto de BackendConfig añade tres encabezados de solicitud:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

Encabezados de respuesta personalizados

Para habilitar los encabezados de respuesta personalizados, especifica una lista de encabezados en la propiedad customResponseHeaders del recurso BackendConfig. Especifica cada encabezado como una cadena header-name:header-value.

Los encabezados de respuesta personalizados solo están disponibles en clústeres de GKE con la versión 1.25 o posterior.

El siguiente manifiesto de BackendConfig es un ejemplo para añadir una cabecera de respuesta HTTP Strict Transport Security (HSTS):

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customResponseHeaders:
    headers:
    - "Strict-Transport-Security: max-age=28800; includeSubDomains"

Ejercicio: configurar los tiempos de espera de Ingress mediante un servicio de backend

En el siguiente ejercicio se muestran los pasos necesarios para configurar los tiempos de espera y el drenaje de conexiones con un recurso Ingress con un recurso BackendConfig.

Para configurar las propiedades de backend de un Ingress, complete las siguientes tareas:

  1. Crea un despliegue.
  2. Crea un BackendConfig.
  3. Crea un servicio y asocia uno de sus puertos a BackendConfig.
  4. Crea un objeto Ingress y asócialo al par (Service, port).
  5. Valida las propiedades del servicio de backend.
  6. Liberar espacio.

Creando un despliegue

Antes de crear un BackendConfig y un Service, debes crear un Deployment.

El siguiente es un ejemplo de manifiesto de una implementación llamada my-deployment.yaml:

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Para crear el Deployment, ejecuta el siguiente comando:

kubectl apply -f my-deployment.yaml

Crear un BackendConfig

Usa tu BackendConfig para especificar las funciones de Ingress que quieras usar.

Este manifiesto de BackendConfig, llamado my-backendconfig.yaml, especifica lo siguiente:

  • Un tiempo de espera de 40 segundos.
  • Tiempo de espera de 60 segundos para la purga de conexiones.
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

Para crear el recurso BackendConfig, ejecuta el siguiente comando:

kubectl apply -f my-backendconfig.yaml

Crear un servicio

Un BackendConfig corresponde a una sola combinación de servicio y puerto, aunque un servicio tenga varios puertos. Cada puerto se puede asociar a un solo CRD BackendConfig. Si un Ingress hace referencia a un puerto de servicio y este está asociado a un BackendConfig, el servicio de backend de balanceo de carga HTTP(S) toma parte de su configuración del BackendConfig.

A continuación, se muestra un ejemplo de manifiesto de servicio llamado my-service.yaml:

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  # Associate the Service with Pods that have the same label.
  labels:
    purpose: bsc-config-demo
  annotations:
    # Associate TCP port 80 with a BackendConfig.
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  # Forward requests from port 80 in the Service to port 8080 in a member Pod.
  - port: 80
    protocol: TCP
    targetPort: 8080

La anotación cloud.google.com/backend-config especifica una asignación entre puertos y objetos BackendConfig. En my-service.yaml:

  • Todos los pods que tengan la etiqueta purpose: bsc-config-demo son miembros del servicio.
  • El puerto TCP 80 del servicio está asociado a un BackendConfig llamado my-backendconfig. La anotación cloud.google.com/backend-config especifica este comportamiento.
  • Una solicitud enviada al puerto 80 del servicio se reenvía a uno de los pods miembros en el puerto 8080.

Para crear el servicio, ejecuta el siguiente comando:

kubectl apply -f my-service.yaml

Crear un objeto Ingress

A continuación, se muestra un manifiesto de Ingress llamado my-ingress.yaml.. En este ejemplo, las solicitudes entrantes se dirigen al puerto 80 del servicio llamado my-service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  # Route all HTTP requests to port 80 in a Service.
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-service
            port:
              number: 80

Para crear el Ingress, ejecuta el siguiente comando:

kubectl apply -f my-ingress.yaml

Espera unos minutos a que el controlador Ingress configure un balanceador de carga de aplicaciones externo y un servicio de backend asociado. Una vez completado este proceso, habrás configurado tu Ingress para que use un tiempo de espera de 40 segundos y un tiempo de espera hasta la desconexión de 60 segundos.

Validar propiedades de servicios de backend

Puedes validar que se han aplicado los ajustes correctos del balanceador de carga a través de BackendConfig. Para ello, identifica el servicio backend que ha implementado Ingress e inspecciona su configuración para comprobar que coincide con los manifiestos de Deployment.

Primero, describe el recurso my-ingress y filtra la anotación que enumera los servicios backend asociados al Ingress. Por ejemplo:

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

Debería aparecer lo siguiente:

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

El resultado proporciona información sobre tus servicios backend. Por ejemplo, esta anotación contiene dos servicios de backend:

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY" proporciona información sobre el servicio de backend asociado al servicio de Kubernetes my-service.
    • k8s1-27fde173 es un hash que se usa para describir el clúster.
    • default es el espacio de nombres de Kubernetes.
    • HEALTHY indica que el backend está en buen estado.
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY" Proporciona información sobre el servicio backend asociado al backend predeterminado (servidor 404).
    • k8s1-27fde173 es un hash que se usa para describir el clúster.
    • kube-system es el espacio de nombres.
    • default-http-backend es el nombre del servicio de Kubernetes.
    • 80 es el puerto del host.
    • HEALTHY indica que el backend está en buen estado.

A continuación, inspecciona el servicio de backend asociado a my-service con gcloud. Filtra por "drainingTimeoutSec" y "timeoutSec" para confirmar que se han definido en el plano de control de Google Cloud Load Balancer. Por ejemplo:

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

Resultado:

  drainingTimeoutSec: 60
  timeoutSec: 40

Si ves drainingTimeoutSec y timeoutSec en el resultado, significa que sus valores se han definido correctamente a través de BackendConfig.

Eliminar los recursos utilizados

Para evitar que se apliquen cargos no deseados en tu cuenta, elimina los objetos de Kubernetes que has creado para este ejercicio:

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

Limitaciones de BackendConfig

Los BackendConfigs tienen las siguientes limitaciones:

  • Solo un par (servicio, puerto) puede consumir un solo BackendConfig, aunque varios objetos Ingress hagan referencia al par (servicio, puerto). Esto significa que todos los objetos Ingress que hagan referencia al mismo servicio y puerto deben usar la misma configuración para Cloud Armor, IAP y Cloud CDN.

  • No se pueden habilitar IAP y Cloud CDN en el mismo servicio de backend de balanceo de carga de HTTP(S). Esto significa que no puedes configurar tanto IAP como Cloud CDN en el mismo BackendConfig.

  • Debes usar kubectl 1.7 o una versión posterior para interactuar con BackendConfig.

Eliminar la configuración especificada en un FrontendConfig o un BackendConfig

Para revocar una función de Ingress, debes inhabilitar explícitamente la configuración de la función en el CRD FrontendConfig o BackendConfig. El controlador Ingress solo reconcilia las configuraciones especificadas en estos CRDs.

Para borrar o inhabilitar una configuración que se haya habilitado anteriormente, asigne al campo el valor de una cadena vacía ("") o el valor booleano false, en función del tipo de campo.

El siguiente manifiesto de BackendConfig inhabilita una política de seguridad de Google Cloud Armor y Cloud CDN:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

Eliminar un FrontendConfig o un BackendConfig

FrontendConfig

Para eliminar un FrontendConfig, sigue estos pasos:

  1. Quita el nombre de FrontendConfig de la anotación networking.gke.io/v1beta1.FrontendConfig en el manifiesto de Ingress.

  2. Aplica el manifiesto de Ingress modificado a tu clúster. Por ejemplo, usa kubectl apply.

  3. Elimina el FrontendConfig. Por ejemplo, usa kubectl delete frontendconfig config my-frontendconfig.

BackendConfig

Para eliminar un BackedConfig, sigue estos pasos:

  1. Quita el nombre de BackendConfig de la anotación cloud.google.com/backend-config en el manifiesto de Service.

  2. Aplica el manifiesto de Service modificado a tu clúster. Por ejemplo, usa kubectl apply.

  3. Elimina el BackendConfig. Por ejemplo, usa kubectl delete backendconfig my-backendconfig.

Solución de problemas

Puedes detectar errores de configuración habituales con la herramienta de diagnóstico de Ingress. También debes asegurarte de que las comprobaciones del estado estén configuradas correctamente.

No se ha encontrado BackendConfig

Este error se produce cuando se especifica un BackendConfig para un puerto de servicio en la anotación Service, pero no se ha encontrado el recurso BackendConfig.

Para evaluar un evento de Kubernetes, ejecuta el siguiente comando:

kubectl get event

El siguiente ejemplo de resultado indica que no se ha encontrado tu BackendConfig:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

Para solucionar este problema, asegúrate de que no hayas creado el recurso BackendConfig en el espacio de nombres incorrecto o de que no hayas escrito mal su referencia en la anotación Service.

No se ha encontrado la política de seguridad de entrada

Una vez creado el objeto Ingress, si la política de seguridad no se asocia correctamente al servicio LoadBalancer, evalúa el evento de Kubernetes para ver si hay algún error de configuración. Si tu BackendConfig especifica una política de seguridad que no existe, se emitirá periódicamente un evento de advertencia.

Para evaluar un evento de Kubernetes, ejecuta el siguiente comando:

kubectl get event

El siguiente ejemplo de salida indica que no se ha encontrado tu política de seguridad:

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

Para solucionar este problema, especifique el nombre correcto de la política de seguridad en su BackendConfig.

Solucionar errores de la serie 500 con NEGs durante el escalado de cargas de trabajo en GKE

Síntoma:

Cuando usas NEGs aprovisionados de GKE para el balanceo de carga, es posible que se produzcan errores 502 o 503 en los servicios durante la reducción de la carga de trabajo. Los errores 502 se producen cuando los pods se terminan antes de que se cierren las conexiones existentes, mientras que los errores 503 se producen cuando el tráfico se dirige a pods eliminados.

Este problema puede afectar a los clústeres si usas productos de balanceo de carga gestionados de GKE que utilizan NEGs, como Gateway, Ingress y NEGs independientes. Si sueles escalar tus cargas de trabajo, tu clúster corre un mayor riesgo de verse afectado.

Diagnóstico:

Si eliminas un pod en Kubernetes sin vaciar su endpoint y quitarlo del NEG primero, se producirán errores de la serie 500. Para evitar problemas durante la finalización de los pods, debes tener en cuenta el orden de las operaciones. En las siguientes imágenes se muestran situaciones en las que BackendService Drain Timeout no está definido y en las que BackendService Drain Timeout está definido con BackendConfig.

Situación 1: BackendService Drain Timeout no está definida.

En la siguiente imagen se muestra un caso en el que BackendService Drain Timeout no está definido.

No se ha definido el tiempo de espera de drenaje de BackendService.

Situación 2: se ha definido BackendService Drain Timeout.

En la siguiente imagen se muestra un caso en el que se ha definido el BackendService Drain Timeout.

Se ha definido el tiempo de espera de Drain de BackendService.

El momento exacto en el que se producen los errores de la serie 500 depende de los siguientes factores:

  • Latencia de separación de la API NEG: representa el tiempo que tarda en finalizar la operación de separación en Google Cloud. Esto depende de varios factores ajenos a Kubernetes, como el tipo de balanceador de carga y la zona específica.

  • Latencia de purga: es el tiempo que tarda el balanceador de carga en empezar a dirigir el tráfico lejos de una parte concreta de tu sistema. Una vez que se inicia el drenaje, el balanceador de carga deja de enviar nuevas solicitudes al endpoint. Sin embargo, sigue habiendo una latencia en el activador del drenaje (latencia de drenaje), lo que puede provocar errores 503 temporales si el pod ya no existe.

  • Configuración de la comprobación del estado: los umbrales de comprobación del estado más sensibles reducen la duración de los errores 503, ya que pueden indicar al balanceador de carga que deje de enviar solicitudes a los endpoints aunque la operación de separación no haya finalizado.

  • Periodo de gracia de finalización: determina el tiempo máximo que se le da a un pod para salir. Sin embargo, un pod puede salir antes de que finalice el periodo de gracia de finalización. Si un pod tarda más de este periodo, se le obliga a salir al final del mismo. Este es un ajuste del pod y debe configurarse en la definición de la carga de trabajo.

Posible solución:

Para evitar esos errores 5XX, aplica los siguientes ajustes. Los valores de tiempo de espera son orientativos y puede que tengas que ajustarlos a tu aplicación específica. En la siguiente sección se explica el proceso de personalización.

En la siguiente imagen se muestra cómo mantener activo el Pod con un gancho preStop:

Se ha definido el tiempo de espera de Drain de BackendService.

Para evitar errores de la serie 500, sigue estos pasos:

  1. Define el BackendService Drain Timeout de tu servicio en 1 minuto.

  2. Prolonga la terminationGracePeriod en el Pod.

    Define el terminationGracePeriodSeconds en el Pod en 3,5 minutos. Si se combina con los ajustes recomendados, tus pods tendrán entre 30 y 45 segundos para apagarse correctamente después de que se haya eliminado el endpoint del pod del NEG. Si necesitas más tiempo para el cierre gradual, puedes ampliar el periodo de gracia o seguir las instrucciones que se indican en la sección Personalizar tiempos de espera.

    El siguiente manifiesto de Pod especifica un tiempo de espera hasta la desconexión de 210 segundos (3,5 minutos):

    spec:
  terminationGracePeriodSeconds: 210
  containers:
  - name: my-app
    ...
  ...

  3. Aplica un hook de preStop a todos los contenedores.

    Aplica un gancho preStop que asegure que el pod esté activo durante 120 segundos más mientras se agota el punto final del pod en el balanceador de carga y se elimina del NEG.

    necesario.
    spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 120s"]
  ...

Personalizar los tiempos de espera

Para asegurar la continuidad del pod y evitar errores de la serie 500, el pod debe estar activo hasta que se elimine el endpoint del NEG. Para evitar los errores 502 y 503, te recomendamos que implementes una combinación de tiempos de espera y un gancho preStop.

Para que el Pod siga funcionando durante más tiempo durante el proceso de apagado, añade un preStop hook al Pod. Ejecuta el hook preStop antes de que se le indique a un pod que salga, de modo que el hook preStop se pueda usar para mantener el pod activo hasta que se quite su endpoint correspondiente del NEG.

Para ampliar el tiempo que un Pod permanece activo durante el proceso de apagado, inserta un hook preStop en la configuración del Pod de la siguiente manera:

spec:
  containers:
  - name: my-app
    ...
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep <latency time>"]

Puedes configurar los tiempos de espera y los ajustes relacionados para gestionar el cierre correcto de los pods durante las reducciones de escala de las cargas de trabajo. Puedes ajustar los tiempos de espera en función de casos prácticos específicos. Te recomendamos que empieces con tiempos de espera más largos y que reduzcas la duración según sea necesario. Puedes personalizar los tiempos de espera configurando los parámetros relacionados con el tiempo de espera y el gancho preStop de las siguientes formas:

Tiempo de espera de drenaje del servicio de backend

El parámetro Backend Service Drain Timeout no está definido de forma predeterminada y no tiene ningún efecto. Si define el parámetro Backend Service Drain Timeout y lo activa, el balanceador de carga dejará de enrutar nuevas solicitudes al endpoint y esperará el tiempo de espera antes de finalizar las conexiones.

Puedes definir el parámetro Backend Service Drain Timeout mediante BackendConfig con Ingress, GCPBackendPolicy con Gateway o manualmente en BackendService con NEGs independientes. El tiempo de espera debe ser entre 1,5 y 2 veces mayor que el tiempo que se tarda en procesar una solicitud. De esta forma, si se recibe una solicitud justo antes de que se inicie el drenaje, se completará antes de que finalice el tiempo de espera. Si asigna al parámetro Backend Service Drain Timeout un valor superior a 0, se reducen los errores 503 porque no se envían nuevas solicitudes a los endpoints que se van a retirar. Para que este tiempo de espera sea efectivo, debes usarlo con el hook preStop para asegurarte de que el pod permanezca activo mientras se produce el drenaje. Sin esta combinación, las solicitudes que no se hayan completado recibirán un error 502.

preStop Tiempo de enganche

El hook preStop debe retrasar el cierre del pod lo suficiente para que se completen tanto la latencia de drenaje como el tiempo de espera de drenaje del servicio backend, lo que asegura que se produzca un drenaje de conexión adecuado y que se elimine el endpoint del NEG antes de que se cierre el pod.

Para obtener resultados óptimos, asegúrate de que el tiempo de ejecución del gancho preStop sea mayor o igual que la suma de la latencia de Backend Service Drain Timeout y la latencia de drenaje.

Calcula el tiempo de ejecución ideal de tu preStop hook con la siguiente fórmula:

preStop hook execution time >= BACKEND_SERVICE_DRAIN_TIMEOUT + DRAIN_LATENCY

Haz los cambios siguientes:

  • BACKEND_SERVICE_DRAIN_TIMEOUT: la hora que hayas configurado para Backend Service Drain Timeout.
  • DRAIN_LATENCY: tiempo estimado de latencia de vaciado. Te recomendamos que uses un minuto como estimación.

Si persisten 500 errores, calcula la duración total de la incidencia y añade el doble de ese tiempo a la latencia de purga estimada. De esta forma, te aseguras de que tu Pod tenga tiempo suficiente para agotar las pilas correctamente antes de que se retire del servicio. Puedes ajustar este valor si es demasiado largo para tu caso práctico específico.

También puedes estimar el tiempo examinando la marca de tiempo de eliminación del pod y la marca de tiempo en la que se quitó el endpoint del NEG en los registros de auditoría de Cloud.

Parámetro TerminationGracePeriod

Debes configurar el parámetro terminationGracePeriod para que el hook preStop tenga tiempo suficiente para finalizar y el pod pueda completar un cierre ordenado.

De forma predeterminada, si no se define explícitamente, el valor de terminationGracePeriod es de 30 segundos. Puedes calcular el terminationGracePeriod óptimo con la siguiente fórmula:

terminationGracePeriod >= preStop hook time + Pod shutdown time

Para definir terminationGracePeriod en la configuración del pod, haz lo siguiente:

  spec:
    terminationGracePeriodSeconds: <terminationGracePeriod>
    containers:
    - name: my-app
      ...
    ...

No se ha encontrado ningún NEG al crear un recurso Internal Ingress

Puede producirse el siguiente error al crear un Ingress interno en GKE:

Error syncing: error running backend syncing routine: googleapi: Error 404: The resource 'projects/PROJECT_ID/zones/ZONE/networkEndpointGroups/NEG' was not found, notFound

Este error se produce porque Ingress para balanceadores de carga de aplicaciones internos requiere grupos de puntos de conexión de red (NEGs) como backends.

En los entornos de VPC compartida o en los clústeres con políticas de red habilitadas, añade la anotación cloud.google.com/neg: '{"ingress": true}' al manifiesto de Service.

504 Gateway Timeout: tiempo de espera de solicitud upstream agotado

Puede producirse el siguiente error al acceder a un servicio desde un Ingress interno en GKE:

HTTP/1.1 504 Gateway Timeout
content-length: 24
content-type: text/plain

upsteam request timeout

Este error se produce porque el tráfico enviado a los balanceadores de carga de aplicaciones internos se envía a través de proxies Envoy en el intervalo de subredes de solo proxy.

Para permitir el tráfico del intervalo de la subred de solo proxy, crea una regla de cortafuegos en el targetPort del servicio.

Error 400: Invalid value for field 'resource.target' (Valor no válido para el campo "resource.target")

Puede producirse el siguiente error al acceder a un servicio desde un Ingress interno en GKE:

Error syncing:LB_NAME does not exist: googleapi: Error 400: Invalid value for field 'resource.target': 'https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/regions/REGION_NAME/targetHttpProxies/LB_NAME. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.

Para solucionar este problema, crea una subred de solo proxy.

Error durante la sincronización: error al ejecutar la rutina de sincronización del balanceador de carga: el balanceador de carga no existe

Puede producirse uno de los siguientes errores cuando se actualiza el plano de control de GKE o cuando se modifica un objeto Ingress:

"Error during sync: error running load balancer syncing routine: loadbalancer
INGRESS_NAME does not exist: invalid ingress frontend configuration, please
check your usage of the 'kubernetes.io/ingress.allow-http' annotation."

O:

Error during sync: error running load balancer syncing routine: loadbalancer LOAD_BALANCER_NAME does not exist:
googleapi: Error 400: Invalid value for field 'resource.IPAddress':'INGRESS_VIP'. Specified IP address is in-use and would result in a conflict., invalid

Para solucionar estos problemas, sigue estos pasos:

  • Añade el campo hosts en la sección tls del manifiesto de Ingress y, a continuación, elimina el Ingress. Espera cinco minutos a que GKE elimine los recursos de Ingress no utilizados. A continuación, vuelve a crear el Ingress. Para obtener más información, consulta El campo hosts de un objeto Ingress.
  • Deshace los cambios que hayas hecho en el Ingress. A continuación, añade un certificado mediante una anotación o un secreto de Kubernetes.

Problemas conocidos

No se pueden habilitar las redirecciones HTTPS con el esquema de nomenclatura de Ingress V1

No puedes habilitar las redirecciones HTTPS en los recursos Ingress de GKE creados en GKE 1.16.8-gke.12 y versiones anteriores. Debes volver a crear el objeto Ingress antes de poder habilitar las redirecciones HTTPS. De lo contrario, se creará un evento de error y el objeto Ingress no se sincronizará.

El mensaje del evento de error es similar al siguiente:

Error syncing: error running load balancer syncing routine: loadbalancer lb-name does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with the V1 Ingress naming scheme. Please recreate your ingress to use the newest naming scheme.

Campos de la política de seguridad de Google Cloud Armor eliminados de BackendConfig

Hay un problema conocido que provoca que, al actualizar un recurso BackendConfig mediante la API v1beta1 , se elimine una política de seguridad de Cloud Armor activa de su servicio. Este problema afecta a las siguientes versiones de GKE:

  • 1.18.19-gke.1400 a 1.18.20-gke.5099
  • 1.19.10-gke.700 a 1.19.14-gke.299
  • 1.20.6-gke.700 a 1.20.9-gke.899

Si no configuras Cloud Armor en tus recursos Ingress mediante BackendConfig, este problema no afectará a tus clústeres.

En los clústeres de GKE que configuran Cloud Armor a través de BackendConfig, se recomienda encarecidamente actualizar los recursos de BackendConfig solo mediante la API v1. Si aplicas un BackendConfig a tu clúster mediante recursos v1beta1 BackendConfig, se eliminará tu política de seguridad de Cloud Armor del servicio al que hace referencia.

Para mitigar este problema, solo puedes actualizar tu BackendConfig mediante la v1 API BackendConfig. v1 BackendConfig admite los mismos campos que v1beta1 y no introduce ningún cambio incompatible, por lo que el campo de la API se puede actualizar de forma transparente. Sustituye el campo apiVersion de cualquier manifiesto de BackendConfig activo por cloud.google.com/v1 y no uses cloud.google.com/v1beta1. El siguiente manifiesto de ejemplo describe un recurso BackendConfig que usa la API v1:

  apiVersion: cloud.google.com/v1
  kind: BackendConfig
  metadata:
    name: my-backend-config
  spec:
    securityPolicy:
      name: "ca-how-to-security-policy"

Si tienes sistemas o herramientas de CI/CD que actualizan periódicamente los recursos de BackendConfig, asegúrate de usar el grupo de APIs cloud.google.com/v1 en esos sistemas.

Si tu BackendConfig ya se ha actualizado con la API v1beta1, es posible que se haya eliminado tu política de seguridad de Cloud Armor. Para determinar si esto ha ocurrido, ejecuta el siguiente comando:

kubectl get backendconfigs -A -o json | jq -r '.items[] | select(.spec.securityPolicy == {}) | .metadata | "\(.namespace)/\(.name)"'

Si la respuesta devuelve un resultado, significa que tu clúster se ve afectado por el problema. El resultado de este comando devuelve una lista de recursos BackendConfig (<namespace>/<name>) que se ven afectados por el problema. Si la salida está vacía, significa que tu BackendConfig no se ha actualizado con la API v1beta1 desde que se introdujo el problema. Las futuras actualizaciones de BackendConfig solo deben usar v1.

Si se ha eliminado tu política de seguridad de Cloud Armor, puedes determinar cuándo se eliminó mediante la siguiente consulta de Logging:

resource.type="gce_backend_service"
protoPayload.methodName="v1.compute.backendServices.setSecurityPolicy"
protoPayload.authenticationInfo.principalEmail:"container-engine-robot.iam.gserviceaccount.com"
protoPayload.response.status = "RUNNING"
NOT protoPayload.authorizationInfo.permission:"compute.securityPolicies.use"

Si alguno de tus clústeres se ha visto afectado, puedes corregirlo enviando una actualización a tu recurso BackendConfig que use la API v1.

Actualiza tu plano de control de GKE a una de las siguientes versiones actualizadas que corrige este problema y permite usar de forma segura los recursos v1beta1BackendConfig:

  • 1.18.20-gke.5100 y versiones posteriores
  • 1.19.14-gke.300 y versiones posteriores
  • 1.20.9-gke.900 y versiones posteriores

Siguientes pasos