Men-deploy Solo Enterprise untuk kagent di implementasi referensi khusus software Distributed Cloud

Solo Enterprise untuk kagent memungkinkan administrator platform men-deploy dan mengelola agen AI di software Google Distributed Cloud (GDC) saja (GDC-SO). Dalam implementasi referensi ini, Anda akan menduplikasi image container dan diagram Helm ke registry Harbor pribadi, men-deploy bidang kontrol kagent, UI, dan Solo Enterprise untuk agentgateway, serta meninjau panduan ukuran cluster. Untuk mengetahui informasi selengkapnya tentang arsitektur, lihat Arsitektur referensi membawa server MCP Anda sendiri ke kagent.

Prasyarat

Sebelum memulai, pastikan Anda memiliki akses ke workstation Linux dengan Chrome, Docker, crane, kubectl, Helm, envsubst, dan gdcloud CLI. Pastikan komponen berikut dikonfigurasi untuk lingkungan GDC-SO Anda:

Komponen Detail atau persyaratan Nilai contoh
ProjectGoogle Cloud untuk GDC-SO Project yang terkait dengan cluster GDC-SO kagent-enterprise
Cluster Cluster GDC-SO target user-project-8a210897
Kredensial Kubernetes (Connect Gateway) Koneksi ke cluster gcloud container fleet memberships get-credentials user-project-8a210897
Registry pribadi URL registry Harbor solo-kagent-enterprise.org-1.zone1.google.gdch.test
Repositori project Jalur repositori project solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise
Secret pull Nama secret pull Docker solo-harbor-pull-secret

Petunjuk berikut berlaku untuk Solo Enterprise untuk kagent versi 0.4.0 dan yang lebih baru.

Deployment ini divalidasi di GDC-SO versi 1.31.5-gke.300.

Men-deploy di cluster GDC-SO

Buat file .env berdasarkan konfigurasi cluster dan registry Anda:

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"

Ganti kode berikut:

  • SOLO_LICENSE_KEY: kunci lisensi Solo Enterprise Anda
  • ORG: nama organisasi GDC Anda
  • ZONE: nama zona GDC Anda

Membuat file nilai Helm

Buat file nilai Helm untuk ketiga diagram. Anda tidak perlu mengubah nilai apa pun kecuali jika ingin menyesuaikan penginstalan. Anda dapat mengonfigurasi model dan agen tambahan nanti di UI kagent.

Buat 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

Buat 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

Buat 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

Menyiapkan lingkungan

Dalam direktori yang sama dengan file nilai Helm dan .env Anda, muat variabel lingkungan dan render template nilai Helm. Jalankan perintah yang tersisa dalam panduan ini di sesi shell yang sama agar variabel ini tetap ditetapkan:

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"

Mencerminkan image dan diagram dari registry publik

Autentikasi Docker dan Helm ke registry Harbor pribadi Anda, lalu duplikasi chart Helm dan image container dari registry publik:

# 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

Membuat namespace di cluster GDC-SO

Buat namespace target di cluster Anda:

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

Membuat dan menerapkan secret pull Docker ke cluster

Buat secret pull registry Docker di cluster Anda:

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"

Ganti kode berikut:

  • REGISTRY_USERNAME: nama pengguna registry Harbor Anda
  • REGISTRY_PASSWORD: sandi registry Harbor Anda

Menginstal kagent

Instal diagram CRD dan Solo Enterprise untuk diagram Helm 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"

Memvalidasi deployment

Pastikan pod berjalan di namespace Anda:

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

Outputnya mirip dengan hal berikut ini:

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

Teruskan port lokal ke layanan solo-enterprise-ui:

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

Di browser, buka http://localhost:9090 untuk membuka UI Solo Enterprise for kagent, lalu konfigurasikan model dan agen Anda:

Solo Enterprise untuk dasbor UI kagent.

Pertimbangan performa dan ukuran deployment

