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