Solo Enterprise für kagent in der Referenzimplementierung für Distributed Cloud (nur Software) bereitstellen

Mit Solo Enterprise for kagent können Plattformadministratoren KI-Agenten auf Google Distributed Cloud (GDC) – nur Software (GDC-SO) bereitstellen und verwalten. In dieser Referenzimplementierung spiegeln Sie Container-Images und Helm-Diagramme in einer privaten Harbor-Registry, stellen die kagent-Steuerungsebene, die Benutzeroberfläche und Solo Enterprise für agentgateway bereit und prüfen die Richtlinien zur Clustergröße. Weitere Informationen zur Architektur finden Sie unter Referenzarchitektur für die Verwendung eines eigenen MCP-Servers mit kagent.

Vorbereitung

Bevor Sie beginnen, müssen Sie Zugriff auf eine Linux-Workstation mit Chrome, Docker, crane, kubectl, Helm, envsubst und der gdcloud-Befehlszeile haben. Achten Sie darauf, dass die folgenden Komponenten für Ihre GDC-SO-Umgebung konfiguriert sind:

Komponente Detail oder Anforderung Beispielwert
Google Cloud -Projekt für GDC-SO Mit dem GDC-SO-Cluster verknüpftes Projekt kagent-enterprise
Cluster GDC-SO-Zielcluster user-project-8a210897
Kubernetes-Anmeldedaten (Connect Gateway) Verbindung zum Cluster gcloud container fleet memberships get-credentials user-project-8a210897
Private Registry Harbor-Registry-URL solo-kagent-enterprise.org-1.zone1.google.gdch.test
Projekt-Repository Pfad des Projekt-Repositorys solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise
Pull-Secret Name des Docker-Pull-Secrets solo-harbor-pull-secret

Die folgende Anleitung gilt für Solo Enterprise für kagent-Version 0.4.0 und höher.

Diese Bereitstellung wurde mit der GDC-SO-Version 1.31.5-gke.300 validiert.

In einem GDC-SO-Cluster bereitstellen

Erstellen Sie eine .env-Datei basierend auf Ihrer Cluster- und Registry-Konfiguration:

export PUBLIC_REGISTRY="us-docker.pkg.dev/solo-public/kagent-enterprise-helm/charts"
export PUBLIC_MANAGEMENT_REGISTRY="us-docker.pkg.dev/solo-public/solo-enterprise-helm/charts"
export PUBLIC_AGENTGATEWAY_REGISTRY="us-docker.pkg.dev/solo-public/enterprise-agentgateway/charts"

# Set these based on your desired installation version
export KAGENT_ENT_VERSION=0.4.1
export KAGENT_VERSION=0.9.1
export AGENTGATEWAY_VERSION=v2.4.0-beta.0
export SOLO_LICENSE_KEY="SOLO_LICENSE_KEY"

# Set the following values based on your GDC setup
export PROJECT_ID="kagent-enterprise"
export CLUSTER_NAME="user-project-8a210897"
export NAMESPACE="solo-kagent"
export USER_CONTEXT="user-vm-1-zone1-gdch_console-org-1-zone1-google-gdch-test_user-vm-1"
export MGMT_CONTEXT="user-project-8a210897-zone1-gdch_console-org-1-zone1-google-gdch-test_user-project-8a210897"
export PULL_SECRET_NAME="solo-harbor-pull-secret"

# Set the following values based on your Harbor registry setup
export ORG="ORG"
export ZONE="ZONE"
export PRIVATE_REGISTRY="solo-kagent-enterprise.${ORG}.${ZONE}.google.gdch.test"
export PRIVATE_REPO="${PRIVATE_REGISTRY}/${PROJECT_ID}"
export PRIVATE_CHART_REGISTRY="${PRIVATE_REPO}/charts"

Ersetzen Sie Folgendes:

  • SOLO_LICENSE_KEY: Ihr Solo Enterprise-Lizenzschlüssel
  • ORG: Name Ihrer GDC-Organisation
  • ZONE: Name Ihrer GDC-Zone

Helm-Wertedateien erstellen