Bagian berikut menjelaskan cara penskalaan konsumsi resource komponen dan memberikan ukuran penyimpanan dan resource dasar untuk deployment cluster tunggal.

Karakteristik penskalaan

Konsumsi resource berubah secara kualitatif seiring dengan meningkatnya jumlah agen dan beban permintaan per agen dalam penginstalan cluster tunggal (diagram management dan kagent-enterprise tanpa relai). Gunakan karakteristik ini untuk mengidentifikasi komponen mana yang sensitif terhadap dimensi penskalaan tertentu sebelum Anda menyesuaikan alokasi resource atau merencanakan kapasitas.

Fakta arsitektur utama yang mengatur penskalaan

  • Traffic agen ke LLM bersifat langsung. Agen memanggil endpoint model bahasa besar (LLM) (seperti layanan model dalam cluster) secara langsung. Traffic ini tidak melewati pengontrol atau komponen bidang pengelolaan lainnya. Menambahkan agen atau meningkatkan rasio permintaan tidak akan meningkatkan beban terkait LLM pada komponen bersama apa pun.
  • Server MCP berada di jalur utama eksekusi alat agen. Saat agen memanggil alat yang didukung oleh server Model Context Protocol (MCP), panggilan tersebut bersifat sinkron dan memblokir. Latensi dan throughput server MCP secara langsung memengaruhi latensi permintaan agen. Setiap resource MCPServer yang di-deploy adalah Deployment terpisah dengan amplop resource-nya sendiri.
  • Telemetri adalah platform penskalaan utama. Metrik, trace, dan snapshot objek Kubernetes semuanya mengalir melalui pipeline telemetri ke ClickHouse. Pipeline ini berkembang seiring dengan jumlah agen dan volume permintaan, serta merupakan bagian sistem yang paling sensitif terhadap resource.
  • Server tunnel ada, tetapi tidak membawa traffic yang berarti dalam penginstalan cluster tunggal. Container tunnel-server berjalan di pod UI, tetapi tidak memiliki klien untuk dilayani dan tidak berkontribusi pada tekanan penskalaan.

Perilaku penskalaan komponen

Bagian berikut menjelaskan cara setiap komponen diskalakan dengan jumlah agen dan beban permintaan.

kagent-controller
  • Tumbuh secara sublinear dengan jumlah agen—setiap agen memiliki koneksi streaming agent-to-agent (A2A).
  • Tidak sensitif terhadap volume permintaan karena panggilan LLM dan eksekusi alat melewati pengontrol.
  • Mendukung penskalaan horizontal untuk mendistribusikan beban koneksi dan evaluasi kebijakan.
Pengontrol perusahaan KMCP

Pengontrol perusahaan KMCP berbasis peristiwa hanya pada perubahan resource MCPServer dan tidak sensitif terhadap jumlah agen atau volume permintaan.

Server MCP
  • Men-deploy satu Deployment per resource kustom (CR) MCPServer; ukuran fleet bertambah seiring dengan jumlah resource MCPServer yang di-deploy.
  • Berjalan di hot path sinkron eksekusi alat agen—latensi dan throughput secara langsung memengaruhi agen.
  • Menskalakan dengan total rasio panggilan alat di semua konsumen saat server bersama dipanggil oleh banyak agen secara bersamaan.
  • Menjalankan server bawaan (grafana-mcp, querydoc) sebagai satu replika secara default; tingkatkan replika atau batas untuk penggunaan yang sangat banyak.
  • Menggunakan image, permintaan resource, dan batas resource yang ditentukan pengguna untuk server MCP yang di-deploy pengguna.
Kolektor telemetri
  • Menskalakan secara linear dengan volume permintaan—setiap permintaan memunculkan metrik dan, secara opsional, trace.
  • Merupakan komponen yang paling mungkin mengalami keterbatasan resource saat beban agen tinggi.
  • Berfungsi sebagai gateway OpenTelemetry Protocol (OTLP) (penerima di port 4316-4318) untuk cluster jarak jauh dalam penginstalan multi-cluster; tidak ada pod gateway terpisah.
  • Menggunakan sidecar k8sobjects, yang diskalakan dengan ukuran inventaris Kubernetes, bukan rasio permintaan.
