2026 年、Docker または Kubernetes 上で OpenClaw Gateway を動かすチームはリリースを早く回しがちですが、しばしば「コンテナが動いている」を健全とみなします。HTTP プローブのパス、readiness の意味、ローリングのパラメータを同一の変更チケットに載せないと、コールドスタート中に liveness で kill されたり、depends_on がコンテナ起動だけを待って readiness を待たないまま 502 が出たり、プロバイダの 429 を Gateway 死と誤って再起動が止まらない、といった事象が起きます。本稿は《Docker 本番 Runbook》《アップグレードと移行》《プロバイダ別ルーティングとフェイルオーバー》とスコープを揃え、RCA 向け落とし穴六つ、liveness／readiness／startup の対照、Compose と Kubernetes の対応、コピペ可能な YAML 断片、六ステップのロールアウト Runbook、ダッシュボード指標三つをまとめます。あわせて安定したリモート Mac上の実行面の置き方にも触れます。
近い OpenClaw のリリースではオーケストレーション向けの HTTP エンドポイントが追加されています（正確なパスとポートは固定したイメージタグとリリースノートに従います。エコシステムでは /health、/ready、/healthz などの名称が現れます）。次の六パターンを RCA に記録し、《doctor とインストール後の切り分け》の語彙と合わせてください。
depends_on に health 条件がない： Gateway がまだバックエンドに届かないうちに従属サービスが立ち、断続的な 502 になります。127.0.0.1 は通るが ClusterIP では失敗する、とアプリ障害と誤読します。maxUnavailable が攻撃的： 古い Pod が drain される一方で新 Pod が readiness を通らず、短時間フルレッドになります。《クロスプラットフォーム導入》と比べると、導入は初回起動、本番は長期運用、本稿はオーケストレータが健全と判断する条件、アップグレード編はイメージの移動とロールバックを扱います。
Kubernetes のプローブ種別は Docker healthcheck の再起動意味と 1 対 1 ではありません。アーキテクチャレビューでは次の表を使います。
| チェック | 典型的な失敗時の効果 | 検証するもの | OpenClaw 向けの指針 |
|---|---|---|---|
| startupProbe | 成功まで liveness の失敗を抑制 | 遅いが上限のあるコールドスタート | 初回の設定取得、インデックス、依存の待ちに数分かかる場合に使います |
| livenessProbe | コンテナ／Pod を再起動 | デッドロック、応答しないプロセス | 外部 LLM には依存させず、最小限の自己チェックに留めます |
| readinessProbe | Service のエンドポイントから外す | トラフィックを受ける準備ができていない | 軽いモデル疎通や設定読込完了のシグナルを含めてもよいですが、フェイルオーバー方針に揃えます |
| Docker healthcheck | 不健全マーク、再起動はポリシー次第 | 単一ホストの Compose | depends_on: condition: service_healthy と組み合わせます（構文は Compose v2 のドキュメントに従います） |
「健全」を具体的なフィールドに落とすと、深夜の議論が減ります。
| 次元 | Docker Compose（パターン） | Kubernetes Deployment |
|---|---|---|
| プローブ手段 | healthcheck.test で curl／wget | httpGet または exec |
| 起動猶予 | start_period | startupProbe または大きめの initialDelaySeconds |
| トラフィックの切り離し | プロキシ／LB 層またはラベルに依存 | readinessProbe が Endpoints を制御 |
| ローリング | 手動の compose 順序または外部 CD | maxSurge／maxUnavailable／minReadySeconds |
# 例—PORT とパスはタグ向けドキュメントの値に置き換えてください
# Docker Compose（抜粋）
healthcheck:
test: ["CMD-SHELL", "curl -fsS http://127.0.0.1:${GATEWAY_PORT}/health || exit 1"]
interval: 15s
timeout: 3s
retries: 5
start_period: 120s
# Kubernetes（抜粋）
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 10
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 30
periodSeconds: 20
注意： アップストリームは 2026.3.x 系のリリースで /health、/ready、/healthz を追加または改名する場合があります。断片をコピーする前に公式ドキュメントで digest／タグを確認し、ステージングでコンテナ内 curl -v を実行してください。
docker compose exec または kubectl exec で 127.0.0.1 を叩き、その後 Service 経路を確認します。maxUnavailable とメンテナンス窗口を文書化します。《Linux の systemd と Tunnel》経路では、トンネルの健全性、ループバックのリスナー、上流 LB のチェックを揃えないと「トンネルは生きているが Gateway が聞いていない」という偽陽性が出ます。
kubectl rollout status や compose の更新ログを Git の変更と突き合わせ、きついプローブとイメージ退行を切り分けます。
コンシューマ機器はスリープ、ディスクのばらつき、計画外の OS 更新と戦い、起動時間とプローブ閾値が漂います。ローリング窗口と組み合わさると当番時間を削ります。OpenClaw とエージェントを期待できる SLA で動かすには、専用計算、安定した外向き通信、バーストに耐えるノードが必要です。
バラバラなセルフホストではマルチリージョンの遅延と契約運用も難しく、プローブ調整とホスト再起動の結合がノート環境では特に痛みます。24 時間観測でき、ロールでき、ロールバックしやすい Gateway には、プロ向けのマルチリージョン Apple Silicon クラウド Mac の方がアドホック機材に勝ちやすいです。MACCOME は Mac Mini M4／M4 Pro のベアメタルを柔軟な条件で提供し、Gateway や混在自動化の実行面に使えます。まず《ヘルプセンター》で接続言語を確認し、《レンタル料金》と《マルチリージョンガイド》で SKU を確定してください。
パイロットでは対象リージョンで短期レンタルし、コンテナプローブ、Service プローブ、フルローリング演習を一度通してから月次や四半期契約に固定します。
よくある質問
プローブは失敗するのに UI は開きます。どちらが正ですか？
オーケストレータが設定した URL とステータスコードです。課金文脈は《レンタル料金》を参照し、プローブはステージングでコンテナ内 curl で再現してください。
Docker 本番記事とどう併用しますか？
本番編はボリュームとトークンを扱い、本稿はプローブとロールアウトを扱います。両方に《アップグレードと移行》を同じ変更に添えてください。
429 は liveness に載せますか？
原則いいえです。《プロバイダ別ルーティングとフェイルオーバー》でバックオフとルーティングを扱い、readiness への結合は明示的な SLO 選択にします。