Erstellen Sie die Helm-Wertedateien für die drei Diagramme. Sie müssen keine Werte ändern, es sei denn, Sie möchten die Installation anpassen. Sie können zusätzliche Modelle und Agenten später in der kagent-Benutzeroberfläche konfigurieren.

Erstellen Sie die Datei enterprise-agentgateway-values.yaml.

image:
  registry: ${PRIVATE_REPO}/enterprise-agentgateway
  tag: ${AGENTGATEWAY_VERSION}
licensing:
  licenseKey: ${SOLO_LICENSE_KEY}
imagePullSecrets:
- name: ${PULL_SECRET_NAME}
inferenceExtension:
  enabled: true

Erstellen Sie die Datei kagent-enterprise-values.yaml.

registry: ${PRIVATE_REPO}
cluster: ${CLUSTER_NAME}
imagePullSecrets:
- name: ${PULL_SECRET_NAME}
global:
  imagePullSecrets:
  - name: ${PULL_SECRET_NAME}
oidc:
  skipOBO: true
otel:
  tracing:
    enabled: true
    exporter:
      otlp:
        endpoint: http://solo-enterprise-telemetry-collector.${NAMESPACE}.svc.cluster.local.:4317
        insecure: true
kubernetes:
  jwksUrl: "https://kubernetes.default.svc.cluster.local/openid/v1/jwks"
providers:
  default: OpenAI # Choose the model API type
  OpenAI:
    provider: OpenAI
    model: "/model/gemma-4-12B" # Choose the model
    apiKeySecretRef: "kagent-openai"
    apiKeySecretKey: "none" # Name of the key in the Secret, or "none" if no API key is required
controller:
  agentDeployment:
    podLabels:
      egress.networking.gke.io/enabled: "true"
  imagePullSecrets:
  - name: ${PULL_SECRET_NAME}
  image:
    registry: ${PRIVATE_REPO}
  agentImage:
    registry: ${PRIVATE_REPO}
    repository: "kagent-dev/kagent/app"
    pullSecret: "${PULL_SECRET_NAME}"
licensing:
  createSecret: true
  secretName: "enterprise-kagent-license"
kmcp:
  imagePullSecrets:
  - name: ${PULL_SECRET_NAME}
  image:
    registry: ${PRIVATE_REPO}
  enabled: true
kagent-tools:
  enabled: true
  imagePullSecrets:
  - name: ${PULL_SECRET_NAME}
  tools:
    image:
      registry: ${PRIVATE_REPO}
agents:
  k8s-agent:
    enabled: true
grafana-mcp:
  enabled: false # Pull secret is not supported
tools:
  grafana-mcp:
    enabled: false # Pull secret is not supported
database:
  postgres:
    bundled:
      storageClassName: local-shared
      image:
        registry: ${PRIVATE_REPO}
      enabled: true

Erstellen Sie die Datei management-values.yaml.

cluster: ${CLUSTER_NAME}
context: "${USER_CONTEXT}"

management-crds:
  enabled: false

global:
  imagePullPolicy: IfNotPresent
  imagePullSecrets:
  - name: ${PULL_SECRET_NAME}

products:
  kagent:
    enabled: true
  agentgateway:
    enabled: true
  mesh:
    enabled: false
  agentregistry:
    enabled: false

oidc:
  issuer: ""

traces:
  verbose: false

tunnelserver:
  registry: ${PRIVATE_REPO}
  repository: solo-enterprise
  name: solo-enterprise-tunnel-server

ui:
  backend:
    registry: ${PRIVATE_REPO}
    repository: solo-enterprise
    name: solo-enterprise-ui-backend
    clickhouse:
      migrations:
        registry: ${PRIVATE_REPO}
  frontend:
    registry: ${PRIVATE_REPO}
    repository: solo-enterprise
  telemetryGateway:
    repository: ${PRIVATE_REPO}/otel/opentelemetry-collector-contrib

idp:
  registry: ${PRIVATE_REPO}
  repository: solo-enterprise

telemetry:
  image:
    registry: ${PRIVATE_REPO}
    repository: otel
    name: opentelemetry-collector-contrib
  k8sobjects:
    enabled: true
  metrics:
    enabled: false
  selfMonitoring:
    enabled: false
    verbose: false
  traces:
    enabled: true

