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, el controlador de puerta de enlace la procesa y vuelve a configurar automáticamente el recurso del balanceador de cargas subyacente. Esto elimina la necesidad de borrar o volver a crear los recursos de puerta de enlace, ruta o servicio.

También puedes usar un BackendTLSPolicy para configurar los parámetros de configuración de TLS autenticado del backend y verificar la identidad de los backends a los que se conecta la puerta de enlace. Para obtener más información, consulta Configura TLS de backend.

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 el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se indican en este documento.

• Asegúrate de tener un clúster de Autopilot o Standard existente. Para crear un clúster nuevo, consulta Crea un clúster de Autopilot.

Requisitos del controlador de la puerta de enlace de GKE

• La API de Gateway solo es compatible con clústeres nativos de VPC.
• Si usas las GatewayClasses regionales o entre regiones, 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 un 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.

• Cuando se usa una puerta de enlace de varios clústeres, los recursos GCPBackendPolicy y HealthCheckPolicy deben hacer referencia a un recurso ServiceImport.

• Solo se puede conectar una GCPBackendPolicy a un Service a la vez. Cuando se crean dos políticas GCPBackendPolicy que se segmentan para el mismo Service o ServiceImport, la política más antigua tiene prioridad y la segunda no se puede adjuntar.

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

• GCPBackendPolicy no admite las opciones HEADER_FIELD ni HTTP_COOKIE para la afinidad de sesión. Para la afinidad de sesión HEADER_FIELD o HTTP_COOKIE, usa el recurso GCPTrafficDistributionPolicy.

• No uses el mismo Service de backend en diferentes puertas de enlace de tipos de GatewayClass distintos (como global frente a regional, interno frente a externo o administrado frente a clásico) si esas puertas de enlace requieren configuraciones incompatibles. Por ejemplo, un GCPBackendPolicy configurado con funciones no admitidas por una GatewayClass "clásica" no se puede aplicar a un Service que también se usa en una puerta de enlace "clásica". Para garantizar la configuración correcta, crea un objeto Service distinto para cada puerta de enlace que requiera una configuración de política diferente.

• La afinidad de sesión configurada con un GCPTrafficDistributionPolicy solo se admite para las Gateways de un solo clúster.

• La afinidad de sesión GCPTrafficDistributionPolicy no es compatible con los recursos InferencePool porque estos usan algoritmos de balanceo de cargas de localidad dedicados.

• GCPTrafficDistributionPolicy no admite la configuración de la afinidad de sesión ni las políticas de balanceo de cargas de localidad para el balanceador de cargas de aplicaciones clásico.

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

• Cuando se usa una puerta de enlace de varios clústeres, los recursos GCPBackendPolicy y HealthCheckPolicy deben hacer referencia a un recurso ServiceImport o GCPInferencePoolImport.

• Solo se puede adjuntar un GCPBackendPolicy a un solo recurso de destino (Service, ServiceImport, InferencePool o GCPInferencePoolImport) en un momento determinado. Cuando se crean varios recursos GCPBackendPolicy que se segmentan para el mismo recurso, la política más antigua tiene prioridad y no se puede adjuntar la más reciente.

• Los recursos HealthCheckPolicy y GCPBackendPolicy deben existir en el mismo espacio de nombres que el recurso de destino Service, ServiceImport, InferencePool o GCPInferencePoolImport.

• Los recursos GCPBackendPolicy y HealthCheckPolicy solo pueden segmentarse para un solo recurso (como un Service o un InferencePool).

Práctica recomendada: Crea un Service distinto para cada Gateway con una GatewayClass diferente para garantizar la compatibilidad entre las políticas del Service y el tipo de balanceador de cargas.

Configura el acceso global para la puerta de enlace interna regional

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 habilitar el acceso global con la puerta de enlace interna, adjunta una política al recurso de puerta de enlace.

En el siguiente manifiesto de GCPGatewayPolicy, se habilita la puerta de enlace interna regional para el acceso global:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    # Enable global access for the regional internal Application Load Balancer.
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Configura la región para tu puerta de enlace de varios clústeres

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

