Configura recursos de la puerta de enlace mediante políticas

En esta página, se muestra cómo configurar el balanceador de cargas que crea Google Kubernetes Engine (GKE) cuando implementas una puerta de enlace en un clúster de GKE.

Cuando implementas una Gateway, la configuración de GatewayClass determina qué balanceador de cargas crea GKE. Este balanceador de cargas administrado está preconfigurado con una configuración predeterminada que puedes modificar mediante una Política.

Puedes personalizar los recursos de las puertas de enlace para que se adapten a tus requisitos de infraestructura o aplicación si adjuntas políticas a las puertas de enlace, Services o ServiceImports. Después de aplicar o modificar una política, no necesitas borrar ni volver a crear tus recursos de puerta de enlace, ruta o servicio, a través del controlador de puerta de enlace se procesa la política y el recurso del balanceador de cargas subyacente es el siguiente: (reconfigurado) de acuerdo con la nueva política.

Antes de comenzar

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

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Requisitos del controlador de la puerta de enlace de GKE

  • Para Standard, la versión 1.24 de GKE o una posterior.
  • Para Autopilot, versión 1.26 de GKE o posterior.
  • Versión 407.0.0 o posterior de Google Cloud CLI.
  • La API de la puerta de enlace solo es compatible con clústeres nativos de VPC.
  • Si usas las GatewayClasses internas, debes habilitar una subred de solo proxy.
  • El clúster debe tener el complemento HttpLoadBalancing habilitado.
  • Si usas Istio, debes actualizarlo a una de las siguientes versiones:
    • 1.15.2 o una versión posterior
    • 1.14.5 o una versión posterior
    • 1.13.9 o una versión posterior.
  • Si usas una VPC compartida, en el proyecto host, debes asignar el rol Compute Network User a la cuenta de servicio de GKE para el proyecto de servicio.

Restricciones y limitaciones

Además de las restricciones y limitaciones del controlador de puerta de enlace de GKE, las siguientes limitaciones se aplican específicamente a las políticas aplicadas en los recursos de puerta de enlace:

  • Los recursos GCPGatewayPolicy solo se pueden adjuntar a una Gateway gateway.networking.k8s.io.

  • Los recursos GCPGatewayPolicy deben existir en el mismo espacio de nombres que el Gateway de destino.

  • Cuando se usa una sola puerta de enlace de clúster, los recursos GCPBackendPolicy y HealthCheckPolicy, deben hacer referencia a un recurso Service.

  • Solo se puede conectar una GCPGatewayPolicy a un Service a la vez. Cuando se crean dos políticas GCPGatewayPolicy y se orientan a los mismos Service o ServiceImport, la política más antigua tendrá prioridad y no se conectará la segunda.

  • Las políticas jerárquicas no son compatibles con la puerta de enlace de GKE.

  • Los recursos HealthCheckPolicy y GCPBackendPolicy deben existir en el mismo espacio de nombres que los recursos de destino Service o ServiceImport

  • Los recursos GCPBackendPolicy y HealthCheckPolicy están estructurados de modo que puedan hacer referencia a un solo servicio de backend.

Configura políticas de SSL para proteger el tráfico entre el cliente y el balanceador de cargas

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

Para proteger el tráfico del cliente a un balanceador de cargas, configura la política de SSL mediante la adición del nombre de tu política a GCPGatewayPolicy. De forma predeterminada, la puerta de enlace no tiene ninguna política de SSL definida y adjunta.

Asegúrate de crear una política de SSL antes de hacer referencia a la política en tu GCPGatewayPolicy.

En el siguiente manifiesto de GCPGatewayPolicy, se especifica una política de seguridad llamada gke-gateway-ssl-policy:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: team1
spec:
  default:
    sslPolicy: gke-gateway-ssl-policy
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Configura las verificaciones de estado

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

Puedes usar una HealthCheckPolicy para controlar la configuración de la verificación de estado del balanceador de cargas. Cada tipo de verificación de estado (http, https, grpc y http2) tiene un parámetro que puedes definir. Google Cloud crea una verificación de estado única para cada servicio de backend de cada Service de GKE.

En el siguiente manifiesto de HealthCheckPolicy, se muestran todos los campos disponibles cuando configuras una política de verificación de estado:

