Teams, die OpenClaw Gateway 2026 auf Docker oder Kubernetes betreiben, liefern oft schnell und behandeln trotzdem „Container läuft“ als gesund. Ohne HTTP-Probe-Pfade, Readiness-Semantik und Rolling-Parameter auf demselben Change-Ticket folgen Liveness-Kills beim Cold Start, depends_on, das Container aber nicht Readiness abwartet, oder Provider-429, fälschlich als totes Gateway mit endlosen Restarts. Der Artikel grenzt sich zum Docker-Produktions-Runbook, zur Upgrade- und Migrations-Checkliste und zu Provider-Routing und Failover ab und liefert sechs RCA-taugliche Fallen, eine Matrix für Liveness/Readiness/Startup, Compose-gegen-Kubernetes-Zuordnung, kopierbare YAML-Snippets, ein Sechs-Schritte-Rollout-Runbook und drei Dashboard-Kennzahlen—plus Einordnung des Gateways auf einer stabilen Remote-Mac-Ausführungsebene.
Aktuelle OpenClaw-Releases ergänzen HTTP-Endpunkte für Orchestrierung (exakte Pfade und Ports folgen Ihrem fixierten Image-Tag und den Release Notes; Namen wie /health, /ready, /healthz tauchen im Ökosystem auf). Diese sechs Muster in RCAs festhalten und Begriffe aus Doctor und Post-Install-Triage wiederverwenden.
depends_on ohne Health-Bedingungen: Abhängige starten, während das Gateway noch keinen Backend-Socket erreicht—sporadische 502.127.0.0.1 im Pod ok, ClusterIP scheitert—wird als App-Fehler gelesen.maxUnavailable: alte Pods weg, bevor neue Readiness bestehen—kurze Voll-Ausfall-Fenster.Im Vergleich zum plattformübergreifenden Installationsleitfaden: Installation beantwortet ersten Start; Produktion beantwortet langfristigen Betrieb; dieser Text beantwortet wie Orchestratoren „gesund“ entscheiden; Upgrades beantworten Image-Wechsel und Rollback.
Kubernetes-Probe-Typen entsprechen nicht 1:1 Docker-Healthcheck-Restarts; die Tabelle in Architekturreviews nutzen.
| Check | Typischer Effekt bei Fehler | Prüft | OpenClaw-orientierte Leitplanken |
|---|---|---|---|
| startupProbe | unterdrückt Liveness-Fehler bis Erfolg | langsamer, aber begrenzter Cold Start | nutzen, wenn erster Config-Fetch, Indizes oder Abhängigkeiten Minuten brauchen |
| livenessProbe | Container/Pod neu starten | Deadlocks, nicht antwortender Prozess | externe LLM-Abhängigkeiten vermeiden; minimaler Self-Check |
| readinessProbe | aus Service-Endpoints nehmen | nicht trafficbereit | kann minimalen Model-Ping oder „Config geladen“ enthalten—an Failover-Politik angleichen |
| Docker healthcheck | unhealthy markieren; Restart-Policy variiert | Compose auf einem Host | mit depends_on: condition: service_healthy koppeln (Syntax laut Compose-v2-Doku) |
„Gesund“ in konkrete Felder zu übersetzen, beendet Mitternachtsdebatten.
| Dimension | Docker Compose (Muster) | Kubernetes Deployment |
|---|---|---|
| Probe-Befehl | healthcheck.test mit curl/wget | httpGet oder exec |
| Startup-Toleranz | start_period | startupProbe oder größere initialDelaySeconds |
| Traffic absenken | Proxy/LB-Schicht oder nur Health-Label | readinessProbe steuert Endpoints |
| Rolling | manuelle Compose-Reihenfolge oder externes CD | maxSurge / maxUnavailable / minReadySeconds |
# Beispiele—PORT und Pfade durch Werte aus der Doku zu Ihrem Tag ersetzen
# Docker Compose (Auszug)
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 (Auszug)
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 10
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 30
periodSeconds: 20
Hinweis: Upstream kann /health, /ready, /healthz über 2026.3.x-ähnliche Releases ergänzen oder umbenennen. Vor dem Kopieren der Snippets offizielle Doku zu Ihrem Digest/Tag prüfen und mit curl -v in Staging verifizieren.
127.0.0.1 per docker compose exec oder kubectl exec prüfen, danach über den Service.maxUnavailable versus Wartungsfenster dokumentieren.Auf dem Pfad Linux systemd + Tunnel Tunnel-Health, Loopback-Listener und Upstream-LB-Checks angleichen—sonst entstehen „Tunnel lebt, Gateway hört nicht“-Falschpositive.
kubectl rollout status oder Compose-Upgrade-Logs mit Git-Änderungen korrelieren, um enge Probes von Image-Regressionen zu trennen.
Werden in Gateway-, Ingress- oder Laufzeit-Logs personenbezogene Daten erfasst, sollten Speicherort, Auftragsverarbeitung und Ihre DSGVO-Dokumentation mit Recht und IT kurz abgestimmt sein.
Consumer-Hardware kämpft mit Sleep, Platten-Jitter und ungeplanten OS-Updates—Startzeiten und Probe-Schwellen driften. Zusammen mit Rolling-Fenstern kostet das Bereitschaftszeit. OpenClaw und Agents unter einer erwarteten SLA brauchen dedizierte Rechenleistung, stabilen Egress und burst-freundliche Knoten.
Fragmentiertes Self-Hosting erschwert zudem Multi-Region-Latenz und Vertragsbetrieb: Probe-Tuning plus Host-Reboot-Kopplung tut auf Laptops weh. Für 24/7 beobachtbare, rollbare, rollback-freundliche Gateways schlagen professionelle multi-regionale Apple-Silicon-Cloud-Macs Ad-hoc-Hardware meist. MACCOME bietet Mac Mini M4 / M4 Pro Bare-Metal mit flexiblen Konditionen als Gateway oder gemischter Automatisierungshost—zuerst das Hilfe-Center zu Zugang und Formulierungen, dann Mietpreise und den Mehrregionen-Leitfaden für SKUs.
Pilot: kurzfristig in der Zielregion mieten, Container-Probes, Service-Probes und ein vollständiges Rolling-Übungsspiel fahren, bevor monatliche oder quartalsweise Laufzeiten fixiert werden.
FAQ
Die Probes schlagen fehl, die Control UI lädt—welche Quelle gilt?
Vom Orchestrator konfigurierte URLs und Statuscodes. Für Abrechnungskontext Mietpreise öffnen; für Probes curl im Container in Staging nachstellen.
Wie nutze ich das zusammen mit dem Docker-Produktions-Artikel?
Produktion deckt Volumes und Tokens ab; dieser Text Probes und Rollouts. Beides plus Upgrades an dasselbe Ticket hängen.
Soll 429 die Liveness treffen?
In der Regel nein—Provider-Routing und Failover für Backoff und Routing; Readiness-Kopplung ist eine bewusste SLO-Wahl.