Personalizar configurações de back-end com escopos do GCPBackendPolicy

Em um ambiente de Inferência do Google Kubernetes Engine (GKE) com vários clusters, é possível aplicar diferentes configurações de back-end a serviços implantados em vários clusters. Por exemplo, é possível definir diferentes taxas máximas de solicitação ou escalonadores de capacidade para back-ends em diferentes regiões ou ambientes.

Para entender este documento, você precisa conhecer os seguintes conceitos:

Este documento é destinado aos seguintes perfis:

  • Engenheiros de machine learning (ML), administradores e operadores de plataforma e especialistas em dados e IA interessados em usar os recursos de orquestração de contêineres do Kubernetes para veiculação de cargas de trabalho de IA/ML.
  • Arquitetos de nuvem ou especialistas Rede que interagem com redes do Kubernetes.

Para saber mais sobre papéis comuns e tarefas de exemplo que mencionamos no conteúdo doGoogle Cloud , consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Como os escopos do GCPBackendPolicy funcionam

O campo scopes em GCPBackendPolicy permite personalizar as configurações de back-end com base nos clusters específicos em que os back-ends estão sendo executados. É possível aplicar configurações diferentes a back-ends em diferentes ambientes ou regiões, o que oferece controle refinado sobre suas cargas de trabalho distribuídas de IA/ML. As seções a seguir explicam como segmentar recursos, definir escopos de política e lidar com a resolução de conflitos.

Segmentar recursos do gateway de inferência

Para usar políticas do Inference Gateway em um ambiente do GKE de vários clusters, o campo targetRef do GCPBackendPolicy precisa fazer referência a um recurso GCPInferencePoolImport:

targetRef:
  group: networking.gke.io
  kind: GCPInferencePoolImport
  name: example

Definição do escopo da política

O campo scopes em GCPBackendPolicy permite aplicar diferentes configurações de back-end a grupos específicos de back-ends. Ao definir objetos de configuração em default.scopes, é possível usar rótulos de cluster para segmentar back-ends com precisão e aplicar configurações específicas. Por exemplo, é possível definir limites de capacidade ou taxas de solicitação exclusivas para back-ends em diferentes regiões ou clusters.

Não é possível especificar os mesmos campos no nível do back-end (como maxRatePerEndpoint) na seção principal default e nas entradas default.scopes. Tentar fazer isso causa a rejeição da política, o que ajuda a garantir configurações claras e consistentes.

Resolução de conflitos

Quando um back-end corresponde a vários escopos, o sistema aplica as seguintes regras para garantir um comportamento previsível:

  • Correspondência priorizada:se um back-end corresponder a vários seletores na sua lista scopes, o sistema vai aplicar apenas as configurações do primeiro seletor correspondente. Ordene os escopos do mais específico ao mais geral para garantir que a configuração pretendida entre em vigor.
  • Segmentação precisa:quando um único seletor contém vários rótulos (por exemplo, gke.io/region: us-central1 e env: prod), o back-end precisa atender a todos esses rótulos para que o sistema aplique a configuração do escopo. Essa abordagem permite segmentar back-ends com base em vários critérios.

Campos compatíveis por back-end

A tabela a seguir lista os campos no nível do back-end que podem ser personalizados para controlar o comportamento do back-end em diferentes ambientes ou regiões.

Nome do campo Descrição Exemplo de configuração
backendPreference Especifica se o back-end é preferencial (PREFERRED) ou padrão (DEFAULT) durante a busca de capacidade para balanceamento de carga multirregional. backendPreference: PREFERRED
balancingMode Especifica o algoritmo de balanceamento. Os valores aceitos são RATE, UTILIZATION ou CUSTOM_METRICS. balancingMode: CUSTOM_METRICS
capacityScalerPercent Configura a distribuição de tráfego com base na capacidade. Esse valor é uma porcentagem de 0 a 100, atuando como um multiplicador na capacidade de destino configurada do back-end. O valor padrão é 100%. capacityScalerPercent: 20
customMetrics Especifica métricas personalizadas usadas para balanceamento de carga quando balancingMode é definido como CUSTOM_METRICS. Esse campo é uma lista de definições de métricas. customMetrics: [{ name: "my-metric", value: 0.8 }]
maxInFlightPerEndpoint Define o número máximo de solicitações ou conexões simultâneas por endpoint. maxInFlightPerEndpoint: 100
maxRatePerEndpoint Define a taxa máxima de solicitações por endpoint, em solicitações por segundo (RPS). maxRatePerEndpoint: 50

