Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Distributed Cloud ソフトウェアのみのリファレンス実装に kagent 用の Solo Enterprise をデプロイする

kagent 用 Solo Enterprise を使用すると、プラットフォーム管理者は Google Distributed Cloud（GDC）ソフトウェアのみ（GDC-SO）に AI エージェントをデプロイして管理できます。このリファレンス実装では、コンテナイメージと Helm チャートを限定公開の Harbor レジストリにミラーリングし、kagent コントロールプレーン、UI、Solo Enterprise for agentgateway をデプロイして、クラスタのサイズ設定ガイドラインを確認します。アーキテクチャの詳細については、独自の MCP サーバーを kagent リファレンスアーキテクチャに導入するをご覧ください。

前提条件

始める前に、Chrome、Docker、crane、kubectl、Helm、envsubst、gdcloud CLI がインストールされた Linux ワークステーションにアクセスできることを確認してください。GDC-SO 環境に次のコンポーネントが構成されていることを確認します。

コンポーネント	詳細または要件	値の例
GDC-SO のGoogle Cloud プロジェクト	GDC-SO クラスタに関連付けられたプロジェクト	`kagent-enterprise`
クラスタ	ターゲット GDC-SO クラスタ	`user-project-8a210897`
Kubernetes 認証情報（Connect Gateway）	クラスタへの接続	`gcloud container fleet memberships get-credentials user-project-8a210897`
非公開レジストリ	Harbor レジストリの URL	`solo-kagent-enterprise.org-1.zone1.google.gdch.test`
プロジェクトリポジトリ	プロジェクトリポジトリのパス	`solo-kagent-enterprise.org-1.zone1.google.gdch.test/kagent-enterprise`
pull secret	Docker pull シークレット名	`solo-harbor-pull-secret`

次の手順は、kagent バージョン 0.4.0 以降の Solo Enterprise に適用されます。

このデプロイは、GDC-SO バージョン 1.31.5-gke.300 で検証されています。

GDC-SO クラスタにデプロイする

クラスタとレジストリの構成に基づいて .env ファイルを作成します。

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"

次のように置き換えます。

SOLO_LICENSE_KEY: Solo Enterprise ライセンスキー
ORG: GDC 組織名
ZONE: GDC ゾーン名

Helm 値ファイルを作成する

3 つのチャートの Helm 値ファイルを作成します。インストールをカスタマイズする場合を除き、値を変更する必要はありません。追加のモデルとエージェントは、後で kagent UI で構成できます。

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

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

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

環境を設定する

.env ファイルと Helm 値ファイルと同じディレクトリで、環境変数を読み込み、Helm 値テンプレートをレンダリングします。これらの変数が設定されたままになるように、このガイドの残りのコマンドを同じシェルセッションで実行します。

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"

一般公開レジストリからイメージとグラフをミラーリングする

非公開の Harbor レジストリに対して Docker と Helm を認証し、公開レジストリから Helm チャートとコンテナイメージをミラーリングします。

# 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

GDC-SO クラスタに Namespace を作成する

クラスタにターゲット Namespace を作成します。

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

Docker pull シークレットを作成してクラスタに適用する

クラスタに Docker レジストリの pull シークレットを作成します。

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"

次のように置き換えます。

REGISTRY_USERNAME: Harbor レジストリのユーザー名
REGISTRY_PASSWORD: Harbor レジストリのパスワード

kagent をインストールする

CRD チャートと Solo Enterprise for kagent 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"

デプロイを検証する

Namespace で Pod が実行されていることを確認します。

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

出力は次のようになります。

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

ローカルポートを solo-enterprise-ui サービスに転送します。

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

ブラウザで http://localhost:9090 に移動して、kagent UI の Solo Enterprise を開き、モデルとエージェントを構成します。

kagent UI ダッシュボード用の Solo Enterprise。

パフォーマンスに関する考慮事項とデプロイのサイジング

以降のセクションでは、コンポーネントのリソース消費量のスケーリング方法について説明し、単一クラスタデプロイのベースラインストレージとリソースのサイズ設定について説明します。

スケーリングの特徴

