O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Configurar recursos de gateway usando políticas

Nesta página, mostramos como configurar o balanceador de carga que o Google Kubernetes Engine (GKE) cria quando você implanta um gateway em um cluster do GKE.

Quando você implanta um gateway, a configuração GatewayClass determina qual balanceador de carga o GKE cria. Esse balanceador de carga gerenciado é pré-configurado com configurações padrão que podem ser modificadas por uma política.

Para personalizar os recursos de gateway de acordo com os requisitos da sua infraestrutura ou aplicativo, anexe políticas a gateways, serviços ou ServiceImports. Depois de aplicar ou modificar uma política, o controlador de gateway a processa e reconfigura automaticamente o recurso do balanceador de carga subjacente. Isso elimina a necessidade de excluir ou recriar os recursos de gateway, rota ou serviço.

Você também pode usar uma BackendTLSPolicy para configurar as configurações de TLS autenticado de back-end e verificar a identidade dos back-ends a que o gateway se conecta. Para mais informações, consulte Configurar o TLS de back-end.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ative a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da CLI gcloud não sejam compatíveis com a execução dos comandos neste documento.
Observação:em instalações prévias da CLI gcloud, defina a propriedade compute/region. Se você usa principalmente clusters zonais, defina compute/zone. Ao definir um local padrão, é possível evitar erros na CLI gcloud como: One of [--zone, --region] must be supplied: Please specify location. Talvez seja necessário especificar o local em determinados comandos se o local do cluster for diferente do padrão definido.

Verifique se você tem um cluster do Autopilot ou Standard. Para criar um novo cluster, consulte Criar um cluster do Autopilot.

Requisitos do GKE Gateway Controller

A API Gateway é compatível apenas com clusters nativos da VPC.
Se você estiver usando o GatewayClasses regional ou entre regiões, ative uma sub-rede somente proxy.
O cluster precisa ter o complemento HttpLoadBalancing ativado.
Se você estiver usando o Istio, será necessário fazer upgrade do Istio para uma das seguintes versões:
- 1.15.2 ou mais recente
- 1.14.5 ou mais recente
- 1.13.9 ou mais recente
Se você estiver usando a VPC compartilhada, será necessário atribuir o papel Compute Network User à conta de serviço do GKE referente ao projeto de serviço no projeto host.

Restrições e limitações

Além das restrições e limitações do controlador de gateway do GKE, as seguintes limitações se aplicam especificamente às políticas aplicadas aos recursos de gateway:

Os recursos GCPGatewayPolicy só podem ser anexados a um gateway gateway.networking.k8s.io.
Os recursos GCPGatewayPolicy precisam estar no mesmo namespace que o gateway de destino.
Ao usar um único gateway de cluster, os recursos GCPBackendPolicy e HealthCheckPolicy precisam se referir a um recurso Service.
Ao usar um gateway de vários clusters, GCPBackendPolicy e HealthCheckPolicy, os recursos precisam se referir a um recurso ServiceImport.
Apenas uma GCPBackendPolicy pode ser anexada a um serviço por vez. Quando duas políticas GCPBackendPolicy são criadas para o mesmo Service ou ServiceImport, a política mais antiga tem precedência e a segunda não é anexada.
As políticas hierárquicas não são compatíveis com o gateway do GKE.
Os recursos HealthCheckPolicy e GCPBackendPolicy precisam estar no mesmo namespace que o recurso de destino Service ou ServiceImport.
Os recursos GCPBackendPolicy e HealthCheckPolicy são estruturados para referenciar apenas um serviço de back-end.
O GCPBackendPolicy não é compatível com as opções HEADER_FIELD ou HTTP_COOKIE para afinidade da sessão. Para afinidade da sessão HEADER_FIELD ou HTTP_COOKIE, use o recurso GCPTrafficDistributionPolicy.
Não use o mesmo serviço de back-end em gateways de diferentes tipos de GatewayClass (como global x regional, interno x externo ou gerenciado x clássico) se esses gateways exigirem configurações incompatíveis. Por exemplo, uma GCPBackendPolicy configurada com recursos não compatíveis com uma GatewayClass "Classic" não pode ser aplicada a um serviço também usado por um gateway "Classic". Para garantir a configuração correta, crie um serviço distinto para cada gateway que exija configurações de política diferentes.
A afinidade da sessão configurada usando uma GCPTrafficDistributionPolicy é compatível apenas com gateways de cluster único.
A afinidade da sessão do GCPTrafficDistributionPolicy não é compatível com recursos do InferencePool porque eles usam algoritmos dedicados de balanceamento de carga de localidade.
A GCPTrafficDistributionPolicy não é compatível com a configuração de afinidade da sessão ou políticas de balanceamento de carga de localidade para o balanceador de carga de aplicativo clássico.
Ao usar um gateway de cluster único, os recursos GCPBackendPolicy e HealthCheckPolicy precisam se referir a um recurso Service ou InferencePool.
Ao usar um gateway de vários clusters, os recursos GCPBackendPolicy e HealthCheckPolicy precisam se referir a um recurso ServiceImport ou GCPInferencePoolImport.
Apenas uma GCPBackendPolicy pode ser anexada a um único recurso de destino (Service, ServiceImport, InferencePool ou GCPInferencePoolImport) por vez. Quando vários recursos GCPBackendPolicy são criados e segmentam o mesmo recurso, a política mais antiga tem precedência e a mais recente não é anexada.
Os recursos HealthCheckPolicy e GCPBackendPolicy precisam estar no mesmo namespace que o serviço, ServiceImport, InferencePool ou GCPInferencePoolImport de destino.
Os recursos GCPBackendPolicy e HealthCheckPolicy só podem segmentar um único recurso, como um serviço ou InferencePool.

