Déployer Solo Enterprise pour kagent sur l'implémentation de référence de Distributed Cloud (logiciel uniquement)

Solo Enterprise pour kagent permet aux administrateurs de plates-formes de déployer et de gérer des agents IA sur Google Distributed Cloud (GDC) – Logiciel uniquement (GDC-SO). Dans cette implémentation de référence, vous allez mettre en miroir des images de conteneurs et des charts Helm dans un registre Harbor privé, déployer le plan de contrôle kagent, l'interface utilisateur et Solo Enterprise pour agentgateway, et examiner les consignes de dimensionnement des clusters. Pour en savoir plus sur l'architecture, consultez Architecture de référence pour l'utilisation de votre propre serveur MCP avec kagent.

Prérequis

Avant de commencer, assurez-vous d'avoir accès à un poste de travail Linux sur lequel sont installés Chrome, Docker, crane, kubectl, Helm, envsubst et la CLI gdcloud. Assurez-vous que les composants suivants sont configurés pour votre environnement GDC-SO :

Composant Détail ou exigence Exemple de valeur
Google Cloud projet pour GDC-SO Projet associé au cluster GDC-SO kagent-enterprise
Cluster Cluster GDC-SO cible user-project-8a210897
Identifiants Kubernetes (passerelle Connect) Connexion au cluster gcloud container fleet memberships get-credentials user-project-8a210897
Registre privé URL du registre Harbor solo-kagent-enterprise.org-1.zone1.google.gdch.test
Dépôt du projet Chemin d'accès au dépôt du projet solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise
Secret d'extraction Nom du secret d'extraction Docker solo-harbor-pull-secret

Les instructions suivantes s'appliquent à Solo Enterprise pour kagent version 0.4.0 et ultérieure.

Ce déploiement a été validé sur GDC-SO version 1.31.5-gke.300.

Déployer sur un cluster GDC-SO

Créez un fichier .env en fonction de la configuration de votre cluster et de votre registre :

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"

Remplacez les éléments suivants :

  • SOLO_LICENSE_KEY : votre clé de licence Solo Enterprise
  • ORG : nom de votre organisation GDC
  • ZONE : nom de votre zone GDC

Créer les fichiers de valeurs Helm

Créez les fichiers de valeurs Helm pour les trois charts. Vous n'avez pas besoin de modifier les valeurs, sauf si vous souhaitez personnaliser l'installation. Vous pourrez configurer d'autres modèles et agents ultérieurement dans l'interface utilisateur de kagent.

Créez le fichier 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

Créez le fichier 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

Créez le fichier 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

Configurer l'environnement

Dans le même répertoire que vos fichiers de valeurs .env et Helm, chargez les variables d'environnement et affichez les modèles de valeurs Helm. Exécutez les commandes restantes de ce guide dans la même session shell afin que ces variables restent définies :

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"

Mettre en miroir des images et des charts à partir du registre public

Authentifiez Docker et Helm auprès de votre registre Harbor privé, puis mettez en miroir les charts Helm et les images de conteneurs du registre public :

# 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

Créer un espace de noms dans le cluster GDC-SO

Créez l'espace de noms cible dans votre cluster :

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

Créer et appliquer un secret d'extraction Docker au cluster

Créez le secret d'extraction du registre Docker dans votre 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"

Remplacez les éléments suivants :

  • REGISTRY_USERNAME : votre nom d'utilisateur du registre Harbor
  • REGISTRY_PASSWORD : mot de passe de votre registre Harbor

Installer kagent

Installez les charts CRD et les charts Helm Solo Enterprise pour kagent :

# 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"

Validez le déploiement.

Vérifiez que les pods sont en cours d'exécution dans votre espace de noms :

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

Le résultat ressemble à ce qui suit :

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

Transférez un port local vers le service solo-enterprise-ui :

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

Dans votre navigateur, accédez à http://localhost:9090 pour ouvrir l'interface utilisateur de Solo Enterprise pour kagent, puis configurez vos modèles et agents :