単一クラスタのインストール（リレーなしの management チャートと kagent-enterprise チャート）でエージェント数とエージェントあたりのリクエスト負荷が増加すると、リソース消費量が質的に変化します。これらの特性を使用して、リソース割り当ての調整や容量の計画を行う前に、特定のスケーリングディメンションに敏感なコンポーネントを特定します。

スケーリングを制御する主なアーキテクチャ上の事実

エージェントから LLM へのトラフィックは直接送信されます。エージェントは、大規模言語モデル（LLM）エンドポイント（クラスタ内モデルサービスなど）を直接呼び出します。このトラフィックは、コントローラやその他の管理プレーンコンポーネントを通過しません。エージェントを追加したり、リクエスト率を上げたりしても、共有コンポーネントの LLM 関連の負荷は増加しません。
MCP サーバーは、エージェントツールの実行のホットパスにあります。エージェントが Model Context Protocol（MCP）サーバーを基盤とするツールを呼び出すと、呼び出しは同期的に行われ、ブロックされます。MCP サーバーのレイテンシとスループットは、エージェントリクエストのレイテンシに直接影響します。デプロイされた各 MCPServer リソースは、独自のリソースエンベロープを持つ個別の Deployment です。
テレメトリーは、スケーリングの主要な対象です。指標、トレース、Kubernetes オブジェクトのスナップショットはすべて、テレメトリーパイプラインを介して ClickHouse に送信されます。このパイプラインは、エージェント数とリクエスト量の両方に応じて増加し、システムの中で最もリソースに敏感な部分です。
トンネルサーバーは存在しますが、単一クラスタのインストールでは意味のあるトラフィックを伝送しません。tunnel-server コンテナは UI Pod で実行されますが、サービスを提供するクライアントがないため、スケーリングの負荷には影響しません。

コンポーネントのスケーリング動作

以降のセクションでは、エージェント数とリクエスト負荷に応じて個々のコンポーネントがどのようにスケーリングされるかについて説明します。

kagent-controller

エージェント数に比例して増加します。各エージェントはエージェント間（A2A）ストリーム接続を保持します。
LLM 呼び出しとツール実行がコントローラをバイパスするため、リクエスト量の影響を受けません。
水平スケーリングをサポートして、接続とポリシー評価の負荷を分散します。

KMCP エンタープライズコントローラ

KMCP エンタープライズコントローラは、MCPServer リソースの変更のみでイベントドリブンであり、エージェント数やリクエスト量に影響されません。

MCP サーバー

MCPServer カスタムリソース（CR）ごとに 1 つの Deployment をデプロイします。フリートサイズは、デプロイされた MCPServer リソースの数に応じて増加します。
エージェントツールの実行の同期ホットパスで実行されます。レイテンシとスループットはエージェントに直接影響します。
共有サーバーが多数のエージェントによって同時に呼び出される場合、すべてのコンシューマーの合計ツール呼び出し率に応じてスケーリングされます。
デフォルトでは、組み込みサーバー（grafana-mcp、querydoc）を単一のレプリカとして実行します。共有使用量が多い場合は、レプリカまたは上限を増やします。
ユーザーがデプロイした MCP サーバーに、ユーザー定義のイメージ、リソースリクエスト、リソース上限を使用します。

テレメトリーコレクタ

リクエスト量に応じて直線的にスケーリングします。各リクエストは指標を出力し、必要に応じてトレースを出力します。
エージェントの負荷が高い場合に、リソースが制約される可能性が最も高いコンポーネントです。
マルチクラスタインストールでリモートクラスタの OpenTelemetry Protocol（OTLP）ゲートウェイ（ポート 4316 ～ 4318 のレシーバー）として機能します。別のゲートウェイ Pod は存在しません。
k8sobjects サイドカーを使用します。これは、リクエスト率ではなく Kubernetes インベントリサイズに応じてスケーリングされます。

ClickHouse

ClickHouse は、持続的な負荷の下でリソースのボトルネックとなります。ストレージ、メモリ、CPU はすべて、次の要因で増加します。

エージェント数: エージェントタイプを追加するたびに、指標のカーディナリティ（一意のラベルの組み合わせ）が増加します。
リクエスト量: 各リクエストは、書き込まれてインデックスに登録される指標データポイントとトレーススパンを生成します。
Kubernetes インベントリサイズ: k8sobjects スナップショットは、リクエストの負荷に関係なく定期的に保存されます。

