Equilíbrio de carga avançado em clusters do GKE

Pré-visualização

Este produto ou funcionalidade está sujeito aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. Os produtos e as funcionalidades pré-GA estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

Esta página mostra como configurar o equilíbrio de carga avançado em clusters do GKE para utilizadores do Cloud Service Mesh (TD) gerido através da API Kubernetes. Para aceder ao guia do utilizador correspondente para configurar o equilíbrio de carga avançado através daGoogle Cloud API, consulte o artigo Configure o equilíbrio de carga avançado.

Pode usar o balanceamento de carga avançado para:

• Manter o tráfego numa zona de serviço até a capacidade local estar esgotada.
• Envie tráfego para o serviço numa localização "principal" com comutação por falha para uma localização secundária quando existirem pontos finais suficientes na localização principal que se tornem não saudáveis.
• Controlar quando ocorre a comutação por falha (com base na percentagem de anfitriões em bom estado).

Limitações

• Limitações gerais relativas à utilização do equilíbrio de carga avançado no Google Cloud apply.
• Esta funcionalidade só está disponível para utilizadores do Cloud Service Mesh geridos que usam o Traffic Director como plano de controlo e requer a versão 1.19.10-asm.22 ou posterior do plano de dados.
• Nem todos os campos em GCPTrafficDistributionPolicy e GCPBackendPolicy são suportados para a malha de serviços na nuvem gerida (TD). Os campos suportados são os seguintes:
  • GCPTrafficDistributionPolicy
    • ServiceLbAlgorithm
    • AutoCapacityDrain
    • FailoverConfig
  • GCPBackendPolicy
    • MaxRatePerEndpoint
    • BackendPreference
• O equilíbrio de carga avançado só pode ser aplicado a serviços do Kubernetes suportados por cargas de trabalho executadas em Google Cloud. Os serviços ou as cargas de trabalho externos (como ServiceEntry) não são suportados.
• As políticas de equilíbrio de carga só podem ser aplicadas a serviços individuais do Kubernetes. As políticas de equilíbrio de carga ao nível do espaço de nomes/malha não são suportadas.
• Apenas é suportada a capacidade de QPS.
• Apenas são suportadas versões do GKE >= 1.31.1.
• As políticas de equilíbrio de carga avançadas da malha de serviços só podem ser aplicadas a serviços que apenas servem tráfego de malha. Não deve ser aplicado a serviços que funcionam como back-ends do GKE Gateway. Os comportamentos de tráfego não estão definidos quando um destino de tráfego de balanceamento de carga avançado segmenta um serviço Kubernetes que serve tráfego de malha e tráfego de um gateway do GKE.

Configure o balanceamento de carga avançado

Pode usar os seguintes recursos personalizados para configurar o equilíbrio de carga avançado no GKE. Pode encontrar a definição detalhada do recurso no repositório gke-gateway-api.

GCPTrafficDistributionPolicy

A GCPTrafficDistributionPolicy configura a política de balanceamento de carga ao nível do serviço para serviços Kubernetes. Permite-lhe:

• Escolha um algoritmo de equilíbrio de carga personalizado. Os algoritmos suportados são descritos na tabela de balanceamento de carga avançado.
• Ative a redução automática da capacidade.
• Ajuste o limite de estado de funcionamento da comutação por falha.

Se várias GCPTrafficDistributionPolicies segmentarem o mesmo serviço, a política mais antiga é aplicada.

GCPBackendPolicy

A GCPBackendPolicy configura as propriedades dos back-ends de serviço que afetam o comportamento de equilíbrio de carga, incluindo:

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

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

Estado da política

Tanto GCPTrafficDistributionPolicy como GCPBackendPolicy têm um campo de estado que indica o estado de associação da política.

Por exemplo, a execução de kubectl describe gcpbackendpolicies example-policy -n example geraria 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 poder concluir este guia, tem de aprovisionar o Cloud Service Mesh num cluster do GKE.

