Balanceamento de carga avançado em clusters do GKE

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Nesta página, mostramos como configurar o balanceamento de carga avançado em clusters do GKE para usuários gerenciados do Cloud Service Mesh (TD) usando a API do Kubernetes. Para acessar o guia do usuário correspondente para configurar o balanceamento de carga avançado usando a API Google Cloud , consulte Configurar o balanceamento de carga avançado.

É possível usar o balanceamento de carga avançado para:

• Manter o tráfego em uma zona de serviço até que a capacidade local seja esgotada.
• Envie tráfego para o serviço em um local "principal" com failover para um local secundário quando endpoints suficientes no local principal ficarem inativos.
• Controle quando o failover acontece (com base na porcentagem de hosts saudáveis).

Limitações

• Limitações gerais sobre o uso do balanceamento de carga avançado no Google Cloud .
• Esse recurso está disponível apenas para usuários gerenciados do Cloud Service Mesh que usam o Traffic Director como plano de controle e exige a versão 1.19.10-asm.22 ou mais recente do plano de dados.
• Nem todos os campos em GCPTrafficDistributionPolicy e GCPBackendPolicy são compatíveis com o managedCloud Service Mesh (TD). Os campos aceitos são os seguintes:
  • GCPTrafficDistributionPolicy
    • ServiceLbAlgorithm
    • AutoCapacityDrain
    • FailoverConfig
  • GCPBackendPolicy
    • MaxRatePerEndpoint
    • BackendPreference
• O balanceamento de carga avançado só pode ser aplicado a serviços do Kubernetes com cargas de trabalho executadas no Google Cloud. Não há suporte para serviços ou cargas de trabalho externos (como ServiceEntry).
• As políticas de balanceamento de carga só podem ser aplicadas a serviços individuais do Kubernetes. Não há suporte para políticas de balanceamento de carga em todo o namespace/mesh.
• Somente a capacidade QPS é aceita.
• Somente as versões do GKE >= 1.31.1 são compatíveis.
• As políticas de balanceamento de carga avançadas da malha de serviço precisam ser aplicadas apenas a serviços que atendem apenas o tráfego da malha. Ele não pode ser aplicado a serviços que servem como back-ends do GKE Gateway. Os comportamentos de tráfego são indefinidos quando um tráfego de balanceamento de carga avançado é direcionado a um serviço do Kubernetes que atende ao tráfego da malha e ao tráfego de um gateway do GKE.

Configurar o balanceamento de carga avançado

É possível usar os recursos personalizados abaixo para configurar o balanceamento de carga avançado no GKE. A definição detalhada do recurso está disponível no repositório gke-gateway-api.

GCPTrafficDistributionPolicy

A GCPTrafficDistributionPolicy configura a política de balanceamento de carga no nível do serviço para serviços do Kubernetes. Ele permite que você:

• Escolha um algoritmo de balanceamento de carga personalizado. Os algoritmos compatíveis são descritos na tabela de balanceamento de carga avançado.
• Ative a diminuição automática de capacidade.
• Ajuste o limite de integridade para failover.

Se várias políticas GCPTrafficDistributionPolicies forem direcionadas ao mesmo serviço, a mais antiga será aplicada.

GCPBackendPolicy

A GCPBackendPolicy configura propriedades de back-end de serviço que afetam o comportamento do balanceamento de carga, incluindo:

• Capacidade do back-end do serviço.
• Designar back-ends preferenciais.

Se várias GCPBackendPolicies segmentarem o mesmo serviço em um cluster, a política mais antiga será aplicada.

Status da política

Tanto a GCPTrafficDistributionPolicy quanto a GCPBackendPolicy têm um campo de status que indica o status de anexo da política.

Por exemplo, executar kubectl describe gcpbackendpolicies example-policy -n example produziria uma saída semelhante a:

...
Status:
  Ancestors:
    Ancestor Ref:
      Group:
      Kind:       Service
      Name:       example-svc
      Namespace:  example
    Conditions:
      Last Transition Time:  2024-10-13T01:15:03Z
      Message:
      Observed Generation:   1
      Reason:                Attached
      Status:                True
      Type:                  Attached
    Controller Name:         gsmconfig.gke.io/controller