Solo Enterprise pour le tableau de bord de l'UI kagent.

Considérations sur les performances et dimensionnement du déploiement

Les sections suivantes décrivent comment la consommation de ressources des composants évolue et fournissent un dimensionnement de base du stockage et des ressources pour un déploiement à cluster unique.

Caractéristiques du scaling

La consommation de ressources change qualitativement à mesure que le nombre d'agents et la charge de requêtes par agent augmentent dans une installation à cluster unique (les graphiques management et kagent-enterprise sans relais). Utilisez ces caractéristiques pour identifier les composants sensibles à des dimensions de scaling spécifiques avant d'ajuster les allocations de ressources ou de planifier la capacité.

Principaux faits architecturaux qui régissent le scaling

  • Le trafic entre l'agent et le LLM est direct. Les agents appellent directement les points de terminaison de grands modèles de langage (LLM), tels qu'un service de modèle au sein du cluster. Ce trafic ne passe pas par le contrôleur ni par aucun autre composant du plan de gestion. L'ajout d'agents ou l'augmentation des taux de requêtes n'augmente pas la charge liée au LLM sur un composant partagé.
  • Les serveurs MCP se trouvent sur le chemin critique de l'exécution des outils de l'agent. Lorsqu'un agent appelle un outil soutenu par un serveur MCP (Model Context Protocol), l'appel est synchrone et bloquant. La latence et le débit du serveur MCP ont un impact direct sur la latence des requêtes de l'agent. Chaque ressource MCPServer déployée est un déploiement distinct avec sa propre enveloppe de ressources.
  • La télémétrie est la principale surface de scaling. Les métriques, les traces et les instantanés d'objets Kubernetes transitent tous par le pipeline de télémétrie vers ClickHouse. Ce pipeline évolue en fonction du nombre d'agents et du volume de requêtes. Il s'agit de la partie du système la plus sensible aux ressources.
  • Le serveur de tunnel est présent, mais ne transporte aucun trafic significatif dans une installation à cluster unique. Le conteneur tunnel-server s'exécute dans le pod de l'interface utilisateur, mais il n'a pas de clients à servir et ne contribue pas à la pression de scaling.

Comportement de scaling des composants

Les sections suivantes décrivent comment les composants individuels évoluent en fonction du nombre d'agents et de la charge de requêtes.

kagent-controller
  • Augmente de manière sous-linéaire avec le nombre d'agents : chaque agent détient une connexion de flux d'agent à agent (A2A).
  • Il n'est pas sensible au volume de requêtes, car les appels de LLM et les exécutions d'outils contournent le contrôleur.
  • Il est compatible avec le scaling horizontal pour répartir la charge d'évaluation des connexions et des règles.
Contrôleur d'entreprise KMCP

Le contrôleur d'entreprise KMCP est basé sur les événements uniquement pour les modifications de ressources MCPServer et n'est pas sensible au nombre d'agents ni au volume de requêtes.

Serveurs MCP
  • Déploie un déploiement par ressource personnalisée (CR) MCPServer. La taille du parc augmente avec le nombre de ressources MCPServer déployées.
  • S'exécute dans le chemin réactif synchrone de l'exécution de l'outil de l'agent. La latence et le débit affectent directement les agents.
  • S'adapte au taux total d'appels d'outils pour tous les clients lorsque des serveurs partagés sont appelés par de nombreux agents simultanément.
  • Exécute les serveurs intégrés (grafana-mcp, querydoc) en tant qu'instance répliquée unique par défaut. Augmentez le nombre d'instances répliquées ou les limites pour une utilisation intensive.
  • Utilise des images, des requêtes de ressources et des limites de ressources définies par l'utilisateur pour les serveurs MCP déployés par l'utilisateur.
