Implantar o Solo Enterprise para kagent na implementação de referência somente de software do Distributed Cloud

O Solo Enterprise para kagent permite que os administradores de plataforma implantem e gerenciem agentes de IA no Google Distributed Cloud (GDC) somente software (GDC-SO). Nesta implementação de referência, você vai espelhar imagens de contêiner e gráficos do Helm em um registro particular do Harbor, implantar o plano de controle do kagent, UI e o Solo Enterprise para o agentgateway e analisar as diretrizes de dimensionamento do cluster. Para mais informações sobre a arquitetura, consulte Arquitetura de referência para usar seu próprio servidor MCP no kagent.

Pré-requisitos

Antes de começar, verifique se você tem acesso a uma estação de trabalho Linux com Chrome, Docker, crane, kubectl, Helm, envsubst e a CLI gdcloud. Verifique se os seguintes componentes estão configurados para o ambiente do GDC-SO:

Componente Detalhe ou requisito Valor de exemplo
Projeto doGoogle Cloud para o GDC-SO Projeto associado ao cluster do GDC-SO kagent-enterprise
Cluster Cluster de destino do GDC-SO user-project-8a210897
Credenciais do Kubernetes (gateway do Connect) Conexão com o cluster gcloud container fleet memberships get-credentials user-project-8a210897
Registro particular URL do registro do Harbor solo-kagent-enterprise.org-1.zone1.google.gdch.test
Repositório do projeto Caminho do repositório do projeto solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise
Secret de pull Nome do secret de pull do Docker solo-harbor-pull-secret

As instruções a seguir se aplicam ao Solo Enterprise para kagent versão 0.4.0 e mais recentes.

Essa implantação foi validada na versão 1.31.5-gke.300 do GDC-SO.

Implantar em um cluster do GDC-SO

Crie um arquivo .env com base na configuração do cluster e do 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"

Substitua:

  • SOLO_LICENSE_KEY: sua chave de licença do Solo Enterprise
  • ORG: o nome da organização do GDC
  • ZONE: o nome da zona do GDC.

Criar os arquivos de valores do Helm

Crie os arquivos de valores do Helm para os três gráficos. Não é necessário modificar nenhum valor, a menos que você queira personalizar a instalação. É possível configurar outros modelos e agentes mais tarde na UI do kagent.

Crie o arquivo 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

Crie o arquivo 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

Crie o arquivo 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

Configure o ambiente

No mesmo diretório que os arquivos .env e de valores do Helm, carregue as variáveis de ambiente e renderize os modelos de valores do Helm. Execute os comandos restantes neste guia na mesma sessão do shell para que essas variáveis permaneçam definidas:

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"

Espelhar imagens e gráficos do registro público

Autentique o Docker e o Helm no seu registro particular do Harbor e espelhe os gráficos do Helm e as imagens de contêiner do 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

Criar um namespace no cluster do GDC-SO

Crie o namespace de destino no cluster:

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

Criar e aplicar um secret de pull do Docker ao cluster

Crie o secret de extração do registro do Docker no 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"

Substitua:

  • REGISTRY_USERNAME: seu nome de usuário do registro do Harbor.
  • REGISTRY_PASSWORD: a senha do registro do Harbor.

Instalar o kagent

Instale os gráficos de CRD e os gráficos do Helm do Solo Enterprise para 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"

Validar a implantação

Verifique se os pods estão em execução no namespace:

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

O resultado será o seguinte:

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

Encaminhe uma porta local para o serviço solo-enterprise-ui:

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

No navegador, acesse http://localhost:9090 para abrir a UI do Solo Enterprise para kagent e configurar seus modelos e agentes:

Solo Enterprise para o painel da UI do kagent.

Considerações sobre desempenho e dimensionamento de implantação

As seções a seguir descrevem como o consumo de recursos do componente é escalonado e fornecem o armazenamento de referência e o dimensionamento de recursos para uma implantação de cluster único.

Características do escalonamento

O consumo de recursos muda qualitativamente à medida que o número de agentes e a carga de solicitações por agente aumentam em uma instalação de cluster único (os gráficos management e kagent-enterprise sem uma retransmissão). Use essas características para identificar quais componentes são sensíveis a dimensões de escalonamento específicas antes de ajustar as alocações de recursos ou planejar a capacidade.

