En 2026, beaucoup d'équipes combinent un plan de contrôle Linux sous Kubernetes avec des hôtes macOS pour la build ou la passerelle : le cluster orchestre l'API, les runners restent sous launchd ou Actions auto-hébergées. Ici, la moitié cluster : faire passer un service de type OpenClaw d'un namespace de démo à un objet d'astreinte — Helm face aux apply scriptés, sondes adaptées au warm-up, rotation des Secrets sans fichiers périmés, et un CrashLoopBackOff reproductible. Enchaînez avec 2026 — OpenClaw : manuel pas à pas du déploiement et de l'intégration automatisée — agents multiplateformes hors ligne, droits d'exécution et collaboration GitHub Actions multi-machines pour jetons et runners ; pour launchd hors cluster, 2026 — Manuel de stabilité launchd pour la passerelle OpenClaw : triade doctor/status/journaux, ports occupés et conflits de doubles LaunchAgent — procédures reproductibles sur Mac distant toujours allumé dans le même runbook que vos manifests.
1. Charts Helm contre manifests et scripts
Helm gagne lorsqu'il faut des releases reproductibles : fichiers de valeurs par environnement, versions de chart épinglées dans la CI, et sémantique helm upgrade --install qui tolère mieux les échecs partiels qu'une cascade de shell. Le chart devient aussi l'endroit naturel pour documenter les défauts à côté des templates plutôt que d'éparpiller des commentaires dans du bash. Les manifests YAML purs avec Make ou bash restent attractifs pour les empreintes minimes : moins de pièces mobiles, revue de sécurité plus simple pour les équipes méfiantes envers la logique de templating, et GitOps direct si vous rendez déjà avec Kustomize ou cdk8s avant d'appliquer.
Choisissez Helm lorsque plusieurs ingénieurs touchent le même Deployment et que les rollbacks comptent ; restez sur des scripts lorsqu'un seul mainteneur possède peu de fichiers. La CI doit exécuter l'apply ; les portables ne sont pas des consoles de production.
kubectl apply artisanales avec retries.2. Sondes alignées sur un warm-up de passerelle réel
Les processus de type OpenClaw paient souvent une taxe de démarrage à froid : matériel TLS, découverte de plugins ou allers-retours vers un gestionnaire de secrets. Une livenessProbe naïve sur /healthz qui tire après deux secondes fera osciller le Pod pendant que le binaire est encore honnête. Utilisez une startupProbe généreuse qui partage le même handler que la readiness mais autorise plusieurs minutes d'échec pendant le warm-up, puis une readinessProbe stricte pour que le Service n'envoie du trafic que lorsque le travail peut réussir. Réservez la livenessProbe aux interblocages — si les deux sondes diffèrent, assurez-vous que la liveness ne peut pas passer lorsque le processus est bloqué sur un mutex.
Journalisez les échecs de sondes avec horodatage pour corréler kubectl describe pod et les journaux. Si le TLS se termine devant le Pod, pointez les probes vers le port conteneur, pas le nom d'hôte ingress.
3. Rotation des Secrets sans surprises
Kubernetes met à jour les volumes Secret des Pods en cours d'exécution éventuellement ; beaucoup d'applications gardent des descripteurs de fichiers ouverts et ne relisent jamais des certificats tournés. Pour les jetons qu'OpenClaw consomme, préférez des volumes projetés avec chemins explicites et crochets de rechargement, ou des variables d'environnement uniquement si la rotation est rare et qu'un rollout est acceptable. Si vous devez tourner sur place, documentez si le binaire accepte un rechargement SIGHUP ; sinon, liez la rotation à un rollout du Deployment pour que chaque réplica absorbe les octets au même stade du cycle de vie.
Automatisez avec CSI ou External Secrets, et gardez une recette break-glass kubectl create secret generic ... --dry-run=client -o yaml | kubectl apply -f - dans le dépôt du chart.
4. Reproduire CrashLoopBackOff volontairement
Formez les opérateurs juniors en cassant la préproduction. Fixez la commande du conteneur sur un chemin binaire déplacé après bump d'image, ou injectez une variable d'environnement qui force une sortie immédiate non nulle. Observez kubectl get pods -w passer en CrashLoopBackOff, puis enchaînez le triage : kubectl logs pod --previous pour le dernier crash, kubectl describe pod pour les intervalles de backoff, et kubectl get events --field-selector involvedObject.name=<pod> pour le bruit d'ordonnancement. Retirez la faute, bumppez une annotation du Deployment pour forcer la réconciliation, et vérifiez que les compteurs du ReplicaSet reviennent à la valeur désirée.
Causes fréquentes : OOMKilled (137), ConfigMap montée avec clés manquantes, securityContext trop strict. Documentez chaque scénario une fois pour l'astreinte.
5. Checklist production prête à coller
- Le répertoire chart ou manifeste n'est appliqué que depuis la CI ; les kubeconfigs production sont courts et étroitement scopés.
startupProbecouvre le boot lent ;readinessProbeconditionne le trafic du Service ;livenessProbereste conservatrice.- Le chemin de rotation des Secrets est documenté, y compris redémarrage des Pods ou rechargement des fichiers.
- Les étapes du lab CrashLoopBackOff vivent dans le même dépôt que le chart Helm ou l'overlay Kustomize.
- Les passerelles hébergées sur Mac disposent encore d'un runbook
launchdafin que les incidents Linux et Darwin ne partagent pas une seule procédure confuse.
Pourquoi le Mac mini reste central à côté de votre cluster
Kubernetes ordonnance surtout du Linux ; le macOS reste sur du matériel réel. Un Mac mini offre Unix natif pour éditer des charts, un kind local et le SSH vers passerelles sans friction WSL. Apple Silicon allie monothread solide et idle bas ; Gatekeeper, SIP et FileVault durcissent l'automatisation exposée.
Pour un poste silencieux qui retouche Helm et exécute vos scripts, le Mac mini M4 reste le meilleur compromis. Besoin de capacité hors bureau ? Ouvrez la page d'accueil Macstripe et alignez régions avec l'ingress du cluster et vos runners.