Prática recomendada:crie um serviço distinto para cada gateway usando uma GatewayClass diferente para garantir a compatibilidade entre as políticas do serviço e o tipo de balanceador de carga.

Configurar o acesso global para seu gateway interno regional

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

Para permitir o acesso global com seu gateway interno, anexe uma política ao recurso de gateway.

O manifesto GCPGatewayPolicy a seguir ativa o gateway interno regional para acesso 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 a região para o gateway de vários clusters

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.30.3-gke.1225000 ou mais recente.

Se a frota tiver clusters em várias regiões, talvez seja necessário implantar gateways regionais em regiões diferentes para vários casos de uso, por exemplo, redundância entre regiões, baixa latência e soberania de dados. No cluster de configuração do gateway de vários clusters, é possível especificar a região em que você quer implantar os gateways regionais. Se você não especificar uma região, a região padrão será a do cluster de configuração.

Para configurar uma região para o gateway de vários clusters, use o campo region na GCPGatewayPolicy. No exemplo a seguir, o gateway está configurado na região 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 o tráfego do cliente para o balanceador de carga

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

Para proteger o tráfego do cliente para o balanceador de carga, configure a política de SSL adicionando o nome da política ao GCPGatewayPolicy. Por padrão, o gateway não tem uma política de SSL definida e anexada.

Crie uma política de SSL antes de fazer referência a ela no recurso GCPGatewayPolicy.

O manifesto GCPGatewayPolicy a seguir especifica uma política de segurança chamada 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 verificações de integridade

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

Por padrão, para serviços de back-end que usam os protocolos de aplicativo HTTP ou kubernetes.io/h2c, o HealthCheck é do tipo HTTP. Para o protocolo HTTPS, o HealthCheck padrão é do tipo HTTPS. Para o protocolo HTTP2, o HealthCheck padrão é do tipo HTTP2.

É possível usar uma HealthCheckPolicy para controlar as configurações de verificação de integridade do balanceador de carga. Cada tipo de verificação de integridade (http, https, grpc, http2 e tcp) tem parâmetros que podem ser definidos. Google Cloud cria uma verificação de integridade exclusiva para cada serviço de back-end de cada serviço do GKE.

Para que o balanceador de carga funcione normalmente, talvez seja necessário configurar uma HealthCheckPolicy personalizada se o caminho da verificação de integridade não for o padrão "/". Essa configuração também é necessária se você precisar ajustar os parâmetros da verificação de integridade. Por exemplo, se o caminho de solicitação padrão for "/", mas seu serviço não puder ser acessado nesse caminho e usar "/health" para informar a integridade, configure requestPath na HealthCheckPolicy de acordo.

Ao configurar verificações de integridade, lembre-se das seguintes limitações:

Ao contrário do GKE Ingress, o GKE Gateway não infere automaticamente parâmetros de verificação de integridade (como caminho, porta ou protocolo) das sondagens de prontidão ou atividade do seu pod. Se o serviço não retornar uma resposta bem-sucedida no caminho raiz padrão (/), você precisará configurar explicitamente um HealthCheckPolicy.
As sondagens de verificação de integridade doGoogle Cloud exigem estritamente um código de resposta HTTP 200 (OK). Se o aplicativo retornar redirecionamentos (por exemplo, HTTP 301 ou 302) ou erros do cliente (por exemplo, HTTP 401 ou 403 em endpoints autenticados) no caminho testado, o balanceador de carga vai marcar o back-end como não íntegro, resultando em um erro "Nenhum upstream íntegro".
Não é possível configurar cabeçalhos de solicitação HTTP personalizados (como cabeçalhos Authorization) em sondagens do GKE Gateway HealthCheckPolicy. Se o back-end exigir cabeçalhos de autenticação, configure o aplicativo para permitir o acesso não autenticado especificamente ao caminho dedicado de verificação de integridade (por exemplo, /healthz ou /ping) para intervalos de endereços IP de verificação de integridade doGoogle Cloud .

O manifesto HealthCheckPolicy a seguir mostra todos os campos disponíveis ao configurar uma política de verificação de integridade:

Serviço

# 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

Serviço em vários clusters

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

InferencePool

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

Multi-cluster InferencePool

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

Substitua:

INTERVAL: especifica o intervalo de verificação, em segundos, para cada sondagem de verificação de integridade. Esse é o momento entre o início da verificação de uma sondagem e o começo da próxima verificação. Se você omitir esse parâmetro, o padrão Google Cloud será de 15 segundos se nenhuma HealthCheckPolicy for especificada e de 5 segundos quando uma HealthCheckPolicy for especificada sem um valor checkIntervalSec. Para mais informações, consulte Várias sondagens e frequências.
TIMEOUT: especifica o tempo que Google Cloud aguarda uma resposta para uma sondagem. O valor de TIMEOUT precisa ser menor ou igual ao INTERVAL. As unidades são informadas em segundos. Cada sondagem exige que um código de resposta HTTP 200 (OK) seja entregue antes do tempo limite da sondagem.
HEALTHY_THRESHOLDe UNHEALTHY_THRESHOLD: especifica o número de tentativas de conexão sequenciais que precisam ser realizadas ou falhar, para pelo menos uma sondagem, para alterar o estado de integridade de íntegro para não íntegro ou de não íntegro para íntegro. Se você omitir um desses parâmetros, o padrão do Google Cloud será 2.
PROTOCOL: especifica um protocolo usado pelos sistemas de sondagem para verificação de integridade. Para mais informações, consulte Critérios de sucesso para HTTP, HTTPS e HTTP/2, Critérios de sucesso para gRPC e Critérios de sucesso para TCP. Este parâmetro é obrigatório.
ENABLED: especifica se a geração de registros está ativada ou desativada.
PORT_SPECIFICATION: especifica se a verificação de integridade usa uma porta fixa (USE_FIXED_PORT), uma porta nomeada (USE_NAMED_PORT) ou uma porta de serviço (USE_SERVING_PORT). Se não for especificada, a verificação de integridade seguirá o comportamento especificado no campo port. Se port não for especificado, o padrão desse campo será USE_SERVING_PORT.
PORT: uma HealthCheckPolicy só permite a especificação da porta de verificação de integridade do balanceador de carga usando um número de porta. Se você omitir esse parâmetro, o padrão Google Cloud será 80. Como o balanceador de carga envia sondagens para o endereço IP do pod diretamente, selecione uma porta que corresponda a um containerPort de pods de exibição, mesmo que o containerPort seja indicado por um targetPort do serviço. Você não fica limitado ao containerPorts indicado pelo targetPort de um serviço.
HOST: o valor do cabeçalho do host na solicitação de verificação de integridade. Esse valor usa a definição RFC 1123 de um nome de host, exceto endereços IP numéricos não permitidos. Se não for especificado ou deixado em branco, esse valor será o padrão para o endereço IP da verificação de integridade.
REQUEST: especifica os dados do aplicativo a serem enviados depois que a conexão TCP for estabelecida. Se não for especificado, o valor será vazio. Se a solicitação e a resposta estiverem vazias, a conexão estabelecida por si só indicará integridade. Os dados da solicitação só podem estar no formato ASCII.
REQUEST_PATH: especifica o caminho da solicitação de verificação de integridade. Se não for especificado ou ficar em branco, o padrão será /.
RESPONSE: especifica os bytes que serão comparados com o início dos dados da resposta. Se não for especificado ou deixado em branco, o GKE interpretará qualquer resposta como íntegra. Os dados de resposta só podem ser ASCII.
PROXY_HEADER: especifica o tipo de cabeçalho do proxy. É possível usar NONE ou PROXY_V1. O padrão é NONE.
GRPC_SERVICE_NAME: um nome opcional do serviço gRPC. Omita esse campo para especificar todos os Serviços.

Para mais informações sobre os campos de HealthCheckPolicy, consulte a referência de healthChecks.

Configurar a política de segurança de back-end do Cloud Armor para proteger seus serviços de back-end

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

Configure a política de segurança de back-end do Cloud Armor adicionando o nome da política de segurança ao GCPBackendPolicy para proteger os serviços de back-end. Por padrão, o gateway não tem nenhuma política de segurança de back-end do Cloud Armor definida e anexada.

Crie uma política de segurança de back-end do Cloud Armor antes de fazer referência à política no GCPBackendPolicy. Se você estiver ativando um gateway regional, crie uma política de segurança de back-end regional do Cloud Armor.

O manifesto GCPBackendPolicy a seguir especifica uma política de segurança de back-end chamada example-security-policy:

Serviço

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

Serviço em vários clusters

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

InferencePool

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

Multi-cluster InferencePool

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

Configurar o IAP

O Identity-Aware Proxy (IAP) impõe políticas de controle de acesso a serviços de back-end associados a uma HTTPRoute. Com essa aplicação, somente usuários ou aplicativos autenticados com o papel correto do Identity and Access Management (IAM) atribuído podem acessar esses serviços de back-end.

Por padrão, não há IAP aplicado aos serviços de back-end. Você precisa configurar explicitamente o IAP em uma GCPBackendPolicy.

Para configurar o IAP com o gateway, faça o seguinte:

Receba o ID do cliente e a chave secreta do cliente OAuth. A chave secreta do cliente fica disponível apenas quando você cria o cliente OAuth. Para mais informações, consulte Gerenciar clientes OAuth.
Ative o IAP para GKE.

Não é necessário criar um BackendConfig, porque ele é um recurso de configuração do Entrada.

Para especificar a política do IAP que faz referência a um secret:

Salve o seguinte manifesto GCPBackendPolicy como backend-policy.yaml:

Serviço

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

Substitua:

CLIENT_SECRET: a chave secreta do cliente OAuth.
CLIENT_ID: o ID do cliente OAuth.
SERVICE_NAME: o nome do serviço a ser direcionado na GCPBackendPolicy.

Serviço em vários clusters

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

Substitua:

CLIENT_SECRET: a chave secreta do cliente OAuth.
CLIENT_ID: o ID do cliente OAuth.
SERVICEIMPORT_NAME: o nome do ServiceImport a ser segmentado na GCPBackendPolicy.

Aplique o manifesto backend-policy.yaml:
```
kubectl apply -f backend-policy.yaml
```

Verifique a configuração:

Confirme se a política foi aplicada depois de criar o GCPBackendPolicy com o IAP:
```
kubectl get gcpbackendpolicy
```
O resultado será o seguinte:
```
NAME             AGE
backend-policy   45m
```

Para ver mais detalhes, use o comando "describe":

kubectl describe gcpbackendpolicy

O resultado será assim:

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 o tempo limite do serviço de back-end

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

O manifesto GCPBackendPolicy a seguir especifica um tempo limite do serviço de back-end de 40 segundos. O campo timeoutSec tem como padrão 30 segundos.

Serviço

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

Serviço em vários clusters

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

InferencePool

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

Multi-cluster InferencePool

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

Configurar a seleção de back-end usando GCPBackendPolicy

O modo de balanceamento CUSTOM_METRICS na GCPBackendPolicy permite configurar métricas personalizadas específicas que influenciam como os serviços de back-end dos balanceadores de carga distribuem o tráfego. Esse modo permite o balanceamento de carga com base em métricas personalizadas definidas e informadas pelos back-ends de aplicativos.

Para mais informações, consulte Gerenciamento de tráfego com balanceamento de carga personalizado baseado em métricas.

A matriz customMetrics[], no campo backends[], contém os seguintes campos:

name: especifica o nome definido pelo usuário da métrica personalizada.
maxUtilization: define a meta ou a utilização máxima para essa métrica. O intervalo válido é [0, 100].
dryRun: um campo booleano. Quando verdadeiro, os dados de métricas são enviados ao Cloud Monitoring, mas não influenciam as decisões de balanceamento de carga.

Exemplo

O exemplo a seguir mostra um manifesto GCPBackendPolicy que configura métricas personalizadas para seleção de back-end e roteamento no nível do endpoint.

Salve o seguinte manifesto 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

Aplique o manifesto ao cluster:

kubectl apply -f my-backend-policy.yaml

O balanceador de carga distribui o tráfego com base no modo de balanceamento RATE e na métrica personalizada gpu-load.

Configurar o roteamento no nível do endpoint com GCPTrafficDistributionPolicy

A API GCPTrafficDistributionPolicy no Gateway do Google Kubernetes Engine (GKE) oferece recursos avançados de gerenciamento de tráfego que permitem controlar com precisão como o tráfego é distribuído para os pods de aplicativos. Esse recurso unificado e nativo do GKE simplifica o gerenciamento de algoritmos de balanceamento de carga e configurações de afinidade da sessão.

Com a GCPTrafficDistributionPolicy, é possível configurar:

Algoritmos de balanceamento de carga: especifique como o tráfego é distribuído entre os endpoints em um back-end.
- WEIGHTED_ROUND_ROBIN: quando você seleciona esse algoritmo, o balanceador de carga usa métricas personalizadas para calcular pesos e distribuir o tráfego com base nessas métricas informadas. A matriz customMetrics[] na configuração GCPTrafficDistributionPolicy inclui os seguintes campos:
  - name: especifica o nome definido pelo usuário da métrica personalizada.
  - dryRun: quando true, os dados de métrica são informados ao Cloud Monitoring, mas não influenciam o balanceamento de carga.
  Observação: as métricas personalizadas definidas em GCPTrafficDistributionPolicy se aplicam somente ao WEIGHTED_ROUND_ROBIN localityLbPolicy e não são herdadas de backends[].customMetrics[] em GCPBackendPolicy.
RING_HASH: esse algoritmo é útil para serviços sensíveis ao desempenho do cache. Ele usa hashing consistente para minimizar o remapeamento de solicitações quando pods de back-end são adicionados ou removidos, o que ajuda a garantir a estabilidade durante eventos de escalonamento. Configurar o campo minimumHashRingSize oferece uma distribuição de carga mais granular.
Afinidade da sessão: ajuda a garantir que as solicitações do mesmo cliente sejam roteadas de forma consistente para o mesmo pod de back-end. Isso é crucial para cargas de trabalho com estado, como carrinhos de compras de e-commerce ou sessões de jogos. O GKE Gateway usa o GCPTrafficDistributionPolicy para oferecer suporte a todos os tipos de afinidade da sessão disponíveis em instâncias do balanceador de carga de aplicativo Google Cloud, incluindo STRONG_COOKIE_AFFINITY, HEADER_FIELD, HTTP_COOKIE, GENERATED_COOKIE e CLIENT_IP.

Para mais informações, consulte Gerenciamento de tráfego com balanceamento de carga personalizado baseado em métricas.