Collecteur de télémétrie
  • Évolue de manière linéaire en fonction du volume de requêtes : chaque requête émet des métriques et, éventuellement, des traces.
  • Il s'agit du composant le plus susceptible de manquer de ressources en cas de charge élevée des agents.
  • Sert de passerelle OTLP (OpenTelemetry Protocol) (récepteurs sur les ports 4316-4318) pour les clusters distants dans une installation multicluster. Il n'existe pas de pod de passerelle distinct.
  • Utilise le side-car k8sobjects, qui évolue en fonction de la taille de l'inventaire Kubernetes plutôt que du taux de demandes.
ClickHouse

ClickHouse est le principal goulot d'étranglement des ressources en cas de charge soutenue. Le stockage, la mémoire et le processeur augmentent tous en fonction des facteurs suivants :

  • Nombre d'agents : chaque type d'agent supplémentaire augmente la cardinalité des métriques (combinaisons d'étiquettes uniques).
  • Volume de requêtes : chaque requête produit des points de données de métriques et des segments de trace qui sont écrits et indexés.
  • Taille de l'inventaire Kubernetes : les instantanés k8sobjects sont stockés régulièrement, quelle que soit la charge de requêtes.

Le débit d'écriture est le point de pression initial. Les performances des requêtes (utilisées par le backend de l'interface utilisateur) se dégradent à mesure que le volume de données augmente sans réglage du schéma ou de la conservation. La configuration par défaut cible un déploiement modéré à un seul nœud. Les charges plus lourdes peuvent nécessiter l'augmentation de replicasPerShard ou de shards, ou l'ajustement des valeurs TTL de conservation.

Backend de l'UI
  • Il est sans état et lié aux requêtes. Il évolue en fonction du volume de données dans ClickHouse plutôt que du débit des requêtes en temps réel.
  • Augmente le coût des requêtes de graphe et de trace de parc à mesure que le nombre d'agents et les données historiques augmentent.
Agents
  • Agents basés sur Python :
    • Chaque agent est un déploiement indépendant. L'ajout d'agents est purement additif, sans pénalité d'état partagé.
    • La consommation de ressources par agent évolue en fonction de la simultanéité des requêtes et de la profondeur de la chaîne d'outils.
  • Agents basés sur Go :
    • Utilise environ 36 fois moins de mémoire inactive (7 Mo contre 253 Mo par agent au repos).
    • Utilise une image de conteneur environ 11 fois plus petite (29,7 Mo contre 335,4 Mo).
    • Démarre environ 6,7 fois plus vite (2,7 secondes contre 18,2 secondes).

Résumé des caractéristiques de scaling

Le tableau suivant récapitule la manière dont chaque composant évolue en fonction du nombre d'agents et de la charge de requêtes :

Composant Sensible au nombre d'agents Sensible à la charge de requêtes Remarques
Contrôleur Modéré Faible Maintient les flux A2A par agent ; non affecté par le taux d'appels LLM
Scaler Aucun Aucun Basé sur des événements, statique de fait
Contrôleur d'entreprise KMCP Aucun Aucun Réagit uniquement aux modifications de la ressource MCPServer
Serveurs MCP Élevée Élevée Un déploiement par CR MCPServer ; dans le chemin d'accès à chaud de l'exécution de l'outil
Collecteur de télémétrie Élevée Élevée Surface de scaling principale ; linéaire avec le volume de requêtes
ClickHouse Élevée Élevée Goulot d'étranglement principal, déterminé par la cardinalité et le taux d'écriture
Backend de l'UI Faible Faible Lié aux requêtes ; affecté par le volume de données historiques
Agents (Python et Go) Non applicable Élevée Déploiements indépendants ; scaling avec simultanéité

Dimensionnement du stockage

Le tableau suivant fournit des recommandations initiales pour les tailles de volume de stockage de départ :

  • Le stockage PostgreSQL (état de kagent, y compris la gestion des sessions, de la mémoire et du cycle de vie) évolue de manière linéaire à mesure que le nombre de sessions de chat augmente.
  • Le stockage ClickHouse (traçage) évolue également de manière linéaire à mesure que le nombre de sessions de chat uniques augmente.
