Esegui il deployment di Solo Enterprise per kagent nell'implementazione di riferimento solo software di Google Distributed Cloud

Solo Enterprise per kagent consente agli amministratori della piattaforma di eseguire il deployment e gestire gli agenti AI solo su software Google Distributed Cloud (GDC) (GDC-SO). In questa implementazione di riferimento, esegui il mirroring delle immagini container e dei grafici Helm in un registry Harbor privato, esegui il deployment del control plane kagent, della UI e di Solo Enterprise per agentgateway ed esamini le linee guida per il dimensionamento del cluster. Per saperne di più sull'architettura, consulta Architettura di riferimento per l'integrazione di un server MCP con kagent.

Prerequisiti

Prima di iniziare, assicurati di avere accesso a una workstation Linux con Chrome, Docker, crane, kubectl, Helm, envsubst e l'interfaccia a riga di comando gdcloud. Assicurati che i seguenti componenti siano configurati per il tuo ambiente GDC-SO:

Componente Dettaglio o requisito Valore di esempio
ProgettoGoogle Cloud per GDC-SO Progetto associato al cluster GDC-SO kagent-enterprise
Cluster Cluster GDC-SO di destinazione user-project-8a210897
Credenziali Kubernetes (Connect Gateway) Connessione al cluster gcloud container fleet memberships get-credentials user-project-8a210897
Registry privato URL del registry Harbor solo-kagent-enterprise.org-1.zone1.google.gdch.test
Repository del progetto Percorso del repository del progetto solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise
Secret pull Nome del secret pull Docker solo-harbor-pull-secret

Le seguenti istruzioni si applicano a Solo Enterprise per kagent versione 0.4.0 e successive.

Il deployment è stato convalidato sulla versione GDC-SO 1.31.5-gke.300.

Esegui il deployment su un cluster GDC-SO

Crea un file .env in base alla configurazione del cluster e del registry:

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"

Sostituisci quanto segue:

  • SOLO_LICENSE_KEY: il tuo codice licenza Solo Enterprise
  • ORG: il nome della tua organizzazione GDC
  • ZONE: il nome della tua zona GDC

Crea i file dei valori Helm

Crea i file dei valori Helm per i tre grafici. Non è necessario modificare alcun valore, a meno che tu non voglia personalizzare l'installazione. Puoi configurare altri modelli e agenti in un secondo momento nell'interfaccia utente di kagent.

Crea il file 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

Crea il file 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

Crea il file 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

Configura l'ambiente

Nella stessa directory dei file .env e dei valori Helm, carica le variabili di ambiente ed esegui il rendering dei template dei valori Helm. Esegui i comandi rimanenti in questa guida nella stessa sessione della shell in modo che queste variabili rimangano impostate:

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"

Immagini e grafici mirror dal registro pubblico

Autentica Docker e Helm nel tuo registry Harbor privato, quindi esegui il mirroring dei grafici Helm e delle immagini container dal registry pubblico:

# 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

Crea uno spazio dei nomi nel cluster GDC-SO

Crea lo spazio dei nomi di destinazione nel tuo cluster:

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

Crea e applica un secret di pull Docker al cluster

Crea il secret di pull del registry Docker nel tuo 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"

Sostituisci quanto segue:

  • REGISTRY_USERNAME: il tuo nome utente del registro Harbor
  • REGISTRY_PASSWORD: la password del registro Harbor

Installa kagent

Installa i grafici CRD e i grafici Helm Solo Enterprise per 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"

Convalida il deployment

Verifica che i pod siano in esecuzione nello spazio dei nomi:

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

L'output è simile al seguente:

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

Inoltra una porta locale al servizio solo-enterprise-ui:

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

Nel browser, vai a http://localhost:9090 per aprire la UI di Solo Enterprise for kagent e configurare i modelli e gli agenti:

Solo Enterprise per la dashboard della UI di kagent.

