Implementa Solo Enterprise para kagent en la implementación de referencia de solo software de Distributed Cloud

Solo Enterprise para kagent permite que los administradores de plataformas implementen y administren agentes de IA en Google Distributed Cloud (GDC) solo software (GDC-SO). En esta implementación de referencia, duplicarás imágenes de contenedor y gráficos de Helm en un registro privado de Harbor, implementarás el plano de control de kagent, la IU y Solo Enterprise para agentgateway, y revisarás los lineamientos de dimensionamiento de clústeres. Para obtener más información sobre la arquitectura, consulta Arquitectura de referencia para usar tu propio servidor de MCP en kagent.

Requisitos previos

Antes de comenzar, asegúrate de tener acceso a una estación de trabajo de Linux con Chrome, Docker, crane, kubectl, Helm, envsubst y la CLI de gdcloud. Asegúrate de que los siguientes componentes estén configurados para tu entorno de GDC-SO:

Componente Detalle o requisito Valor de ejemplo
Proyecto deGoogle Cloud para GDC-SO Proyecto asociado con el clúster de GDC-SO kagent-enterprise
Clúster Clúster de GDC-SO de destino user-project-8a210897
Credenciales de Kubernetes (puerta de enlace de Connect) Conexión al clúster gcloud container fleet memberships get-credentials user-project-8a210897
Registro privado URL del registro de Harbor solo-kagent-enterprise.org-1.zone1.google.gdch.test
Repositorio del proyecto Ruta del repositorio del proyecto solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise
Secreto de extracción Nombre del secreto de extracción de Docker solo-harbor-pull-secret

Las siguientes instrucciones se aplican a Solo Enterprise para la versión 0.4.0 y posteriores de kagent.

Esta implementación se validó en la versión 1.31.5-gke.300 de GDC-SO.

Implementa en un clúster de GDC-SO

Crea un archivo .env según la configuración del clúster y del registro:

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"

Reemplaza lo siguiente:

  • SOLO_LICENSE_KEY: tu clave de licencia de Solo Enterprise
  • ORG: Es el nombre de tu organización de GDC.
  • ZONE: el nombre de tu zona de GDC

Crea los archivos de valores de Helm

Crea los archivos de valores de Helm para los tres gráficos. No es necesario que modifiques ningún valor, a menos que quieras personalizar la instalación. Puedes configurar modelos y agentes adicionales más adelante en la IU de kagent.

Crea el archivo 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 el archivo 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 el archivo 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 el entorno

En el mismo directorio que tus archivos .env y de valores de Helm, carga las variables de entorno y renderiza las plantillas de valores de Helm. Ejecuta los comandos restantes de esta guía en la misma sesión de shell para que estas variables sigan configuradas:

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"

Duplica imágenes y gráficos del registro público

Autentica Docker y Helm en tu registro privado de Harbor y, luego, duplica los gráficos de Helm y las imágenes de contenedor del registro público:

# 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 un espacio de nombres en el clúster de GDC-SO

Crea el espacio de nombres de destino en tu clúster:

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

Crea y aplica un secreto de extracción de Docker al clúster

Crea el Secret de extracción del registro de Docker en tu clúster:

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"

Reemplaza lo siguiente:

  • REGISTRY_USERNAME: Es tu nombre de usuario del registro de Harbor.
  • REGISTRY_PASSWORD: Es la contraseña de tu registro de Harbor.

Instala kagent

Instala los gráficos de CRD y los gráficos de Solo Enterprise para kagent de Helm:

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

Valida la implementación

Verifica que los Pods se estén ejecutando en tu espacio de nombres:

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

El resultado es similar a lo siguiente:

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

Redirecciona un puerto local al Service solo-enterprise-ui:

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

En el navegador, ve a http://localhost:9090 para abrir la IU de Solo Enterprise para kagent y configurar tus modelos y agentes:

Solo Enterprise para el panel de la IU de kagent.

Consideraciones de rendimiento y tamaño de la implementación

En las siguientes secciones, se describe cómo escala el consumo de recursos de los componentes y se proporciona un tamaño de almacenamiento y recursos de referencia para una implementación de un solo clúster.

Características del escalamiento

El consumo de recursos cambia de forma cualitativa a medida que aumenta la cantidad de agentes y la carga de solicitudes por agente en una instalación de un solo clúster (los gráficos management y kagent-enterprise sin un retransmisor). Usa estas características para identificar qué componentes son sensibles a dimensiones de escalamiento específicas antes de ajustar las asignaciones de recursos o planificar la capacidad.

