Esta página se ha traducido con Cloud Translation API.

Configurar recursos de pasarela mediante políticas

En esta página se muestra cómo configurar el balanceador de carga que crea Google Kubernetes Engine (GKE) al desplegar una pasarela en un clúster de GKE.

Cuando despliegas una pasarela, la configuración de GatewayClass determina qué balanceador de carga crea GKE. Este balanceador de carga gestionado está preconfigurado con ajustes predeterminados que puedes modificar mediante una política.

Puedes personalizar los recursos de Gateway para que se adapten a los requisitos de tu infraestructura o aplicación. Para ello, adjunta políticas a Gateways, Services o ServiceImports. Después de aplicar o modificar una política, no es necesario que elimines ni vuelvas a crear tus recursos de pasarela, ruta o servicio. El controlador de la pasarela procesa la política y el recurso de balanceador de carga subyacente se (re)configura según la (nueva) política.

Antes de empezar

Antes de empezar, asegúrate de que has realizado las siguientes tareas:

Habilita la API de Google Kubernetes Engine.

Habilitar la API de Google Kubernetes Engine

Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.
Nota: Si ya tienes instalada la CLI gcloud, asegúrate de definir la compute/region propiedad. Si usas principalmente clústeres zonales, define compute/zone en su lugar. Si defines una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que tengas que especificar la ubicación en determinados comandos si la ubicación de tu clúster es diferente de la predeterminada que hayas definido.

Asegúrate de que tienes un clúster Autopilot o Standard. Para crear un clúster, consulta Crear un clúster de Autopilot.

Requisitos de GKE Gateway Controller

La API Gateway solo se admite en clústeres nativos de VPC.
Si usas GatewayClasses internas, debes habilitar una subred de solo proxy.
Tu clúster debe tener habilitado el complemento HttpLoadBalancing.
Si usas Istio, debes actualizarlo a una de las siguientes versiones:
- 1.15.2 o posterior
- 1.14.5 o posterior
- 1.13.9 o posterior.
Si utilizas una VPC compartida, en el proyecto host debes asignar el rol Compute Network User a la cuenta de servicio de GKE del proyecto de servicio.

Restricciones y limitaciones

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

Los recursos de GCPGatewayPolicy solo se pueden adjuntar a un gateway.networking.k8s.io Gateway.
Los recursos GCPGatewayPolicy deben estar en el mismo espacio de nombres que el Gateway de destino.
Cuando se usa un único clúster de puerta de enlace, GCPBackendPolicy y los recursos de HealthCheckPolicy deben hacer referencia a un recurso de Service.
Cuando se usa una pasarela de varios clústeres, los recursos GCPBackendPolicy y HealthCheckPolicy deben hacer referencia a un recurso ServiceImport.
Solo se puede adjuntar un GCPBackendPolicy a un servicio en un momento dado. Cuando se crean dos políticas GCPBackendPolicy que se aplican al mismo Service o ServiceImport, prevalece la política más antigua y la segunda no se puede adjuntar.
Las políticas jerárquicas no se admiten en GKE Gateway.
Los recursos HealthCheckPolicy y GCPBackendPolicy deben existir en el mismo espacio de nombres que el recurso de destino Service o ServiceImport.
Los recursos GCPBackendPolicy y HealthCheckPolicy están estructurados de forma que solo pueden hacer referencia a un servicio de backend.
GCPBackendPolicy no admite las opciones HEADER_FIELD ni HTTP_COOKIE para la afinidad de sesión.

Configurar el acceso global a una pasarela interna regional

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

Para habilitar el acceso global con tu pasarela interna, adjunta una política al recurso de pasarela.

El siguiente manifiesto de GCPGatewayPolicy habilita la pasarela 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

Configurar la región de tu pasarela de varios clústeres

En esta sección se describe una función 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 tengas que desplegar pasarelas regionales en diferentes regiones para varios casos prácticos, como la redundancia entre regiones, la baja latencia y la soberanía de los datos. En el clúster de configuración de tu pasarela de varios clústeres, puedes especificar la región en la que quieres desplegar las pasarelas regionales. Si no especificas una región, la región predeterminada es la de clúster de configuración.