Configuração preliminar

Antes de concluir este guia, você precisa provisionar o Cloud Service Mesh em um cluster do GKE.

1. Verifique se os CRDs estão instalados:

   kubectl get crd
   

   A saída é semelhante a:

   ...
   gcptrafficdistributionpolicies.networking.gke.io   2024-07-18T21:50:12Z
   gcpbackendpolicies.networking.gke.io               2024-07-18T21:50:12Z
   ...
   

2. Instale o CRD GCPBackendPolicy, se ainda não estiver instalado:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcpbackendpolicies.yaml
   

3. Instale o CRD GCPTrafficDistributionPolicy, se ainda não estiver instalado:

   kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-gateway-api/refs/heads/main/config/crd/networking.gke.io_gcptrafficdistributionpolicies.yaml
   

Os exemplos de políticas neste guia do usuário têm como alvo o serviço foo no namespace foo para fins de demonstração. Execute o comando abaixo para criar o serviço e o namespace de teste ou, se preferir, use seu próprio serviço e namespace:

kubectl apply -f - <<EOF
kind: Namespace
apiVersion: v1
metadata:
  name: foo
  labels:
    istio-injection: enabled
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: foo
  namespace: foo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: test-backend
  template:
    metadata:
      labels:
        app: test-backend
    spec:
      containers:
      - name: whereami
        image: gcr.io/google-samples/whereami:v1.2.23
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: foo
spec:
  selector:
    app: test-backend
  ports:
  - port: 8080
    targetPort: 8080
EOF

Como configurar o algoritmo de balanceamento de carga

Por padrão, o tráfego para um serviço é distribuído de maneira uniforme para cada back-end de serviço saudável em uma malha de serviço do Cloud Service Mesh. É possível criar a política GCPTrafficDistributionPolicy a seguir para que o tráfego seja distribuído para a zona mais próxima até a capacidade do back-end:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
    serviceLbAlgorithm: WATERFALL_BY_ZONE
EOF

Observação: as configurações em GCPTrafficDistributionPolicy têm precedência sobre as da API principal do serviço do Kubernetes.

Por padrão, os back-ends de serviço são tratados como se tivessem capacidade infinita. Quando há hosts íntegros suficientes na zona local/mais próxima, o tráfego nunca é distribuído fora da zona local/mais próxima para uma determinada localidade do cliente. Você pode configurar a capacidade do back-end do serviço usando a GCPBackendPolicy para que uma única zona não fique sobrecarregada.

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
  namespace: foo
spec:
  targetRef:
    kind: Service
    group: ""
    name: foo-backend
  default:
    maxRatePerEndpoint: 5
EOF

Como ajustar o comportamento de failover

Por padrão, o failover não será acionado enquanto uma porcentagem suficiente de hosts estiver íntegra nos back-ends principais. Para mais informações sobre back-ends principais e outras terminologias, consulte a Visão geral do balanceamento de carga avançado. A GCPTrafficDistributionPolicy permite configurar o limite de porcentagem de hosts saudáveis até que o tráfego seja desviado dos back-ends principais para os back-ends de failover. O failover é acionado mais cedo com um limite maior. Por exemplo, se você quiser que o failover seja acionado assim que a porcentagem de hosts íntegros cair abaixo de 90% nos back-ends principais, configure a política GCPTrafficDistributionPolicy:

kubectl apply -f - <<EOF
apiVersion: networking.gke.io/v1
kind: GCPTrafficDistributionPolicy
metadata:
  name: lb-policy
  namespace: foo
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: foo-service
  default:
   failoverConfig:
     failoverHealthThreshold: 90
EOF

Como configurar o balanceamento de carga avançado em uma malha de serviço de vários clusters

A GCPTrafficDistributionPolicy e a GCPBackendPolicy são aplicadas em diferentes escopos em uma malha de serviços de vários clusters.