Considerazioni sulle prestazioni e dimensionamento del deployment

Le sezioni seguenti descrivono come viene scalato il consumo delle risorse dei componenti e forniscono il dimensionamento di base dello spazio di archiviazione e delle risorse per un deployment a cluster singolo.

Caratteristiche di scalabilità

Il consumo di risorse cambia qualitativamente man mano che il numero di agenti e il carico di richieste per agente aumentano in un'installazione con un singolo cluster (i grafici management e kagent-enterprise senza un relay). Utilizza queste caratteristiche per identificare i componenti sensibili a dimensioni di scalabilità specifiche prima di modificare le allocazioni delle risorse o pianificare la capacità.

Aspetti chiave dell'architettura che regolano la scalabilità

  • Il traffico dall'agente all'LLM è diretto. Gli agenti chiamano direttamente gli endpoint dei modelli linguistici di grandi dimensioni (LLM), ad esempio un servizio di modelli in-cluster. Questo traffico non passa attraverso il controller o qualsiasi altro componente del piano di gestione. L'aggiunta di agenti o l'aumento dei tassi di richieste non aumenta il carico relativo all'LLM su nessun componente condiviso.
  • I server MCP si trovano nel percorso critico dell'esecuzione degli strumenti dell'agente. Quando un agente richiama uno strumento supportato da un server Model Context Protocol (MCP), la chiamata è sincrona e bloccante. La latenza e la velocità effettiva del server MCP influiscono direttamente sulla latenza delle richieste dell'agente. Ogni risorsa MCPServer di cui è stato eseguito il deployment è un deployment separato con il proprio envelope di risorse.
  • La telemetria è la piattaforma di scalabilità principale. Le metriche, le tracce e gli snapshot degli oggetti Kubernetes passano tutti attraverso la pipeline di telemetria in ClickHouse. Questa pipeline cresce sia con il numero di agenti sia con il volume delle richieste ed è la parte del sistema più sensibile alle risorse.
  • Il server tunnel è presente, ma non trasporta traffico significativo in un'installazione a cluster singolo. Il container tunnel-server viene eseguito nel pod UI, ma non ha client da gestire e non contribuisce alla pressione di scalabilità.

Comportamento di scalabilità dei componenti

Le sezioni seguenti descrivono in che modo i singoli componenti scalano in base al numero di agenti e al carico delle richieste.

kagent-controller
  • Cresce in modo sublineare con il numero di agenti: ogni agente mantiene una connessione di stream da agente ad agente (A2A).
  • Non è sensibile al volume delle richieste perché le chiamate LLM e le esecuzioni degli strumenti bypassano il controller.
  • Supporta la scalabilità orizzontale per distribuire il carico di connessione e di valutazione delle policy.
Controller aziendale KMCP

Il controller aziendale KMCP è basato sugli eventi solo in caso di modifiche alle risorse MCPServer e non è sensibile al numero di agenti o al volume delle richieste.

Server MCP
  • Esegue un deployment per risorsa personalizzata MCPServer; le dimensioni del parco risorse aumentano con il numero di risorse MCPServer di cui è stato eseguito il deployment.
  • Viene eseguito nel percorso critico sincrono dell'esecuzione degli strumenti dell'agente: la latenza e il throughput influiscono direttamente sugli agenti.
  • Scala con la frequenza totale delle chiamate allo strumento di tutti i consumer quando i server condivisi vengono chiamati da molti agenti contemporaneamente.
  • Esegue i server integrati (grafana-mcp, querydoc) come singola replica per impostazione predefinita; aumenta le repliche o i limiti per un utilizzo ampiamente condiviso.
  • Utilizza immagini, richieste di risorse e limiti delle risorse definiti dall'utente per i server MCP di cui l'utente ha eseguito il deployment.