Si tu flota tiene clústeres en varias regiones, es posible que debas implementar Gateways regionales en diferentes regiones para una variedad de casos de uso, por ejemplo, redundancia entre regiones, baja latencia y soberanía de los datos. En el clúster de configuración de la puerta de enlace de varios clústeres, puedes especificar la región en la que deseas implementar las puertas de enlace regionales. Si no especificas una región, la región predeterminada es la del clúster de configuración.

Para configurar una región para tu puerta de enlace de varios clústeres, usa el campo region en GCPGatewayPolicy. En el siguiente ejemplo, la puerta de enlace se configura en la región us-central1:

apiVersion: networking.gke.io/v1
kind: GCPGatewayPolicy
metadata:
  name: my-gateway-policy
  namespace: default
spec:
  default:
    region: us-central1
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-regional-gateway

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

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

Para proteger el tráfico del cliente al balanceador de cargas, configura la política de SSL agregando el nombre de la política a GCPGatewayPolicy. De forma predeterminada, la puerta de enlace no tiene una 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 el recurso 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.

De forma predeterminada, para los servicios de backend que usan los protocolos de aplicación HTTP o kubernetes.io/h2c, el HealthCheck es de tipo HTTP. Para el protocolo HTTPS, el HealthCheck predeterminado es del tipo HTTPS. Para el protocolo HTTP2, el HealthCheck predeterminado es del tipo HTTP2.

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, http2 y tcp) tiene parámetros que puedes definir. Cloud de Confiance crea una verificación de estado única para cada servicio de backend de cada Service de GKE.

Para que el balanceador de cargas funcione con normalidad, es posible que debas configurar un HealthCheckPolicy personalizado para el balanceador de cargas si la ruta de verificación de estado no es la estándar "/". Esta configuración también es necesaria si la ruta requiere encabezados especiales o si necesitas ajustar los parámetros de verificación de estado. Por ejemplo, si la ruta de solicitud predeterminada es “/”, pero no se puede acceder a tu servicio en esa ruta de solicitud y, en cambio, se usa “/health” para informar su estado, debes configurar requestPath en tu HealthCheckPolicy según corresponda.

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

# Health check configuration for the load balancer. For more information
# about these fields, see https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  # The default and config fields control the health check configuration for the
  # load balancer. For more information about these fields, see
  # https://cloud.google.com/compute/docs/reference/rest/v1/healthChecks.
  default:
    checkIntervalSec: INTERVAL
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: ENABLED
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: HealthCheckPolicy
metadata:
  name: lb-healthcheck
  namespace: lb-service-namespace
spec:
  default:
    checkIntervalSec: INTERVAL  # The default value is 15 seconds.
    timeoutSec: TIMEOUT
    healthyThreshold: HEALTHY_THRESHOLD
    unhealthyThreshold: UNHEALTHY_THRESHOLD
    logConfig:
      enabled: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

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: true
    config:
      type: PROTOCOL
      httpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      httpsHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      grpcHealthCheck:
        grpcServiceName: GRPC_SERVICE_NAME
        portSpecification: PORT_SPECIFICATION
        port: PORT
      http2HealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        host: HOST
        requestPath: REQUEST_PATH
        response: RESPONSE
        proxyHeader: PROXY_HEADER
      tcpHealthCheck:
        portSpecification: PORT_SPECIFICATION
        port: PORT
        portName: PORT_NAME
        request: REQUEST
        response: RESPONSE
        proxyHeader: PROXY_HEADER
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

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 Cloud de Confiance es de 15 segundos si no se especifica ningún HealthCheckPolicy, y de 5 segundos cuando se especifica un HealthCheckPolicy sin ningún valor de checkIntervalSec. Para obtener más información, consulta Varios sondeos y frecuencia.
• TIMEOUT: Especifica la cantidad de tiempo queCloud de Confiance 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 Cloud de Confiance 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, Criterios de éxito para gRPC y Criterios de éxito para TCP. 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 el campo port. Si no se especifica port, 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 Cloud de Confiance 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 un containerPort de los Pods de entrega, incluso si el containerPort hace referencia a un targetPort del Service. No estás limitado a containerPorts a los que hace referencia un targetPort de Service.
• 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: Especifica los datos de la aplicación que se enviarán después de que se establezca la conexión TCP. Si no se especifica, el valor predeterminado es vacío. Si tanto la solicitud como la respuesta están vacías, la conexión establecida por sí sola indica el estado. Los datos de la solicitud solo pueden estar en formato ASCII.
• 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 de backend de 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 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 Cloud Armor definida y adjunta.