Servicio

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Reemplaza lo siguiente:

  • INTERVAL: Especifica el intervalo de verificación, en segundos, para cada sistema de sondeo de verificación de estado. Abarca el tiempo desde el inicio de la verificación de un sondeador hasta el comienzo de la siguiente. Si omites este parámetro, el valor predeterminado de Google Cloud es de 5 segundos. Para obtener más información, consulta Varios sondeos y frecuencia.
  • TIMEOUT es la cantidad de tiempo que Google Cloud espera una respuesta a un sondeo. El valor de TIMEOUT debe ser menor o igual que INTERVAL. Las unidades son segundos. Cada sondeo requiere que se entregue un código de respuesta HTTP 200 (OK) antes de que se agote su tiempo de espera.
  • HEALTHY_THRESHOLDyUNHEALTHY_THRESHOLD: Especifica la cantidad de intentos de conexión secuenciales que deben completarse o fallar para, al menos, un sistema de sondeo, cambiar elestado En buen o mal estado. Si omites uno de estos parámetros, el valor predeterminado de Google Cloud es 2.
  • PROTOCOL: Especifica un protocolo que usan los sistemas de sondeo para la verificación de estado. Si deseas obtener más información, consulta Criterios de éxito para HTTP, HTTPS y HTTP/2 y Criterios de éxito para gRPC. Este parámetro es obligatorio.
  • ENABLED: Especifica si el registro está habilitado o inhabilitado.
  • PORT_SPECIFICATION: Especifica si la verificación de estado usa un puerto fijo (USE_FIXED_PORT), un puerto con nombre (USE_NAMED_PORT) o un puerto de entrega (USE_SERVING_PORT). Si no se especifica, la verificación de estado sigue el comportamiento especificado en los campos port y portName. Si no se especifican port ni portName, este campo se establece de forma predeterminada en USE_SERVING_PORT.
  • PORT: HealthCheckPolicy solo admite la especificación del puerto de verificación de estado del balanceador de cargas mediante un número de puerto. Si omites este parámetro, el valor predeterminado de Google Cloud es 80. Debido a que el balanceador de cargas envía sondeos directamente a la dirección IP del Pod, debes seleccionar un puerto que coincida con uncontainerPort de pods de entrega, incluso si elcontainerPort hace referencia a untargetPort del Servicio. No estás limitado a containerPorts a los que hace referencia un targetPort de Service.
  • PORT_NAME: Especifica el nombre del puerto como se define en InstanceGroup.NamedPort.name. Si se definen port y portName, Google Cloud considera el valor de port primero.
  • HOST: Es el valor del encabezado del host en la solicitud de verificación de estado. Este valor utiliza la definición RFC 1123 de un nombre de host, excepto que no se permitan las direcciones IP numéricas. Si no se especifica o se deja vacío, este valor se establece de forma predeterminada en la dirección IP de la verificación de estado.
  • REQUEST_PATH: Especifica la ruta de acceso de la solicitud de verificación de estado. Si no se especifica o se deja vacío, el valor predeterminado es /.
  • RESPONSE: Especifica los bytes que deben coincidir con el comienzo de los datos de respuesta. Si no se especifica o se deja vacío, GKE interpreta que cualquier respuesta está en buen estado. Los datos de respuesta solo pueden ser ASCII.
  • PROXY_HEADER: especifica el tipo de encabezado del proxy. Puedes usar NONE o PROXY_V1. La configuración predeterminada es NONE.
  • GRPC_SERVICE_NAME: Es un nombre opcional del servicio de gRPC. Omite este campo para especificar todos los Services.

Para obtener más información sobre los campos de HealthCheckPolicy, consulta la referencia de healthChecks.

Configura la política de seguridad del backend de Google Cloud Armor para proteger tus servicios de backend

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

Para configurar la política de seguridad de backend de Google Cloud Armor, agrega el nombre de tu política de seguridad a GCPBackendPolicy para proteger los servicios de backend. De forma predeterminada, la puerta de enlace no tiene ninguna política de seguridad de backend de Google Cloud Armor definida y adjunta.

Asegúrate de crear una política de seguridad de backend de Google Cloud Armor antes de hacer referencia a la política en tu GCPBackendPolicy.

En el siguiente manifiesto de GCPBackendPolicy, se especifica una política de seguridad de backend llamada example-security-policy:

Servicio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Configura IAP

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

Identity-Aware Proxy (IAP) aplica políticas de control de acceso a los servicios de backend asociados a una HTTPRoute. Con esta aplicación, solo los usuarios o las aplicaciones autenticados con el rol correcto de Identity and Access Management (IAM) pueden acceder a esos servicios de backend.

De forma predeterminada, no se aplica IAP a tus servicios de backend; debes configurar IAP de manera explícita en un GCPBackendPolicy.

Para configurar IAP con puerta de enlace, haz lo siguiente:

  1. Habilita IAP para GKENo configures el backend (Configura BackendConfig) porque BackendConfig solo es válido en el caso de una implementación de Ingress.

  2. Crea un secreto para tu IAP:

    1. En la consola de Google Cloud, ve a la página Credenciales.

      Ir a Credenciales

    2. Haz clic en el nombre del cliente y descarga el archivo de cliente de OAuth.

    3. En el archivo del cliente de OAuth, copia el secreto de OAuth en el portapapeles.

    4. Crea un archivo llamado iap-secret.txt.

    5. Pega el secreto de OAuth en el archivo iap-secret.txt mediante el siguiente comando:

      echo -n CLIENT_SECRET > iap-secret.txt
kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt

  3. Para especificar la política de IAP que hace referencia a un secreto:

    1. Crea el siguiente manifiesto GCPBackendPolicy y reemplaza SECRET_NAME y CLIENT_ID respectivamente. Guarda el manifiesto como backend-policy.yaml:

      Servicio

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  targetRef:
    group: ""
    kind: Service
    name: lb-service

      Servicio de varios clústeres

      apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  default:
    iap:
      enabled: true
      oauth2ClientSecret:
        name: SECRET_NAME
      clientID: CLIENT_ID
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

    2. Aplica el manifiesto backend-policy.yaml:

      kubectl apply -f backend-policy.yaml

  4. Verifica la configuración:

    1. Confirma que la política se aplicó después de crear tu GCPBackendPolicy con IAP:

      kubectl get gcpbackendpolicy

      El resultado es similar a este:

      NAME             AGE
backend-policy   45m

    2. Para obtener más detalles, usa el comando describe:

      kubectl describe gcpbackendpolicy

      El resultado es similar a este:

      Name:         backend-policy
Namespace:    default
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1
Kind:         GCPBackendPolicy
Metadata:
  Creation Timestamp:  2023-05-27T06:45:32Z
  Generation:          2
  Resource Version:    19780077
  UID:                 f4f60a3b-4bb2-4e12-8748-d3b310d9c8e5
Spec:
  Default:
    Iap:
      Client ID:  441323991697-luotsrnpboij65ebfr13hlcpm5a4heke.apps.googleusercontent.com
      Enabled:    true
      oauth2ClientSecret:
        Name:  my-iap-secret
  Target Ref:
    Group:
    Kind:   Service
    Name:   lb-service
Status:
  Conditions:
    Last Transition Time:  2023-05-27T06:48:25Z
    Message:
    Reason:                Attached
    Status:                True
    Type:                  Attached
Events:
  Type     Reason  Age                 From                   Message
  ----     ------  ----                ----                   -------
  Normal   ADD     46m                 sc-gateway-controller  default/backend-policy
  Normal   SYNC    44s (x15 over 43m)  sc-gateway-controller  Application of GCPGatewayPolicy "default/backend-policy" was a success

Configura el tiempo de espera del servicio de backend

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

En el siguiente manifiesto de GCPBackendPolicy, se especifica un período de tiempo de espera del servicio de backend de 40 segundos. El valor predeterminado del campo timeoutSec es de 30 segundos.

Servicio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Configura la afinidad de sesión

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

Puedes configurar la afinidad de sesión en función de los siguientes criterios:

  • Dirección IP de cliente
  • Cookie generada

Cuando configuras la afinidad de sesión para tu Service, la configuración localityLbPolicy de la puerta de enlace se establece en MAGLEV.

Cuando quitas una configuración de afinidad de sesión de GCPBackendPolicy, la puerta de enlace revierte la configuración de localityLbPolicy al valor predeterminado, ROUND_ROBIN. Este valor se establece de forma silenciosa en el servicio de backend administrado por GKE (adjunto al balanceador de cargas) y no se refleja en el resultado de un comando de la gcloud CLI, en la IU ni con Terraform.

