2026 OpenClaw Gateway: health checks и rolling updates
Docker Compose, пробы Kubernetes, runbook без простоя

Около 20 минут чтения · MACCOME

Команды, которые крутят OpenClaw Gateway в Docker или Kubernetes, в 2026 году часто выкатывают быстро, но по-прежнему принимают «контейнер запущен» за «здоров». Без HTTP-путей проб, семантики readiness и параметров rolling на том же тикете получаются убийства liveness на холодном старте, depends_on, который ждёт контейнеры, но не готовность, или 429 от провайдера, ошибочно принятый за мёртвый Gateway и бесконечные рестарты. Текст увязан с runbook по Docker в продакшене, чеклистом апгрейда и миграции и маршрутизацией и failover провайдеров; даны шесть типовых ловушек для RCA, матрица liveness/readiness/startup, сопоставление Compose и Kubernetes, фрагменты YAML, шестишаговый runbook выката и три метрики для дашборда, плюс размещение Gateway на стабильной плоскости удалённого Mac.

От «порт слушает» к корректной семантике: шесть ловушек проб

Свежие релизы OpenClaw добавляют HTTP-эндпоинты, удобные для оркестраторов (точные пути и порты — по вашему зафиксированному образу и release notes; в экосистеме встречаются имена вроде /health, /ready, /healthz). Фиксируйте шесть сценариев в RCA и используйте ту же лексику, что в doctor и постинсталляционном триаже.

  1. Liveness бьёт в «процесс есть, бизнес не готов»: на холодном старте поднимаются таблицы маршрутизации или локальное состояние — слишком ранний 200 пускает трафик; слишком ранний fail даёт убийства kubelet.
  2. Readiness завязана на внешние модели: троттлинг может снимать нагрузку со всего кластера — проверьте, что это совпадает с SLO, а не с глобальным отказом.
  3. Compose depends_on без условий health: зависимые сервисы стартуют, пока Gateway ещё не держит backend-сокет — плавающие 502.
  4. Пробы на localhost и пути Service расходятся: 127.0.0.1 в Pod работает, ClusterIP — нет; ошибочно трактуют как падение приложения.
  5. Агрессивный maxUnavailable: старые Pod уходят до того, как новые проходят readiness — короткие окна полного отказа.
  6. Триаж логов смешивает слои: TLS на edge, таймауты прокси и ошибки Gateway сливаются — пробы ужесточают вслепую.

Относительно кроссплатформенного гайда по установке: установка закрывает первый запуск; продакшен — долгую эксплуатацию; эта статья — как оркестратор решает «здоров»; апгрейды — смену образа и откат.

Таблица 1: liveness, readiness и startup — разделение ответственности

Типы проб Kubernetes не совпадают один в один с рестартами Docker healthcheck; таблицу используйте на архитектурных ревью.

ПроверкаТипичный эффект при сбоеЧто валидируетОриентир для OpenClaw
startupProbeПодавляет сбои liveness до успехаМедленный, но ограниченный cold startКогда первая загрузка конфигурации, индексы или зависимости занимают минуты
livenessProbeПерезапуск контейнера или PodДедлок, неотвечающий процессБез внешних LLM; минимальная самопроверка
readinessProbeИсключение из endpoints ServiceНе готов к трафикуДопустим лёгкий ping модели или сигнал загрузки конфигурации — согласовать с политикой failover
Docker healthcheckПомечает unhealthy; рестарт зависит от политикиОднохостовый ComposeСочетать с depends_on: condition: service_healthy (синтаксис по доке Compose v2)

Таблица 2: одно требование к здоровью в Compose и в Kubernetes

Явная формулировка «здоров» снимает споры в ночных инцидентах.

ИзмерениеDocker Compose (паттерн)Deployment в Kubernetes
Команда пробыhealthcheck.test с curl/wgethttpGet или exec
Грейс на стартеstart_periodstartupProbe или больший initialDelaySeconds
Снятие трафикаСлой прокси/LB или только метка healthreadinessProbe управляет Endpoints
RollingРучной порядок compose или внешний CDmaxSurge / maxUnavailable / minReadySeconds
yaml
# Примеры: подставьте 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
warning