clickhouse:
  enabled: true
  image:
    repository: ${PRIVATE_REPO}/clickhouse/clickhouse-server

Umgebung einrichten

Laden Sie im selben Verzeichnis wie Ihre .env- und Helm-Wertedateien die Umgebungsvariablen und rendern Sie die Helm-Wertvorlagen. Führen Sie die verbleibenden Befehle in diesem Leitfaden in derselben Shell-Sitzung aus, damit diese Variablen festgelegt bleiben:

SCRIPT_DIR="${PWD}"

set -a
source "$SCRIPT_DIR/.env"
set +a

COMMON_FLAGS=(--kube-context "$MGMT_CONTEXT" -n "$NAMESPACE" --create-namespace --insecure-skip-tls-verify)

# Values files live alongside the script. Render them with envsubst into
# *.generated.yaml siblings that are then fed to helm upgrade.

MANAGEMENT_VALUES_GENERATED="$SCRIPT_DIR/management-values.generated.yaml"
KAGENT_ENTERPRISE_VALUES_GENERATED="$SCRIPT_DIR/kagent-enterprise-values.generated.yaml"
ENTERPRISE_AGENTGATEWAY_VALUES_GENERATED="$SCRIPT_DIR/enterprise-agentgateway-values.generated.yaml"

envsubst < "$SCRIPT_DIR/management-values.yaml"            > "$MANAGEMENT_VALUES_GENERATED"
envsubst < "$SCRIPT_DIR/kagent-enterprise-values.yaml"     > "$KAGENT_ENTERPRISE_VALUES_GENERATED"
envsubst < "$SCRIPT_DIR/enterprise-agentgateway-values.yaml" > "$ENTERPRISE_AGENTGATEWAY_VALUES_GENERATED"

Images und Diagramme aus der öffentlichen Registry spiegeln

Authentifizieren Sie Docker und Helm bei Ihrer privaten Harbor-Registry und spiegeln Sie dann die Helm-Diagramme und Container-Images aus der öffentlichen Registry:

# Authenticate to the private Harbor registry before mirroring charts and images.
helm registry login "$PRIVATE_REGISTRY"
docker login "$PRIVATE_REGISTRY"

function mirror() {
  if command -v crane &> /dev/null; then
    crane cp "$1" "$2"
  else
    docker pull "$1"
    docker tag "$1" "$2"
    docker push "$2"
  fi
}

MANAGEMENT_CHARTS=(management-crds management)
KAGENT_CHARTS=(kagent-enterprise-crds kagent-enterprise)
AGENTGATEWAY_CHARTS=(enterprise-agentgateway-crds enterprise-agentgateway)

# Mirror Helm chart OCI artifacts to the private registry using the same mirror() helper.

for CHART in "${MANAGEMENT_CHARTS[@]}"; do
  mirror \
    "${PUBLIC_MANAGEMENT_REGISTRY}/${CHART}:${KAGENT_ENT_VERSION}" \
    "${PRIVATE_CHART_REGISTRY}/${CHART}:${KAGENT_ENT_VERSION}"
done

for CHART in "${KAGENT_CHARTS[@]}"; do
  mirror \
    "${PUBLIC_REGISTRY}/${CHART}:${KAGENT_ENT_VERSION}" \
    "${PRIVATE_CHART_REGISTRY}/${CHART}:${KAGENT_ENT_VERSION}"
done

for CHART in "${AGENTGATEWAY_CHARTS[@]}"; do
  mirror \
    "${PUBLIC_AGENTGATEWAY_REGISTRY}/${CHART}:${AGENTGATEWAY_VERSION}" \
    "${PRIVATE_CHART_REGISTRY}/${CHART}:${AGENTGATEWAY_VERSION}"
done

# Discover images by templating the charts directly from their public OCI source.