Asegúrate de crear una política de seguridad de backend de Cloud Armor antes de hacer referencia a la política en tu GCPBackendPolicy. Si habilitas una puerta de enlace regional, debes crear una política de seguridad de backend de Cloud Armor regional.

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Apply a Cloud Armor security policy.
    securityPolicy: example-security-policy
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    securityPolicy: example-security-policy
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Configura IAP

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. Obtén el ID de cliente y el secreto del cliente para tu cliente de OAuth. El secreto del cliente solo está disponible cuando creas tu cliente de OAuth. Para obtener más información, consulta Administra clientes de OAuth.

2. Habilita IAP para GKE.

   No es necesario que crees un BackendConfig, ya que BackendConfig es un recurso de configuración de Ingress.

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

   1. Guarda el siguiente manifiesto GCPBackendPolicy como backend-policy.yaml:

      Servicio

      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: backend-policy
      spec:
        default:
          # IAP OAuth2 settings. For more information about these fields,
          # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
          iap:
            enabled: true
            oauth2ClientSecret:
              name: CLIENT_SECRET
            clientID: CLIENT_ID
        # Attach to a Service in the cluster.
        targetRef:
          group: ""
          kind: Service
          name: SERVICE_NAME
      

      Reemplaza lo siguiente:

      • CLIENT_SECRET: El secreto del cliente de OAuth.
      • CLIENT_ID: Es el ID de cliente de OAuth.
      • SERVICE_NAME: Es el nombre del servicio al que se segmenta en GCPBackendPolicy.

      Servicio de varios clústeres

      apiVersion: networking.gke.io/v1
      kind: GCPBackendPolicy
      metadata:
        name: backend-policy
      spec:
        default:
          # IAP OAuth2 settings. For more information about these fields,
          # see https://cloud.google.com/iap/docs/reference/rest/v1/IapSettings#oauth2.
          iap:
            enabled: true
            oauth2ClientSecret:
              name: CLIENT_SECRET
            clientID: CLIENT_ID
        # Attach to a multi-cluster Service by referencing the ServiceImport.
        targetRef:
          group: net.gke.io
          kind: ServiceImport
          name: SERVICEIMPORT_NAME
      

      Reemplaza lo siguiente:

      • CLIENT_SECRET: El secreto del cliente de OAuth.
      • CLIENT_ID: Es el ID de cliente de OAuth.
      • SERVICEIMPORT_NAME: Es el nombre del ServiceImport al que se orienta en GCPBackendPolicy.

   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 GCPBackendPolicy "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.

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Backend service timeout, in seconds, for the load balancer. The default
    # value is 30.
    timeoutSec: 40
  # Attach to a Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    timeoutSec: 40
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Configura la selección de backend con GCPBackendPolicy

El modo de balanceo CUSTOM_METRICS dentro de GCPBackendPolicy te permite configurar métricas personalizadas específicas que influyen en cómo los servicios de backend de los balanceadores de cargas distribuyen el tráfico. Este modo de balanceo permite el balanceo de cargas basado en métricas personalizadas que defines y que informan los backends de la aplicación.

Para obtener más información, consulta Administración del tráfico con balanceo de cargas basado en métricas personalizadas.

El array customMetrics[], en el campo backends[], contiene los siguientes campos:

• name: Especifica el nombre definido por el usuario de la métrica personalizada.
• maxUtilization: Establece el uso objetivo o máximo para esta métrica. El rango válido es [0, 100].
• dryRun: Es un campo booleano. Cuando es verdadero, los datos de la métrica se registran en Cloud Monitoring, pero no influyen en las decisiones de balanceo de cargas.

Ejemplo

En el siguiente ejemplo, se muestra un manifiesto de GCPBackendPolicy que configura métricas personalizadas para la selección de backend y el enrutamiento a nivel del extremo.