Datos arquitectónicos clave que rigen el escalamiento

  • El tráfico del agente al LLM es directo. Los agentes llaman directamente a los extremos de modelos de lenguaje grandes (LLM), como un servicio de modelos en el clúster. Este tráfico no pasa por el controlador ni por ningún otro componente del plano de administración. Agregar agentes o aumentar los porcentajes de solicitudes no aumenta la carga relacionada con el LLM en ningún componente compartido.
  • Los servidores de MCP se encuentran en la ruta de acceso activa de la ejecución de herramientas de agentes. Cuando un agente invoca una herramienta respaldada por un servidor de Protocolo de contexto del modelo (MCP), la llamada es síncrona y bloqueante. La latencia y la capacidad de procesamiento del servidor de MCP afectan directamente la latencia de las solicitudes de los agentes. Cada recurso MCPServer implementado es un Deployment independiente con su propio sobre de recursos.
  • La telemetría es la superficie de escalamiento principal. Las métricas, los seguimientos y las instantáneas de objetos de Kubernetes fluyen a través de la canalización de telemetría hacia ClickHouse. Esta canalización crece con el recuento de agentes y el volumen de solicitudes, y es la parte del sistema que más recursos consume.
  • El servidor de túnel está presente, pero no transporta tráfico significativo en una instalación de un solo clúster. El contenedor tunnel-server se ejecuta en el Pod de la IU, pero no tiene clientes a los que entregar contenido y no contribuye a la presión de escalamiento.

Comportamiento del escalamiento de componentes

En las siguientes secciones, se describe cómo se escalan los componentes individuales con el recuento de agentes y la carga de solicitudes.

kagent-controller
  • Crece de forma sublineal con el recuento de agentes: cada agente mantiene una conexión de transmisión de agente a agente (A2A).
  • No es sensible al volumen de solicitudes porque las llamadas de LLM y las ejecuciones de herramientas omiten el controlador.
  • Admite el escalamiento horizontal para distribuir la carga de evaluación de conexiones y políticas.
Controlador empresarial de KMCP

El controlador empresarial de KMCP se basa en eventos solo en los cambios de recursos de MCPServer y no es sensible al recuento de agentes ni al volumen de solicitudes.

Servidores de MCP
  • Implementa un Deployment por recurso personalizado (CR) de MCPServer; el tamaño de la flota crece con la cantidad de recursos de MCPServer implementados.
  • Se ejecuta en la ruta de acceso activa síncrona de la ejecución de la herramienta del agente; la latencia y la capacidad de procesamiento afectan directamente a los agentes.
  • Se escala con la tasa total de llamadas a herramientas en todos los consumidores cuando muchos agentes llaman a los servidores compartidos de forma simultánea.
  • Ejecuta servidores integrados (grafana-mcp, querydoc) como una sola réplica de forma predeterminada. Aumenta las réplicas o los límites para el uso compartido intensivo.
  • Usa imágenes definidas por el usuario, solicitudes de recursos y límites de recursos para los servidores de MCP implementados por el usuario.
Recopilador de telemetría
  • Escala de forma lineal con el volumen de solicitudes: cada solicitud emite métricas y, de manera opcional, seguimientos.
  • Es el componente que tiene más probabilidades de quedarse sin recursos con una carga alta de agentes.
  • Funciona como la puerta de enlace del protocolo de OpenTelemetry (OTLP) (receptores en los puertos 4316-4318) para clústeres remotos en una instalación de varios clústeres; no existe un Pod de puerta de enlace independiente.
  • Usa el archivo adicional k8sobjects, que escala con el tamaño del inventario de Kubernetes, en lugar del porcentaje de solicitudes.
ClickHouse

ClickHouse es el cuello de botella de recursos principal con una carga sostenida. El almacenamiento, la memoria y la CPU aumentan con los siguientes factores:

  • Recuento de agentes: Cada tipo de agente adicional aumenta la cardinalidad de la métrica (combinaciones de etiquetas únicas).
  • Volumen de solicitudes: Cada solicitud produce puntos de datos de métricas y intervalos de seguimiento que se escriben y se indexan.
  • Tamaño del inventario de Kubernetes: Las instantáneas de k8sobjects se almacenan de forma periódica, independientemente de la carga de solicitudes.

La capacidad de procesamiento de escritura es el punto de presión inicial; el rendimiento de las consultas (que usa el backend de la IU) se degrada a medida que aumenta el volumen de datos sin ajustar el esquema ni la retención. La configuración predeterminada se orienta a una implementación moderada de un solo nodo. Las cargas más pesadas pueden requerir un aumento de replicasPerShard o shards, o un ajuste de los TTL de retención.

Backend de la IU
  • No tiene estado y está vinculado a las consultas; escala con el volumen de datos en ClickHouse, en lugar de con la capacidad de procesamiento de solicitudes en tiempo real.
  • Aumenta el costo de las consultas de grafos y seguimientos de la flota a medida que aumentan el recuento de agentes y los datos históricos.
Agentes
  • Agentes basados en Python:
    • Cada agente es un Deployment independiente. Agregar agentes es puramente aditivo, sin penalización por estado compartido.
    • El consumo de recursos por agente escala con la simultaneidad de solicitudes y la profundidad de la cadena de herramientas.
  • Agentes basados en Go:
    • Usa aproximadamente 36 veces menos memoria inactiva (7 MB en comparación con 253 MB por agente en reposo).
    • Usa una imagen de contenedor aproximadamente 11 veces más pequeña (29.7 MB en comparación con 335.4 MB).
    • Se inicia aproximadamente 6.7 veces más rápido (2.7 segundos en comparación con 18.2 segundos).