ClickHouse

ClickHouse adalah bottleneck resource utama dalam beban berkelanjutan. Penyimpanan, memori, dan CPU semuanya bertambah seiring dengan faktor-faktor berikut:

  • Jumlah agen: Setiap jenis agen tambahan meningkatkan kardinalitas metrik (kombinasi label unik).
  • Volume permintaan: Setiap permintaan menghasilkan titik data metrik dan span trace yang ditulis dan diindeks.
  • Ukuran inventaris Kubernetes: Snapshot k8sobjects disimpan secara berkala, terlepas dari beban permintaan.

Throughput tulis adalah titik tekanan awal; performa kueri (yang digunakan oleh backend UI) menurun seiring bertambahnya volume data tanpa penyesuaian skema atau retensi. Konfigurasi default menargetkan deployment node tunggal sedang; beban yang lebih berat mungkin memerlukan peningkatan replicasPerShard atau shards, atau penyesuaian TTL retensi.

Backend UI
  • Bersifat stateless dan terikat kueri; diskalakan dengan volume data di ClickHouse, bukan throughput permintaan real-time.
  • Meningkatkan biaya kueri trace dan grafik fleet seiring bertambahnya jumlah agen dan data historis.
Agen
  • Agen berbasis Python:
    • Setiap agen adalah Deployment independen—penambahan agen murni bersifat tambahan tanpa penalti status bersama.
    • Konsumsi resource per agen diskalakan dengan konkurensi permintaan dan kedalaman rantai alat.
  • Agen berbasis Go:
    • Menggunakan memori tidak ada aktivitas sekitar 36 kali lebih sedikit (7 MB versus 253 MB per agen saat tidak ada aktivitas).
    • Menggunakan image container yang kira-kira 11 kali lebih kecil (29,7 MB versus 335,4 MB).
    • Mulai sekitar 6,7 kali lebih cepat (2,7 detik dibandingkan dengan 18,2 detik).

Ringkasan karakteristik penskalaan

Tabel berikut merangkum cara setiap komponen diskalakan dengan jumlah agen dan beban permintaan:

Komponen Sensitif terhadap jumlah agen Sensitif terhadap beban permintaan Catatan
Pengontrol Sedang Rendah Mempertahankan streaming A2A per agen; tidak terpengaruh oleh tingkat panggilan LLM
Scaler Tidak ada Tidak ada Berbasis peristiwa, statis secara efektif
Pengontrol perusahaan KMCP Tidak ada Tidak ada Hanya bereaksi terhadap perubahan resource MCPServer
Server MCP Tinggi Tinggi Satu Deployment per CR MCPServer; di jalur panas eksekusi alat
Kolektor telemetri Tinggi Tinggi Platform penskalaan utama; linear dengan volume permintaan
ClickHouse Tinggi Tinggi Bottleneck utama; didorong oleh kardinalitas dan kecepatan tulis
Backend UI Rendah Rendah Terikat kueri; dipengaruhi oleh volume data historis
Agen (Python dan Go) Tidak berlaku Tinggi Deployment Independen; penskalaan dengan konkurensi

Penentuan ukuran penyimpanan

Tabel berikut memberikan rekomendasi awal untuk memulai ukuran volume penyimpanan:

  • Penyimpanan PostgreSQL (status kagent, termasuk pengelolaan sesi, memori, dan siklus proses) diskalakan secara linear seiring meningkatnya jumlah sesi chat.
  • Penyimpanan ClickHouse (pelacakan) juga diskalakan secara linear seiring dengan meningkatnya jumlah sesi chat unik.
Komponen Volume awal yang direkomendasikan
PostgreSQL 50 GiB
ClickHouse 50 GiB

Pengukuran deployment