Exemplo

O exemplo a seguir mostra um manifesto do GCPTrafficDistributionPolicy que configura o roteamento no nível do endpoint usando o algoritmo de balanceamento de carga WEIGHTED_ROUND_ROBIN e métricas personalizadas.

Salve o seguinte manifesto de amostra 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

Aplique o manifesto ao cluster:

kubectl apply -f GCPTrafficDistributionPolicy.yaml

O balanceador de carga distribui o tráfego para endpoints com base no algoritmo WEIGHTED_ROUND_ROBIN e nas métricas personalizadas fornecidas.

Configurar o tamanho do anel de hash

Para serviços em que minimizar falhas de cache é fundamental, use o algoritmo RING_HASH. Ajustar o campo minimumHashRingSize permite uma distribuição de carga mais granular entre os back-ends. Embora o balanceador de carga gerencie automaticamente o tamanho do anel, fornecer um valor mínimo mais alto pode ajudar a garantir uma distribuição mais uniforme de solicitações para conjuntos de back-end maiores.

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

Configurar a afinidade da sessão

Configure a afinidade da sessão para garantir que as solicitações do mesmo cliente sejam sempre encaminhadas para o mesmo pod de back-end.

Configurar a afinidade da sessão usando GCPTrafficDistributionPolicy (padrão)

Os tipos de afinidade da sessão descritos nesta seção exigem as seguintes versões mínimas do GKE:

CLIENT_IP, HEADER_FIELD, GENERATED_COOKIE e HTTP_COOKIE:versão 1.35.2-gke.1269001 ou mais recente.
STRONG_COOKIE_AFFINITY:versão 1.36.3-gke.1767000 ou mais recente.

O GKE Gateway é compatível com todos os tipos de afinidade da sessão usando o recurso GCPTrafficDistributionPolicy. Esse recurso oferece um controle mais granular, como roteamento com base em cabeçalhos HTTP ou cookies personalizados. Configurar a afinidade da sessão usando GCPTrafficDistributionPolicy é o método padrão e recomendado.

A tabela a seguir descreve os tipos de afinidade compatíveis quando você usa GCPTrafficDistributionPolicy:

Tipo de afinidade	Descrição
`STRONG_COOKIE_AFFINITY`	Persistência de sessão com estado baseada em cookies. Ajuda a garantir uma fixação forte da sessão em eventos de escalonamento e redimensionamentos do pool de pods. É necessário configurar o campo `cookie.name` e, opcionalmente, os campos `cookie.path` e `cookie.ttl`. Funciona com qualquer configuração de `localityLbAlgorithm`. O valor padrão é `ROUND_ROBIN`.
`HTTP_COOKIE`	Afinidade baseada em um cookie HTTP. Ao responder à primeira solicitação, o balanceador de carga gera um cookie e o fornece em um cabeçalho de resposta `Set-Cookie`. Em solicitações subsequentes, o cliente retorna o cookie fornecido pelo balanceador de carga, e o balanceador de carga o usa para rotear solicitações de forma consistente para os mesmos pods. É necessário configurar o campo `cookie.name` e, opcionalmente, os campos `cookie.path` e `cookie.ttl`. Requer que o campo `localityLbAlgorithm` seja definido como `MAGLEV` ou `RING_HASH`.
`GENERATED_COOKIE`	O balanceador de carga gera um cookie para rastrear a sessão. O nome do cookie é `GCLB` para balanceadores de carga de aplicativo externos globais e `GCILB` para balanceadores de carga de aplicativo internos regionais e balanceadores de carga de aplicativo externos regionais. O caminho do cookie é `/`. Se quiser, configure o campo `cookie.ttl` por até duas semanas. Os campos `cookie.name` e `cookie.path` não podem ser configurados para esse tipo. Exige que o campo `localityLbAlgorithm` seja definido como `MAGLEV` ou `RING_HASH`.
`HEADER_FIELD`	Afinidade baseada em um cabeçalho HTTP específico. Requer que o campo `localityLbAlgorithm` seja definido como `MAGLEV` ou `RING_HASH`.
`CLIENT_IP`	Afinidade com base no endereço IP do cliente. Requer que o campo `localityLbAlgorithm` seja definido como `MAGLEV` ou `RING_HASH`.
`NONE`	Desativa a afinidade da sessão.

Os exemplos a seguir demonstram como configurar GCPTrafficDistributionPolicy agrupada por categoria de afinidade da sessão: com base em cookies, com base em cabeçalhos e com base em IP do cliente.

Para aplicar qualquer uma das seguintes configurações de afinidade da sessão ao cluster, faça o seguinte:

Salve o manifesto escolhido como policy.yaml.
Aplique o manifesto ao cluster:
```
kubectl apply -f policy.yaml
```

A afinidade da sessão baseada em cookies inclui os tipos STRONG_COOKIE_AFFINITY, HTTP_COOKIE e GENERATED_COOKIE.

Afinidade de cookie com estado (STRONG_COOKIE_AFFINITY)