Composant Volume de départ recommandé
PostgreSQL 50 Gio
ClickHouse 50 Gio

Dimensionnement du déploiement

Les sections suivantes répertorient les requêtes et les limites de ressources de processeur, de mémoire et de stockage par défaut pour les charts Helm.

Graphique de gestion

Le graphique management déploie le pod solo-enterprise-ui, un collecteur de télémétrie autonome et ClickHouse.

solo-enterprise-ui conteneur de pod

Le tableau suivant liste les requêtes de ressource et les limites par défaut pour les conteneurs de pods solo-enterprise-ui :

Conteneur Activé Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
ui-backend Toujours 250 m 500 m 512 Mi 1024Mi
ui-frontend Toujours 250 m 500 m 512 Mi 1024Mi
k8sobjects-collector telemetry.k8sobjects.enabled 100 min 300 m 384Mi 768 Mi
idp autoAuth activé 100 min 250 m 256 Mi 512 Mi
Collecteur de télémétrie (StatefulSet ou Deployment)

Le tableau suivant liste les requêtes et limites de ressources par défaut pour le collecteur de télémétrie :

Composant Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
telemetry-collector 200 m 1 000 m 512 Mi 2Gi

La passerelle de télémétrie (collecteur OpenTelemetry) définit également ses propres ressources séparément :

Composant Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
telemetry-gateway 100 min 500 m 300 Mi 1024Mi
Sous-graphique ClickHouse

Le tableau suivant liste les requêtes de ressources et limites par défaut pour le sous-chart ClickHouse, en fonction du préréglage Bitnami 2xlarge et configuré à l'aide des valeurs replicasPerShard et shards :

Composant Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire Espace de stockage éphémère
clickhouse 1 000 m (1 cœur) 6000m (6 cœurs) 3 072 Mio (3 Gio) 12288Mi (12 Gio) 50 Mi

Graphique kagent-enterprise

Le chart kagent-enterprise déploie le contrôleur principal, le sous-chart kmcp-enterprise, les serveurs d'outils MCP intégrés et les agents facultatifs.

Composants principaux

Le tableau suivant liste les requêtes de ressource et limites par défaut pour le contrôleur principal :

Composant Activé Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
controller Toujours 100 min 2000m (2 cœurs) 128Mi 512 Mi
Sous-chart kmcp-enterprise

Le tableau suivant liste les requêtes de ressource et limites par défaut pour le contrôleur kmcp-enterprise :

Composant Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
kmcp-enterprise-controller 100 min 500 m 128Mi 512 Mi
Outils intégrés

Le tableau suivant liste les requêtes de ressources et limites par défaut pour les serveurs d'outils intégrés :

Composant Activé Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
kagent-tools kagent-tools.enabled 100 min 1 000 m 256 Mi 1Gi
grafana-mcp grafana-mcp.enabled 100 min 500 m 128Mi 512 Mi
querydoc querydoc.enabled 100 min 500 m 128Mi 512 Mi
Agents

Tous les agents partagent le même profil de ressources par défaut. Chaque agent est désactivé par défaut et activé individuellement :

Agent Demande de processeurs Limite de processeur Demande de mémoire Limite de mémoire
k8s-agent 100 min 1 000 m 256 Mi 1Gi
kgateway-agent 100 min 1 000 m 256 Mi 1Gi
istio-agent 100 min 1 000 m 256 Mi 1Gi
promql-agent 100 min 1 000 m 256 Mi 1Gi
observability-agent 100 min 1 000 m 256 Mi 1Gi
argo-rollouts-agent 100 min 1 000 m 256 Mi 1Gi
helm-agent 100 min 1 000 m 256 Mi 1Gi
cilium-policy-agent 100 min 1 000 m 256 Mi 1Gi
cilium-manager-agent 100 min 1 000 m 256 Mi 1Gi
cilium-debug-agent 100 min 1 000 m 256 Mi 1Gi