Balanceamento de carga avançado em clusters do GKE

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 Kubernetes. Para conferir o guia do usuário correspondente e configurar o balanceamento de carga avançado usando a APIGoogle Cloud , consulte Configurar o balanceamento de carga avançado.

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

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

Limitações

  • Limitações gerais ao usar o balanceamento de carga avançado em Google Cloud apply.
  • Esse recurso está disponível apenas para usuários do Cloud Service Mesh gerenciado 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 Cloud Service Mesh gerenciado (TD). Os campos aceitos são os seguintes:

    • GCPTrafficDistributionPolicy
      • ServiceLbAlgorithm
      • AutoCapacityDrain
      • FailoverConfig
    • GCPBackendPolicy
      • MaxRatePerEndpoint
      • BackendPreference

    Todos os campos não listados são incompatíveis, e uma política com pelo menos um campo incompatível configurado não entra em vigor no Cloud Service Mesh .

  • O balanceamento de carga avançado só pode ser aplicado a serviços do Kubernetes com suporte de cargas de trabalho executadas no Google Cloud. Serviços ou cargas de trabalho externos (como ServiceEntry) não são compatíveis.

  • 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/malha.

  • Há suporte apenas para capacidade de QPS.

  • Somente as versões do GKE >= 1.31.1 são compatíveis.

  • As políticas avançadas de balanceamento de carga da malha de serviço só podem ser aplicadas a serviços que atendem apenas ao tráfego da malha. Não pode ser aplicado a serviços que atuam como back-ends do GKE Gateway. Os comportamentos de tráfego são indefinidos quando um destino de tráfego de balanceamento de carga avançado é 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 seguintes recursos personalizados para configurar o balanceamento de carga avançado no GKE. Confira a definição detalhada do recurso no repositório gke-gateway-api.

GCPTrafficDistributionPolicy

O GCPTrafficDistributionPolicy configura a política de balanceamento de carga no nível do serviço para serviços do Kubernetes. Com ela, é possível:

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

GCPBackendPolicy

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

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

Status da política

GCPTrafficDistributionPolicy e GCPBackendPolicy têm um campo de status que indica o status de vinculação da política.

Por exemplo, executar kubectl describe gcpbackendpolicies example-policy -n example resultaria em 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, provisione 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 ele 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 ele 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 usuário têm como destino o serviço foo no namespace foo para fins de demonstração. Execute o comando a seguir 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 igualmente para cada back-end de serviço em bom estado em uma malha de serviço do Cloud Service Mesh. É possível criar a 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

Por padrão, os back-ends de serviço são tratados como se tivessem capacidade infinita. Quando houver hosts íntegros suficientes na zona local/mais próxima, o tráfego nunca será distribuído fora dessa zona para uma determinada localidade do cliente. Você pode configurar a capacidade do back-end do serviço usando 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 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. Com a GCPTrafficDistributionPolicy, é possível configurar o limite de porcentagem de hosts íntegros até que o tráfego seja alternado 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 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

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

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

Quando uma GCPTrafficDistributionPolicy tem como destino um serviço de vários clusters, ela define o comportamento de balanceamento de carga no nível do 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 sua malha de serviço, poderá criar GCPTrafficDistributionPolicy em qualquer cluster da frota. Para verificar se uma política entra em conflito com outra, inspecione o status da política.

Quando uma GCPBackendPolicy tem como destino um serviço de vários clusters, ela define configurações no nível do back-end (por exemplo, capacidade por pod) para os pods de back-end selecionados pelo serviço de destino no cluster local. Para o mesmo serviço de vários clusters, é possível definir configurações diferentes no nível do 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 GCPBackendPolicies estão em cada cluster. Ambas as GCPBackendPolicy configuram uma capacidade de 10 qps 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 preferido.

Juntas, essas políticas configuram os comportamentos de balanceamento de carga para o tráfego na malha 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 preferenciais, consulte Visão geral do balanceamento de carga avançado.
    • Esse 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.

Malha de serviço de vários clusters de balanceamento de carga avançado

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

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