OpenClawクラスタ管理：リカバリパスをクラスタ外に保持する

OpenClawがKubernetesクラスタを管理する場合、そのリカバリパスをクラスタの外に保ってください。OpenClawに読み取り専用のクラスタアクセス、プルリクエスト権限、人間がレビューするGitOpsデプロイパスを付与することは、強力なパターンです。残る問題は、OpenClaw自体をどこに置くかです。

問題：クラスタ内

唯一のGateway、タスク状態、およびリカバリツールが管理対象クラスタ内で実行されている場合、深刻なクラスタ障害がワークロードとそれを診断するシステムの両方を削除する可能性があります。同じクラスタ内の別のPodは、コントロールプレーン、ストレージ、またはネットワーク障害から保護しません。

推奨トポロジ

より安全なアプローチ：

• OpenClaw Gatewayとタスク状態はターゲットクラスタの外に置く — OpenClawのリモートアクセスドキュメントでサポートされている専用ホスト上。
• 読み取り専用IDを使用して、クラスタからログとステータスにアクセスします。
• 変更はブランチ → PR → CI → 人間のマージ → Argo CDのフローで行われ、ライブクラスタの読み戻しがあります。

最小権限RBAC

Kubernetes内では、可能な限り最小の名前空間権限を持つ専用のサービスアカウントを使用します。シークレットアクセス、ワイルドカード、クラスタ管理者、直接のパッチまたは削除権限は避けてください。 Kubernetesの現在のRBACガイダンスは、この最小権限アプローチを推奨しています。

GitOpsデプロイパス

OpenClawにプルリクエストを作成させます。CIとポリシーチェックがそれを評価し、人間がマージを承認し、Argo CDがGitとクラスタを調整します。 Argo CDの自動同期ドキュメントは、提案プロセスに直接デプロイアクセスを与えることなく、Gitからデプロイを駆動できることを確認しています。

検証手順

リカバリパスをテストします：

• 非本番クラスタ利用不可テストを実行します：OpenClawが到達可能であり、タスクを保持し、結果をブロックまたは不明として報告することを確認します（成功として報告しない）。
• 無害なマニフェスト変更を送信し、プルリクエストのみが作成されることを確認します（直接デプロイなし）。
• 承認後、マージされたコミット、Argo CDのリビジョン、およびライブリソースの状態を確認します。

OpenClawが管理するインフラストラクチャのリカバリ権限とタスク状態をどこに置いていますか？