2026 — OpenClaw Gateway : sondes de santé intégrées (/health, /ready) et équilibrage de charge — alignement sur Mac physique distant, Docker Compose et Kubernetes ; masquage de chemins et faux « non prêt » : runbook reproductible (extraits + FAQ)

1. Points de friction : shadowing, dérive et « mensonges » de l’équilibreur

1. Masquage de chemins. Un location / statique, un fallback SPA ou un try_files agressif peut renvoyer 200 OK en HTML pour /ready sans jamais joindre OpenClaw. Le pool semble chaud ; la passerelle n’a pas vu la sonde.
2. Dérive sémantique entre plateformes. Compose marque un service sain quand la sonde moteur réussit ; Kubernetes peut router vers une autre révision si les sélecteurs se chevauchent, ou si un Ingress envoie les sondes vers un backend canary non intentionnel.
3. Coût caché d’audit et de stabilité. Réutiliser /ready pour la liveness couple les pannes de dépendances aux redémarrages de pods. Sur un parc de Mac distants, cela se traduit par du flapping Screen Sharing, des états d’agents à moitié écrits et une astreinte bruyante — pas « juste Kubernetes ».

2. Matrice : où faire tourner chaque sonde

Utilisez ce tableau en revue de conception avant de coller du YAML en production. La question est : « qui doit observer quoi ? »

3. Runbook d’alignement en sept étapes

1. Recenser les appelants. Exportez chaque URL de santé depuis le LB cloud, le bloc server_name nginx, le fichier Compose, les values Helm et le monitoring ad hoc. Toute ligne vide est un angle mort.
2. Prouver le shadowing. Depuis l’hôte proxy, curl -svH 'Host: votre.api' https://127.0.0.1/ready et différenciez le corps d’un curl direct vers le port passerelle en loopback.
3. Épingler les locations avant les catch-all. Des location = /health et location = /ready avec proxy_pass vers l’upstream passerelle, proxy_buffering off; et add_header Cache-Control no-store;.
4. Compose : caler les timeouts sur le LB. Réglez interval, timeout et retries dans ~80 % de ce qu’impose le LB externe pour ne pas marquer sain trop tôt.
5. Kubernetes : séparer les probes. Liveness sur /health, readiness sur /ready, et startupProbe avec failureThreshold plus large pour le warm-up du routeur de modèles.
6. Répétition générale de rollout. Bleu/vert ou rolling : surveillez kubectl get endpoints en suivant les journaux passerelle ; le trafic ne doit bouger qu’après bascule de /ready sur la nouvelle révision.
7. Archiver les diffs. Conservez nginx -T expurgé, le YAML Compose et les extraits kubectl describe pod horodatés — votre futur vous remerciera au prochain faux NotReady.

4. Extraits de configuration

4.1 nginx : locations de sonde explicites (sans shadowing)

location = /health { proxy_pass http://openclaw_gateway; proxy_http_version 1.1;
  proxy_set_header Host $host; proxy_buffering off; add_header Cache-Control "no-store"; }
location = /ready  { proxy_pass http://openclaw_gateway; proxy_http_version 1.1;
  proxy_set_header Host $host; proxy_buffering off; add_header Cache-Control "no-store"; }

4.2 Docker Compose : healthcheck + dépendance

services:
  openclaw-gateway:
    image: votre.registre/openclaw-gateway@sha256:…
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:18789/health"]
      interval: 15s
      timeout: 3s
      retries: 5
      start_period: 120s
  edge-proxy:
    depends_on:
      openclaw-gateway:
        condition: service_healthy

4.3 Kubernetes : startup + readiness + liveness

startupProbe:
  httpGet: { path: /ready, port: http }
  periodSeconds: 5
  failureThreshold: 30
readinessProbe:
  httpGet: { path: /ready, port: http }
  periodSeconds: 10
  timeoutSeconds: 3
livenessProbe:
  httpGet: { path: /health, port: http }
  periodSeconds: 20
  timeoutSeconds: 2

Adaptez port: http au nom du containerPort. Si le TLS se termine à l’Ingress, gardez les probes sur le port clair du conteneur sauf sidecar mesh imposant du TLS.

5. Paramètres prêts à citer

• 18789 — surface HTTP courante de la passerelle OpenClaw sur les nœuds Mac ; confirmez toujours via openclaw.json ou les notes de version avant de figer les modèles LB.
• 120 s de start_period — premier ordre de grandeur utile pour cache modèle froid et latence de montage Secret sur Mac distants ; affinez avec le P95 mesuré sur deux semaines de métriques.
• 3 s de timeout readiness — compromis entre upstreams lents et agressivité du kubelet ; couplez avec failureThreshold plutôt qu’avec des timeouts illimités qui masquent les blocages réels.

6. FAQ : faux positifs reproductibles

7. Mac mini : héberger cette complexité sans la subir

Les sémantiques de santé de la passerelle n’ont de valeur que si l’hôte reste debout : les Mac mini Apple Silicon combinent une très faible consommation au repos (souvent de l’ordre de quelques watts), un fonctionnement silencieux adapté aux bureaux et baies, et une chaîne d’outils Unix — curl, launchctl, Docker Desktop ou Colima, SSH — sans la friction pilote typique des flottes Windows.

Gatekeeper, SIP et FileVault réduisent aussi le risque de falsification pour les jetons d’agent de longue durée stockés à côté de la passerelle. Ce niveau de confiance compte lorsque /ready est le signal par lequel l’équilibreur expose votre automatisation à Internet.

Si vous voulez cette histoire de sondes et d’équilibrage sur du matériel que vous pouvez laisser sans opérateur sur site, le Mac mini M4 constitue une base 2026 solide — utilisez ensuite le bandeau ci-dessous pour comparer les nœuds ZoneMac prêts passerelle et déployer avec les mêmes curls d’acceptation que vous venez de documenter.