書き込みスループットは最初のプレッシャーポイントです。スキーマや保持のチューニングを行わずにデータ量が増加すると、クエリのパフォーマンス（UI バックエンドで使用）が低下します。デフォルトの構成は、中程度の単一ノードデプロイを対象としています。負荷が大きい場合は、replicasPerShard または shards を増やすか、保持 TTL を調整する必要があります。

UI バックエンド

ステートレスでクエリにバインドされます。リアルタイムのリクエストスループットではなく、ClickHouse のデータ量に応じてスケーリングされます。
エージェント数と過去のデータが増加するにつれて、フリートグラフとトレースクエリの費用が増加します。

エージェント

Python ベースのエージェント:
- 各エージェントは独立した Deployment です。エージェントの追加は純粋な追加であり、共有状態のペナルティはありません。
- エージェントあたりのリソース消費量は、リクエストの同時実行数とツールチェーンの深さに応じてスケーリングされます。
Go ベースのエージェント:
- アイドル状態のメモリ使用量が約 36 分の 1 に削減されます（エージェントあたりのメモリ使用量は、アイドル状態で 253 MB から 7 MB に減少）。
- 約 11 分の 1 のサイズのコンテナイメージ（335.4 MB に対して 29.7 MB）を使用します。
- 起動が約 6.7 倍高速（18.2 秒に対して 2.7 秒）。

スケーリング特性の概要

次の表は、各コンポーネントがエージェント数とリクエスト負荷に応じてどのようにスケーリングするかをまとめたものです。

コンポーネント	エージェント数の影響を受けやすい	リクエスト負荷に敏感	メモ
コントローラ	中	低	エージェントごとに A2A ストリームを維持。LLM 呼び出しレートの影響を受けない
スケーラー	なし	なし	イベントドリブン、実質的に静的
KMCP エンタープライズコントローラ	なし	なし	`MCPServer` リソースの変更にのみ対応する
MCP サーバー	高	高	`MCPServer` CR ごとに 1 つの Deployment。ツール実行のホットパス
テレメトリーコレクタ	高	高	プライマリスケーリングサーフェス。リクエスト量に比例
ClickHouse	高	高	主なボトルネック。カーディナリティと書き込みレートによって発生
UI バックエンド	低	低	クエリに依存。過去のデータ量の影響を受ける
エージェント（Python と Go）	該当なし	高	独立したデプロイ、同時実行によるスケーリング

ストレージのサイジング

次の表に、ストレージボリュームサイズの初期段階の推奨事項を示します。

PostgreSQL ストレージ（セッション、メモリ、ライフサイクル管理を含む kagent 状態）は、チャットセッションの数が増えるにつれて直線的にスケーリングされます。
ClickHouse ストレージ（トレース）も、一意のチャットセッション数が増えるにつれて線形にスケーリングされます。

コンポーネント	推奨される開始時の音量
PostgreSQL	50 GiB
ClickHouse	50 GiB

デプロイのサイズ設定

以降のセクションでは、Helm チャートのデフォルトの CPU、メモリ、ストレージのリソースリクエストと上限について説明します。

管理グラフ

management チャートは、solo-enterprise-ui Pod、スタンドアロンテレメトリーコレクタ、ClickHouse をデプロイします。

`solo-enterprise-ui` 個の Pod コンテナ

次の表に、solo-enterprise-ui Pod コンテナのデフォルトのリソースリクエストと上限を示します。

コンテナ	有効	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`ui-backend`	常に	250m	500m	512Mi	1024Mi
`ui-frontend`	常に	250m	500m	512Mi	1024Mi
`k8sobjects-collector`	`telemetry.k8sobjects.enabled`	100 分	300m	384Mi	768Mi
`idp`	`autoAuth` が有効	100 分	250m	256Mi	512Mi

テレメトリーコレクタ（StatefulSet または Deployment）

次の表に、テレメトリーコレクタのデフォルトのリソースリクエストと上限を示します。

コンポーネント	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`telemetry-collector`	200 m	1000m	512Mi	2Gi