IMAGES=$( (
  helm template management "oci://${PUBLIC_MANAGEMENT_REGISTRY}/management" \
    --version "$KAGENT_ENT_VERSION" \
    --set products.kagent.enabled=true \
    --set products.agentgateway.enabled=true \
    --set products.agentregistry.enabled=true \
    --set licensing.licenseKey=placeholder
  helm template kagent-enterprise "oci://${PUBLIC_REGISTRY}/kagent-enterprise" \
    --version "$KAGENT_ENT_VERSION" \
    --set licensing.licenseKey=placeholder \
    --set kmcp.licensing.licenseKey=placeholder \
    --set ui.enabled=true \
    --set kagent-tools.enabled=true \
    --set agents.k8s-agent.enabled=true
  helm template enterprise-agentgateway "oci://${PUBLIC_AGENTGATEWAY_REGISTRY}/enterprise-agentgateway" \
    --version "$AGENTGATEWAY_VERSION" \
    --set licensing.licenseKey=placeholder
) | grep "image:" | grep -v '{' | sed 's/.*image: //' | tr -d '" ' | grep -E '^[a-zA-Z0-9].*[:/]' | sort -u)

IMAGES_EXTRA="cr.kagent.dev/kagent-dev/kagent/golang-adk:$KAGENT_VERSION cr.kagent.dev/kagent-dev/kagent/app:$KAGENT_VERSION ghcr.io/kagent-dev/kagent/skills-init:$KAGENT_VERSION"

TARGET_PREFIX="${PRIVATE_REPO//\//\\/}"

for IMG in $IMAGES $IMAGES_EXTRA; do
  echo "From: $IMG"
  NEW_IMG=$(echo "$IMG" | sed s/'us-docker\.pkg\.dev\/solo-public'/"$TARGET_PREFIX"/ | sed s/'^clickhouse\/'/"$TARGET_PREFIX\/clickhouse\/"/ | sed s/'^argoproj\/'/"$TARGET_PREFIX\/argoproj\/"/ | sed s/'^docker.io\/otel\/'/"$TARGET_PREFIX\/otel\/"/ | sed s/'^docker.io\/library\/postgres'/"$TARGET_PREFIX\/library\/postgres"/ | sed s/'^cr.kagent.dev\/kagent-dev\/'/"$TARGET_PREFIX\/kagent-dev\/"/ | sed s/'^docker.io\/mcp\/'/"$TARGET_PREFIX\/mcp\/"/ | sed s/'^ghcr.io\/kagent-dev\/'/"$TARGET_PREFIX\/kagent-dev\/"/)
  echo "To  : $NEW_IMG"
  mirror "$IMG" "$NEW_IMG"
done

Namespace im GDC-SO-Cluster erstellen

Erstellen Sie den Ziel-Namespace in Ihrem Cluster:

kubectl create namespace "$NAMESPACE" --context "$MGMT_CONTEXT" \
    --dry-run=client -o yaml | kubectl apply --context "$MGMT_CONTEXT" -f -

Docker-Pull-Secret erstellen und auf den Cluster anwenden

Erstellen Sie das Docker-Registry-Pull-Secret in Ihrem Cluster:

kubectl create secret docker-registry "$PULL_SECRET_NAME" \
    --context "$MGMT_CONTEXT" \
    --namespace "$NAMESPACE" \
    --docker-server="$PRIVATE_REGISTRY" \
    --docker-username="REGISTRY_USERNAME" \
    --docker-password="REGISTRY_PASSWORD"

Ersetzen Sie Folgendes:

  • REGISTRY_USERNAME: Ihr Harbor-Registry-Nutzername
  • REGISTRY_PASSWORD: Ihr Harbor-Registry-Passwort

kagent installieren

Installieren Sie die CRD-Diagramme und die Solo Enterprise for kagent-Helm-Diagramme:

# Standard clusters allow cluster-scoped resources, so install CRD charts first.

helm upgrade -i management-crds \
  "oci://${PRIVATE_CHART_REGISTRY}/management-crds" \
  "${COMMON_FLAGS[@]}" \
  --version "$KAGENT_ENT_VERSION"

helm upgrade -i kagent-enterprise-crds \
  "oci://${PRIVATE_CHART_REGISTRY}/kagent-enterprise-crds" \
  "${COMMON_FLAGS[@]}" \
  --version "$KAGENT_ENT_VERSION"

helm upgrade -i enterprise-agentgateway-crds \
  "oci://${PRIVATE_CHART_REGISTRY}/enterprise-agentgateway-crds" \
  "${COMMON_FLAGS[@]}" \
  --version "$AGENTGATEWAY_VERSION"