Quando uma GCPTrafficDistributionPolicy é direcionada a um serviço de vários clusters, ela define o comportamento de balanceamento de carga do nível de serviço em todos os clusters. Apenas uma GCPTrafficDistributionPolicy precisa ser criada para um serviço de vários clusters específico. Se você estiver usando a API Istio para configurar a malha de serviço, será possível criar a GCPTrafficDistributionPolicy em qualquer cluster da frota. Para verificar se uma política conflita com outra, inspecione o status da política.

Quando uma GCPBackendPolicy é direcionada a um serviço de vários clusters, ela define as configurações do nível de back-end (por exemplo, a capacidade por pod) para os pods de back-end selecionados pelo serviço de segmentação no cluster local. Para o mesmo serviço com vários clusters, é possível definir diferentes configurações de nível de back-end em clusters diferentes.

No exemplo a seguir, uma GCPTrafficDistributionPolicy é criada no cluster A para definir o algoritmo de balanceamento de carga a ser usado em toda a frota, enquanto as GCPBackendPolicies estão em cada cluster. Ambas as políticas GCPBackendPolicy configuram uma capacidade de 10qps por pod para os pods de back-end no cluster local, enquanto a GCPBackendPolicy no cluster A configura os pods de back-end no cluster A como back-end preferencial.

Juntas, essas políticas configuram os comportamentos de balanceamento de carga para o tráfego no mesh enviado ao serviço foo:

• O tráfego de qualquer lugar prefere back-ends no cluster A até que os pods de back-end no cluster A precisem processar 10 qps por pod.
  • Esse comportamento é definido principalmente pela GCPBackendPolicy que define backendPreference como PREFERRED no cluster A.
• O tráfego que excede a capacidade configurada dos back-ends no cluster A é roteado usando o algoritmo WATERFALL_BY_ZONE para o cluster B. Para uma explicação mais detalhada dos back-ends preferidos, consulte Visão geral do balanceamento de carga avançado.
  • Esse comportamento é definido principalmente pela GCPTrafficDistributionPolicy, que define o algoritmo, no cluster A e na GCPBackendPolicy, que definem a capacidade do back-end, nos clusters A e B.

Observação: esta seção demonstra o recurso do Cloud Service Mesh para balancear a carga do tráfego em vários clusters. Para fins de demonstração, implante o exemplo de serviço foo e os pods de back-end nos dois clusters.

No Istio, os serviços Kubernetes comuns se tornam implicitamente "multicluster" quando há vários clusters na malha de serviço e o serviço é criado em fronteiras de cluster. Embora a GCPTrafficDistributionPolicy a seguir seja destinada ao serviço foo do Kubernetes regular, ela se aplica ao serviço foo de vários clusters, que consiste em cargas de trabalho correspondentes em dois clusters.

1. Crie a GCPTrafficDistributionPolicy para o cluster A:

   kubectl apply --context cluster-a-context -f - <<EOF
   kind: GCPTrafficDistributionPolicy
   apiVersion: networking.gke.io/v1
   metadata:
   name: foo-traffic-distribution-policy
   namespace: foo
   spec:
     targetRefs:
     - kind: Service
       group: ""
       name: foo-service
     default:
       serviceLbAlgorithm: WATERFALL_BY_ZONE
   
   EOF
   

2. Crie a GCPBackendPolicy para o cluster A:

   kubectl apply --context cluster-a-context -f - <<EOF
   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
   name: foo-backend-policy
   namespace: foo
   spec:
     default:
       maxRatePerEndpoint: 100
       backendPreference: PREFERRED
     targetRef:
       group: ""
       kind: Service
       name: foo-service
   EOF
   

3. Crie a GCPBackendPolicy para o cluster B:

   kubectl apply --context cluster-b-context -f - <<EOF
   kind: GCPBackendPolicy
   apiVersion: networking.gke.io/v1
   metadata:
   name: foo-backend-policy
   namespace: foo
   spec:
     default:
       maxRatePerEndpoint: 10
     targetRef:
       group: ""
       kind: Service
       name: foo-service
   EOF
   

A seguir

• Saiba mais sobre o balanceamento de carga avançado.