Para configurar una región en tu pasarela de varios clústeres, usa el campo region del GCPGatewayPolicy. En el siguiente ejemplo, la pasarela 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

Configurar políticas de SSL para proteger el tráfico entre el cliente y el balanceador de carga

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

Para proteger el tráfico de cliente a balanceador de carga, configura la política de SSL añadiendo el nombre de tu política a GCPGatewayPolicy. De forma predeterminada, la puerta de enlace no tiene ninguna política SSL definida ni asociada.

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

El siguiente manifiesto de GCPGatewayPolicy 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

Configurar comprobaciones del estado

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

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

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

Para que el balanceador de carga funcione correctamente, es posible que tengas que configurar un HealthCheckPolicy personalizado para el balanceador de carga si la ruta de comprobación de estado no es la estándar "/". Esta configuración también es necesaria si la ruta requiere encabezados especiales o si tienes que ajustar los parámetros de comprobación de estado. Por ejemplo, si la ruta de solicitud predeterminada es "/", pero no se puede acceder a tu servicio en esa ruta y, en su lugar, usa "/health" para informar de su estado, debes configurar requestPath en tu HealthCheckPolicy en consecuencia.

El siguiente manifiesto de HealthCheckPolicy muestra todos los campos disponibles al configurar una política de comprobació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
  # 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
  # Attach to a multi-cluster Service by referencing the ServiceImport.
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Haz los cambios siguientes:

INTERVAL: especifica el intervalo de comprobación, en segundos, de cada comprobador de estado. Es el tiempo que transcurre desde el inicio de una comprobación de una sonda hasta el inicio de la siguiente. Si se omite este parámetro, el valor predeterminado es 15 segundos si no se especifica ningún HealthCheckPolicy, y 5 segundos si se especifica un HealthCheckPolicy sin ningún valor checkIntervalSec. Google Cloud Para obtener más información, consulta Varias sondas y frecuencia.
TIMEOUT: especifica el tiempo queGoogle Cloud espera una respuesta a una petición. El valor de TIMEOUT debe ser inferior o igual al de INTERVAL. Las unidades son segundos. Cada sonda requiere que se envíe un código de respuesta HTTP 200 (OK) antes de que se agote el tiempo de espera de la sonda.
HEALTHY_THRESHOLD y UNHEALTHY_THRESHOLD: especifica el número de intentos de conexión secuenciales que deben completarse correctamente o fallar, en al menos una sonda, para cambiar el estado de salud de la instancia de VM de correcto a incorrecto o de incorrecto a correcto. Si omites uno de estos parámetros, el valor predeterminado es 2. Google Cloud
PROTOCOL: especifica un protocolo que usan los sistemas de sondeo para comprobar el estado. Para obtener más información, consulta los criterios de éxito de HTTP, HTTPS y HTTP/2 y los criterios de éxito de gRPC. Este parámetro es obligatorio.
ENABLED: especifica si el registro está habilitado o inhabilitado.
PORT_SPECIFICATION: especifica si la comprobación de estado usa un puerto fijo (USE_FIXED_PORT), un puerto con nombre (USE_NAMED_PORT) o un puerto activo (USE_SERVING_PORT). Si no se especifica, la comprobación de estado sigue el comportamiento especificado en el campo port. Si no se especifica port, este campo se define de forma predeterminada como USE_SERVING_PORT.
PORT: HealthCheckPolicy solo admite la especificación del puerto de comprobación del estado del balanceador de carga mediante un número de puerto. Si omite este parámetro, el valor predeterminado es 80. Google Cloud Como el balanceador de carga envía sondeos directamente a la dirección IP del pod, debes seleccionar un puerto que coincida con el containerPort de un pod de servicio, aunque el containerPort esté referenciado por un targetPort del servicio. No estás limitado a containerPorts referenciados por el targetPort de un Servicio.
HOST: el valor del encabezado Host en la solicitud de comprobación del estado. Este valor usa la definición RFC 1123 de un nombre de host, pero no se permiten las direcciones IP numéricas. Si no se especifica o se deja vacío, este valor se asigna de forma predeterminada a la dirección IP de la comprobación de estado.
REQUEST_PATH: especifica el request-path de la solicitud de comprobación del estado. Si no se especifica o se deja en blanco, se utiliza / de forma predeterminada.
RESPONSE: especifica los bytes que se compararán con el principio de los datos de respuesta. Si no se especifica o se deja vacío, GKE interpreta cualquier respuesta como correcta. Los datos de respuesta solo pueden ser ASCII.
PROXY_HEADER: especifica el tipo de encabezado de proxy. Puedes usar NONE o PROXY_V1. El valor predeterminado es NONE.
GRPC_SERVICE_NAME: nombre opcional del servicio gRPC. Omite este campo para especificar todos los servicios.

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