helm upgrade -i management \
  "oci://${PRIVATE_CHART_REGISTRY}/management" \
  "${COMMON_FLAGS[@]}" \
  --version "$KAGENT_ENT_VERSION" \
  --values "$MANAGEMENT_VALUES_GENERATED" \
  --set "licensing.licenseKey=$SOLO_LICENSE_KEY"

helm upgrade -i kagent-enterprise \
  "oci://${PRIVATE_CHART_REGISTRY}/kagent-enterprise" \
  "${COMMON_FLAGS[@]}" \
  --version "$KAGENT_ENT_VERSION" \
  --values "$KAGENT_ENTERPRISE_VALUES_GENERATED" \
  --set "licensing.licenseKey=$SOLO_LICENSE_KEY" \
  --set "kmcp.licensing.licenseKey=$SOLO_LICENSE_KEY" \
  --set "controller.agentImage.tag=$KAGENT_VERSION" \
  --set "controller.skillsInitImage.tag=$KAGENT_VERSION"


helm upgrade -i enterprise-agentgateway \
  "oci://${PRIVATE_CHART_REGISTRY}/enterprise-agentgateway" \
  "${COMMON_FLAGS[@]}" \
  --version "$AGENTGATEWAY_VERSION" \
  --values "$ENTERPRISE_AGENTGATEWAY_VALUES_GENERATED" \
  --set "licensing.licenseKey=$SOLO_LICENSE_KEY"

Deployment validieren

Prüfen Sie, ob die Pods in Ihrem Namespace ausgeführt werden:

kubectl get pods -n "$NAMESPACE" --context "$MGMT_CONTEXT"

Die Ausgabe sieht etwa so aus:

NAME                                                  READY   STATUS    RESTARTS   AGE
enterprise-agentgateway-5b57c9496b-hfnqq              1/1     Running   0          36m
k8s-agent-796b6674f5-fd8cq                            1/1     Running   0          4m8s
kagent-controller-5f7b44f647-9nd95                    1/1     Running   0          5m31s
kagent-postgresql-688d8c679d-4g9n9                    1/1     Running   0          36m
kagent-tools-6b9f8d58c6-t5zsm                         1/1     Running   0          23m
kmcp-enterprise-controller-manager-7886cdfb57-kgnmw   1/1     Running   0          23m
management-clickhouse-shard0-0                        1/1     Running   0          14m
solo-enterprise-telemetry-collector-0                 1/1     Running   0          23m
solo-enterprise-ui-7c7c889d6-frkvn                    5/5     Running   0          9m34s

Leiten Sie einen lokalen Port an den solo-enterprise-ui-Dienst weiter:

kubectl port-forward -n "$NAMESPACE" --context "$MGMT_CONTEXT" \
    svc/solo-enterprise-ui 9090:80

Rufen Sie in Ihrem Browser http://localhost:9090 auf, um die Solo Enterprise for kagent-Benutzeroberfläche zu öffnen und Ihre Modelle und Agents zu konfigurieren:

Solo Enterprise für kagent-UI-Dashboard.

Leistungsaspekte und Bereitstellungsgröße

In den folgenden Abschnitten wird beschrieben, wie der Ressourcenverbrauch von Komponenten skaliert wird. Außerdem werden die grundlegenden Speicher- und Ressourcengrößen für eine Bereitstellung mit einem einzelnen Cluster angegeben.

Skalierungsmerkmale

Der Ressourcenverbrauch ändert sich qualitativ, wenn die Anzahl der Agents und die Anfragebelastung pro Agent in einer Installation mit einem einzelnen Cluster steigen (die Diagramme management und kagent-enterprise ohne Relay). Anhand dieser Merkmale können Sie feststellen, welche Komponenten empfindlich auf bestimmte Skalierungsdimensionen reagieren, bevor Sie die Ressourcenzuweisung anpassen oder die Kapazität planen.

