Auf dieser Seite wird beschrieben, wie Sie die Bereitstellung von GKE Inference Gateway anpassen.
Diese Seite richtet sich an Netzwerkexperten, die für die Verwaltung der GKE-Infrastruktur verantwortlich sind, und an Plattformadministratoren, die KI-Arbeitslasten verwalten.
Sie konfigurieren erweiterte Funktionen von GKE Inference Gateway, um Inferenzarbeitslasten zu verwalten und zu optimieren.
Machen Sie sich mit den folgenden erweiterten Funktionen vertraut und konfigurieren Sie sie:
- Wenn Sie die Model Armor-Integration verwenden möchten, müssen Sie KI-Sicherheits- und ‑Schutzprüfungen konfigurieren.
- Wenn Sie Messwerte und Dashboards für GKE Inference Gateway und den Modellserver aufrufen und HTTP-Zugriffsprotokollierung für detaillierte Informationen zu Anfragen und Antworten aktivieren möchten, müssen Sie die Beobachtbarkeit konfigurieren.
- Wenn Sie Ihre GKE Inference Gateway-Bereitstellungen automatisch skalieren möchten, konfigurieren Sie die automatische Skalierung.
KI-Sicherheits- und Sicherheitsprüfungen konfigurieren
GKE Inference Gateway ist in Model Armor integriert, um Sicherheitsprüfungen für Prompts und Antworten für Anwendungen durchzuführen, die Large Language Models (LLMs) verwenden. Diese Integration bietet eine zusätzliche Ebene für die Durchsetzung von Sicherheitsmaßnahmen auf Infrastrukturebene, die die Sicherheitsmaßnahmen auf Anwendungsebene ergänzt. So können Richtlinien zentral auf den gesamten LLM-Traffic angewendet werden.
Das folgende Diagramm zeigt die Integration von Model Armor in das GKE Inference Gateway in einem GKE-Cluster:
So konfigurieren Sie KI-Sicherheitsprüfungen:
Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:
- Aktivieren Sie den Model Armor-Dienst in Ihrem Trusted Cloud by S3NS -Projekt.
- Erstellen Sie die Model Armor-Vorlagen mit der Model Armor-Konsole, der Google Cloud CLI oder der API.
Prüfen Sie, ob Sie bereits eine Model Armor-Vorlage mit dem Namen
my-model-armor-template-name-iderstellt haben.So konfigurieren Sie die
GCPTrafficExtension:Speichern Sie das folgende Beispielmanifest als
gcp-traffic-extension.yaml:kind: GCPTrafficExtension apiVersion: networking.gke.io/v1 metadata: name: my-model-armor-extension spec: targetRefs: - group: "gateway.networking.k8s.io" kind: Gateway name: GATEWAY_NAME extensionChains: - name: my-model-armor-chain1 matchCondition: celExpressions: - celMatcher: request.path.startsWith("/") extensions: - name: my-model-armor-service supportedEvents: - RequestHeaders timeout: 1s googleAPIServiceName: "modelarmor.us-central1.rep.googleapis.com" metadata: 'extensionPolicy': MODEL_ARMOR_TEMPLATE_NAME 'sanitizeUserPrompt': 'true' 'sanitizeUserResponse': 'true'Ersetzen Sie Folgendes:
GATEWAY_NAME: der Name des Gateways.MODEL_ARMOR_TEMPLATE_NAME: der Name Ihrer Model Armor-Vorlage.
Die Datei
gcp-traffic-extension.yamlenthält die folgenden Einstellungen:targetRefs: gibt das Gateway an, für das diese Erweiterung gilt.extensionChains: Definiert eine Kette von Erweiterungen, die auf den Traffic angewendet werden sollen.matchCondition: Definiert die Bedingungen, unter denen die Erweiterungen angewendet werden.extensions: Definiert die anzuwendenden Erweiterungen.supportedEvents: Gibt die Ereignisse an, bei denen die Erweiterung aufgerufen wird.timeout: Gibt das Zeitlimit für die Erweiterung an.googleAPIServiceName: Gibt den Dienstnamen für die Erweiterung an.metadata: Gibt die Metadaten für die Erweiterung an, einschließlich derextensionPolicyund der Einstellungen für die Bereinigung von Prompts oder Antworten.
Wenden Sie das Beispielmanifest auf Ihren Cluster an:
kubectl apply -f `gcp-traffic-extension.yaml`
Nachdem Sie die KI-Sicherheitsprüfungen konfiguriert und in Ihr Gateway eingebunden haben, filtert Model Armor Prompts und Antworten automatisch anhand der definierten Regeln.
Beobachtbarkeit konfigurieren
Das GKE Inference Gateway bietet Einblicke in den Zustand, die Leistung und das Verhalten Ihrer Inferenzarbeitslasten. So können Sie Probleme identifizieren und beheben, die Ressourcennutzung optimieren und die Zuverlässigkeit Ihrer Anwendungen sicherstellen.
Trusted Cloud by S3NS bietet die folgenden Cloud Monitoring-Dashboards, die eine Beobachtbarkeit der Inferenz für das GKE Inference Gateway ermöglichen:
- GKE Inference Gateway-Dashboard: Bietet wichtige Messwerte für die Bereitstellung von LLMs, z. B. Anfragen- und Tokendurchsatz, Latenz, Fehler und Cache-Auslastung für die
InferencePool. Eine vollständige Liste der verfügbaren GKE Inference Gateway-Messwerte finden Sie unter Exposed metrics. - Dashboard für Modellserver: Bietet ein Dashboard für goldene Signale des Modellservers. So können Sie die Last und Leistung der Modellserver überwachen, z. B.
KVCache UtilizationundQueue length. So können Sie die Last und Leistung der Modellserver im Blick behalten. - Load-Balancer-Dashboard: Hier werden Messwerte des Load-Balancers wie Anfragen pro Sekunde, End-to-End-Latenz bei der Anfragebearbeitung und Anfrage-Antwort-Statuscodes angezeigt. Mithilfe dieser Messwerte können Sie die Leistung der End-to-End-Anfragebearbeitung nachvollziehen und Fehler erkennen.
- Data Center GPU Manager-Messwerte (DCGM): Bietet Messwerte von NVIDIA-GPUs, z. B. Leistung und Auslastung von NVIDIA-GPUs. Sie können NVIDIA Data Center GPU Manager-Messwerte (DCGM) in Cloud Monitoring konfigurieren. Weitere Informationen finden Sie unter DCGM-Messwerte erfassen und ansehen.
GKE Inference Gateway-Dashboard aufrufen
So rufen Sie das GKE Inference Gateway-Dashboard auf:
Rufen Sie in der Trusted Cloud Console die Seite Monitoring auf.
Wählen Sie im Navigationsbereich die Option Dashboards aus.
Wählen Sie im Bereich Integrationen die Option GMP aus.
Suchen Sie auf der Seite Cloud Monitoring Dashboard Templates (Cloud Monitoring-Dashboardvorlagen) nach „Gateway“.
Rufen Sie das GKE Inference Gateway-Dashboard auf.
Alternativ können Sie der Anleitung unter Monitoring-Dashboard folgen.
Dashboard für die Beobachtbarkeit des Modellservers konfigurieren
Wenn Sie Golden Signals von jedem Modellserver erfassen und nachvollziehen möchten, was zur Leistung des GKE Inference Gateway beiträgt, können Sie die automatische Überwachung für Ihre Modellserver konfigurieren. Dazu gehören Modellserver wie die folgenden:
So rufen Sie die Integrationsdashboards auf:
- Messwerte von Ihrem Modellserver erfassen
Rufen Sie in der Trusted Cloud Console die Seite Monitoring auf.
Wählen Sie im Navigationsbereich die Option Dashboards aus.
Wählen Sie unter Integrationen die Option GMP aus. Die entsprechenden Integrationsdashboards werden angezeigt.
Abbildung : Integrationsdashboards
Weitere Informationen finden Sie unter Überwachung für Anwendungen anpassen.
Cloud Monitoring-Benachrichtigungen konfigurieren
So konfigurieren Sie Cloud Monitoring-Benachrichtigungen für GKE Inference Gateway:
Den Grenzwert in Benachrichtigungen ändern Speichern Sie das folgende Beispielmanifest als
alerts.yaml:groups: - name: gateway-api-inference-extension rules: - alert: HighInferenceRequestLatencyP99 annotations: title: 'High latency (P99) for model {{ $labels.model_name }}' description: 'The 99th percentile request duration for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 10.0 seconds for 5 minutes.' expr: histogram_quantile(0.99, rate(inference_model_request_duration_seconds_bucket[5m])) > 10.0 for: 5m labels: severity: 'warning' - alert: HighInferenceErrorRate annotations: title: 'High error rate for model {{ $labels.model_name }}' description: 'The error rate for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 5% for 5 minutes.' expr: sum by (model_name) (rate(inference_model_request_error_total[5m])) / sum by (model_name) (rate(inference_model_request_total[5m])) > 0.05 for: 5m labels: severity: 'critical' impact: 'availability' - alert: HighInferencePoolAvgQueueSize annotations: title: 'High average queue size for inference pool {{ $labels.name }}' description: 'The average number of requests pending in the queue for inference pool {{ $labels.name }} has been consistently above 50 for 5 minutes.' expr: inference_pool_average_queue_size > 50 for: 5m labels: severity: 'critical' impact: 'performance' - alert: HighInferencePoolAvgKVCacheUtilization annotations: title: 'High KV cache utilization for inference pool {{ $labels.name }}' description: 'The average KV cache utilization for inference pool {{ $labels.name }} has been consistently above 90% for 5 minutes, indicating potential resource exhaustion.' expr: inference_pool_average_kv_cache_utilization > 0.9 for: 5m labels: severity: 'critical' impact: 'resource_exhaustion'Führen Sie folgenden Befehl aus, um Benachrichtigungsrichtlinien zu erstellen:
gcloud alpha monitoring policies migrate --policies-from-prometheus-alert-rules-yaml=alerts.yamlNeue Benachrichtigungsrichtlinien werden auf der Seite Benachrichtigungen angezeigt.
Benachrichtigungen ändern
Eine vollständige Liste der neuesten verfügbaren Messwerte finden Sie im GitHub-Repository kubernetes-sigs/gateway-api-inference-extension. Sie können dem Manifest mit anderen Messwerten neue Benachrichtigungen hinzufügen.
So ändern Sie Beispielbenachrichtigungen:
- alert: HighInferenceRequestLatencyP99
annotations:
title: 'High latency (P99) for model {{ $labels.model_name }}'
description: 'The 99th percentile request duration for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 10.0 seconds for 5 minutes.'
expr: histogram_quantile(0.99, rate(inference_model_request_duration_seconds_bucket[5m])) > 10.0
for: 5m
labels:
severity: 'warning'
Die Benachrichtigung wird ausgelöst, wenn das 99. Perzentil der Anfragedauer in 5 Minuten mehr als 10 Sekunden beträgt. Sie können den expr-Abschnitt der Benachrichtigung ändern, um den Schwellenwert an Ihre Anforderungen anzupassen.
Logging für GKE Inference Gateway konfigurieren
Wenn Sie das Logging für GKE Inference Gateway konfigurieren, erhalten Sie detaillierte Informationen zu Anfragen und Antworten, die für die Fehlerbehebung, das Auditieren und die Leistungsanalyse nützlich sind. In HTTP-Zugriffsprotokollen werden alle Anfragen und Antworten aufgezeichnet, einschließlich Headern, Statuscodes und Zeitstempeln. Mit diesem Detaillierungsgrad können Sie Probleme und Fehler identifizieren und das Verhalten Ihrer Inferenz-Arbeitslasten nachvollziehen.
Wenn Sie die Protokollierung für GKE Inference Gateway konfigurieren möchten, aktivieren Sie die HTTP-Zugriffsprotokollierung für jedes Ihrer InferencePool-Objekte.
Speichern Sie das folgende Beispielmanifest als
logging-backend-policy.yaml:apiVersion: networking.gke.io/v1 kind: GCPBackendPolicy metadata: name: logging-backend-policy namespace: NAMESPACE_NAME spec: default: logging: enabled: true sampleRate: 500000 targetRef: group: inference.networking.x-k8s.io kind: InferencePool name: INFERENCE_POOL_NAMEErsetzen Sie Folgendes:
NAMESPACE_NAME: der Name des Namespace, in dem IhrInferencePoolbereitgestellt wird.INFERENCE_POOL_NAMEist der Name desInferencePool.
Wenden Sie das Beispielmanifest auf Ihren Cluster an:
kubectl apply -f logging-backend-policy.yaml
Nachdem Sie dieses Manifest angewendet haben, aktiviert GKE Inference Gateway HTTP-Zugriffsprotokolle für die angegebene InferencePool. Sie können diese Logs in Cloud Logging aufrufen. Die Logs enthalten detaillierte Informationen zu jeder Anfrage und Antwort, z. B. die Anfrage-URL, Header, den Antwortstatuscode und die Latenz.
Autoscaling konfigurieren
Beim Autoscaling wird die Ressourcenzuweisung als Reaktion auf Lastschwankungen angepasst. Die Leistung und Ressourceneffizienz werden aufrechterhalten, indem Pods je nach Bedarf dynamisch hinzugefügt oder entfernt werden. Für das GKE Inference Gateway umfasst dies das horizontale Autoscaling von Pods in jeder InferencePool. Das horizontale Pod-Autoscaling (HPA) von GKE skaliert Pods automatisch basierend auf Messwerten des Modellservers wie KVCache Utilization. So kann der Inferenzdienst verschiedene Arbeitslasten und Anfragevolumen verarbeiten und gleichzeitig die Ressourcennutzung effizient verwalten.
So konfigurieren Sie InferencePool-Instanzen für das automatische Skalieren basierend auf Messwerten, die von GKE Inference Gateway erzeugt werden:
Stellen Sie ein
PodMonitoring-Objekt im Cluster bereit, um Messwerte zu erfassen, die vom GKE Inference Gateway generiert werden. Weitere Informationen finden Sie unter Observability konfigurieren.Stellen Sie den Stackdriver-Adapter für benutzerdefinierte Messwerte bereit, um HPA Zugriff auf die Messwerte zu gewähren:
Speichern Sie das folgende Beispielmanifest als
adapter_new_resource_model.yaml:apiVersion: v1 kind: Namespace metadata: name: custom-metrics --- apiVersion: v1 kind: ServiceAccount metadata: name: custom-metrics-stackdriver-adapter namespace: custom-metrics --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: custom-metrics:system:auth-delegator roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:auth-delegator subjects: - kind: ServiceAccount name: custom-metrics-stackdriver-adapter namespace: custom-metrics --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: custom-metrics-auth-reader namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: extension-apiserver-authentication-reader subjects: - kind: ServiceAccount name: custom-metrics-stackdriver-adapter namespace: custom-metrics --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: custom-metrics-resource-reader namespace: custom-metrics rules: - apiGroups: - "" resources: - pods - nodes - nodes/stats verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: custom-metrics-resource-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: custom-metrics-resource-reader subjects: - kind: ServiceAccount name: custom-metrics-stackdriver-adapter namespace: custom-metrics --- apiVersion: apps/v1 kind: Deployment metadata: run: custom-metrics-stackdriver-adapter k8s-app: custom-metrics-stackdriver-adapter spec: replicas: 1 selector: matchLabels: run: custom-metrics-stackdriver-adapter k8s-app: custom-metrics-stackdriver-adapter template: metadata: labels: run: custom-metrics-stackdriver-adapter k8s-app: custom-metrics-stackdriver-adapter kubernetes.io/cluster-service: "true" spec: serviceAccountName: custom-metrics-stackdriver-adapter containers: - image: gcr.io/gke-release/custom-metrics-stackdriver-adapter:v0.15.2-gke.1 imagePullPolicy: Always name: pod-custom-metrics-stackdriver-adapter command: - /adapter - --use-new-resource-model=true - --fallback-for-container-metrics=true resources: limits: cpu: 250m memory: 200Mi requests: cpu: 250m memory: 200Mi --- apiVersion: v1 kind: Service metadata: labels: run: custom-metrics-stackdriver-adapter k8s-app: custom-metrics-stackdriver-adapter kubernetes.io/cluster-service: 'true' kubernetes.io/name: Adapter name: custom-metrics-stackdriver-adapter namespace: custom-metrics spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: custom-metrics-stackdriver-adapter k8s-app: custom-metrics-stackdriver-adapter type: ClusterIP --- apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: name: v1beta1.custom.metrics.k8s.io spec: insecureSkipTLSVerify: true group: custom.metrics.k8s.io groupPriorityMinimum: 100 versionPriority: 100 service: name: custom-metrics-stackdriver-adapter namespace: custom-metrics version: v1beta1 --- apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: name: v1beta2.custom.metrics.k8s.io spec: insecureSkipTLSVerify: true group: custom.metrics.k8s.io groupPriorityMinimum: 100 versionPriority: 200 service: name: custom-metrics-stackdriver-adapter namespace: custom-metrics version: v1beta2 --- apiVersion: apiregistration.k8s.io/v1 kind: APIService metadata: name: v1beta1.external.metrics.k8s.io spec: insecureSkipTLSVerify: true group: external.metrics.k8s.io groupPriorityMinimum: 100 versionPriority: 100 service: name: custom-metrics-stackdriver-adapter namespace: custom-metrics version: v1beta1 --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: external-metrics-reader rules: - apiGroups: - "external.metrics.k8s.io" resources: - "*" verbs: - list - get - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: external-metrics-reader roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-metrics-reader subjects: - kind: ServiceAccount name: horizontal-pod-autoscaler namespace: kube-systemWenden Sie das Beispielmanifest auf Ihren Cluster an:
kubectl apply -f adapter_new_resource_model.yaml
Führen Sie den folgenden Befehl aus, um dem Adapter die Berechtigung zu erteilen, Messwerte aus dem Projekt zu lesen:
$ PROJECT_ID=PROJECT_ID $ PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)") $ gcloud projects add-iam-policy-binding projects/PROJECT_ID \ --role roles/monitoring.viewer \ --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapterErsetzen Sie
PROJECT_IDdurch Ihre Trusted Cloud Projekt-ID.Stellen Sie für jede
InferencePoolein HPA bereit, das dem folgenden ähnelt:apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: INFERENCE_POOL_NAME namespace: INFERENCE_POOL_NAMESPACE spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: INFERENCE_POOL_NAME minReplicas: MIN_REPLICAS maxReplicas: MAX_REPLICAS metrics: - type: External external: metric: name: prometheus.googleapis.com|inference_pool_average_kv_cache_utilization|gauge selector: matchLabels: metric.labels.name: INFERENCE_POOL_NAME resource.labels.cluster: CLUSTER_NAME resource.labels.namespace: INFERENCE_POOL_NAMESPACE target: type: AverageValue averageValue: TARGET_VALUEErsetzen Sie Folgendes:
INFERENCE_POOL_NAMEist der Name desInferencePool.INFERENCE_POOL_NAMESPACE: der Namespace desInferencePool.CLUSTER_NAMEist der Name des Clusters.MIN_REPLICAS: Die Mindestverfügbarkeit derInferencePool(Basiskapazität). HPA hält diese Anzahl von Replikaten aufrecht, wenn die Nutzung unter dem HPA-Zielgrenzwert liegt. Bei Arbeitslasten mit hoher Verfügbarkeit muss dieser Wert auf einen Wert über1festgelegt werden, um die Verfügbarkeit bei Pod-Unterbrechungen aufrechtzuerhalten.MAX_REPLICAS: Der Wert, der die Anzahl der Beschleuniger begrenzt, die den imInferencePoolgehosteten Arbeitslasten zugewiesen werden müssen. HPA erhöht die Anzahl der Replikate nicht über diesen Wert hinaus. Behalten Sie während der Spitzenzeiten die Anzahl der Replikate im Blick, um sicherzustellen, dass der Wert des FeldsMAX_REPLICASgenügend Spielraum bietet, damit die Arbeitslast skaliert werden kann, um die ausgewählten Leistungsmerkmale der Arbeitslast beizubehalten.TARGET_VALUE: Der Wert, der das ausgewählte ZielKV-Cache Utilizationpro Modellserver darstellt. Dies ist eine Zahl zwischen 0 und 100 und hängt stark vom Modellserver, Modell, Beschleuniger und den Merkmalen des eingehenden Traffics ab. Sie können diesen Zielwert experimentell ermitteln, indem Sie Lasttests durchführen und ein Diagramm mit Durchsatz und Latenz erstellen. Wählen Sie im Diagramm eine Kombination aus Durchsatz und Latenz aus und verwenden Sie den entsprechendenKV-Cache Utilization-Wert als HPA-Ziel. Sie müssen diesen Wert anpassen und genau im Blick behalten, um die gewünschten Ergebnisse in Bezug auf das Preis-Leistungs-Verhältnis zu erzielen. Sie können diesen Wert automatisch mit GKE Inference Recommendations ermitteln.