A afinidade de cookie com estado (STRONG_COOKIE_AFFINITY) oferece persistência de sessão com estado que mantém a fixação mesmo durante eventos de escalonamento do back-end.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: strong-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: STRONG_COOKIE_AFFINITY
      cookie:
        name: "GKE_STATEFUL_SESSION"
        path: "/"
        ttl: "24h"
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Afinidade de cookie HTTP (HTTP_COOKIE)

O tipo de afinidade HTTP_COOKIE se baseia em um cookie nomeado específico retornado em um cabeçalho Set-Cookie. Para usar tipos de afinidade da sessão diferentes de NONE e STRONG_COOKIE_AFFINITY, defina o campo localityLbAlgorithm como MAGLEV ou RING_HASH.

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"
        path: "/"
        ttl: "3600s"
    # HTTP_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

Afinidade de cookie gerado (GENERATED_COOKIE)

O tipo de afinidade GENERATED_COOKIE permite que o balanceador de carga gere e nomeie o cookie de sessão automaticamente. Você pode configurar o valor do campo cookie.ttl em até duas semanas (336h).

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: generated-cookie-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: GENERATED_COOKIE
      cookie:
        ttl: "2h30m"
    # GENERATED_COOKIE affinity requires localityLbAlgorithm to be MAGLEV or RING_HASH.
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: my-stateful-service

O comportamento de TTL zero para afinidade da sessão baseada em cookie inclui o seguinte:

Todas as afinidades de sessão baseadas em cookies (STRONG_COOKIE_AFFINITY, HTTP_COOKIE e GENERATED_COOKIE) têm um atributo ttl.
Um TTL de zero segundos significa que o balanceador de carga não atribui um atributo Expires ao cookie. Nesse caso, o cliente trata o cookie como um cookie de sessão. A definição de uma sessão varia de acordo com o cliente:
- Alguns clientes, como navegadores da Web, retêm o cookie durante toda a sessão de navegação. Essa abordagem significa que o cookie persiste em várias solicitações até que o aplicativo seja fechado.
- Outros clientes tratam uma sessão como uma única solicitação HTTP, descartando o cookie imediatamente após o término da sessão.

Afinidade da sessão baseada em cabeçalho

O tipo de afinidade HEADER_FIELD roteia o tráfego com base em um cabeçalho HTTP específico para cenários como testes A/B ou roteamento especializado de clientes em que um cookie não é adequado. Para usar tipos de afinidade da sessão diferentes de NONE e STRONG_COOKIE_AFFINITY, defina o campo localityLbAlgorithm como MAGLEV ou RING_HASH. Ao contrário do ROUND_ROBIN padrão, esses algoritmos oferecem suporte hashing consistente com base em campos personalizados, como cabeçalhos HTTP.

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

Afinidade da sessão baseada no endereço IP do cliente

O tipo de afinidade CLIENT_IP encaminha o tráfego de um endereço IP de cliente específico para o mesmo pod de back-end da melhor maneira possível. Para usar tipos de afinidade da sessão diferentes de NONE e STRONG_COOKIE_AFFINITY, defina o campo localityLbAlgorithm como MAGLEV ou RING_HASH.

apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: client-ip-affinity-policy
  namespace: default
spec:
  default:
    sessionAffinity:
      type: CLIENT_IP
    localityLbAlgorithm: MAGLEV
  targetRefs:
  - group: ""
    kind: Service
    name: SERVICE_NAME

Verificar a política

Para garantir que sua GCPTrafficDistributionPolicy esteja configurada e ativa corretamente, verifique o status dela depois de aplicá-la:

Para verificar o status da política, execute o seguinte comando:
```
kubectl describe gcptrafficdistributionpolicy POLICY_NAME
```
Substitua POLICY_NAME pelo nome da sua política.
Na saída, verifique a seção Conditions. Um status True com o motivo Attached indica que a configuração é válida e está ativa.

Configurar a afinidade da sessão usando GCPBackendPolicy

Esta seção descreve como configurar a afinidade da sessão usando GCPBackendPolicy.

É possível configurar a afinidade da sessão do GCPBackendPolicy com base nos seguintes critérios:

Endereço IP do cliente (CLIENT_IP)
Cookie gerado (GENERATED_COOKIE)

Quando você configura a afinidade da sessão para o serviço usando GCPBackendPolicy, o gateway define a configuração localityLbPolicy no serviço de back-end como MAGLEV. Quando você remove a afinidade da sessão da GCPBackendPolicy, o gateway reverte a configuração localityLbPolicy para o valor padrão, ROUND_ROBIN.

O manifesto GCPBackendPolicy a seguir especifica a afinidade da sessão com base no endereço IP do cliente:

Serviço

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

Serviço em vários clusters

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

O manifesto GCPBackendPolicy a seguir especifica a afinidade da sessão com base em um cookie gerado e configura o TTL do cookie como 50 segundos:

Serviço

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

Serviço em vários clusters

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

Configurar o tempo limite de diminuição da conexão

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

É possível configurar o tempo limite de diminuição da conexão usando GCPBackendPolicy. O tempo limite de diminuição da conexão é o tempo, em segundos, de espera pela redução das conexões. A duração do tempo limite pode ser de 0 a 3.600 segundos. O valor padrão é 0, o que também desativa a diminuição da conexão.

