Personnaliser les configurations de backend avec les portées GCPBackendPolicy

Dans un environnement Google Kubernetes Engine (GKE) Inference Gateway multicluster, vous pouvez appliquer différentes configurations de backend aux services déployés sur plusieurs clusters. Par exemple, vous pouvez définir différents taux de requêtes maximales ou scalers de capacité pour les backends dans différentes régions ou différents environnements.

Pour comprendre ce document, vous devez connaître les points suivants :

Ce document s'adresse aux personas suivants :

  • Ingénieurs en machine learning (ML), administrateurs et opérateurs de plate-forme, et spécialistes des données et de l'IA qui souhaitent utiliser les fonctionnalités d'orchestration de conteneurs Kubernetes pour diffuser des charges de travail d'IA/ML.
  • Architectes cloud ou spécialistes de la mise en réseau qui interagissent avec la mise en réseau Kubernetes.

Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenuGoogle Cloud , consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Fonctionnement des niveaux d'accès GCPBackendPolicy

Le champ scopes dans GCPBackendPolicy vous permet d'adapter les configurations de backend en fonction des clusters spécifiques sur lesquels vos backends sont exécutés. Vous pouvez appliquer différents paramètres aux backends dans différents environnements ou régions, ce qui vous permet de contrôler précisément vos charges de travail d'IA/ML distribuées. Les sections suivantes expliquent comment cibler des ressources, définir des périmètres de règles et gérer la résolution des conflits.

Cibler les ressources Inference Gateway

Pour utiliser des règles Inference Gateway dans un environnement GKE multicluster, le champ targetRef de GCPBackendPolicy doit faire référence à une ressource GCPInferencePoolImport :

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

Définition du champ d'application des règles

Le champ scopes de GCPBackendPolicy vous permet d'appliquer différents paramètres de backend à des groupes de backends spécifiques. En définissant des objets de configuration dans default.scopes, vous pouvez utiliser des libellés de cluster pour cibler précisément les backends et appliquer des paramètres spécifiques. Par exemple, vous pouvez définir des limites de capacité ou des taux de requêtes uniques pour les backends de différentes régions ou différents clusters.

Vous ne pouvez pas spécifier les mêmes champs au niveau du backend (comme maxRatePerEndpoint) à la fois dans la section principale default et dans les entrées default.scopes. Si vous essayez de le faire, la règle sera refusée, ce qui permet de garantir des configurations claires et cohérentes.

Résolution de conflits

Lorsqu'un backend correspond à plusieurs niveaux d'accès, le système applique les règles suivantes pour garantir un comportement prévisible :

  • Correspondance prioritaire : si un backend correspond à plusieurs sélecteurs de votre liste scopes, le système n'applique que les paramètres du premier sélecteur correspondant. Pour vous assurer que la configuration souhaitée prend effet, ordonnez vos niveaux d'accès du plus spécifique au plus général.
  • Ciblage précis : lorsqu'un sélecteur unique contient plusieurs libellés (par exemple, gke.io/region: us-central1 et env: prod), le backend doit satisfaire tous ces libellés pour que le système applique la configuration du champ d'application. Cette approche vous permet de cibler précisément les backends en fonction de plusieurs critères.

Champs compatibles par backend

Le tableau suivant liste les champs de niveau backend que vous pouvez personnaliser pour contrôler le comportement du backend dans différents environnements ou régions.

Nom du champ Description Exemple de configuration
backendPreference Indique si le backend est préféré (PREFERRED) ou par défaut (DEFAULT) lors de la recherche de capacité pour l'équilibrage de charge multirégional. backendPreference: PREFERRED
balancingMode Spécifie l'algorithme d'équilibrage. Les valeurs acceptées sont RATE, UTILIZATION ou CUSTOM_METRICS. balancingMode: CUSTOM_METRICS
capacityScalerPercent Configure la répartition du trafic en fonction de la capacité. Cette valeur est un pourcentage compris entre 0 et 100, qui sert de multiplicateur pour la capacité cible configurée dans le backend. La valeur par défaut est de 100 %. capacityScalerPercent: 20
customMetrics Spécifie les métriques personnalisées utilisées pour l'équilibrage de charge lorsque balancingMode est défini sur CUSTOM_METRICS. Ce champ est une liste de définitions de métriques. customMetrics: [{ name: "my-metric", value: 0.8 }]
maxInFlightPerEndpoint Définit le nombre maximal de requêtes ou de connexions simultanées par point de terminaison. maxInFlightPerEndpoint: 100
maxRatePerEndpoint Définit le taux maximal de requêtes par point de terminaison, en requêtes par seconde (RPS). maxRatePerEndpoint: 50

Spécifier des sélecteurs de champ d'application

Le champ selectors de chaque champ d'application vous permet de contrôler les backends qui reçoivent des paramètres de stratégie spécifiques. Vous pouvez cibler les backends en fonction de leurs libellés de cluster (libellés GKE intégrés ou vos propres libellés personnalisés) pour adapter les configurations à différents groupes de backends.

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

Libellés GKE implicites

Les libellés implicites suivants peuvent être utilisés comme sélecteurs. GKE applique automatiquement les libellés suivants à vos clusters :

Libellé Description Exemple de valeur
gke.io/cluster-name Nom du cluster GKE. my-cluster
gke.io/region Région dans laquelle se trouve le cluster. us-central1
gke.io/zone Zone dans laquelle se trouve le cluster. us-central1-a

Libellés de clusters personnalisés

Les libellés de cluster personnalisés offrent plus de flexibilité pour regrouper et gérer vos backends. En définissant vos propres libellés sur vos clusters GKE, vous pouvez créer des sélecteurs très spécifiques dans votre GCPBackendPolicy pour appliquer des configurations uniques. Par exemple, vous pouvez baser ces configurations sur des critères tels que différents environnements (dev, staging ou prod) ou des versions d'application spécifiques.

Pour ajouter un libellé personnalisé, tel que environment=production, à un cluster GKE, exécutez la commande suivante :

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

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster
  • REGION : région de votre cluster.
  • LABEL_KEY : clé de votre libellé personnalisé, par exemple environment.
  • LABEL_VALUE : valeur de votre libellé personnalisé (par exemple, production).

Vous pouvez ensuite sélectionner des backends dans ce cluster à l'aide du sélecteur de libellés personnalisés de votre règle.

Exemple GCPBackendPolicy avec des sélecteurs de portée

L'exemple suivant définit un GCPBackendPolicy qui cible un GCPInferencePoolImport nommé experimental. La règle utilise des libellés implicites et personnalisés pour définir les valeurs de backendPreference, maxRatePerEndpoint et 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

Après avoir appliqué cette règle, vous observez les comportements suivants :

  • La capacité effective des backends des clusters de la région us-west2 est réduite à 50 %.
  • Les backends des clusters portant le libellé env: prod sont limités à un maximum de 40 requêtes par seconde et par point de terminaison.
  • Les backends des clusters situés spécifiquement dans la zone us-central1-a sont prioritaires (PREFERRED) lors de l'équilibrage de charge et ont un taux maximal de 50 requêtes par seconde par point de terminaison.

Étapes suivantes