Configurar una política de seguridad de backend de Cloud Armor para proteger los servicios de backend

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

Configura la política de seguridad de backend de Cloud Armor añadiendo el nombre de tu política de seguridad al GCPBackendPolicy para proteger tus servicios de backend. De forma predeterminada, la pasarela no tiene ninguna política de seguridad de backend de Cloud Armor definida ni asociada.

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 pasarela regional, debes crear una política de seguridad de backend de Cloud Armor regional.

El siguiente manifiesto de GCPBackendPolicy 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

Configurar IAP

En esta sección se describe una función 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 en los servicios backend asociados a una HTTPRoute. Con esta medida, solo los usuarios o las aplicaciones autenticados que tengan asignado el rol de Gestión de Identidades y Accesos (IAM) correcto podrán acceder a estos servicios backend.

De forma predeterminada, no se aplica IAP a tus servicios de backend, por lo que debes configurar IAP explícitamente en un GCPBackendPolicy.

Para configurar IAP con Gateway, haz lo siguiente:

Habilita IAP para GKE. No configures el backend (Configurar BackendConfig) porque BackendConfig solo es válido en el caso de una implementación de Ingress.
Crea un secreto para tu compra en la aplicación:
1. En la Google Cloud consola, ve a la página Credenciales:
  
  Ir a Credenciales
2. Haga clic en el nombre del cliente y descargue el archivo de cliente de OAuth.
3. En el archivo de 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 con el siguiente comando:
```
echo -n CLIENT_SECRET > iap-secret.txt
kubectl create secret generic SECRET_NAME --from-file=key=iap-secret.txt
```

Para especificar una política de IAP que haga referencia a un secreto, sigue estos pasos:

Crea el siguiente archivo de manifiesto GCPBackendPolicy y sustituye SECRET_NAME y CLIENT_ID respectivamente. Guarda el archivo de 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

Aplica el manifiesto backend-policy.yaml:
```
kubectl apply -f backend-policy.yaml
```

Verifica tu configuración:

Confirma que la política se ha aplicado después de crear tu GCPBackendPolicy con compras en la aplicación:
```
kubectl get gcpbackendpolicy
```
El resultado debería ser similar al siguiente:
```
NAME             AGE
backend-policy   45m
```

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

kubectl describe gcpbackendpolicy

El resultado debería ser similar al siguiente:

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

Configurar el tiempo de espera del servicio de backend

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

El siguiente manifiesto de GCPBackendPolicy especifica un periodo de tiempo de espera del servicio backend de 40 segundos. El campo timeoutSec tiene el valor predeterminado 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

Configurar la selección de backend mediante `GCPBackendPolicy`

El modo de balanceo CUSTOM_METRICS de GCPBackendPolicy te permite configurar métricas personalizadas específicas que influyen en la forma en que los servicios de backend de los balanceadores de carga distribuyen el tráfico. Este modo de balanceo permite balancear la carga en función de las métricas personalizadas que definas y que comuniquen los back-ends de la aplicación.

Para obtener más información, consulte Gestión del tráfico con balanceo de carga basado en métricas personalizadas.

La matriz customMetrics[], en el campo backends[], contiene los siguientes campos:

name: especifica el nombre de la métrica personalizada definido por el usuario.
maxUtilization: define el uso objetivo o máximo de esta métrica. El intervalo válido es [0, 100].
dryRun: campo booleano. Si es true, los datos de métricas se envían a Cloud Monitoring, pero no influyen en las decisiones de balanceo de carga.

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

Guarda el siguiente archivo de 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

Aplica el manifiesto a tu clúster:

kubectl apply -f my-backend-policy.yaml

