Personnaliser les configurations de backend avec les portées GCPBackendPolicy

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

Pour comprendre ce document, vous devez connaître les éléments suivants :

Ce document s'adresse aux profils 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 Google Cloud le contenu, consultez Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Fonctionnement des champs d'application GCPBackendPolicy

Le champ scopes de GCPBackendPolicy vous permet d'adapter les configurations de backend en fonction des clusters spécifiques sur lesquels vos backends s'exécutent. 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 champs d'application 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 dans 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 default principale et dans les entrées default.scopes. Si vous essayez de le faire, la règle est rejetée, ce qui permet de garantir des configurations claires et cohérentes.

Résolution de conflits

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

  • Correspondance priorisée : si un backend correspond à plusieurs sélecteurs dans votre liste scopes, le système n'applique que les paramètres du premier sélecteur correspondant. Organisez vos champs d'application du plus spécifique au plus général pour vous assurer que la configuration souhaitée prend effet.
  • Ciblage précis : lorsqu'un seul sélecteur 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 par backend compatibles

Le tableau suivant répertorie les champs au niveau du 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 compatibles 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 agit comme un multiplicateur sur la capacité cible configurée du backend. La valeur par défaut est 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 règles 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 ces libellés à 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 cluster 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 les backends de ce cluster à l'aide du sélecteur de libellé personnalisé dans votre règle.

Exemple de GCPBackendPolicy avec des sélecteurs de champ d'application

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

Étape suivante