Configurar recursos de gateway usando políticas

Autopilot Padrão

---

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, não é preciso excluir ou recriar os recursos de gateway, rota ou serviço. A política é processada pelo controlador de gateway, e o recurso do balanceador de carga subjacente é (re)configurada de acordo com a (nova) política.

Antes de começar

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

• Ativar 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 gcloud components update.
  Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Requisitos do GKE Gateway Controller

• Para o Standard, o GKE versão 1.24 ou posterior.

• Para o Autopilot, o GKE versão 1.26 ou posterior.
• Google Cloud CLI versão 407.0.0 ou mais recente.
• A API Gateway é compatível apenas com clusters nativos da VPC.
• Se você estiver usando o GatewayClasses interno, 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.networking.k8s.io Gateway.

• Os recursos GCPGatewayPolicy precisam existir 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, os recursos GCPBackendPolicy e HealthCheckPolicy devem se referir a um recurso ServiceImport.

• Apenas um GCPGatewayPolicy pode ser anexado a um serviço por vez. Quando duas políticas GCPGatewayPolicy são criadas e segmentam a mesma Service ou ServiceImport, a política mais antiga tem precedência e a segunda falha ao ser 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.

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:
    allowGlobalAccess: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: my-gateway

Observação: o upgrade de um gateway interno existente adicionando acesso global recria a regra de encaminhamento do seu balanceador de carga regional interno. Esse upgrade exclui e depois recria os balanceadores de carga do Google Cloud, o que resulta em até 15 minutos de indisponibilidade. Recomendamos realizar essa operação durante uma janela de manutenção para evitar que o aplicativo fique inativo.

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 a GCPGatewayPolicy. Por padrão, o gateway não tem nenhuma política de SSL definida e anexada.

Crie uma política de SSL antes de referenciar a política em GCPGatewayPolicy.

Observação: se você usa um gateway regional, crie uma política de SSL regional.

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.

É 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 e http2) tem parâmetros que podem ser definidos. O Google Cloud cria uma verificação de integridade exclusiva para cada serviço de back-end em cada serviço do GKE.

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

Serviço

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

Serviço em vários clusters

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

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 do Google Cloud será de cinco segundos. Para mais informações, consulte Várias sondagens e frequências.
• TIMEOUT: especifica o tempo pelo qual o 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 e Critérios de sucesso para gRPC. 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 nos campos port e portName. Se port e portName não forem especificados, o padrão do campo será USE_SERVING_PORT.
• PATH: especifica o caminho de solicitação a que o sistema de sondagem se conecta para verificações de integridade HTTP, HTTPS ou HTTP2. Se você omitir esse parâmetro, o padrão do Google Cloud será /.
• 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 do 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.
• PORT_NAME: especifica o nome da porta, conforme definido em InstanceGroup.NamedPort.name. Se port e portName estiverem definidos, o Google Cloud considera o valor port primeiro.
• 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_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 do back-end do Google 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.

Observação: o Google Cloud substituiu a política LbPolicy pela política GCPBackendPolicy. O LbPolicy ainda é compatível, mas sem outros atributos.

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

Crie uma política de segurança do back-end do Google Cloud Armor antes de referenciar a política na GCPBackendPolicy.

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:
    securityPolicy: example-security-policy
  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:
    securityPolicy: example-security-policy
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

Configurar o IAP

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

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

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

1. Ative o IAP para GKE Não configure o back-end (Como configurar o BackendConfig) porque BackendConfig só é válido no caso de uma implantação do Ingress.

2. Crie um secret para o IAP:

   1. Acesse a página "Credenciais". Botão: Acessar a página "Credenciais".

   2. Clique no nome do cliente e faça o download do arquivo do cliente OAuth.

   3. No arquivo do cliente OAuth, copie a chave secreta OAuth na área de transferência.

   4. Crie um arquivo chamado iap-secret.txt.

   5. Cole a chave secreta OAuth no arquivo iap-secret.txt usando o seguinte comando:

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

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

   1. Crie o manifesto GCPBackendPolicy a seguir, substituindo SECRET_NAME e CLIENT_ID, respectivamente. Salve o manifesto como backend-policy.yaml:

      Serviço

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

      Serviço em vários clusters

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

   2. Aplique o manifesto backend-policy.yaml:

      kubectl apply -f backend-policy.yaml
      

4. Verifique a configuração:

   1. Confirme se a política foi aplicada depois de criar GCPBackendPolicy com o IAP:

      kubectl get gcpbackendpolicy
      

      O resultado será assim:

      NAME             AGE
      backend-policy   45m
      

   2. 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 GCPGatewayPolicy "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.

Observação: o Google Cloud substituiu a política LbPolicy pela política GCPBackendPolicy. O LbPolicy ainda é compatível, mas sem outros atributos.

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

Configurar a afinidade da sessão

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

Observação: o Google Cloud substituiu a política LbPolicy pela política GCPBackendPolicy. O LbPolicy ainda é compatível, mas sem outros atributos.

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

• Endereço IP do cliente
• Cookie gerado

Quando você define a afinidade da sessão para o serviço, a configuração localityLbPolicy do gateway é definida como MAGLEV.

Quando você remove uma configuração de afinidade da sessão de GCPBackendPolicy, o gateway reverte a configuração localityLbPolicy para o valor padrão, ROUND_ROBIN. Esse valor é definido silenciosamente no serviço de back-end gerenciado pelo GKE (anexado ao balanceador de carga) e não é refletido na saída de um comando da gcloud CLI, na interface ou com o Terraform.

O manifesto GCPBackendPolicy a seguir especifica uma afinidade de 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:
    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:
    sessionAffinity:
      type: CLIENT_IP
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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

Serviço

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

Serviço em vários clusters

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

É possível usar as seguintes opções para sessionAffinity.type: CLIENT_IP , CLIENT_IP_PROTO, CLIENT_IP_PORT_PROTO, GENERATED_COOKIE, HEADER_FIELD, HTTP_COOKIE, NONE.

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.

Observação: o Google Cloud substituiu a política LbPolicy pela política GCPBackendPolicy. O LbPolicy ainda é compatível, mas sem outros atributos.

É 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

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.

Observação: o Google Cloud substituiu a política LbPolicy pela política GCPBackendPolicy. O LbPolicy ainda é compatível, mas sem outros atributos.

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.

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

• Você pode deixar a seção GCPBackendPolicy sem 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.

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 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:
    logging:
      enabled: true
      sampleRate: 500000
  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:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: net.gke.io
    kind: ServiceImport
    name: lb-service

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 define enable como false.

Solução de problemas

Vários GCPBackendPolicy anexados ao mesmo Service

Sintoma:

A condição de status a seguir pode ocorrer quando você anexa um GCPBackendPolicy a um Service 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 um segundo GCPBackendPolicy a um Service ou ServiceImport que já tem um GCPBackendPolicy anexado.

Vários GCPBackendPolicy anexados 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:

Defina um único GCPBackendPolicy que inclua todas as configurações personalizadas e anexe-o ao seu Service ou ServiceImport.

A seguir

• Saiba mais sobre o controlador de gateway.
• Saiba como fazer referência a um gateway em um recurso.