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, 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 CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. 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.

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.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 GCPBackendPolicy pode ser anexado a um serviço por vez. Quando duas políticas GCPBackendPolicy 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.

  • O GCPBackendPolicy não é compatível com as opções HEADER_FIELD ou HTTP_COOKIE para afinidade da sessão.

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, como 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 seu 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 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.

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 um HealthCheckPolicy personalizado se o caminho da verificação de integridade não for o padrão "/". Essa configuração também é necessária se o caminho exigir cabeçalhos especiais ou 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 no HealthCheckPolicy de acordo.

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: ENABLED     config:       type: PROTOCOL       httpHealthCheck:         portSpecification: PORT_SPECIFICATION         port: PORT         host: HOST         requestPath: REQUEST_PATH         response: RESPONSE         proxyHeader: PROXY_HEADER       httpsHealthCheck:         portSpecification: PORT_SPECIFICATION         port: PORT         host: HOST         requestPath: REQUEST_PATH         response: RESPONSE         proxyHeader: PROXY_HEADER       grpcHealthCheck:         grpcServiceName: GRPC_SERVICE_NAME         portSpecification: PORT_SPECIFICATION         port: PORT       http2HealthCheck:         portSpecification: PORT_SPECIFICATION         port: PORT         host: HOST         requestPath: REQUEST_PATH         response: RESPONSE         proxyHeader: PROXY_HEADER       tcpHealthCheck:         portSpecification: PORT_SPECIFICATION         port: PORT         portName: PORT_NAME         request: REQUEST         response: RESPONSE         proxyHeader: PROXY_HEADER   # Attach to a Service in the cluster.   targetRef:     group: ""     kind: Service     name: lb-service

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

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 nenhum HealthCheckPolicy for especificado e de 5 segundos quando um HealthCheckPolicy for especificado 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 do 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 do back-end do 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 de back-end do Cloud Armor definida e anexada.

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

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

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. No console Google Cloud , acesse a página Credenciais:

      Ir para 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 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

      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: SECRET_NAME       clientID: CLIENT_ID   # Attach to a multi-cluster Service by referencing the ServiceImport.   targetRef:     group: net.gke.io     kind: ServiceImport     name: lb-service

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

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

O modo de balanceamento CUSTOM_METRICS no 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 relatórios de 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.

  1. 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         maxUtilization: 100 # value ranges from 0 to 100 and maps to the floating pointrange [0.0, 1.0]         dryRun: false

  2. 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 configuração GCPTrafficDistributionPolicy configura o algoritmo de balanceamento de carga para escolha de endpoints em um back-end. Quando você seleciona WEIGHTED_ROUND_ROBIN, o balanceador de carga usa pesos derivados de métricas informadas (incluindo métricas personalizadas) para distribuir o tráfego a instâncias ou endpoints individuais.

O campo WEIGHTED_ROUND_ROBIN localityLbPolicy do recurso GCPTrafficDistributionPolicy especifica um algoritmo de balanceamento de carga para selecionar instâncias ou endpoints individuais em um back-end. Quando você usa esse algoritmo, a política utiliza métricas personalizadas para calcular ponderações para a atribuição de carga.

A matriz customMetrics[] na configuração GCPTrafficDistributionPolicy contém os seguintes campos:

  • name: especifica o nome definido pelo usuário da métrica personalizada.
  • dryRun: um campo booleano. Quando é "true", os dados de métricas são enviados ao Cloud Monitoring, mas não influenciam o balanceamento de carga.

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 GCPTrafficDistributionPolicy que configura o roteamento no nível do endpoint usando o algoritmo de balanceamento de carga WEIGHTED_ROUND_ROBIN e métricas personalizadas.

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

  2. 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 usando as métricas personalizadas fornecidas.

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.

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

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:     # 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 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:     # 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

É possível usar os seguintes valores para o campo sessionAffinity.type:

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

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

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 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 e uma lista de campos opcionais, por exemplo, "tls.cipher" ou "orca_load_report".

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       - orca_load_report.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       - orca_load_report.cpu_utilization   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.
  • optionalMode: CUSTOM: especifica que um conjunto de optionalFields deve ser incluído nas entradas de registro.
  • optionalFields: tls.cipher, orca_load_report.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 seu 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 um GCPBackendPolicy associado. O manifesto 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

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.

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 projeto e faça referência a ela no GCPBackendPolicy.

A seguir