Configure recursos do gateway através de políticas

Esta página mostra como configurar o equilibrador de carga que o Google Kubernetes Engine (GKE) cria quando implementa um gateway num cluster do GKE.

Quando implementa um Gateway, a configuração GatewayClass determina que equilibrador de carga o GKE cria. Este equilibrador de carga gerido está pré-configurado com predefinições que pode modificar através de uma política.

Pode personalizar os recursos do Gateway para se adaptarem aos requisitos da sua infraestrutura ou aplicação anexando políticas a Gateways, serviços ou ServiceImports. Depois de aplicar ou modificar uma política, não precisa de eliminar nem recriar os recursos de gateway, rota ou serviço. A política é processada pelo controlador de gateway e o recurso de balanceamento de carga subjacente é (re)configurado de acordo com a (nova) política.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  • Certifique-se de que tem um cluster do Autopilot ou Standard existente. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Requisitos do GKE Gateway Controller

  • A API Gateway é suportada apenas em clusters nativos de VPC.
  • Se estiver a usar as GatewayClasses regionais ou entre regiões, tem de ativar uma sub-rede apenas de proxy.
  • O seu cluster tem de ter o suplemento HttpLoadBalancing ativado.
  • Se estiver a usar o Istio, tem de atualizar o Istio para uma das seguintes versões:
    • 1.15.2 ou posterior
    • 1.14.5 ou posterior
    • 1.13.9 ou posterior.
  • Se estiver a usar a VPC partilhada, no projeto anfitrião, tem de atribuir a função Compute Network User à conta de serviço do GKE para o projeto de serviço.

Restrições e limitações

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

  • Os recursos GCPGatewayPolicy só podem ser anexados a um gateway.networking.k8s.io Gateway.

  • Os recursos GCPGatewayPolicy têm de existir no mesmo espaço de nomes que o recurso de destino Gateway.

  • Quando usar um gateway de cluster único, os recursos GCPBackendPolicy e HealthCheckPolicy têm de fazer referência a um recurso Service.

  • Quando usar um gateway de vários clusters, os recursos GCPBackendPolicy e HealthCheckPolicy têm de fazer referência a um recurso ServiceImport.

  • Só pode anexar um GCPBackendPolicy a um serviço de cada vez. Quando são criadas duas políticas GCPBackendPolicy que segmentam 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 suportadas com o GKE Gateway.

  • HealthCheckPolicy e GCPBackendPolicy os recursos têm de existir no mesmo espaço de nomes que o recurso Service ou ServiceImport de destino.

  • Os recursos GCPBackendPolicy e HealthCheckPolicy estão estruturados de forma a poderem referenciar apenas um serviço de back-end.

  • GCPBackendPolicy não suporta as opções HEADER_FIELD nem HTTP_COOKIE para afinidade de sessão.

Configure o acesso global para o seu gateway interno regional

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

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

O manifesto GCPGatewayPolicy seguinte 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

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

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.30.3-gke.1225000 ou posterior.

Se a sua frota tiver clusters em várias regiões, pode ter de implementar gateways regionais em diferentes regiões para vários exemplos de utilização, por exemplo, redundância entre regiões, baixa latência e soberania dos dados. No cluster de configuração do gateway de vários clusters, pode especificar a região na qual quer implementar os gateways regionais. Se não especificar uma região, a região predefinida é a da região do cluster de configuração.

Para configurar uma região para o seu gateway de vários clusters, use o campo region no GCPGatewayPolicy. No exemplo seguinte, 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

Configure políticas SSL para proteger o tráfego do cliente para o equilibrador de carga

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

Para proteger o tráfego do cliente para o equilibrador de carga, configure a política SSL adicionando o nome da sua política ao GCPGatewayPolicy. Por predefinição, o Gateway não tem nenhuma política SSL definida e anexada.

Certifique-se de que cria uma política SSL antes de fazer referência à política no seu GCPGatewayPolicy.