Raccoglitore di telemetria
  • Scala in modo lineare con il volume delle richieste: ogni richiesta genera metriche e, facoltativamente, tracce.
  • È il componente che più probabilmente subirà limitazioni delle risorse in caso di carico elevato degli agenti.
  • Funge da gateway OpenTelemetry Protocol (OTLP) (ricevitori sulle porte 4316-4318) per i cluster remoti in un'installazione multi-cluster; non esiste un pod gateway separato.
  • Utilizza il sidecar k8sobjects, che scala in base alle dimensioni dell'inventario di Kubernetes anziché al tasso di richieste.
ClickHouse

ClickHouse è il principale collo di bottiglia delle risorse in caso di carico prolungato. Lo spazio di archiviazione, la memoria e la CPU aumentano in base ai seguenti fattori:

  • Numero di agenti: ogni tipo di agente aggiuntivo aumenta la cardinalità delle metriche (combinazioni di etichette uniche).
  • Volume delle richieste: ogni richiesta produce punti dati delle metriche e intervalli di tracce che vengono scritti e indicizzati.
  • Dimensioni dell'inventario Kubernetes: gli snapshot di k8sobjects vengono archiviati periodicamente, indipendentemente dal carico delle richieste.

La velocità effettiva di scrittura è il punto di pressione iniziale; le prestazioni delle query (utilizzate dal backend della UI) peggiorano man mano che il volume dei dati cresce senza ottimizzazione dello schema o della conservazione. La configurazione predefinita è destinata a un deployment moderato su un singolo nodo; carichi più pesanti potrebbero richiedere l'aumento di replicasPerShard o shards o la modifica dei TTL di conservazione.

Backend UI
  • È stateless e associato alle query; scala con il volume di dati in ClickHouse anziché con la velocità effettiva delle richieste in tempo reale.
  • Aumenta il costo delle query di traccia e del grafico del parco risorse man mano che il numero di agenti e i dati storici aumentano.
Agenti
  • Agenti basati su Python:
    • Ogni agente è un deployment indipendente: l'aggiunta di agenti è puramente additiva, senza penalità per lo stato condiviso.
    • Il consumo di risorse per agente varia in base alla contemporaneità delle richieste e alla profondità della catena di strumenti.
  • Agenti basati su Go:
    • Utilizza circa 36 volte meno memoria inattiva (7 MB rispetto a 253 MB per agente inattivo).
    • Utilizza un'immagine container circa 11 volte più piccola (29,7 MB rispetto a 335,4 MB).
    • Si avvia circa 6,7 volte più velocemente (2,7 secondi rispetto a 18,2 secondi).

Riepilogo delle caratteristiche di scalabilità

La tabella seguente riassume il modo in cui ogni componente scala in base al numero di agenti e al carico delle richieste:

Componente Sensibile al numero di agenti Sensibile al carico delle richieste Note
Controller Moderato Bassa Mantiene gli stream A2A per agente; non è influenzato dalla frequenza delle chiamate LLM
Scaler Nessuno Nessuno Basato su eventi, effettivamente statico
Controller aziendale KMCP Nessuno Nessuno Reagisce solo alle modifiche delle risorse MCPServer
Server MCP Alta Alta Un deployment per CR MCPServer; nel percorso critico dell'esecuzione dello strumento
Raccoglitore di telemetria Alta Alta Superficie di scalabilità principale; lineare con il volume delle richieste
ClickHouse Alta Alta Collo di bottiglia principale; determinato dalla cardinalità e dalla frequenza di scrittura
Backend UI Bassa Bassa Vincolato alle query; influenzato dal volume dei dati storici
Agenti (Python e Go) Non applicabile Alta Deployment indipendenti; scalabilità con concorrenza

Dimensionamento dello spazio di archiviazione

La tabella seguente fornisce i suggerimenti iniziali per le dimensioni dei volumi di archiviazione iniziali:

  • Lo spazio di archiviazione di PostgreSQL (stato di kagent, inclusa la gestione di sessioni, memoria e ciclo di vita) scala in modo lineare con l'aumento del numero di sessioni di chat.
  • Anche lo spazio di archiviazione di ClickHouse (tracciamento) scala in modo lineare con l'aumento del numero di sessioni di chat uniche.