1. Guarda el siguiente manifiesto como my-backend-policy.yaml:

   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: my-backend-policy
     namespace: team-awesome
   spec:
     # Attach to the super-service Service.
     targetRef:
       kind: Service
       name: super-service
     default:
       backends:
       # Configuration for all locations.
       - location: "*"
         # Use the rate balancing mode for the load balancer.
         balancingMode: RATE
         # Maximum number of requests per second for each endpoint.
         maxRatePerEndpoint: 9000
       # Configuration for us-central1-a
       - location: us-central1-a
         # maxRatePerEndpoint: 9000 inherited from the * configuration.
         # Use the custom metrics balancing mode for the load balancer.
         balancingMode: CUSTOM_METRICS
         # Configure the custom metrics for the load balancer to use.
         customMetrics:
         - name: gpu-load
           maxUtilizationPercent: 100 # value ranges from 0 to 100 and maps to the floating point range [0.0, 1.0]
           dryRun: false
   

2. Aplica el manifiesto al clúster:

   kubectl apply -f my-backend-policy.yaml
   

El balanceador de cargas distribuye el tráfico según el modo de balanceo RATE y la métrica personalizada gpu-load.

Configura el enrutamiento a nivel del extremo con GCPTrafficDistributionPolicy

La API de GCPTrafficDistributionPolicy en la puerta de enlace de Google Kubernetes Engine (GKE) proporciona capacidades avanzadas de administración del tráfico que permiten un control preciso sobre cómo se distribuye el tráfico a los Pods de tu aplicación. Este recurso unificado y nativo de GKE simplifica la administración de los algoritmos de balanceo de cargas y la configuración de afinidad de sesión.

El objeto GCPTrafficDistributionPolicy te permite configurar lo siguiente:

• Algoritmos de balanceo de cargas: Especifican cómo se distribuye el tráfico entre los extremos dentro de un backend.

  • WEIGHTED_ROUND_ROBIN: Cuando seleccionas este algoritmo, el balanceador de cargas usa métricas personalizadas para calcular los pesos y distribuir el tráfico según estas métricas informadas. El array customMetrics[] dentro de la configuración de GCPTrafficDistributionPolicy incluye los siguientes campos:

    • name: Especifica el nombre definido por el usuario de la métrica personalizada.
    • dryRun: Cuando es true, los datos de la métrica se informan a Cloud Monitoring, pero no influyen en el balanceo de cargas.

• RING_HASH: Este algoritmo es beneficioso para los servicios sensibles al rendimiento de la caché. Utiliza el hash coherente para minimizar la reasignación de solicitudes cuando se agregan o quitan Pods de backend, lo que ayuda a garantizar la estabilidad durante los eventos de escalamiento. Configurar un minimumHashRingSize proporciona una distribución de carga más detallada.

• Afinidad de sesión: Ayuda a garantizar que las solicitudes del mismo cliente se enruten de forma coherente al mismo pod de backend. Esto es fundamental para las cargas de trabajo con estado, como los carritos de compras de comercio electrónico o las sesiones de juegos. La puerta de enlace de GKE admite todos los tipos de afinidad de sesión disponibles en las instancias del balanceador de cargas de aplicacionesCloud de Confiance , incluidos HEADER_FIELD y HTTP_COOKIE.

Para obtener más información, consulta Administración del tráfico con balanceo de cargas basado en métricas personalizadas.

Ejemplo

En el siguiente ejemplo, se muestra un manifiesto de GCPTrafficDistributionPolicy que configura el enrutamiento a nivel del extremo con el algoritmo de balanceo de cargas WEIGHTED_ROUND_ROBIN y las métricas personalizadas.

1. Guarda el siguiente manifiesto de muestra como GCPTrafficDistributionPolicy.yaml:

   apiVersion: networking.gke.io/v1
   kind: GCPTrafficDistributionPolicy
   metadata:
     name: echoserver-v2
     namespace: team1
   spec:
     targetRefs:
     # Attach to the echoserver-v2 Service in the cluster.
     - kind: Service
       group: ""
       name: echoserver-v2
     default:
       # Use custom metrics to distribute traffic across endpoints.
       localityLbAlgorithm: WEIGHTED_ROUND_ROBIN
       # Configure metrics from an ORCA load report to use for traffic
       # distribution.
       customMetrics:
       - name: orca.named_metrics.bescm11
         dryRun: false
       - name: orca.named_metrics.bescm12
         dryRun: true
   