1. Verifique se os CRDs estão instalados:

   kubectl get crd
   

   O resultado é semelhante ao seguinte:

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

As políticas de exemplo neste guia do utilizador destinam-se ao serviço foo no espaço de nomes foo para fins de demonstração. Pode executar o seguinte comando para criar o serviço e o espaço de nomes de teste ou, se preferir, pode usar o seu próprio serviço e espaço de nomes:

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

Configurar o algoritmo de balanceamento de carga

Por predefinição, o tráfego para um serviço é distribuído uniformemente a todos os back-ends de serviço em bom estado num serviço de malha de serviços do Cloud Service Mesh. Pode criar a seguinte GCPTrafficDistributionPolicy para que o tráfego seja distribuído para a zona mais próxima até à 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

Nota: as definições em GCPTrafficDistributionPolicy têm precedência sobre as da API Google Kubernetes Service principal.

Por predefinição, os backends de serviço são tratados como se tivessem uma capacidade infinita. Quando existem anfitriões saudáveis 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. Opcionalmente, pode configurar a capacidade do back-end do serviço através de 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

Ajustar o comportamento de comutação por falha

Por predefinição, a comutação por falha não é acionada desde que uma percentagem suficiente de anfitriões esteja em bom estado nos backends principais. Para mais informações sobre back-ends principais e outra terminologia, consulte a vista geral do equilíbrio de carga avançado. A GCPTrafficDistributionPolicy permite-lhe configurar o limite percentual de anfitriões em bom estado até que o tráfego seja desviado dos backends principais para os backends de alternativa. A comutação por falha é acionada mais cedo com um limite superior. Por exemplo, se quiser que a comutação por falha seja acionada assim que a percentagem de anfitriões íntegros descer abaixo de 90% nos servidores de back-end principais, pode configurar a seguinte 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

Configurar o balanceamento de carga avançado numa malha de serviços em vários clusters

A GCPTrafficDistributionPolicy e a GCPBackendPolicy são aplicadas em âmbitos diferentes num serviço de malha de vários clusters.

Quando uma GCPTrafficDistributionPolicy segmenta um serviço em vários clusters, define o comportamento de equilíbrio de carga ao nível do serviço em todos os clusters. Só é necessário criar uma GCPTrafficDistributionPolicy para um serviço multicluster específico. Se estiver a usar a API Istio para configurar a sua malha de serviços, pode criar GCPTrafficDistributionPolicy em qualquer cluster na frota. Pode verificar se uma política entra em conflito com outra inspecionando o respetivo estado da política.

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

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

Em conjunto, estas políticas configuram os comportamentos de balanceamento de carga para o tráfego na malha enviado para o 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 tenham de processar 10 qps por pod.
  • Este comportamento é definido principalmente pela GCPBackendPolicy que definiu backendPreference como PREFERRED no cluster A.
• O tráfego que exceda a capacidade configurada dos back-ends no cluster A é encaminhado através do algoritmo WATERFALL_BY_ZONE para o cluster B. Para uma explicação mais detalhada dos back-ends preferenciais, consulte o artigo Vista geral do equilíbrio de carga avançado.
  • Este comportamento é definido principalmente pela GCPTrafficDistributionPolicy, que define o algoritmo, no cluster A e pela GCPBackendPolicy, que define a capacidade do back-end, nos clusters A e B.

Nota: esta secção demonstra a capacidade da malha de serviços na nuvem de equilibrar a carga do tráfego em vários clusters. Para fins de demonstração, implemente o serviço de exemplo foo e os respetivos pods de back-end em ambos os clusters.

No Istio, os serviços Kubernetes normais tornam-se implicitamente "multicluster" quando existem vários clusters na malha de serviço e o serviço é criado em limites de cluster. Embora a GCPTrafficDistributionPolicy seguinte tenha como destino o serviço Kubernetes normal foo, aplica-se ao serviço multicúmulo foo composto por cargas de trabalho correspondentes em dois cúmulos.

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
   

O que se segue

• Saiba mais acerca do equilíbrio de carga avançado