Especificar seletores de escopo

O campo selectors em cada escopo permite controlar quais back-ends recebem configurações de política específicas. Você pode segmentar back-ends com base nos rótulos do cluster (integrados do GKE ou personalizados) para adaptar as configurações a diferentes grupos de back-ends.

kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: echoserver-v2
spec:
  targetRef:
    group: "networking.gke.io"
    kind: GCPInferencePoolImport
    name: test-inference-pool
  default:
    balancingMode: IN_FLIGHT # IN_FLIGHT mode is set at the default level
    scopes:
    - selector:
        gke.io/zone: "us-central1-a"
      maxInFlightPerEndpoint: 100 # Invalid: maxInFlightPerEndpoint cannot be set within a scope when balancingMode is IN_FLIGHT at the default level

Rótulos implícitos do GKE

Os seguintes rótulos implícitos estão disponíveis para uso como seletores. O GKE aplica automaticamente estes rótulos aos seus clusters:

Rótulo Descrição Valor de exemplo
gke.io/cluster-name O nome do cluster do GKE. my-cluster
gke.io/region A região em que o cluster está localizado. us-central1
gke.io/zone A zona em que o cluster está localizado. us-central1-a

Rótulos de cluster personalizados

Os rótulos de cluster personalizados oferecem mais flexibilidade para agrupar e gerenciar seus back-ends. Ao definir seus próprios rótulos nos clusters do GKE, você pode criar seletores altamente específicos no GCPBackendPolicy para aplicar configurações exclusivas. Por exemplo, é possível basear essas configurações em critérios como diferentes ambientes (dev, staging ou prod) ou versões específicas do aplicativo.

Para adicionar um rótulo personalizado, como environment=production, a um cluster do GKE, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --region=REGION \
    --update-labels=LABEL_KEY=LABEL_VALUE

Substitua:

  • CLUSTER_NAME: o nome do cluster.
  • REGION: a região do cluster.
  • LABEL_KEY: a chave do seu rótulo personalizado, por exemplo, environment.
  • LABEL_VALUE: o valor do seu rótulo personalizado, por exemplo, production.

Em seguida, selecione back-ends nesse cluster usando o seletor de rótulo personalizado na sua política.

Exemplo de GCPBackendPolicy com seletores de escopo

O exemplo a seguir define um GCPBackendPolicy que tem como destino um GCPInferencePoolImport chamado experimental. A política usa rótulos implícitos e personalizados para definir valores para backendPreference, maxRatePerEndpoint e capacityScalerPercent.

apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: backend-policy
spec:
  targetRef:
    kind: GCPInferencePoolImport
    name: experimental
  default:
    scopes:
      # Selector 1: Targets backends in us-west2, sets capacity to 50%
      - capacityScalarPercent: 50
        selector:
          gke.io/region: us-west2

      # Selector 2: Targets backends in clusters labeled 'env: prod'
      - maxRatePerEndpoint: 40
        selector:
          env: prod

      # Selector 3: Targets backends in a specific US-Central zone and marks them as PREFERRED
      - backendPreference: PREFERRED
        maxRatePerEndpoint: 50
        selector:
          gke.io/cluster-name: my-cluster
          gke.io/zone: us-central1-a

Depois de aplicar essa política, você vai observar os seguintes comportamentos:

  • A capacidade efetiva dos back-ends em clusters na região us-west2 é escalonada para 50%.
  • Os back-ends em clusters rotulados com env: prod são limitados a um máximo de 40 solicitações por segundo por endpoint.
  • Os back-ends em clusters localizados especificamente na zona us-central1-a são priorizados (PREFERRED) durante o balanceamento de carga e têm uma taxa máxima de 50 solicitações por segundo por endpoint.

A seguir