Fatos arquitetônicos importantes que regem o escalonamento

  • O tráfego do agente para o LLM é direto. Os agentes chamam endpoints de modelos de linguagem grandes (LLM), como um serviço de modelo no cluster, diretamente. Esse tráfego não passa pelo controlador ou por qualquer outro componente do plano de gerenciamento. Adicionar agentes ou aumentar as taxas de solicitação não aumenta a carga relacionada ao LLM em nenhum componente compartilhado.
  • Os servidores MCP estão no caminho crítico da execução de ferramentas do agente. Quando um agente invoca uma ferramenta apoiada por um servidor do Protocolo de Contexto de Modelo (MCP), a chamada é síncrona e bloqueadora. A latência e a capacidade de processamento do servidor MCP afetam diretamente a latência da solicitação do agente. Cada recurso MCPServer implantado é uma implantação separada com o próprio envelope de recurso.
  • A telemetria é a principal superfície de escalonamento. Métricas, traces e snapshots de objetos do Kubernetes fluem pelo pipeline de telemetria para o ClickHouse. Esse pipeline cresce com o número de agentes e o volume de solicitações e é a parte do sistema mais sensível aos recursos.
  • O servidor de túnel está presente, mas não transporta tráfego significativo em uma instalação de cluster único. O contêiner tunnel-server é executado no pod da UI, mas não tem clientes para atender e não contribui para a pressão de escalonamento.

Comportamento de escalonamento de componentes

As seções a seguir descrevem como os componentes individuais são escalonados com a contagem de agentes e a carga de solicitações.

kagent-controller
  • Cresce de forma sublinear com a contagem de agentes: cada agente mantém uma conexão de stream de agente para agente (A2A).
  • Não é sensível ao volume de solicitações porque as chamadas de LLM e as execuções de ferramentas ignoram o controlador.
  • Oferece suporte ao escalonamento horizontal para distribuir a carga de conexão e avaliação de políticas.
Controlador empresarial do KMCP

O controlador empresarial do KMCP é orientado por eventos apenas em mudanças de recursos do MCPServer e não é sensível à contagem de agentes ou ao volume de solicitações.

Servidores MCP
  • Implanta uma implantação por recurso personalizado (CR) MCPServer. O tamanho da frota aumenta com o número de recursos MCPServer implantados.
  • É executado no caminho de acesso síncrono da execução da ferramenta do agente. A latência e a capacidade de processamento afetam diretamente os agentes.
  • Escala com a taxa total de chamadas de ferramentas em todos os consumidores quando servidores compartilhados são chamados por muitos agentes simultaneamente.
  • Executa servidores integrados (grafana-mcp, querydoc) como uma única réplica por padrão. Aumente as réplicas ou os limites para uso compartilhado intenso.
  • Usa imagens definidas pelo usuário, solicitações de recursos e limites de recursos para servidores MCP implantados pelo usuário.
Coletor de telemetria
  • É escalonado linearmente com o volume de solicitações: cada solicitação emite métricas e, opcionalmente, traces.
  • É o componente com maior probabilidade de ficar com recursos limitados sob alta carga de agentes.
  • Serve como o gateway do protocolo OpenTelemetry (OTLP) (receptores nas portas 4316-4318) para clusters remotos em uma instalação de vários clusters. Não há um pod de gateway separado.
  • Usa o arquivo secundário k8sobjects, que é escalonado com o tamanho do inventário do Kubernetes, em vez da taxa de solicitação.
ClickHouse

O ClickHouse é o principal gargalo de recursos sob carga contínua. O armazenamento, a memória e a CPU aumentam com os seguintes fatores:

  • Contagem de agentes: cada tipo de agente adicional aumenta a cardinalidade da métrica (combinações de rótulos exclusivos).
  • Volume de solicitações: cada solicitação produz pontos de dados de métricas e períodos de trace que são gravados e indexados.
  • Tamanho do inventário do Kubernetes: os snapshots do k8sobjects são armazenados periodicamente, independentemente da carga de solicitações.

A capacidade de gravação é o ponto de pressão inicial. O desempenho da consulta (usado pelo back-end da UI) diminui à medida que o volume de dados aumenta sem ajuste de esquema ou retenção. A configuração padrão é voltada para uma implantação moderada de nó único. Cargas mais pesadas podem exigir o aumento de replicasPerShard ou shards ou o ajuste dos TTLs de retenção.

Back-end da UI
  • Não tem estado e é vinculado a consultas. Ele é escalonado com o volume de dados no ClickHouse, em vez da capacidade de processamento de solicitações em tempo real.
  • Aumenta o custo das consultas de trace e do gráfico de frota à medida que o número de agentes e os dados históricos aumentam.
Agentes
  • Agentes baseados em Python:
    • Cada agente é uma implantação independente. Adicionar agentes é puramente aditivo, sem penalidade de estado compartilhado.
    • O consumo de recursos por agente é escalonado de acordo com a simultaneidade de solicitações e a profundidade da cadeia de ferramentas.
  • Agentes baseados em Go:
    • Usa aproximadamente 36 vezes menos memória inativa (7 MB em comparação com 253 MB por agente em repouso).
    • Usa uma imagem de contêiner aproximadamente 11 vezes menor (29,7 MB em comparação com 335,4 MB).
    • Inicia aproximadamente 6,7 vezes mais rápido (2,7 segundos em comparação com 18,2 segundos).

Resumo das características de escalonamento

A tabela a seguir resume como cada componente é escalonado com a contagem de agentes e a carga de solicitações:

Componente Sensível à contagem de agentes Sensível à carga de solicitações Observações
Controlador Moderado Baixo Mantém streams A2A por agente; não é afetado pela taxa de chamadas de LLM
Scaler Nenhum Nenhum Orientado a eventos, efetivamente estático
Controlador empresarial do KMCP Nenhum Nenhum Reage apenas a mudanças de recursos do MCPServer
Servidores MCP Alta Alta Uma implantação por CR MCPServer; no caminho de acesso rápido da execução da ferramenta
Coletor de telemetria Alta Alta Superfície de escalonamento principal; linear com volume de solicitações
ClickHouse Alta Alta Principal gargalo, impulsionado pela cardinalidade e pela taxa de gravação
Back-end da UI Baixo Baixo Vinculado à consulta; afetado pelo volume de dados históricos
Agentes (Python e Go) Não relevante Alta Implantações independentes; escalonamento com simultaneidade

Dimensionamento do armazenamento

A tabela a seguir fornece recomendações iniciais para os tamanhos de volume de armazenamento:

  • O armazenamento do PostgreSQL (estado do kagent, incluindo gerenciamento de sessão, memória e ciclo de vida) é escalonado linearmente à medida que o número de sessões de chat aumenta.
  • O armazenamento do ClickHouse (rastreamento) também é escalonado linearmente à medida que o número de sessões de chat exclusivas aumenta.
Componente Volume inicial recomendado
PostgreSQL 50 GiB
ClickHouse 50 GiB

Dimensionamento da implantação

As seções a seguir listam as solicitações e os limites padrão de recursos de CPU, memória e armazenamento para os gráficos do Helm.

Gráfico de gerenciamento

O gráfico management implanta o pod solo-enterprise-ui, um coletor de telemetria independente e o ClickHouse.

solo-enterprise-ui contêineres de pod

A tabela a seguir lista as solicitações de recurso e os limites padrão para os contêineres de pod solo-enterprise-ui:

Contêiner Ativado Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
ui-backend Sempre 250 m 500 m 512Mi 1024Mi
ui-frontend Sempre 250 m 500 m 512Mi 1024Mi
k8sobjects-collector telemetry.k8sobjects.enabled 100min 300 m 384Mi 768Mi
idp autoAuth ativado 100min 250 m 256 Mi 512Mi
Coletor de telemetria (StatefulSet ou implantação)

A tabela a seguir lista as solicitações e os limites de recursos padrão para o coletor de telemetria:

Componente Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
telemetry-collector 200 m 1.000 m 512Mi 2Gi

O gateway de telemetria (coletor do OpenTelemetry) também define os próprios recursos separadamente:

Componente Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
telemetry-gateway 100min 500 m 300Mi 1024Mi
Subgráfico do ClickHouse

A tabela a seguir lista as solicitações de recursos padrão e os limites para o subgráfico do ClickHouse, com base na predefinição 2xlarge do Bitnami e configurados usando os valores replicasPerShard e shards:

Componente Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória Armazenamento temporário
clickhouse 1.000 m (1 núcleo) 6000m (6 núcleos) 3072Mi (3 GiB) 12288Mi (12 GiB) 50 Mi

gráfico kagent-enterprise

O gráfico kagent-enterprise implanta o controlador principal, o subgráfico kmcp-enterprise, os servidores de ferramentas MCP integrados e os agentes opcionais.

Principais componentes

A tabela a seguir lista as solicitações e os limites de recursos padrão para o controlador principal:

Componente Ativado Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
controller Sempre 100min 2000m (2 núcleos) 128Mi 512Mi
Subgráfico kmcp-enterprise

A tabela a seguir lista as solicitações de recurso e os limites padrão para o controlador kmcp-enterprise:

Componente Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
kmcp-enterprise-controller 100min 500 m 128Mi 512Mi
Ferramentas integradas

A tabela a seguir lista as solicitações de recurso e os limites padrão para os servidores de ferramentas integrados:

Componente Ativado Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
kagent-tools kagent-tools.enabled 100min 1.000 m 256 Mi 1Gi
grafana-mcp grafana-mcp.enabled 100min 500 m 128Mi 512Mi
querydoc querydoc.enabled 100min 500 m 128Mi 512Mi
Agentes

Todos os agentes compartilham o mesmo perfil de recurso padrão. Cada agente é desativado por padrão e ativado individualmente:

Agente Solicitação de CPU Limite de CPU Solicitação de memória Limite de memória
k8s-agent 100min 1.000 m 256 Mi 1Gi
kgateway-agent 100min 1.000 m 256 Mi 1Gi
istio-agent 100min 1.000 m 256 Mi 1Gi
promql-agent 100min 1.000 m 256 Mi 1Gi
observability-agent 100min 1.000 m 256 Mi 1Gi
argo-rollouts-agent 100min 1.000 m 256 Mi 1Gi
helm-agent 100min 1.000 m 256 Mi 1Gi
cilium-policy-agent 100min 1.000 m 256 Mi 1Gi
cilium-manager-agent 100min 1.000 m 256 Mi 1Gi
cilium-debug-agent 100min 1.000 m 256 Mi 1Gi