Внимание: upstream может добавлять или переименовывать /health, /ready, /healthz в релизах вроде 2026.3.x. Перед копированием сниппетов сверьтесь с официальной документацией для вашего digest/тега и проверьте curl -v на staging.

Шестишаговый runbook выката: от curl 200 к rolling update с откатом

  1. Зафиксируйте якорь версии: digest образа или минорный тег плюс задокументированные health-пути и порты.
  2. Проверьте внутри контейнера: проба 127.0.0.1 через docker compose exec или kubectl exec, затем через Service.
  3. Сначала readiness, потом liveness: стабилизируйте readiness и startup, затем ужесточайте liveness, чтобы не ловить убийства на старте.
  4. Настройте rolling: держите хотя бы одну реплику в сервисе; зафиксируйте maxUnavailable относительно окна обслуживания.
  5. Согласуйте failover провайдера: задокументируйте поведение при внешнем сбое модели — снятие нагрузки, деградация модели или только алерт — по статье о провайдерах.
  6. Отработайте откат: по чеклисту апгрейда перетегируйте образ и восстановите тома; убедитесь, что пробы совпадают со старой сборкой.

Три жёсткие метрики для дашборда и дежурства

  1. Триплет пробы: HTTP-код, перцентиль задержки, число подряд идущих сбоев — рядом с долей 502 на Ingress.
  2. Готовые реплики / желаемые во время деплоя: алерт на длительность, пока readiness ниже 100%; частые мелкие релизы сжимают это окно.
  3. Доля ошибок внешних зависимостей: 429/5xx от провайдеров против внутренних ошибок Gateway — общие поля со статьёй о маршрутизации.

На пути Linux systemd + Tunnel согласуйте health туннеля, loopback-слушатели и проверки upstream LB — иначе возможны ложноположительные «туннель жив, Gateway не слушает».

Сопоставляйте kubectl rollout status или логи апгрейда compose с изменениями в Git, чтобы отделить слишком жёсткие пробы от регрессий образа.

Почему бытовой NAS или запасные ноутбуки плохо держат продакшен-семантику проб

Потребительское железо борется со сном, джиттером диска и внеплановыми обновлениями ОС — время старта и пороги проб плывут. Вместе с окнами rolling это сжигает часы дежурства. Для OpenClaw и агентов под ожидаемым SLA нужны выделенные вычисления, стабильный egress и узлы с запасом по пику.

Разрозненный self-hosting усложняет мультирегиональную задержку и контрактные условия: на ноутбуках связка тюнинга проб и перезагрузок хоста болезненна. Для наблюдаемых, roll-friendly и откатываемых Gateway профессиональные мультирегиональные облачные Mac на Apple Silicon обычно выигрывают у нерегламентированного железа. MACCOME предлагает Mac Mini M4 / M4 Pro bare-metal на гибких условиях как узел Gateway или смешанной автоматизации — начните с центра помощи по языку доступа, затем тарифами аренды и мультирегиональным гайдом для финализации SKU.

Пилот: краткосрочная аренда в целевом регионе, прогон контейнерных проб, проб Service и одного полного rolling-упражнения до фиксации помесячных или квартальных условий.

Вопросы

Пробы падают, но UI открывается — что считать источником истины?

URL, метод и код, заданные оркестратором. Для коммерческого контекста откройте тарифы аренды; для проб воспроизведите curl внутри контейнера на staging.

Как использовать вместе со статьёй про Docker в продакшене?

Продакшен — про тома и токены; здесь — про пробы и выкаты. Прикрепите оба материала и апгрейды к одному изменению.

Должен ли 429 бить liveness?

Как правило нет — см. маршрутизацию и failover провайдеров для backoff и маршрутов; связка readiness с внешней моделью — осознанный выбор SLO.