Dockerイメージの最適化・K8sリソースリスト・macOSノードオペレーター・HPA自動伸縮
OpenClaw はまだローカルで直接実行されますか?マルチチームのコラボレーション、柔軟なスケーリング、クロスリージョン展開のニーズに直面して、ネイティブ インストール方法では不十分になってきています。この記事では、完全なコンテナ化と K8s オーケストレーション ソリューション: OpenClaw を標準 Docker イメージに変換し、macOS ノードで Kubernetes Operator を使用して、自動デプロイメント、サービス公開、カスタム インジケーターに基づく HPA の拡張と縮小を実現する方法。この記事の最後には、多段階のビルド最適化チェックリスト、macOS 権限の構成、コストと回復力のトレードオフ マトリックスが含まれています。
OpenClaw をローカル ノード環境から Docker コンテナに移行し、さらにそれを Kubernetes にデプロイすることは、「技術的なホット スポットを追跡する」ことではなく、運用環境の本当の問題点を解決することです。
環境の一貫性の欠如: 開発者や CI ノードごとにノードのバージョンや npm パッケージの依存関係が異なるため、「私のマシンで実行できるか」という問題が頻繁に発生します。コンテナ化により、ランタイム環境の完全な一貫性が保証されます。
非効率な膨張と収縮: ローカルにインストールされた OpenClaw を複製したり、水平方向に迅速にスケーリングしたりすることはできません。タスクキューが蓄積すると、新しいインスタンスは手動でしか起動できなくなり、応答速度が予想よりも大幅に遅くなります。
リージョンを越えた展開の難しさ：OpenClaw を複数のリージョンのリモート Mac ノードに展開する必要がある場合、手動操作ではエラーが発生しやすく、均一に管理することが困難です。 K8s の宣言型構成により、ゾーン間の一貫性が可能になります。
障害回復が遅い: ノードがダウンした後、ノードを再インストールして構成するには手動介入が必要です。コンテナ オーケストレーターは障害を自動的に検出して再スケジュールできるため、MTTR が大幅に削減されます。
リソース使用率が低い: 各 OpenClaw インスタンスは 1 台のマシンを占有するため、リソースが大幅に浪費されます。 K8s はマルチテナント共有とリソース割り当て制御を実現し、全体的な使用率を向上させます。
コンテナ化の利点: 2026 年の DevOps 調査によると、コンテナ化された AI エージェント サービスの平均障害復旧時間は 70% 短縮され、リソース使用率は 40% 以上増加しました。
Dockerfile を作成する前に、OpenClaw の構成をファイル システムから環境変数と外部ストレージに移行する必要があります。これはコンテナ化の重要な最初のステップです。
| 元の構成（ファイル） | コンテナ化の方針 | 説明 |
|---|---|---|
openclaw.jsonAPI キー | 構成マップ/シークレット | 機密情報は、K8s Secret または外部ボールトを使用して管理する必要があります |
storage.type = "file" | に変更しますredisまたはクラウドストレージ | コンテナ ファイル システムは一時的なものであるため、外部化する必要があります |
gateway.address = "0.0.0.0:8080" | 環境変数GATEWAY_ADDR | Docker経由のポートマッピング-pまたは K8s サービス処理 |
skillsローカルパス | ConfigMap またはサイドカー コンテナー | 更新を容易にするために、スキル定義は画像から独立している必要があります |
logsローカルに書き込む | stdout/stderr + サイドカーコレクション | 12FA アプリケーションの仕様に従い、コンソールにログを出力します。 |
主な変更点: 環境変数から読み取るように「openclaw.json」を変更します。例：
{
"storage": {
"type": "redis",
"host": "${REDIS_HOST}",
"port": 6379,
"password": "${REDIS_PASSWORD}"
},
"gateway": {
"address": "${GATEWAY_ADDR}",
"adminPort": "${ADMIN_PORT}"
},
"llm": {
"provider": "${LLM_PROVIDER}",
"apiKey": "${LLM_API_KEY}"
}
}
効率的で安全な Docker イメージは、K8s オーケストレーションの基盤です。マルチステージ ビルドを使用してサイズを削減し、セキュリティを強化し、K8s 監視のヘルス チェックを追加します。
適切なベース画像を選択してください: 公式の Node.js イメージを使用します (例:node:18-alpine) サイズと攻撃対象領域を削減するために、完全な OS ではなくランタイム フェーズの基礎として使用されます。
多段階ビルド: 第 1 段階では依存関係をインストールして (存在する場合) コンパイルし、第 2 段階では実行環境だけを作成し、最終イメージには実行時に必要なファイルのみが含まれるため、サイズを 60% 以上削減できます。
非 root ユーザーとして実行する:Dockerfile に専用ユーザーを作成します (例:openclaw) 一緒に使用されますUSERコンテナー内で root として実行されないようにコマンドを切り替えます。
ヘルスチェックを追加する:Dockerfileで宣言するHEALTHCHECK、OpenClaw を呼び出します/healthコンテナーの起動後にサービスが利用可能であることを確認するためのエンドポイント。
公開ポート：合格EXPOSE 8080サービス ポートを宣言すると、K8s サービスはそれに応じてトラフィックを転送します。
レイヤーの最適化: 依存関係のインストールとソース コードのコピーを分離し、Docker レイヤー キャッシュを使用してビルドを高速化します。使用npm ci --only=production開発の依存関係が運用イメージに入らないようにします。
# 构建阶段
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# 运行阶段
FROM node:18-alpine
WORKDIR /app
RUN addgroup -g 1001 -S openclaw && adduser -u 1001 -S openclaw -G openclaw
COPY --from=builder --chown=openclaw:openclaw /app/dist ./dist
COPY --from=builder --chown=openclaw:openclaw /app/node_modules ./node_modules
COPY --from=builder --chown=openclaw:openclaw /app/package*.json ./
USER openclaw
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD node -e "require('http').get('http://localhost:8080/health', (r) => {if(r.statusCode!==200)throw new Error('unhealthy')})"
CMD ["node", "dist/index.js"]
Kubernetes を完全にデプロイするには、複数のリソース オブジェクトのコラボレーションが必要です。以下は、リモート Mac ノードで OpenClaw を実行するための最小限の実行可能なセットです。
| リソースの種類 | 効果 | 主要なフィールド |
|---|---|---|
| 導入 | Pod レプリカとローリング アップデートの数を管理する | レプリカ、セレクター、テンプレート、ストラテジー |
| サービス | 内部負荷分散と DNS 検出 | タイプ (ClusterIP)、ポート、セレクター |
| イングレス | 外部HTTP/HTTPSルーティング | ルール、ホスト、パス、サービス名、サービスポート |
| 構成マップ | 機密性の低い構成ストレージ | データ、不変 |
| 秘密 | 機密情報 (API キー、パスワード) | タイプ: 不透明、データ (base64) |
以下は、OpenClaw のデプロイメント、サービス、イングレス、および ConfigMap を含む完全な YAML の例です。 Secretは別途作成する必要があります。
apiVersion: apps/v1
kind: Deployment
metadata:
name: openclaw
labels:
app: openclaw
spec:
replicas: 2
selector:
matchLabels:
app: openclaw
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: openclaw
spec:
containers:
- name: openclaw
image: your-registry/openclaw:latest
ports:
- containerPort: 8080
env:
- name: GATEWAY_ADDR
value: "0.0.0.0:8080"
- name: REDIS_HOST
valueFrom:
configMapKeyRef:
name: openclaw-config
key: redis.host
- name: REDIS_PASSWORD
valueFrom:
secretKeyRef:
name: openclaw-secret
key: redis.password
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 30
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
name: openclaw
spec:
selector:
app: openclaw
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: openclaw
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: openclaw.vpsmesh.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: openclaw
port:
number: 80
---
apiVersion: v1
kind: ConfigMap
metadata:
name: openclaw-config
data:
redis.host: "redis-cluster.vpsmesh.com"
llm.provider: "openai"
Kubernetes は通常、Linux クラスター上で実行されますが、OpenClaw をリモート Mac ノードにデプロイするには、ハードウェア バインディング、権限、特権モードなどの特性に対処する必要があります。 Kubernetes Operator はこれらの複雑さをカプセル化し、自動化された運用とメンテナンスを実現します。
node-role.kubernetes.io/macos=true) とアフィニティ ルールにより、ポッドが確実に Mac ノードにスケジュールされます。securityContext.privileged: true 或 allowPrivilegeEscalation: true有効ですが、使用は厳密に制限する必要があります。k8s-device-plugin) リソース制限で宣言しますlimits: apple.com/metal: 1。hostPath 或 LocalPV は公開されますが、データの永続性と移行の問題に注意する必要があります。OpenClawAgentデプロイメントやサービスなどのネイティブ リソースに変換して、ワンクリックでのデプロイメントとライフサイクル管理を実現します。セキュリティ警告: macOS ノードがコンテナーを実行する場合、カーネル レベルの分離は Linux ほど厳密ではありません。常にサンドボックス環境で特権コンテナをテストし、スケジュール可能なノードの範囲を制限します。
Operator のスケルトンの例 (Kopf を使用):
import kopf
@kopf.on.create('openclawvpsmesh.io', 'v1', 'openclawagents')
def create_fn(spec, **kwargs):
# 提取 spec 中的配置
image = spec.get('image', 'your-registry/openclaw:latest')
replicas = spec.get('replicas', 1)
redis_host = spec['redis']['host']
redis_password = spec['redis'].get('password')
# 创建 Deployment
deployment = {
"apiVersion": "apps/v1",
"kind": "Deployment",
"metadata": {"name": f"openclaw-{kwargs['name']}"},
"spec": {
"replicas": replicas,
"selector": {"matchLabels": {"app": "openclaw"}},
"template": {
"metadata": {"labels": {"app": "openclaw"}},
"spec": {
"containers": [{
"name": "openclaw",
"image": image,
"env": [
{"name": "REDIS_HOST", "value": redis_host},
{"name": "REDIS_PASSWORD", "value": redis_password}
],
"ports": [{"containerPort": 8080}]
}]
}
}
}
}
# 这里简化：实际需调用 K8s API 创建资源
return {"status": "created"}
OpenClaw の負荷はタスク キューの深さに直接関係します。 K8s の horizontalPodAutoscaler は、カスタム指標 (キューの長さ、タスクの応答時間など) に基づいてレプリカの数を自動的に調整し、柔軟なスケーリングを実現できます。
| インジケーターの種類 | 説明する | 伸縮閾値 | 冷却時間 |
|---|---|---|---|
| CPU使用率 | ポッドの CPU 使用率 | 拡大 >70%、縮小 <30% | 300年代 |
| メモリ使用量 | ポッドのメモリ使用率 | 拡大 >80%、縮小 <40% | 300s |
| キューの深さ | OpenClaw の保留中のタスク | 50 タスクを超える拡張、10 タスク未満のタスクの縮小 | 180年代 |
| タスクの応答時間 | P95 応答遅延 | 拡張 > 2 秒、縮小 < 500 ミリ秒 | 300s |
キューの深さに基づいて拡張と縮小を実装するには、Prometheus モニタリング スタックをデプロイし、対応するカスタム メトリクス APIAdapter を作成する必要があります。 HPA 構成の例は次のとおりです。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: openclaw-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: openclaw
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
- type: Pods
pods:
metric:
name: openclaw_queue_depth
target:
type: AverageValue
averageValue: 50
behavior:
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Pods
value: 1
periodSeconds: 300
scaleUp:
stabilizationWindowSeconds: 60
policies:
- type: Pods
value: 2
periodSeconds: 60
コストと弾力性のトレードオフ: レプリカの下限値が高すぎるとリソースが浪費され、遅延しきい値が低すぎると頻繁な拡張と縮小 (フラッピング) が発生する可能性があります。オンラインにする前に、オフピーク時間にストレス テストを実行して、適切なベースライン値を決定することをお勧めします。
コンテナ化と K8s オーケストレーションは「特効薬」ではありません。これらは運用の複雑さとリソースのオーバーヘッドをもたらします。次の 3 つの重要なデータは、投資する価値があるかどうかを判断するのに役立ちます。
stabilizationWindowSecondsそして「振動」を避けるための拡張と収縮のステップ。自社構築のコンテナ化プラットフォームを構築するには、イメージの構築、リソースのスケジューリング、ネットワーク ポリシー、セキュリティの強化など、Kubernetes と macOS に関する深い基礎知識が必要です。ほとんどのチームにとって、この技術的なしきい値と継続的な運用とメンテナンスの負担は低くありません。
したがって、OpenClaw の高可用性と柔軟なスケーラビリティ機能をすぐに取得したい運用環境の場合、VpsMesh の OpenClaw ホスティング サービスは、多くの場合、より優れたソリューションです。当社では、OpenClaw がプリインストールされた Mac Mini M4 ノード、自動スケーリングおよびクロスゾーンの災害復旧機能を提供しているため、複雑な Operator および HPA 構成を自分で作成する必要がなくなります。最小限の初期コストでエンタープライズ グレードの OpenClaw 導入を実現する方法を知りたいですか?あなたは私たちのを閲覧することができます価格ページまたは直接オンラインで注文する。
主な変更点は、構成ファイルを外部化することです。スキル定義は、ローカル ディレクトリから ConfigMap または ConfigMap ボリューム マウントに移動する必要があります。環境変数はハードコードされたパスを置き換えます。さらに、すべてのファイル アクセスは、コンテナー内にパスを直接書き込むのではなく、宣言型ボリュームを通じて行われるようにしてください。詳細な手順については、こちらを参照してください。ヘルプセンターコンテナ化された展開ページ。
macOS 上のコンテナ エコシステムは Linux ほど成熟していないため、特権コンテナ、デバイス プラグイン、およびネットワーク プラグイン (CNI など) のサポートは限られています。 k3s や minikube などの軽量ディストリビューションを使用し、特権のないワークロードまたは特権が制限されたワークロードのみを実行することをお勧めします。高パフォーマンスのニーズについては、コンテナ化する必要があるか、それとも VpsMesh のホストされた OpenClaw ノードを直接使用する必要があるかを評価してください。
カスタム メトリック API を通じてキューを HPA に深く公開するには、Prometheus モニタリング スタックと OpenClaw のメトリック エクスポーターをデプロイする必要があります。次にHPA YAMLで指定しますtype: Podsそして、対応するインジケーター名を引用します。特定のアダプター構成については、Kubernetes の公式ドキュメントの「カスタム インジケーター ソースとしての Prometheus の使用」を参照してください。