Helm を使わない理由
OpenClaw は、いくつかの設定ファイルを持つ単一コンテナです。重要なカスタマイズは、インフラのテンプレート化ではなく、エージェントコンテンツ（Markdown ファイル、Skills、設定オーバーライド）にあります。Kustomize は Helm チャートのオーバーヘッドなしでオーバーレイを扱えます。デプロイがより複雑になった場合は、これらのマニフェストの上に Helm チャートを重ねてください。必要なもの
- 稼働中の Kubernetes クラスター（AKS、EKS、GKE、k3s、kind、OpenShift など）
- クラスターに接続済みの
kubectl - 少なくとも 1 つのモデルプロバイダーの API キー
クイックスタート
deploy.sh はデフォルトでトークン認証を作成します。Control UI 用に生成されたゲートウェイトークンを取得します。
./scripts/k8s/deploy.sh --show-token がデプロイ後にトークンを出力します。
Kind を使ったローカルテスト
クラスターがない場合は、Kind を使ってローカルに作成します。./scripts/k8s/deploy.sh でデプロイします。
ステップごと
1) デプロイ
オプション A: 環境変数内の API キー（1 ステップ）--show-token を追加します。
2) ゲートウェイにアクセスする
デプロイされるもの
カスタマイズ
エージェント指示
scripts/k8s/manifests/configmap.yaml 内の AGENTS.md を編集して、再デプロイします。
Gateway 設定
scripts/k8s/manifests/configmap.yaml 内の openclaw.json を編集します。完全なリファレンスは Gateway 設定 を参照してください。
プロバイダーを追加する
追加のキーをエクスポートして再実行します。カスタム名前空間
カスタムイメージ
scripts/k8s/manifests/deployment.yaml の image フィールドを編集します。
port-forward を超えて公開する
デフォルトのマニフェストは、Pod 内のループバックにゲートウェイをバインドします。これはkubectl port-forward では機能しますが、Pod IP に直接到達する必要がある Kubernetes Service や Ingress パスでは機能しません。
Ingress またはロードバランサー経由でゲートウェイを公開するには、次のようにします。
scripts/k8s/manifests/configmap.yamlのゲートウェイバインドをloopbackから、デプロイモデルに合う非ループバックのバインドに変更します。- ゲートウェイ認証を有効のままにし、適切な TLS 終端エントリーポイントを使用します。
- サポートされる Web セキュリティモデルを使って、リモートアクセス用に Control UI を設定します（たとえば HTTPS/Tailscale Serve と、必要に応じた明示的な許可オリジン）。
再デプロイ
削除
アーキテクチャメモ
- ゲートウェイはデフォルトで Pod 内のループバックにバインドされるため、同梱のセットアップは
kubectl port-forward用です。 - クラスタースコープのリソースはありません。すべて単一の名前空間内にあります。
- セキュリティ強化:
readOnlyRootFilesystem、drop: ALLcapabilities、非 root ユーザー（UID 1000）。 - デフォルト設定では、Control UI をより安全なローカルアクセス経路に保ちます。ループバックバインドに加えて、
kubectl port-forwardでhttp://127.0.0.1:18789に接続します。 - localhost アクセスを超える場合は、サポートされるリモートモデルを使用してください。HTTPS/Tailscale に加えて、適切なゲートウェイバインドと Control UI のオリジン設定を使います。
- Secret は一時ディレクトリ内で生成され、クラスターに直接適用されます。Secret の内容がリポジトリのチェックアウトに書き込まれることはありません。