2. Aplica el manifiesto al clúster:

   kubectl apply -f GCPTrafficDistributionPolicy.yaml
   

El balanceador de cargas distribuye el tráfico a los extremos según el algoritmo WEIGHTED_ROUND_ROBIN y las métricas personalizadas proporcionadas.

Configura el tamaño del anillo de hash

Para los servicios en los que es fundamental minimizar las fallas de caché, usa el algoritmo RING_HASH. Ajustar minimumHashRingSize permite una distribución de carga más detallada en los backends. Si bien el balanceador de cargas administra automáticamente el tamaño del anillo, proporcionar un valor mínimo más alto puede ayudar a garantizar una distribución más uniforme de las solicitudes para conjuntos de backends más grandes.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: ring-hash-policy
  namespace: default
spec:
  default:
    localityLbAlgorithm: RING_HASH
    # Defaults to 1024. Larger ring sizes result in more granular
    # load distributions. Supported range is 1 to 2048.
    minimumHashRingSize: 1024
  targetRefs:
  -   group: ""
    kind: Service
    name: my-cache-heavy-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.

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # On a best-effort basis, send requests from a specific client IP address
    # to the same backend. This field also sets the load balancer locality
    # policy to MAGLEV. For more information, see
    # https://cloud.google.com/load-balancing/docs/backend-service#lb-locality-policy
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    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:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Include an HTTP cookie in the Set-Cookie header of the response.
    # This field also sets the load balancer locality policy to MAGLEV. For more
    # information, see
    # https://cloud.google.com/load-balancing/docs/l7-internal#generated_cookie_affinity.
    sessionAffinity:
      type: GENERATED_COOKIE
      cookieTtlSec: 50  # The cookie expires in 50 seconds.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Puedes usar los siguientes valores para la propiedad sessionAffinity.type:

• CLIENT_IP
• GENERATED_COOKIE
• NONE

Afinidad de sesión expandida con GCPTrafficDistributionPolicy

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

GKE Gateway admite tipos de afinidad de sesión expandidos con el recurso GCPTrafficDistributionPolicy. Esto proporciona un control más detallado, como el enrutamiento basado en encabezados HTTP personalizados o cookies generadas por el balanceador de cargas.

Nota: Para la afinidad de sesión avanzada, usa GCPTrafficDistributionPolicy. Si bien GCPBackendPolicy también admite ciertos tipos de afinidad de sesión, se considera una opción heredada para esta configuración. Si ambas políticas se dirigen al mismo servicio, la configuración de GCPTrafficDistributionPolicy tiene prioridad.

En la siguiente tabla, se describen los tipos de afinidad admitidos cuando se usa GCPTrafficDistributionPolicy:

Ejemplos ampliados de afinidad de sesión

GCPTrafficDistributionPolicy admite varios tipos de afinidad de sesión, cada uno con requisitos de configuración únicos.

Configura la afinidad de sesión basada en cookies HTTP

En el caso de las aplicaciones con estado, como los carritos de compras o los servidores de juegos, enruta las solicitudes al pod específico que contiene los datos de la sesión del usuario. Esta configuración usa la afinidad HTTP_COOKIE, que basa la afinidad de sesión en una cookie específica generada por el balanceador de cargas y que se devuelve al cliente en un encabezado Set-Cookie.

1. Guarda el siguiente manifiesto como policy.yaml:

   apiVersion: networking.gke.io/v1
   kind: GCPTrafficDistributionPolicy
   metadata:
     name: http-cookie-affinity-policy
     namespace: default
   spec:
     default:
       sessionAffinity:
         type: HTTP_COOKIE
         cookie:
           name: "my-app-session-id"
           ttl: "1h"
           path: "/"
       # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
       localityLbAlgorithm: MAGLEV
     targetRefs:
     -   group: ""
       kind: Service
       name: my-stateful-service
   

2. Aplica la política a tu clúster:

   kubectl apply -f policy.yaml
   

Comportamiento del TTL cero para la afinidad de sesión basada en cookies:

Todas las afinidades de sesión basadas en cookies, como la afinidad de GENERATED_COOKIE y HTTP_COOKIE, tienen un atributo ttl.