El balanceador de carga distribuye el tráfico en función del RATE modo de balanceo y de la gpu-load métrica personalizada.

Configurar el enrutamiento a nivel de endpoint con GCPTrafficDistributionPolicy

El GCPTrafficDistributionPolicy configura el algoritmo de balanceo de carga para la selección de endpoints en un backend. Si selecciona WEIGHTED_ROUND_ROBIN, el balanceador de carga usará pesos derivados de las métricas registradas (incluidas las métricas personalizadas) para distribuir el tráfico a instancias o endpoints concretos.

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

La matriz customMetrics[] de la configuración GCPTrafficDistributionPolicy contiene los siguientes campos:

name: especifica el nombre de la métrica personalizada definido por el usuario.
dryRun: campo booleano. Si es true, los datos de métricas se envían a Cloud Monitoring, pero no influyen en el balanceo de carga.

Para obtener más información, consulte Gestión del tráfico con balanceo de carga basado en métricas personalizadas.

Ejemplo

En el siguiente ejemplo se muestra un manifiesto de GCPTrafficDistributionPolicy que configura el enrutamiento a nivel de endpoint mediante el algoritmo de balanceo de carga WEIGHTED_ROUND_ROBIN y métricas personalizadas.

Guarda el siguiente archivo de manifiesto de ejemplo 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

Aplica el manifiesto a tu clúster:

kubectl apply -f GCPTrafficDistributionPolicy.yaml

El balanceador de carga distribuye el tráfico a los endpoints en función del algoritmo WEIGHTED_ROUND_ROBIN y de las métricas personalizadas proporcionadas.

Configurar la afinidad de sesión

En esta sección se describe una función 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 del cliente
Cookie generada

Cuando configuras la afinidad de sesión de tu servicio, el ajuste localityLbPolicy de la pasarela se define como MAGLEV.

Cuando eliminas una configuración de afinidad de sesión de GCPBackendPolicy, la pasarela restaura el valor predeterminado de localityLbPolicy, ROUND_ROBIN.

El siguiente manifiesto GCPBackendPolicy especifica una afinidad de sesión basada en la dirección IP del 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

El siguiente manifiesto de GCPBackendPolicy especifica una afinidad de sesión basada en una cookie generada y configura el TTL de las cookies en 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 en el campo sessionAffinity.type:

CLIENT_IP
GENERATED_COOKIE
NONE

Configurar el tiempo de espera de purga de conexión

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

Puedes configurar el tiempo de espera de purga de conexiones con GCPBackendPolicy. El tiempo de espera de purga de conexión es el tiempo, en segundos, que se espera a que se purguen las conexiones. La duración del tiempo de espera puede ser de 0 a 3600 segundos. El valor predeterminado es 0, lo que también inhabilita el drenaje de conexiones.

El siguiente manifiesto de GCPBackendPolicy especifica un tiempo de espera hasta la desconexión 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 el tiempo de espera especificado, GKE espera a que se completen las solicitudes existentes al backend eliminado. El balanceador de carga no envía nuevas solicitudes al backend eliminado. Cuando se alcanza el tiempo de espera, GKE cierra todas las conexiones restantes con el backend.

Registro de acceso HTTP

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

De forma predeterminada:

El controlador de Gateway registra todas las solicitudes HTTP de los clientes en Cloud Logging.
La frecuencia de muestreo es de 1.000.000, lo que significa que se registran todas las solicitudes.
No se registra ningún campo opcional.

Puedes inhabilitar el registro de acceso en tu Gateway mediante un GCPBackendPolicy de tres formas:

Puedes dejar la sección GCPBackendPolicy sin logging
Puedes definir logging.enabled en false
Puedes definir logging.enabled como true y logging.sampleRate como 0.

También puedes configurar la frecuencia de muestreo del registro de acceso y una lista de campos opcionales, como "tls.cipher" u "orca_load_report".

Para habilitar el registro de los campos opcionales, sigue estos pasos:

Asigna el valor CUSTOM a logging.OptionalMode.
Proporciona la lista de campos opcionales que se registrarán en logging.optionalFields. Consulta la sección Registro y monitorización para ver la lista de campos admitidos.

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