O manifesto GCPBackendPolicy a seguir especifica um tempo limite de diminuição da conexão de 60 segundos:

Serviço

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

Serviço em vários clusters

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

InferencePool

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

Multi-cluster InferencePool

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

Durante o tempo limite especificado, o GKE aguarda a conclusão das solicitações existentes para o back-end removido. O balanceador de carga não envia novas solicitações para o back-end removido. Depois que o tempo limite é alcançado, o GKE fecha todas as conexões restantes com o back-end.

Geração de registros de acesso HTTP

Nesta seção, descrevemos uma funcionalidade disponível nos clusters do GKE que executam a versão 1.24 ou posterior.

Por padrão:

O controlador de gateway registra todas as solicitações HTTP de clientes para o Cloud Logging.
A taxa de amostragem é 1.000.000, o que significa que todas as solicitações são registradas.
Nenhum campo opcional é registrado.

É possível desativar a geração de registros de acesso no gateway usando uma GCPBackendPolicy de três maneiras:

Você pode deixar a GCPBackendPolicy sem uma seção logging.
Você também pode definir logging.enabled como false.
Você pode definir logging.enabled como true e logging.sampleRate como 0

Também é possível configurar a taxa de amostragem da geração de registros de acesso e uma lista de campos opcionais, por exemplo, tls.cipher ou orcaLoadReport.

Para ativar a geração de registros dos campos opcionais:

Defina logging.OptionalMode como CUSTOM.
Forneça a lista de campos opcionais a serem registrados em logging.optionalFields. Consulte Logging e Monitoring para ver a lista de campos compatíveis.

É possível desativar o registro dos campos opcionais de duas maneiras:

Você pode remover todas as entradas de logging.optionalFields.
Você pode definir logging.OptionalMode como EXCLUDE_ALL_OPTIONAL.

O manifesto GCPBackendPolicy a seguir modifica a taxa de amostragem padrão da geração de registros de acesso e a define como 50% das solicitações HTTP. O manifesto também ativa o registro de dois campos opcionais para um determinado recurso de serviço:

Serviço

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
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: ""
    kind: Service
    name: lb-service

Serviço em vários clusters

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
      - orcaLoadReport.cpu_utilization
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

InferencePool

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
      - orcaLoadReport.cpu_utilization
  # Attach to an InferencePool in the cluster.
  targetRef:
    group: inference.networking.k8s.io
    kind: InferencePool
    name: my-inference-pool

Multi-cluster InferencePool

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
      - orcaLoadReport.cpu_utilization
  # Attach to a multi-cluster InferencePool.
  targetRef:
    group: networking.gke.io
    kind: GCPInferencePoolImport
    name: my-inference-pool-import

Esse manifesto tem os seguintes campos:

enable: true: ativa explicitamente a geração de registros de acesso. Os registros ficam disponíveis no Logging.
sampleRate: 500000: especifica que 50% dos pacotes são registrados. É possível usar um valor entre 0 e 1.000.000. O GKE converte esse valor em um valor com ponto flutuante no intervalo [0, 1] ao dividir por 1.000.000. Esse campo só é relevante se enable estiver definido como true. sampleRate é um campo opcional, mas, se configurado, enable: true também precisa ser definido. Se enable estiver definido como true e sampleRate não for informado, o GKE definirá enable como false.
optionalMode: CUSTOM: especifica que um conjunto de optionalFields precisa ser incluído nas entradas de registro.
optionalFields: tls.cipher, orcaLoadReport.cpu_utilization: especifica que as entradas de registro precisam incluir o nome da criptografia usada para o handshake de TLS e a utilização da CPU do serviço, sempre que estiverem disponíveis.

Configurar o escalonamento automático baseado em tráfego para o gateway de cluster único

Verifique se o cluster do GKE está executando a versão 1.31.1-gke.2008000 ou mais recente.

Para ativar o escalonamento automático baseado em tráfego e o balanceamento de carga baseado em capacidade em um gateway de cluster único, configure a capacidade do serviço. A capacidade de serviço é a capacidade de especificar a quantidade de capacidade de tráfego que um serviço pode receber antes que os pods sejam escalonados automaticamente ou que o tráfego ultrapasse outros clusters disponíveis.

Para configurar a capacidade do serviço, crie um serviço e uma GCPBackendPolicy associada. O manifesto do GCPBackendPolicy usa o campo maxRatePerEndpoint, que define um valor máximo de solicitações por segundo (RPS) por pod em um serviço. O manifesto GCPBackendPolicy a seguir define um 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 saber mais sobre o escalonamento automático baseado em tráfego, consulte Escalonamento automático baseado no tráfego do balanceador de carga.

Solução de problemas

Esta seção fornece orientações para solucionar problemas comuns ao configurar recursos de gateway usando políticas.

A GCPTrafficDistributionPolicy não está em vigor

Sintoma:o tráfego não está sendo distribuído de acordo com as configurações de afinidade da sessão ou de localidade definidas na política.

Motivo:isso geralmente ocorre se a política não estiver vinculada corretamente ao serviço ou se o controlador do gateway encontrar um erro de validação ao tentar sincronizar a configuração com o balanceador de carga.

Alternativa:

Verifique o status da política: confira se ela foi anexada ao seu serviço:
```
kubectl describe gcptrafficdistributionpolicy POLICY_NAME
```
Substitua POLICY_NAME pelo nome da sua política.

Na saída, procure a seção Conditions. Um status True com o motivo Attached indica que a configuração é válida e foi aplicada. Se o status for False, verifique os campos Reason e Message para erros de validação (por exemplo, um algoritmo não compatível com o tipo de afinidade escolhido).
Verifique a sincronização da configuração do gateway: confirme se o gateway que gerencia o tráfego sincronizou essas configurações com a infraestrutura em nuvem.

Na seção Status, verifique se a condição Programmed tem um Status de True. Se for False, isso indica que o controlador do gateway encontrou um erro, possivelmente relacionado à sua GCPTrafficDistributionPolicy.

Confira os campos Reason e Message ao lado da condição Programmed para ver detalhes imediatos. Para mensagens de erro mais detalhadas ou um histórico de falhas de sincronização, confira o Events na parte de baixo da saída.

Várias GCPBackendPolicy anexadas ao mesmo serviço

Sintoma:

A condição de status a seguir pode ocorrer quando você anexa uma GCPBackendPolicy a um serviço ou um 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:

Essa condição de status indica que você está tentando aplicar uma segunda GCPBackendPolicy a um Service ou ServiceImport que já tem uma GCPBackendPolicy anexada.

Várias GCPBackendPolicy anexadas ao mesmo Service ou ServiceImport não são compatíveis com o gateway do GKE. Consulte Restrições e limitações para mais detalhes.

Alternativa:

Configure uma única GCPBackendPolicy que inclua todas as configurações personalizadas e anexe-a ao recurso de destino (Service, ServiceImport, InferencePool ou GCPInferencePoolImport).

Afinidade da sessão ignorada durante a divisão de tráfego

Sintoma:

As solicitações não são roteadas de forma consistente para o mesmo pod de back-end, mesmo que a afinidade da sessão esteja configurada.

Motivo:

A divisão de tráfego ponderada tem precedência sobre a afinidade da sessão. Se uma HTTPRoute definir pesos para vários back-ends, o balanceador de carga primeiro selecionará um back-end com base nos pesos antes de aplicar a lógica de afinidade.

Alternativa:

Evite usar a divisão de tráfego ponderada na mesma regra HTTPRoute em que a fixação de sessão é necessária.

Política de segurança do Cloud Armor não encontrada

Sintoma:

A seguinte mensagem de erro pode aparecer quando você ativa o Cloud Armor em um gateway regional:

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

Motivo:

A mensagem de erro indica que a política de segurança regional especificada do Cloud Armor não existe no seu projeto Google Cloud .

Alternativa:

Crie uma política de segurança do Cloud Armor regional no seu projeto e faça referência a ela na GCPBackendPolicy.

A seguir

Saiba como implantar um gateway.
Saiba mais sobre o controlador de gateway.
Saiba como fazer referência a um gateway em um recurso.
Consulte a referência da API Policy Types.
Consulte as definições de tipo de API.

Configurar recursos de gateway usando políticas Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Requisitos do GKE Gateway Controller

Restrições e limitações

Configurar o acesso global para seu gateway interno regional

Configurar a região para o gateway de vários clusters

Configurar políticas de SSL para proteger o tráfego do cliente para o balanceador de carga

Configurar verificações de integridade

Serviço

Serviço em vários clusters

InferencePool

Multi-cluster InferencePool

Configurar a política de segurança de back-end do Cloud Armor para proteger seus serviços de back-end

Serviço

Serviço em vários clusters

InferencePool

Multi-cluster InferencePool

Configurar o IAP

Serviço

Serviço em vários clusters

Configurar o tempo limite do serviço de back-end

Serviço

Serviço em vários clusters

InferencePool

Multi-cluster InferencePool

Configurar a seleção de back-end usando GCPBackendPolicy

Configurar o roteamento no nível do endpoint com GCPTrafficDistributionPolicy

Configurar o tamanho do anel de hash

Configurar a afinidade da sessão

Configurar a afinidade da sessão usando GCPTrafficDistributionPolicy (padrão)

Afinidade da sessão baseada em cookie

Afinidade da sessão baseada em cabeçalho

Afinidade da sessão baseada no endereço IP do cliente

Verificar a política

Configurar a afinidade da sessão usando GCPBackendPolicy

Serviço

Serviço em vários clusters

Serviço

Serviço em vários clusters

Configurar o tempo limite de diminuição da conexão

Serviço

Serviço em vários clusters

InferencePool

Multi-cluster InferencePool

Geração de registros de acesso HTTP

Serviço

Serviço em vários clusters

InferencePool

Multi-cluster InferencePool

Configurar o escalonamento automático baseado em tráfego para o gateway de cluster único

Solução de problemas

A GCPTrafficDistributionPolicy não está em vigor

Várias GCPBackendPolicy anexadas ao mesmo serviço

Afinidade da sessão ignorada durante a divisão de tráfego

Política de segurança do Cloud Armor não encontrada

A seguir

Configurar recursos de gateway usando políticas