Un TTL de cero segundos significa que el balanceador de cargas no asigna un atributo Expires a la cookie. En este caso, el cliente trata la cookie como una cookie de sesión. La definición de una sesión varía según el cliente:

• Algunos clientes, como los navegadores web, conservan la cookie durante toda la sesión de navegación. Esto significa que la cookie persiste en varias solicitudes hasta que se cierra la aplicación.
• Otros clientes tratan una sesión como una sola solicitud HTTP y descartan la cookie inmediatamente después.

Configura la afinidad de sesión basada en encabezados

Enruta el tráfico según un encabezado HTTP específico para situaciones como las pruebas A/B o el enrutamiento de clientes especializados en las que una cookie no es adecuada. Para usar tipos de afinidad de sesión distintos de NONE, debes establecer localityLbAlgorithm en MAGLEV o RING_HASH. A diferencia del ROUND_ROBIN predeterminado, estos algoritmos admiten el hash coherente basado en campos personalizados, como los encabezados HTTP.

1. Guarda el siguiente manifiesto como policy.yaml:

   apiVersion: networking.gke.io/v1
   kind: GCPTrafficDistributionPolicy
   metadata:
     name: header-affinity-policy
     namespace: default
   spec:
     default:
       sessionAffinity:
         type: HEADER_FIELD
         httpHeaderName: "X-User-Group-ID"
       localityLbAlgorithm: MAGLEV
     targetRefs:
     -   group: ""
       kind: Service
       name: SERVICE_NAME
   

2. Aplica la política a tu clúster:

   kubectl apply -f policy.yaml
   

Verifica la política

Para asegurarte de que tu GCPTrafficDistributionPolicy esté configurado y activo correctamente, verifica su estado después de aplicarlo.

1. Para verificar el estado de la política, descríbela:

   kubectl describe gcptrafficdistributionpolicy POLICY_NAME
   

   Reemplaza POLICY_NAME por el nombre de tu política.

2. En el resultado, busca la sección Conditions. El estado True con el motivo Attached indica que la configuración es válida y se aplicó.

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:

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

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

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    connectionDraining:
      drainingTimeoutSec: 60
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

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.
• No se registran campos opcionales.

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 y una lista de campos opcionales, por ejemplo, "tls.cipher" o "orca_load_report".

Para habilitar el registro de los campos opcionales, haz lo siguiente:

• Establece logging.OptionalMode en CUSTOM.
• Proporciona la lista de campos opcionales que se registrarán en logging.optionalFields. Consulta Logging y Monitoring para ver la lista de campos admitidos.

Puedes inhabilitar el registro de los campos opcionales de dos maneras:

• Puedes quitar todas las entradas de logging.optionalFields.
• Puedes configurar logging.OptionalMode como EXCLUDE_ALL_OPTIONAL.

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. El manifiesto también habilita el registro de dos campos opcionales para un recurso Service determinado:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: ""
    kind: Service
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: my-backend-policy
  namespace: lb-service-namespace
spec:
  default:
    # Access logging configuration for the load balancer.
    logging:
      enabled: true
      # Log 50% of the requests. The value must be an integer between 0 and
      # 1000000. To get the proportion of requests to log, GKE
      # divides this value by 1000000.
      sampleRate: 500000
      # Log specific optional fields.
      optionalMode: CUSTOM
      optionalFields:
      - tls.cipher
      - orca_load_report.cpu_utilization
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

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 se establece en true y no se proporciona sampleRate, GKE establece enable en false.
• optionalMode: CUSTOM: Especifica que se debe incluir un conjunto de optionalFields en las entradas de registro.
• optionalFields: tls.cipher, orca_load_report.cpu_utilization: Especifica que las entradas de registro deben incluir el nombre del algoritmo de cifrado que se usó para el handshake de TLS y el uso de CPU del servicio, siempre que estén disponibles.

Configura el ajuste de escala automático basado en el tráfico para tu puerta de enlace de un solo clúster

Asegúrate de que tu clúster de GKE ejecute la versión 1.31.1-gke.2008000 o posterior.

Para habilitar el ajuste de escala automático basado en el tráfico y el balanceo de cargas basado en la capacidad en una Gateway de un solo clúster, puedes configurar la capacidad del servicio. La capacidad de Service es la posibilidad de especificar la cantidad de capacidad de tráfico que un Service puede recibir antes de que los Pods se escalen automáticamente o que el tráfico se desborde hacia otros clústeres disponibles.