Puedes quitar todas las entradas de logging.optionalFields.
Puedes definir logging.OptionalMode en EXCLUDE_ALL_OPTIONAL.

El siguiente manifiesto GCPBackendPolicy modifica la frecuencia de muestreo predeterminada del registro de acceso y la establece en el 50% de las solicitudes HTTP. El manifiesto también permite registrar dos campos opcionales de 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 explícitamente el registro de acceso. 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 intervalo [0, 1] dividiéndolo entre 1.000.000. Este campo solo es relevante si se asigna el valor true a enable. sampleRate es un campo opcional, pero si se configura, también se debe definir enable: true. Si se asigna el valor true a enable y no se proporciona sampleRate, GKE asigna el valor false a enable.
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 usado para el handshake de TLS como la utilización de la CPU del servicio, siempre que estén disponibles.

Configurar el autoescalado basado en el tráfico de una única pasarela de un clúster

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

Para habilitar el autoescalado basado en el tráfico y el balanceo de carga basado en la capacidad en una puerta de enlace de un solo clúster, puedes configurar la capacidad del servicio. La capacidad de servicio es la capacidad de especificar la cantidad de tráfico que puede recibir un servicio antes de que los pods se autoescalen o el tráfico se desborde a otros clústeres disponibles.

Para configurar la capacidad de un servicio, crea un servicio 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 servicio. El siguiente manifiesto de GCPBackendPolicy 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 autoescalado basado en el tráfico, consulte Autoescalado basado en el tráfico del balanceador de carga.

Solución de problemas

Varios `GCPBackendPolicy` adjuntos al mismo `Service`

Síntoma:

El siguiente estado puede producirse cuando adjuntas un GCPBackendPolicy a un Service o a un 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 estás intentando aplicar un segundo GCPBackendPolicy a un Service o un ServiceImport que ya tiene un GCPBackendPolicy adjunto.

No se admite que haya varios GCPBackendPolicy adjuntos al mismo Service o ServiceImport con GKE Gateway. Para obtener más información, consulta Restricciones y limitaciones.

Solución alternativa:

Configura un solo GCPBackendPolicy que incluya todas las configuraciones personalizadas y adjúntalo a tu Service o ServiceImport.

No se ha encontrado la política de seguridad de Cloud Armor

Síntoma:

Puede que aparezca el siguiente mensaje de error cuando habilites Cloud Armor en tu gateway 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.

Siguientes pasos

Consulta cómo implementar una pasarela.
Más información sobre el controlador de la pasarela
Consulta cómo hacer referencia a una pasarela desde un recurso.
Consulta la referencia de la API Policy Types.
Consulta las definiciones de tipos de API.

Configurar recursos de pasarela mediante políticas Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Antes de empezar

Requisitos de GKE Gateway Controller

Restricciones y limitaciones

Configurar el acceso global a una pasarela interna regional

Configurar la región de tu pasarela de varios clústeres

Configurar políticas de SSL para proteger el tráfico entre el cliente y el balanceador de carga

Configurar comprobaciones del estado

Servicio

Servicio de varios clústeres

Configurar una política de seguridad de backend de Cloud Armor para proteger los servicios de backend

Servicio

Servicio de varios clústeres

Configurar IAP

Servicio

Servicio de varios clústeres

Configurar el tiempo de espera del servicio de backend

Servicio

Servicio de varios clústeres

Configurar la selección de backend mediante GCPBackendPolicy

Configurar el enrutamiento a nivel de endpoint con GCPTrafficDistributionPolicy

Configurar la afinidad de sesión

Servicio

Servicio de varios clústeres

Servicio

Servicio de varios clústeres

Configurar el tiempo de espera de purga de conexión

Servicio

Servicio de varios clústeres

Registro de acceso HTTP

Servicio

Servicio de varios clústeres

Configurar el autoescalado basado en el tráfico de una única pasarela de un clúster

Solución de problemas

Varios GCPBackendPolicy adjuntos al mismo Service

No se ha encontrado la política de seguridad de Cloud Armor

Siguientes pasos

Configurar recursos de pasarela mediante políticas

Configurar la selección de backend mediante `GCPBackendPolicy`

Varios `GCPBackendPolicy` adjuntos al mismo `Service`