Resumen de las características de escalamiento

En la siguiente tabla, se resume cómo escala cada componente con el recuento de agentes y la carga de solicitudes:

Componente Sensible al recuento de agentes Sensible a la carga de solicitudes Notas
Controlador Moderado Baja Mantiene las transmisiones de A2A por agente; no se ve afectada por la tasa de llamadas de LLM
Escalador Ninguno Ninguno Basado en eventos, estático de manera eficaz
Controlador empresarial de KMCP Ninguno Ninguno Solo reacciona a los cambios de recursos de MCPServer
Servidores de MCP Alta Alta Una implementación por CR de MCPServer; en la ruta activa de la ejecución de herramientas
Recopilador de telemetría Alta Alta Superficie de escalamiento principal; lineal con el volumen de solicitudes
ClickHouse Alta Alta Cuello de botella principal; impulsado por la cardinalidad y la tasa de escritura
Backend de la IU Baja Baja Vinculado a las consultas; se ve afectado por el volumen de datos históricos
Agentes (Python y Go) No aplicable Alta Implementaciones independientes; escalamiento con simultaneidad

Dimensionamiento del almacenamiento

En la siguiente tabla, se proporcionan recomendaciones iniciales para los tamaños de los volúmenes de almacenamiento:

  • El almacenamiento de PostgreSQL (estado de kagent, incluida la administración de sesiones, memoria y ciclo de vida) escala de forma lineal a medida que aumenta la cantidad de sesiones de chat.
  • El almacenamiento de ClickHouse (seguimiento) también escala de forma lineal a medida que aumenta la cantidad de sesiones de chat únicas.
Componente Volumen inicial recomendado
PostgreSQL 50 GiB
ClickHouse 50 GiB

Dimensionamiento de la Deployment

En las siguientes secciones, se enumeran las solicitudes y los límites predeterminados de recursos de CPU, memoria y almacenamiento para los gráficos de Helm.

Gráfico de administración

El gráfico de management implementa el Pod de solo-enterprise-ui, un recopilador de telemetría independiente y ClickHouse.

solo-enterprise-ui contenedores de Pods

En la siguiente tabla, se enumeran las solicitudes y los límites de recursos predeterminados para los contenedores de Pods de solo-enterprise-ui:

Contenedor Habilitado Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
ui-backend Siempre 250 m 500m 512Mi 1024Mi
ui-frontend Siempre 250 m 500m 512Mi 1024Mi
k8sobjects-collector telemetry.k8sobjects.enabled 100 min 300m 384Mi 768Mi
idp autoAuth habilitado 100 min 250 m 256 Mi 512Mi
Recopilador de telemetría (StatefulSet o Deployment)

En la siguiente tabla, se enumeran las solicitudes y los límites de recursos predeterminados para el recopilador de telemetría:

Componente Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
telemetry-collector 200 m 1,000 m 512Mi 2Gi

La puerta de enlace de telemetría (recopilador de OpenTelemetry) también define sus propios recursos por separado:

Componente Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
telemetry-gateway 100 min 500m 300Mi 1024Mi
Subgráfico de ClickHouse

En la siguiente tabla, se enumeran las solicitudes y los límites de recursos predeterminados para el subgráfico de ClickHouse, según el ajuste predeterminado de Bitnami 2xlarge y configurado con los valores replicasPerShard y shards:

Componente Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria Almacenamiento efímero
clickhouse 1,000 m (1 núcleo) 6,000 m (6 núcleos) 3072Mi (3 GiB) 12288Mi (12 GiB) 50Mi

Gráfico kagent-enterprise

El gráfico kagent-enterprise implementa el controlador principal, el subgráfico kmcp-enterprise, los servidores de herramientas de MCP integrados y los agentes opcionales.

Componentes centrales

En la siguiente tabla, se enumeran las solicitudes y los límites de recursos predeterminados para el controlador principal:

Componente Habilitado Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
controller Siempre 100 min 2000m (2 núcleos) 128Mi 512Mi
Subgráfico de kmcp-enterprise

En la siguiente tabla, se enumeran las solicitudes y los límites de recursos predeterminados para el controlador de kmcp-enterprise:

Componente Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
kmcp-enterprise-controller 100 min 500m 128Mi 512Mi
Herramientas integradas

En la siguiente tabla, se enumeran las solicitudes de recursos y los límites predeterminados para los servidores de herramientas integrados:

Componente Habilitado Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
kagent-tools kagent-tools.enabled 100 min 1,000 m 256 Mi 1Gi
grafana-mcp grafana-mcp.enabled 100 min 500m 128Mi 512Mi
querydoc querydoc.enabled 100 min 500m 128Mi 512Mi
Agentes

Todos los agentes comparten el mismo perfil de recursos predeterminado. Cada agente está inhabilitado de forma predeterminada y se habilita de forma individual:

Agente Solicitud de CPU Límite de CPU Solicitud de memoria Límite de memoria
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