Wichtige Architekturfakten, die die Skalierung bestimmen

  • Der Traffic zwischen Agent und LLM ist direkt. Agenten rufen Large Language Model (LLM)-Endpunkte (z. B. einen clusterinternen Modelldienst) direkt auf. Dieser Traffic wird nicht über den Controller oder eine andere Komponente der Verwaltungsebene geleitet. Das Hinzufügen von Agenten oder das Erhöhen der Anfrageraten erhöht nicht die LLM-bezogene Last auf gemeinsam genutzten Komponenten.
  • MCP-Server befinden sich im Hot Path der Ausführung von Agententools. Wenn ein Agent ein Tool aufruft, das von einem MCP-Server (Model Context Protocol) unterstützt wird, ist der Aufruf synchron und blockierend. Die Latenz und der Durchsatz des MCP-Servers wirken sich direkt auf die Latenz von Agent-Anfragen aus. Jede bereitgestellte MCPServer-Ressource ist ein separates Deployment mit einem eigenen Ressourcen-Envelope.
  • Telemetrie ist die primäre Skalierungsoberfläche. Messwerte, Traces und Snapshots von Kubernetes-Objekten werden alle über die Telemetriepipeline an ClickHouse weitergeleitet. Diese Pipeline wächst sowohl mit der Anzahl der Agenten als auch mit dem Anfragevolumen und ist der ressourcenintensivste Teil des Systems.
  • Der Tunnelserver ist vorhanden, überträgt aber in einer Installation mit einem einzelnen Cluster keinen relevanten Traffic. Der tunnel-server-Container wird im UI-Pod ausgeführt, hat aber keine Clients, die er bedienen muss, und trägt nicht zum Skalierungsdruck bei.

Skalierungsverhalten von Komponenten

In den folgenden Abschnitten wird beschrieben, wie einzelne Komponenten mit der Anzahl der Agents und der Anfragelast skaliert werden.

kagent-controller
  • Wächst sublinear mit der Anzahl der Agenten – jeder Agent hat eine Agent-zu-Agent-Stream-Verbindung (A2A).
  • Ist nicht empfindlich gegenüber dem Anfragevolumen, da LLM-Aufrufe und Toolausführungen den Controller umgehen.
  • Unterstützt die horizontale Skalierung, um die Last für die Verbindungs- und Richtlinienbewertung zu verteilen.
KMCP-Enterprise-Controller

Der KMCP-Enterprise-Controller ist nur bei Änderungen an MCPServer-Ressourcen ereignisgesteuert und reagiert nicht auf die Anzahl der Agents oder das Anfragevolumen.

MCP-Server
  • Stellt ein Deployment pro benutzerdefinierter MCPServer-Ressource bereit. Die Flottengröße wächst mit der Anzahl der bereitgestellten MCPServer-Ressourcen.
  • Wird im synchronen Hot Path der Ausführung von KI-Agententools ausgeführt. Latenz und Durchsatz wirken sich direkt auf KI-Agenten aus.
  • Skaliert mit der Gesamtrate der Toolaufrufe über alle Nutzer hinweg, wenn freigegebene Server von vielen KI-Agenten gleichzeitig aufgerufen werden.
  • Führt integrierte Server (grafana-mcp, querydoc) standardmäßig als einzelnes Replikat aus. Erhöhen Sie die Anzahl der Replikate oder die Limits für eine stark gemeinsam genutzte Verwendung.
  • Verwendet benutzerdefinierte Images, Ressourcenanfragen und Ressourcenlimits für vom Nutzer bereitgestellte MCP-Server.
Telemetrie-Collector
  • Skaliert linear mit dem Anfragevolumen – jede Anfrage gibt Messwerte und optional Traces aus.
  • Ist die Komponente, die bei hoher Agent-Last am wahrscheinlichsten Ressourcenbeschränkungen unterliegt.
  • Dient als OpenTelemetry Protocol (OTLP)-Gateway (Empfänger an den Ports 4316–4318) für Remote-Cluster in einer Multi-Cluster-Installation. Es gibt keinen separaten Gateway-Pod.
  • Verwendet den Sidecar k8sobjects, der mit der Kubernetes-Inventargröße und nicht mit der Anforderungsrate skaliert wird.
ClickHouse