Para configurar la capacidad de Service, crea un Service y un GCPBackendPolicy asociado. El manifiesto GCPBackendPolicy usa el campo maxRatePerEndpoint, que define un valor máximo de solicitudes por segundo (RPS) por Pod en un Service. En el siguiente manifiesto de GCPBackendPolicy, se define un RPS máximo de 10:

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: store
spec:
  default:
    maxRatePerEndpoint: 10
  targetRef:
    group: ""
    kind: Service
    name: store

Para obtener más información sobre el ajuste de escala automático basado en el tráfico, consulta Ajuste de escala automático basado en el tráfico del balanceador de cargas.

Soluciona problemas

En esta sección, se proporciona orientación para solucionar problemas habituales cuando se configuran recursos de la puerta de enlace con políticas.

GCPTrafficDistributionPolicy no tiene efecto

Síntoma: El tráfico no se distribuye según la afinidad de sesión o la configuración de localidad definidas en tu política.

Motivo: Por lo general, esto ocurre si la política no está vinculada correctamente al servicio o si el controlador de la puerta de enlace encontró un error de validación al intentar sincronizar la configuración con el balanceador de cargas.

Solución alternativa:

1. Verifica el estado de la política: Comprueba si la política se adjuntó a tu servicio:

   kubectl describe gcptrafficdistributionpolicy POLICY_NAME
   

   Reemplaza POLICY_NAME por el nombre de tu política.

   En el resultado, busca la sección Conditions. El estado True con el motivo Attached indica que la configuración es válida y se aplicó. Si el estado es False, verifica los campos Reason y Message para detectar errores de validación (por ejemplo, un algoritmo no compatible con el tipo de afinidad elegido).

2. Verifica la sincronización de la configuración de la puerta de enlace: Confirma que la puerta de enlace que administra el tráfico haya sincronizado correctamente estos parámetros de configuración con la infraestructura de la nube.

   En la sección Status, verifica que la condición Programmed tenga un Status de True. Si es False, indica que el controlador de puerta de enlace encontró un error, posiblemente relacionado con tu GCPTrafficDistributionPolicy.

   Consulta los campos Reason y Message junto a la condición Programmed para obtener detalles inmediatos. Para obtener mensajes de error más detallados o un historial de fallas de sincronización, consulta el Events en la parte inferior del resultado.

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 un solo GCPBackendPolicy que incluya todos los parámetros de configuración personalizados y conéctalo a tu recurso de destino (Service, ServiceImport, InferencePool o GCPInferencePoolImport).

Se ignora la afinidad de sesión durante la división del tráfico

Síntoma:

Las solicitudes no se enrutan de forma coherente al mismo Pod de backend, aunque la afinidad de sesión esté configurada.

Motivo:

La división de tráfico ponderada tiene prioridad sobre la afinidad de sesión. Si un HTTPRoute define pesos para varios backends, el balanceador de cargas primero selecciona un backend según los pesos antes de aplicar la lógica de afinidad.

Solución alternativa:

Evita usar la división de tráfico ponderada en la misma regla de HTTPRoute en la que se requiere la persistencia de sesión.

No se encontró la política de seguridad de Cloud Armor

Síntoma:

Es posible que aparezca el siguiente mensaje de error cuando habilites Cloud Armor en tu puerta de enlace regional:

Invalid value for field 'resource': '{
"securityPolicy":"projects/123456789/regions/us-central1/securityPolicies/<policy_name>"}'.
The given security policy does not exist.

Motivo:

El mensaje de error indica que la política de seguridad regional de Cloud Armor especificada no existe en tu proyecto Cloud de Confiance .

Solución alternativa:

Crea una política de seguridad de Cloud Armor regional en tu proyecto y haz referencia a esta política en tu GCPBackendPolicy.

¿Qué sigue?

• Obtén más información para implementar una puerta de enlace.
• Obtén más información sobre el controlador de Gateway.
• Obtén más información sobre cómo hacer referencia a una puerta de enlace desde un recurso.
• Consulta la referencia de la API de Policy Types.
• Consulta las definiciones de tipos de API.