Bagian berikut mencantumkan permintaan dan batas resource CPU, memori, dan penyimpanan default untuk diagram Helm.

Diagram pengelolaan

Diagram management men-deploy pod solo-enterprise-ui, kolektor telemetri mandiri, dan ClickHouse.

solo-enterprise-ui container pod

Tabel berikut mencantumkan permintaan dan batas resource default untuk container pod solo-enterprise-ui:

Container Aktif Permintaan CPU Batas CPU Permintaan memori Batas memori
ui-backend Selalu 250m 500m 512Mi 1024Mi
ui-frontend Selalu 250m 500m 512Mi 1024Mi
k8sobjects-collector telemetry.k8sobjects.enabled 100m 300m 384Mi 768Mi
idp autoAuth diaktifkan 100m 250m 256Mi 512Mi
Kolektor telemetri (StatefulSet atau Deployment)

Tabel berikut mencantumkan permintaan dan batas resource default untuk telemetry collector:

Komponen Permintaan CPU Batas CPU Permintaan memori Batas memori
telemetry-collector 200m 1.000 m 512Mi 2Gi

Gateway telemetri (kolektor OpenTelemetry) juga menentukan resource-nya sendiri secara terpisah:

Komponen Permintaan CPU Batas CPU Permintaan memori Batas memori
telemetry-gateway 100m 500m 300Mi 1024Mi
Subchart ClickHouse

Tabel berikut mencantumkan permintaan dan batas resource default untuk subchart ClickHouse, berdasarkan preset Bitnami 2xlarge dan dikonfigurasi menggunakan nilai replicasPerShard dan shards:

Komponen Permintaan CPU Batas CPU Permintaan memori Batas memori Penyimpanan efemeral
clickhouse 1000m (1 core) 6000m (6 core) 3072Mi (3 GiB) 12288Mi (12 GiB) 50Mi

Diagram kagent-enterprise

Diagram kagent-enterprise men-deploy pengontrol inti, subdiagram kmcp-enterprise, server alat MCP bawaan, dan agen opsional.

Komponen inti

Tabel berikut mencantumkan permintaan dan batas resource default untuk pengontrol inti:

Komponen Aktif Permintaan CPU Batas CPU Permintaan memori Batas memori
controller Selalu 100m 2000m (2 core) 128Mi 512Mi
Subchart kmcp-enterprise

Tabel berikut mencantumkan permintaan dan batas resource default untuk pengontrol kmcp-enterprise:

Komponen Permintaan CPU Batas CPU Permintaan memori Batas memori
kmcp-enterprise-controller 100m 500m 128Mi 512Mi
Alat bawaan

Tabel berikut mencantumkan permintaan dan batas resource default untuk server alat bawaan:

Komponen Aktif Permintaan CPU Batas CPU Permintaan memori Batas memori
kagent-tools kagent-tools.enabled 100m 1.000 m 256Mi 1Gi
grafana-mcp grafana-mcp.enabled 100m 500m 128Mi 512Mi
querydoc querydoc.enabled 100m 500m 128Mi 512Mi
Agen

Semua agen menggunakan profil resource default yang sama. Setiap agen dinonaktifkan secara default dan diaktifkan satu per satu:

Agen Permintaan CPU Batas CPU Permintaan memori Batas memori
k8s-agent 100m 1.000 m 256Mi 1Gi
kgateway-agent 100m 1.000 m 256Mi 1Gi
istio-agent 100m 1.000 m 256Mi 1Gi
promql-agent 100m 1.000 m 256Mi 1Gi
observability-agent 100m 1.000 m 256Mi 1Gi
argo-rollouts-agent 100m 1.000 m 256Mi 1Gi
helm-agent 100m 1.000 m 256Mi 1Gi
cilium-policy-agent 100m 1.000 m 256Mi 1Gi
cilium-manager-agent 100m 1.000 m 256Mi 1Gi
cilium-debug-agent 100m 1.000 m 256Mi 1Gi