ClickHouse ist der primäre Ressourcenengpass bei anhaltender Last. Speicher, Arbeitsspeicher und CPU wachsen mit den folgenden Faktoren:

  • Anzahl der Agents: Jeder zusätzliche Agent-Typ erhöht die Kardinalität der Messwerte (eindeutige Labelkombinationen).
  • Anfragevolumen: Jede Anfrage erzeugt Messwert-Datenpunkte und Trace-Spans, die geschrieben und indexiert werden.
  • Kubernetes-Inventargröße: k8sobjects-Snapshots werden unabhängig von der Anfragelast regelmäßig gespeichert.

Der Schreibdurchsatz ist der erste Druckpunkt. Die Abfrageleistung (vom UI-Backend verwendet) nimmt ab, wenn das Datenvolumen ohne Schema- oder Aufbewahrungsoptimierung zunimmt. Die Standardkonfiguration ist auf eine moderate Bereitstellung mit einem einzelnen Knoten ausgelegt. Bei höheren Lasten müssen Sie möglicherweise replicasPerShard oder shards erhöhen oder die TTLs für die Aufbewahrung anpassen.

UI-Backend
  • Ist zustandslos und abfragegebunden; skaliert mit dem Datenvolumen in ClickHouse und nicht mit dem Durchsatz von Echtzeitanfragen.
  • Erhöht die Kosten für Flottengrafik- und Trace-Abfragen, wenn die Anzahl der Agenten und die Verlaufsdaten zunehmen.
KI-Agenten
  • Python-basierte KI-Agenten:
    • Jeder Agent ist ein unabhängiges Deployment. Das Hinzufügen von Agenten ist rein additiv und hat keine Auswirkungen auf den gemeinsamen Status.
    • Der Ressourcenverbrauch pro Agent skaliert mit der Anzahl gleichzeitiger Anfragen und der Tiefe der Toolkette.
  • Go-basierte Agents:
    • Verbraucht etwa 36-mal weniger inaktiven Speicher (7 MB gegenüber 253 MB pro Agent im Ruhezustand).
    • Verwendet ein etwa 11-mal kleineres Container-Image (29,7 MB im Vergleich zu 335,4 MB).
    • Startet etwa 6,7-mal schneller (2,7 Sekunden im Vergleich zu 18,2 Sekunden).

Zusammenfassung der Skalierungsmerkmale

In der folgenden Tabelle wird zusammengefasst, wie die einzelnen Komponenten mit der Anzahl der Agents und der Anfragelast skaliert werden:

Komponente Empfindlich gegenüber der Anzahl der KI-Agenten Empfindlich gegenüber der Anfragelast Hinweise
Controller Mittel Niedrig Verwaltet A2A-Streams pro Agent; nicht von der LLM-Aufrufrate betroffen
Scaler Keine Keine Ereignisgesteuert, effektiv statisch
KMCP-Enterprise-Controller Keine Keine Reagiert nur auf Änderungen an der Ressource MCPServer
MCP-Server Hoch Hoch Eine Bereitstellung pro MCPServer-CR; im Hot Path der Toolausführung
Telemetrie-Collector Hoch Hoch Primäre Skalierungsoberfläche; linear mit Anfragevolumen
ClickHouse Hoch Hoch Primärer Engpass; bedingt durch Kardinalität und Schreibrate
UI-Backend Niedrig Niedrig Abfragegebunden; von Verlaufsdatenvolumen betroffen
Agenten (Python und Go) Nicht zutreffend Hoch Unabhängige Bereitstellungen; Skalierung mit Nebenläufigkeit

Speichergröße

Die folgende Tabelle enthält erste Empfehlungen für die anfängliche Größe von Speicher-Volumes:

  • Der PostgreSQL-Speicher (kagent-Status, einschließlich Sitzungs-, Speicher- und Lebenszyklusverwaltung) wird linear skaliert, wenn die Anzahl der Chatsitzungen steigt.
  • Der ClickHouse-Speicher (Tracing) wird ebenfalls linear skaliert, wenn die Anzahl der eindeutigen Chatsitzungen zunimmt.
Komponente Empfohlene Startlautstärke
PostgreSQL 50 GiB
ClickHouse 50 GiB

Bereitstellungsgröße