O seguinte manifesto GCPGatewayPolicy especifica uma política de segurança denominada 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

Configure verificações de funcionamento

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

Por predefinição, para serviços de back-end que usam os protocolos de aplicação HTTP ou kubernetes.io/h2c, a verificação de estado é do tipo HTTP. Para o protocolo HTTPS, a verificação de estado predefinida é do tipo HTTPS. Para o protocolo HTTP2, a verificação de estado predefinida é do tipo HTTP2.

Pode usar um HealthCheckPolicy para controlar as definições de verificação de funcionamento do balanceador de carga. Cada tipo de verificação de estado (http, https, grpc, http2 e tcp) tem parâmetros que pode definir. Google Cloud cria uma verificação de estado única para cada serviço de back-end para cada serviço do GKE.

Para que o equilibrador de carga funcione normalmente, pode ter de configurar um HealthCheckPolicy personalizado para o equilibrador de carga se o caminho da verificação de estado não for o "/" padrão. Esta configuração também é necessária se o caminho exigir cabeçalhos especiais ou se precisar de ajustar os parâmetros da verificação de estado. Por exemplo, se o caminho do pedido predefinido for "/", mas o seu serviço não estiver acessível nesse caminho do pedido e, em alternativa, usar "/health" para comunicar o respetivo estado, tem de configurar requestPath no seu HealthCheckPolicy em conformidade.

O manifesto HealthCheckPolicy seguinte mostra todos os campos disponíveis quando configura uma política de verificação de estado:

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 o seguinte:

  • INTERVAL: especifica o check-interval>, em segundos, para cada verificador de estado de funcionamento. Este é o tempo desde o início da verificação de um verificador até ao início da respetiva verificação seguinte. Se omitir este parâmetro, a predefinição é 15 segundos se não for especificado nenhum HealthCheckPolicy e 5 segundos quando é especificado um HealthCheckPolicy sem valor checkIntervalSec. Google Cloud Para mais informações, consulte o artigo Várias sondagens e frequência.
  • TIMEOUT: especifica o tempo que Google Cloud aguarda uma resposta a uma sondagem. O valor de TIMEOUT tem de ser inferior ou igual ao INTERVAL. As unidades são segundos. Cada teste requer um código de resposta HTTP 200 (OK) a ser enviado antes do limite de tempo do teste.
  • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: especifica o número de tentativas de ligação sequenciais que têm de ser bem-sucedidas ou falhar, para, pelo menos, uma sonda, para alterar o estado de saúde de saudável para não saudável ou de não saudável para saudável. Se omitir um destes parâmetros, a Google Cloud predefinição é 2.
  • PROTOCOL: especifica um protocolo usado pelos sistemas de sondagem para a verificação do estado. Para mais informações, consulte os 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 o registo está ativado ou desativado.
  • PORT_SPECIFICATION: especifica se a verificação de estado usa uma porta fixa (USE_FIXED_PORT), uma porta com nome (USE_NAMED_PORT) ou uma porta de serviço (USE_SERVING_PORT). Se não for especificado, a verificação de estado segue o comportamento especificado no campo port. Se port não for especificado, este campo tem a predefinição USE_SERVING_PORT.
  • PORT: Uma HealthCheckPolicy só suporta a especificação da porta de verificação de estado do equilibrador de carga através de um número de porta. Se omitir este parâmetro, a Google Cloud predefinição é 80. Uma vez que o balanceador de carga envia sondagens diretamente para o endereço IP do pod, deve selecionar uma porta que corresponda a um containerPort de um pod de serviço, mesmo que o containerPort seja referenciado por um targetPort do serviço. Não está limitado ao containerPorts referenciado pelo targetPort de um serviço.
  • HOST: o valor do cabeçalho do anfitrião no pedido de verificação do estado. Este valor usa a definição da RFC 1123 de um nome de anfitrião, exceto que os endereços IP numéricos não são permitidos. Se não for especificado ou for deixado em branco, este valor é predefinido como o endereço IP da verificação de estado.
  • REQUEST: especifica os dados da aplicação a enviar após o estabelecimento da ligação TCP. Se não for especificado, o valor é predefinido como vazio. Se o pedido e a resposta estiverem vazios, a ligação estabelecida, por si só, indica o estado de funcionamento. Os dados do pedido só podem estar no formato ASCII.
  • REQUEST_PATH: especifica o request-path do pedido de verificação de estado. Se não for especificado ou for deixado vazio, o fuso horário predefinido é /.
  • RESPONSE: especifica os bytes a comparar com o início dos dados de resposta. Se não for especificado ou for deixado em branco, o GKE interpreta qualquer resposta como saudável. Os dados de resposta só podem ser ASCII.
  • PROXY_HEADER: especifica o tipo de cabeçalho proxy. Pode usar o NONE ou o PROXY_V1. A predefinição é NONE.
  • GRPC_SERVICE_NAME: um nome opcional do serviço gRPC. Omita este campo para especificar todos os serviços.

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

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

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

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

