Personaliza la configuración del backend con los alcances de GCPBackendPolicy

En un entorno de Inference Gateway de Google Kubernetes Engine (GKE) de varios clústeres, puedes aplicar diferentes configuraciones de backend a los servicios implementados en varios clústeres. Por ejemplo, puedes establecer diferentes tasas máximas de solicitudes o escaladores de capacidad para backends en diferentes regiones o entornos.

Para comprender este documento, debes estar familiarizado con lo siguiente:

• Organización de IA y AA en GKE.
• Terminología de IA generativa.
• Conceptos de redes de GKE, incluidos los servicios, Ingress de varios clústeres de GKE y la API de puerta de enlace de GKE.
• Balanceo de cargas en Cloud de Confiance, en especial, cómo interactúan los balanceadores de cargas con GKE.

Este documento está dirigido a los siguientes perfiles:

• Ingenieros de aprendizaje automático (AA), administradores y operadores de plataformas, y especialistas en datos y en IA interesados en usar las capacidades de organización de contenedores de Kubernetes para entregar cargas de trabajo de IA y AA
• Arquitectos de nube o especialistas en redes que interactúan con las redes de Kubernetes

Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en Cloud de Confiance by S3NS el contenido, consulta Roles de usuario y tareas comunes de GKE Enterprise tasks.

Cómo funcionan los alcances de GCPBackendPolicy

El campo scopes en GCPBackendPolicy te permite adaptar las configuraciones de backend según los clústeres específicos en los que se ejecutan tus backends. Puedes aplicar diferentes parámetros de configuración a los backends en diferentes entornos o regiones, lo que te brinda un control detallado sobre tus cargas de trabajo distribuidas de IA y AA. En las siguientes secciones, se explica cómo orientar los recursos, definir los alcances de las políticas y controlar la resolución de conflictos.

Orientar los recursos de Inference Gateway

Para usar las políticas de Inference Gateway en un entorno de GKE de varios clústeres, el campo targetRef de GCPBackendPolicy debe hacer referencia a un recurso GCPInferencePoolImport:

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

Definición del alcance de la política

El campo scopes en GCPBackendPolicy te permite aplicar diferentes parámetros de configuración de backend a grupos específicos de backends. Si defines objetos de configuración dentro de default.scopes, puedes usar etiquetas de clúster para orientar con precisión los backends y aplicar parámetros de configuración específicos. Por ejemplo, puedes establecer límites de capacidad o tasas de solicitudes únicos para backends en diferentes regiones o clústeres.

No puedes especificar los mismos campos a nivel de backend (como maxRatePerEndpoint) en la sección default principal y dentro de las entradas default.scopes. Si lo haces, se rechazará la política, lo que ayuda a garantizar configuraciones claras y coherentes.

Resolución de conflictos

Cuando un backend coincide con varios alcances, el sistema aplica las siguientes reglas para garantizar un comportamiento predecible:

• Coincidencia priorizada: Si un backend coincide con varios selectores en tu lista scopes, el sistema aplica solo la configuración del primer selector coincidente. Ordena tus alcances del más específico al más general para asegurarte de que se aplique la configuración deseada.
• Orientación precisa: Cuando un solo selector contiene varias etiquetas (por ejemplo, gke.io/region: us-central1 y env: prod), el backend debe satisfacer todas esas etiquetas para que el sistema aplique la configuración del alcance. Este enfoque te permite orientar con precisión los backends en función de varios criterios.

Campos compatibles por backend

En la siguiente tabla, se enumeran los campos a nivel de backend que puedes personalizar para controlar el comportamiento del backend en diferentes entornos o regiones.

Especificar selectores de alcance

El campo selectors en cada alcance te permite controlar qué backends reciben parámetros de configuración de políticas específicos. Puedes orientar los backends en función de sus etiquetas de clúster, ya sean etiquetas integradas de GKE o tus propias etiquetas personalizadas, para adaptar las configuraciones a diferentes grupos 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

Etiquetas implícitas de GKE

Las siguientes etiquetas implícitas están disponibles para usarse como selectores. GKE aplica automáticamente estas etiquetas a tus clústeres:

Etiquetas de clúster personalizadas

Las etiquetas de clúster personalizadas brindan más flexibilidad para agrupar y administrar tus backends. Si defines tus propias etiquetas en tus clústeres de GKE, puedes crear selectores muy específicos en tu GCPBackendPolicy para aplicar configuraciones únicas. Por ejemplo, puedes basar estas configuraciones en criterios como diferentes entornos (dev, staging o prod) o versiones específicas de la aplicación.

Para agregar una etiqueta personalizada, como environment=production, a un clúster de GKE, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

• CLUSTER_NAME: El nombre de tu clúster.
• REGION: La región de tu clúster.
• LABEL_KEY: La clave de tu etiqueta personalizada, por ejemplo, environment.
• LABEL_VALUE: El valor de tu etiqueta personalizada, por ejemplo, production.

Luego, puedes seleccionar backends en este clúster con el selector de etiquetas personalizadas en tu política.

Ejemplo de GCPBackendPolicy con selectores de alcance

En el siguiente ejemplo, se define una GCPBackendPolicy que se orienta a un GCPInferencePoolImport llamado experimental. La política usa etiquetas implícitas y personalizadas para establecer valores para backendPreference, maxRatePerEndpoint y 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

Después de aplicar esta política, observarás los siguientes comportamientos:

• Los backends de los clústeres dentro de la región us-west2 tienen su capacidad efectiva escalada al 50%.
• Los backends de los clústeres etiquetados con env: prod están limitados a un máximo de 40 solicitudes por segundo por extremo.
• Los backends de los clústeres ubicados específicamente en la zona us-central1-a tienen prioridad (PREFERRED) durante el balanceo de cargas y tienen una tasa máxima de 50 solicitudes por segundo por extremo.

¿Qué sigue?

• Obtén información para configurar una GCPBackendPolicy.
• Obtén más información sobre Inference Gateway de GKE de varios clústeres.
• Obtén más información para configurar Inference Gateway de GKE de varios clústeres.