In den folgenden Abschnitten sind die standardmäßigen CPU-, Arbeitsspeicher- und Speicherressourcenanfragen und -limits für die Helm-Diagramme aufgeführt.

Verwaltungsdiagramm

Das management-Diagramm stellt den solo-enterprise-ui-Pod, einen eigenständigen Telemetrie-Collector und ClickHouse bereit.

solo-enterprise-ui Pod-Container

In der folgenden Tabelle sind die Standard-Ressourcenanfragen und -limits für die solo-enterprise-ui-Pod-Container aufgeführt:

Container Aktiviert CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
ui-backend Immer 250 m 500m 512 Mi 1024Mi
ui-frontend Immer 250 m 500m 512 Mi 1024Mi
k8sobjects-collector telemetry.k8sobjects.enabled 100 m 300 m 384 Mi 768 Mi
idp autoAuth aktiviert 100 m 250 m 256 Mi 512 Mi
Telemetrie-Collector (StatefulSet oder Deployment)

In der folgenden Tabelle sind die Standardressourcenanfragen und -limits für den Telemetrie-Collector aufgeführt:

Komponente CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
telemetry-collector 200m 1.000 m 512 Mi 2Gi

Das Telemetrie-Gateway (OpenTelemetry Collector) definiert auch eigene Ressourcen separat:

Komponente CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
telemetry-gateway 100 m 500m 300 Mi 1024Mi
ClickHouse-Unterdiagramm

In der folgenden Tabelle sind die Standardressourcenanfragen und -limits für das ClickHouse-Subdiagramm aufgeführt, basierend auf der Bitnami-Voreinstellung 2xlarge und konfiguriert mit den Werten replicasPerShard und shards:

Komponente CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit Sitzungsspezifischer Speicher
clickhouse 1.000 m (1 Kern) 6.000 m (6 Kerne) 3072Mi (3 GiB) 12288Mi (12 GiB) 50 Mi

kagent-enterprise-Diagramm

Mit dem kagent-enterprise-Diagramm werden der Core Controller, das kmcp-enterprise-Unterdiagramm, integrierte MCP-Tool-Server und optionale Agenten bereitgestellt.

Kernkomponenten

In der folgenden Tabelle sind die Standard-Ressourcenanfragen und -limits für den Core-Controller aufgeführt:

Komponente Aktiviert CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
controller Immer 100 m 2.000 m (2 Kerne) 128Mi 512 Mi
kmcp-enterprise-Subdiagramm

In der folgenden Tabelle sind die Standard-Ressourcenanfragen und -limits für den kmcp-enterprise-Controller aufgeführt:

Komponente CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
kmcp-enterprise-controller 100 m 500m 128Mi 512 Mi
Integrierte Tools

In der folgenden Tabelle sind die Standardressourcenanfragen und -limits für die integrierten Toolserver aufgeführt:

Komponente Aktiviert CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
kagent-tools kagent-tools.enabled 100 m 1.000 m 256 Mi 1Gi
grafana-mcp grafana-mcp.enabled 100 m 500m 128Mi 512 Mi
querydoc querydoc.enabled 100 m 500m 128Mi 512 Mi
KI-Agenten

Alle Agenten verwenden dasselbe Standardressourcenprofil. Jeder Agent ist standardmäßig deaktiviert und wird einzeln aktiviert:

Agent CPU-Anfrage CPU-Limit Arbeitsspeicheranfrage Arbeitsspeicherlimit
k8s-agent 100 m 1.000 m 256 Mi 1Gi
kgateway-agent 100 m 1.000 m 256 Mi 1Gi
istio-agent 100 m 1.000 m 256 Mi 1Gi
promql-agent 100 m 1.000 m 256 Mi 1Gi
observability-agent 100 m 1.000 m 256 Mi 1Gi
argo-rollouts-agent 100 m 1.000 m 256 Mi 1Gi
helm-agent 100 m 1.000 m 256 Mi 1Gi
cilium-policy-agent 100 m 1.000 m 256 Mi 1Gi
cilium-manager-agent 100 m 1.000 m 256 Mi 1Gi
cilium-debug-agent 100 m 1.000 m 256 Mi 1Gi