Certifique-se de que cria uma política de segurança de back-end do Cloud Armor antes de fazer referência à política no seu GCPBackendPolicy. Se estiver a ativar um gateway regional, tem de criar uma política de segurança de back-end do Cloud Armor regional.

O manifesto GCPBackendPolicy seguinte especifica uma política de segurança do back-end denominada 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

Configure o IAP

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

O Identity-Aware Proxy (IAP) aplica políticas de controlo de acesso aos serviços de back-end associados a uma HTTPRoute. Com esta aplicação, apenas os utilizadores autenticados ou as aplicações com a função de gestão de identidade e de acesso (IAM) correta atribuída podem aceder a estes serviços de back-end.

Por predefinição, não existe nenhuma IAP aplicada aos seus serviços de back-end. Tem de configurar explicitamente a IAP num GCPBackendPolicy.

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

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

  2. Crie um segredo para a sua IAP:

    1. Na Google Cloud consola, aceda à página Credenciais:

      Aceder a Credenciais

    2. Clique no nome do cliente e transfira o ficheiro do cliente OAuth.

    3. No ficheiro do cliente OAuth, copie o segredo OAuth para a área de transferência.

    4. Cria um ficheiro denominado iap-secret.txt.

    5. Cole o segredo OAuth no ficheiro iap-secret.txt através do 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 de IAP que faz referência a um segredo:

    1. Crie o seguinte GCPBackendPolicymanifesto, substitua os SECRET_NAME e CLIENT_ID, respetivamente. Guarde 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. Valide a configuração:

    1. Confirme que a política foi aplicada após criar o seu GCPBackendPolicy com compras na app:

      kubectl get gcpbackendpolicy

      O resultado é semelhante ao seguinte:

      NAME             AGE
backend-policy   45m

    2. Para ver mais detalhes, use o comando describe:

      kubectl describe gcpbackendpolicy

      O resultado é semelhante ao seguinte:

      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

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

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

O manifesto seguinte especifica um período de tempo limite do serviço de back-end de 40 segundos.GCPBackendPolicy O campo timeoutSec tem como predefiniçã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

Configure a seleção de back-end com GCPBackendPolicy

O CUSTOM_METRICSmodo de equilíbrioGCPBackendPolicy permite-lhe configurar métricas personalizadas específicas que influenciam a forma como os serviços de back-end dos balanceadores de carga distribuem o tráfego. Este modo de equilíbrio permite o equilíbrio de carga com base em métricas personalizadas que define e que são comunicadas pelos back-ends da aplicação.

Para mais informações, consulte o artigo Gestão de tráfego com equilíbrio de carga baseado em métricas personalizadas.

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

  • name: especifica o nome definido pelo utilizador da métrica personalizada.
  • maxUtilization: define a utilização alvo ou máxima para esta métrica. O intervalo válido é [0, 100].
  • dryRun: um campo booleano. Quando é verdadeiro, os dados das métricas são comunicados ao Cloud Monitoring, mas não influenciam as decisões de equilíbrio de carga.