En el siguiente manifiesto de GCPBackendPolicy, se especifica una afinidad de sesión basada en la dirección IP de cliente:

Servicio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

En el siguiente manifiesto de GCPBackendPolicy se especifica una afinidad de sesión basada en una cookie generada y se configura el TTL de las cookies a 50 segundos:

Servicio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Puedes usar las siguientes opciones parasessionAffinity.type: CLIENT_IP ,CLIENT_IP_PROTO, CLIENT_IP_PORT_PROTO, GENERATED_COOKIE, HEADER_FIELD ,HTTP_COOKIE, NONE.

Configura el tiempo de espera para el vaciado de conexiones

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

Puedes configurar el tiempo de espera del vaciado de conexiones mediante GCPBackendPolicy. El tiempo de espera para el vaciado de conexiones es el tiempo, en segundos, en que se espera a que las conexiones se agoten. La duración del tiempo de espera puede ser entre 0 y 3,600 segundos. El valor predeterminado es 0, lo que también inhabilita el vaciado de conexiones.

En el siguiente manifiesto de GCPBackendPolicy, se especifica un tiempo de espera para el vaciado de conexiones de 60 segundos:

Servicio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Durante la duración especificada del tiempo de espera, GKE espera a que se completen las solicitudes existentes al backend que se quitó. El balanceador de cargas no envía solicitudes nuevas al backend que se quitó. Una vez que transcurre el tiempo de espera, GKE cierra todas las conexiones restantes al backend.

Registro de acceso HTTP

En esta sección, se describe una funcionalidad que está disponible en los clústeres de GKE que ejecutan la versión 1.24 o posterior.

De forma predeterminada, se establecen estos ajustes:

  • El controlador de la puerta de enlace registra todas las solicitudes HTTP de los clientes en Cloud Logging.
  • La tasa de muestreo es 1,000,000, lo que significa que se registran todas las solicitudes.

Puedes inhabilitar el registro de acceso en la puerta de enlace a través de un GCPBackendPolicy de tres maneras:

  • Puedes salir de GCPBackendPolicy sin la sección logging.
  • Puedes configurar logging.enabled como false
  • Puedes configurar logging.enabled como true y establecer logging.sampleRate en 0

También puedes configurar la tasa de muestreo del registro de acceso.

Con el siguiente manifiesto de GCPBackendPolicy, se modifica la tasa de muestreo predeterminada del registro de acceso y se establece en el 50% de las solicitudes HTTP para un recurso Ingress determinado:

Servicio

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Este manifiesto tiene los siguientes campos:

  • enable: true: habilita el registro de acceso de forma explícita. Los registros están disponibles en Logging.
  • sampleRate: 500000: Especifica que se registra el 50% de los paquetes. Puedes usar un valor entre 0 y 1,000,000. GKE convierte este valor en un valor de punto flotante en el rango [0, 1] mediante la división por 1,000,000. Este campo solo es relevante si enable se configura como true. sampleRate es un campo opcional, pero, si está configurado, se debe establecer enable: true. Si enable no se proporciona como true y sampleRate no se proporciona, GKE establece enable en false.

Soluciona problemas

Varias GCPBackendPolicy conectadas al mismo Service

Síntoma:

La siguiente condición de estado puede ocurrir cuando conectas una GCPBackendPolicy a un Service o ServiceImport:

status:
  conditions:
    - lastTransitionTime: "2023-09-26T20:18:03Z"
      message: conflicted with GCPBackendPolicy "[POLICY_NAME]" of higher precedence, hence not applied
      reason: Conflicted
      status: "False"
      type: Attached

Motivo:

Esta condición de estado indica que intentas aplicar una segunda GCPBackendPolicy a un Service o ServiceImport que ya tiene una GCPBackendPolicy conectada.

Varias GCPBackendPolicy conectadas al mismo Service o ServiceImport no son compatibles con la puerta de enlace de GKE. Consulta Restricciones y limitaciones para obtener más detalles.

Solución alternativa:

Configura una sola GCPBackendPolicy que incluya todos los parámetros de configuración personalizados y conéctala a tu Service o ServiceImport.

¿Qué sigue?