Componente Volume iniziale consigliato
PostgreSQL 50 GiB
ClickHouse 50 GiB

Dimensionamento del deployment

Le sezioni seguenti elencano le richieste e i limiti predefiniti delle risorse di CPU, memoria e archiviazione per i grafici Helm.

Grafico di gestione

Il grafico management esegue il deployment del pod solo-enterprise-ui, un raccoglitore di telemetria autonomo e ClickHouse.

solo-enterprise-ui container di pod

La tabella seguente elenca le richieste e i limiti di risorse predefiniti per i container dei pod solo-enterprise-ui:

Container Abilitato Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
ui-backend Sempre 250m 500m 512Mi 1024Mi
ui-frontend Sempre 250m 500m 512Mi 1024Mi
k8sobjects-collector telemetry.k8sobjects.enabled 100m 300m 384Mi 768Mi
idp autoAuth abilitato 100m 250m 256Mi 512Mi
Raccoglitore di telemetria (StatefulSet o Deployment)

La tabella seguente elenca le richieste di risorse e i limiti predefiniti per l'agente di raccolta di telemetria:

Componente Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
telemetry-collector 200m 1000m 512Mi 2Gi

Anche il gateway di telemetria (raccoglitore OpenTelemetry) definisce le proprie risorse separatamente:

Componente Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
telemetry-gateway 100m 500m 300Mi 1024Mi
Grafico secondario ClickHouse

La tabella seguente elenca le richieste e i limiti di risorse predefiniti per il grafico secondario ClickHouse, in base al preset Bitnami 2xlarge e configurati utilizzando i valori replicasPerShard e shards:

Componente Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria Archiviazione temporanea
clickhouse 1000m (1 core) 6000m (6 core) 3072Mi (3 GiB) 12288Mi (12 GiB) 50Mi

Grafico kagent-enterprise

Il grafico kagent-enterprise esegue il deployment del controller principale, del grafico secondario kmcp-enterprise, dei server degli strumenti MCP integrati e degli agenti facoltativi.

Componenti principali

La tabella seguente elenca le richieste e i limiti di risorse predefiniti per il controller principale:

Componente Abilitato Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
controller Sempre 100m 2000 m (2 core) 128Mi 512Mi
Grafico secondario kmcp-enterprise

La tabella seguente elenca le richieste e i limiti di risorse predefiniti per il controller kmcp-enterprise:

Componente Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
kmcp-enterprise-controller 100m 500m 128Mi 512Mi
Strumenti integrati

La tabella seguente elenca le richieste e i limiti di risorse predefiniti per i server degli strumenti integrati:

Componente Abilitato Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
kagent-tools kagent-tools.enabled 100m 1000m 256Mi 1Gi
grafana-mcp grafana-mcp.enabled 100m 500m 128Mi 512Mi
querydoc querydoc.enabled 100m 500m 128Mi 512Mi
Agenti

Tutti gli agenti condividono lo stesso profilo delle risorse predefinito. Ogni agente è disattivato per impostazione predefinita e viene attivato singolarmente:

Agente Richiesta di CPU Limite CPU Richiesta di memoria Limite di memoria
k8s-agent 100m 1000m 256Mi 1Gi
kgateway-agent 100m 1000m 256Mi 1Gi
istio-agent 100m 1000m 256Mi 1Gi
promql-agent 100m 1000m 256Mi 1Gi
observability-agent 100m 1000m 256Mi 1Gi
argo-rollouts-agent 100m 1000m 256Mi 1Gi
helm-agent 100m 1000m 256Mi 1Gi
cilium-policy-agent 100m 1000m 256Mi 1Gi
cilium-manager-agent 100m 1000m 256Mi 1Gi
cilium-debug-agent 100m 1000m 256Mi 1Gi