Exemplo

O exemplo seguinte mostra um manifesto GCPBackendPolicy que configura métricas personalizadas para a seleção de back-end e o encaminhamento ao nível do ponto final.

  1. Guarde 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 RATEmodo de balanceamento e na métrica gpu-load personalizada.

Configure o encaminhamento ao nível do ponto final com a GCPTrafficDistributionPolicy

O GCPTrafficDistributionPolicy configura o algoritmo de balanceamento de carga para a seleção de pontos finais num back-end. Quando seleciona WEIGHTED_ROUND_ROBIN, o balanceador de carga usa ponderações derivadas de métricas comunicadas (incluindo métricas personalizadas) para distribuir o tráfego por instâncias ou pontos finais individuais.

O campo WEIGHTED_ROUND_ROBIN localityLbPolicy do recurso GCPTrafficDistributionPolicy especifica um algoritmo de equilíbrio de carga para selecionar instâncias ou pontos finais individuais num back-end. Quando usa este algoritmo, a política usa 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 utilizador da métrica personalizada.
  • dryRun: um campo booleano. Quando é verdadeiro, os dados de métricas são comunicados ao Cloud Monitoring, mas não influenciam o equilíbrio de carga.

Para mais informações, consulte o artigo Gestão de tráfego com equilíbrio de carga baseado em métricas personalizadas.

Exemplo

O exemplo seguinte mostra um manifesto GCPTrafficDistributionPolicy que configura o encaminhamento ao nível do ponto final usando o algoritmo de equilíbrio de carga WEIGHTED_ROUND_ROBIN e métricas personalizadas.

  1. Guarde o seguinte manifesto de exemplo 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 os pontos finais com base no WEIGHTED_ROUND_ROBIN algoritmo e usando as métricas personalizadas fornecidas.

Configure a afinidade de sessão

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

Pode configurar a afinidade de sessão com base nos seguintes critérios:

  • Endereço IP do cliente
  • Cookie gerado

Quando configura a afinidade de sessão para o seu serviço, a definição localityLbPolicy do gateway é definida como MAGLEV.

Quando remove uma configuração de afinidade de sessão de GCPBackendPolicy, o gateway reverte a definição localityLbPolicy para o valor predefinido, ROUND_ROBIN.

O manifesto GCPBackendPolicy seguinte 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 seguinte especifica uma afinidade de sessão com base num cookie gerado e configura o TTL dos cookies para 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

Pode usar os seguintes valores para o campo sessionAffinity.type:

  • CLIENT_IP
  • GENERATED_COOKIE
  • NONE

Configure o limite de tempo da drenagem da ligação

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

Pode configurar o tempo limite de esgotamento da ligação através de GCPBackendPolicy. O limite de tempo de drenagem da ligação é o tempo, em segundos, de espera pela drenagem das ligações. A duração do limite de tempo pode ser de 0 a 3600 segundos. O valor predefinido é 0, o que também desativa a drenagem de ligações.

O manifesto seguinte GCPBackendPolicy especifica um limite de tempo de esgotamento da ligaçã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 a duração especificada do tempo limite, o GKE aguarda a conclusão dos pedidos existentes ao back-end removido. O balanceador de carga não envia novos pedidos ao back-end removido. Quando a duração do limite de tempo é atingida, o GKE fecha todas as ligações restantes ao back-end.

Registo de acesso HTTP

Esta secção descreve uma funcionalidade disponível em clusters do GKE com a versão 1.24 ou posterior.

Por predefinição:

  • O controlador do gateway regista todos os pedidos HTTP dos clientes no Cloud Logging.
  • A taxa de amostragem é de 1 000 000, o que significa que todos os pedidos são registados.
  • Nenhum campo opcional é registado.

