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 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 describen en este documento.

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

  • 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 no se puede adjuntar 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.

  • GCPBackendPolicy no admite las opciones HEADER_FIELD ni HTTP_COOKIE para la afinidad de sesión.

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

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 de 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. Google Cloudcrea 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 la 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:

Servicio

# 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: 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 Service in the cluster.
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Servicio de varios clústeres

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

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 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 queGoogle 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 quieres 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 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 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:

Servicio

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

Servicio de varios clústeres

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

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 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: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a Service in the cluster.
  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 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: SECRET_NAME
      clientID: CLIENT_ID
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  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 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.

Servicio

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

Servicio de varios clústeres

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

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 habilita 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
        maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [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

El parámetro GCPTrafficDistributionPolicy configura el algoritmo de balanceo de cargas para la selección de extremos dentro de un backend. Cuando seleccionas WEIGHTED_ROUND_ROBIN, el balanceador de cargas usa pesos derivados de las métricas informadas (incluidas las métricas personalizadas) para distribuir el tráfico a instancias o extremos individuales.

El campo WEIGHTED_ROUND_ROBIN localityLbPolicy del recurso GCPTrafficDistributionPolicy especifica un algoritmo de balanceo de cargas para seleccionar instancias o extremos individuales dentro de un backend. Cuando usas este algoritmo, la política utiliza métricas personalizadas para calcular los pesos de la asignación de carga.

El array customMetrics[] dentro de la configuración de GCPTrafficDistributionPolicy contiene los siguientes campos:

  • name: Especifica el nombre definido por el usuario de la métrica personalizada.
  • dryRun: Es un campo booleano. Cuando es verdadero, los datos de la métrica se registran en Cloud Monitoring, pero no influyen en el balanceo de cargas.

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 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 de cliente:

Servicio

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

Servicio de varios clústeres

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:

Servicio

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

Servicio de varios clústeres

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

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

Servicio de varios clústeres

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

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:

Servicio

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

Servicio de varios clústeres

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

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.
  • 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 tanto el nombre del cifrado utilizado para el handshake de TLS como 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

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.

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

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?