テレメトリーゲートウェイ（OpenTelemetry コレクタ）も、独自のリソースを個別に定義します。

コンポーネント	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`telemetry-gateway`	100 分	500m	300Mi	1024Mi

ClickHouse サブチャート

次の表に、Bitnami 2xlarge プリセットに基づいて、replicasPerShard 値と shards 値を使用して構成された ClickHouse サブチャートのデフォルトのリソースリクエストと上限を示します。

コンポーネント	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限	エフェメラルストレージ
`clickhouse`	1000m（1 コア）	6,000 m（6 コア）	3072Mi（3 GiB）	12288Mi（12 GiB）	50Mi

kagent-enterprise チャート

kagent-enterprise チャートは、コアコントローラ、kmcp-enterprise サブチャート、組み込みの MCP ツールサーバー、オプションのエージェントをデプロイします。

コアコンポーネント

次の表に、コアコントローラのデフォルトのリソースリクエストと上限を示します。

コンポーネント	有効	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`controller`	常に	100 分	2,000 m（2 コア）	128Mi	512Mi

kmcp-enterprise サブチャート

次の表に、kmcp-enterprise コントローラのデフォルトのリソースリクエストと上限を示します。

コンポーネント	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`kmcp-enterprise-controller`	100 分	500m	128Mi	512Mi

組み込みツール

次の表に、組み込みツールサーバーのデフォルトのリソースリクエストと上限を示します。

コンポーネント	有効	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`kagent-tools`	`kagent-tools.enabled`	100 分	1000m	256Mi	1Gi
`grafana-mcp`	`grafana-mcp.enabled`	100 分	500m	128Mi	512Mi
`querydoc`	`querydoc.enabled`	100 分	500m	128Mi	512Mi

エージェント

すべてのエージェントが同じデフォルトのリソースプロファイルを共有します。各エージェントはデフォルトで無効になっており、個別に有効にします。

エージェント	CPU リクエスト	CPU 上限	メモリリクエスト	メモリ上限
`k8s-agent`	100 分	1000m	256Mi	1Gi
`kgateway-agent`	100 分	1000m	256Mi	1Gi
`istio-agent`	100 分	1000m	256Mi	1Gi
`promql-agent`	100 分	1000m	256Mi	1Gi
`observability-agent`	100 分	1000m	256Mi	1Gi
`argo-rollouts-agent`	100 分	1000m	256Mi	1Gi
`helm-agent`	100 分	1000m	256Mi	1Gi
`cilium-policy-agent`	100 分	1000m	256Mi	1Gi
`cilium-manager-agent`	100 分	1000m	256Mi	1Gi
`cilium-debug-agent`	100 分	1000m	256Mi	1Gi

Distributed Cloud ソフトウェアのみのリファレンス実装に kagent 用の Solo Enterprise をデプロイする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

前提条件

GDC-SO クラスタにデプロイする

Helm 値ファイルを作成する

環境を設定する

一般公開レジストリからイメージとグラフをミラーリングする

GDC-SO クラスタに Namespace を作成する

Docker pull シークレットを作成してクラスタに適用する

kagent をインストールする

デプロイを検証する

パフォーマンスに関する考慮事項とデプロイのサイジング

スケーリングの特徴

スケーリングを制御する主なアーキテクチャ上の事実

コンポーネントのスケーリング動作

kagent-controller

KMCP エンタープライズ コントローラ

MCP サーバー

テレメトリー コレクタ

ClickHouse

UI バックエンド

エージェント

スケーリング特性の概要

ストレージのサイジング

デプロイのサイズ設定

管理グラフ

solo-enterprise-ui 個の Pod コンテナ

テレメトリー コレクタ（StatefulSet または Deployment）

ClickHouse サブチャート

kagent-enterprise チャート

コア コンポーネント

kmcp-enterprise サブチャート

組み込みツール

エージェント

Distributed Cloud ソフトウェアのみのリファレンス実装に kagent 用の Solo Enterprise をデプロイする

KMCP エンタープライズコントローラ

テレメトリーコレクタ

`solo-enterprise-ui` 個の Pod コンテナ

テレメトリーコレクタ（StatefulSet または Deployment）

コアコンポーネント