Pode desativar o registo de acesso no seu gateway através de um GCPBackendPolicy de três formas:

  • Pode deixar a secção GCPBackendPolicy sem logging
  • Pode definir logging.enabled como false
  • Pode definir logging.enabled como true e logging.sampleRate como 0

Também pode configurar a taxa de amostragem do registo de acesso e uma lista de campos opcionais, por exemplo, "tls.cipher" ou "orca_load_report".

Para ativar o registo dos campos opcionais:

  • Defina logging.OptionalMode como CUSTOM.
  • Indique a lista de campos opcionais a registar em logging.optionalFields. Consulte o artigo sobre registo e monitorização para ver a lista de campos suportados.

Pode desativar o registo dos campos opcionais de duas formas:

  • Pode remover todas as entradas de logging.optionalFields.
  • Pode definir logging.OptionalMode como EXCLUDE_ALL_OPTIONAL.

O seguinte manifesto GCPBackendPolicy modifica a taxa de amostragem predefinida do registo de acesso e define-a como 50% dos pedidos HTTP. O manifesto também permite o registo de dois campos opcionais para um determinado recurso Service:

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

Este manifesto tem os seguintes campos:

  • enable: true: ativa explicitamente o registo de acesso. Os registos estão disponíveis em Registo.
  • sampleRate: 500000: especifica que 50% dos pacotes são registados. Pode usar um valor entre 0 e 1 000 000. O GKE converte este valor num valor de vírgula flutuante no intervalo [0, 1] dividindo por 1 000 000. Este campo só é relevante se enable estiver definido como true. sampleRate é um campo opcional, mas, se estiver configurado, enable: true também tem de ser definido. Se enable estiver definido como true e sampleRate não for fornecido, o GKE define enable como false.
  • optionalMode: CUSTOM: especifica que um conjunto de optionalFields deve ser incluído nas entradas do registo.
  • optionalFields: tls.cipher, orca_load_report.cpu_utilization: especifica que as entradas de registo devem incluir o nome da cifra usada para a negociação TLS e a utilização da CPU do serviço, sempre que estes estiverem disponíveis.

Configure a escala automática baseada no tráfego para o gateway de cluster único

Certifique-se de que o cluster do GKE está a executar a versão 1.31.1-gke.2008000 ou posterior.

Para ativar a escala automática baseada no tráfego e o equilíbrio de carga baseado na capacidade num gateway de cluster único, pode configurar 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 de os pods serem dimensionados automaticamente ou o tráfego transbordar para outros clusters disponíveis.

Para configurar a capacidade do serviço, crie um serviço e um GCPBackendPolicyassociado. O manifesto GCPBackendPolicy usa o campo maxRatePerEndpoint que define um valor máximo de pedidos por segundo (RPS) por agrupamento num serviço. O manifesto GCPBackendPolicy seguinte 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 ajuste de escala automático baseado no tráfego, consulte o artigo Ajuste de escala automático baseado no tráfego do equilibrador de carga.

Resolução de problemas

Vários GCPBackendPolicy anexados ao mesmo Service

Sintoma:

A seguinte condição de estado pode ocorrer quando anexa um GCPBackendPolicy a um Service ou a 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:

Esta condição de estado indica que está a tentar aplicar um segundo GCPBackendPolicy a um Service ou ServiceImport que já tem um GCPBackendPolicy anexado.

Não é suportado ter vários GCPBackendPolicy anexados ao mesmo Service ou ServiceImport com o GKE Gateway. Consulte a secção Restrições e limitações para ver mais detalhes.

Solução alternativa:

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

Não foi encontrada a política de segurança do Cloud Armor

Sintoma:

A seguinte mensagem de erro pode aparecer quando ativa o Cloud Armor no 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 do Cloud Armor regional especificada não existe no seu Google Cloud projeto.

Solução alternativa:

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

O que se segue?