AnalysisRun от контура Flux (ImageUpdateAutomation, Receiver, webhook в Git и на шлюз). Здесь — Flux: теги, канареечное расщепление, пробы, bearer с overlap и merge openclaw doctor. Ниже — отличия от Rollouts-материала, матрица, шесть шагов и FAQ.
Три узких места до первой успешной канарейки
На практике ломается не столько сам Kubernetes API, сколько согласованность между notification-controller, сетевым ingress на Mac и политикой секретов. Ниже — типовые провалы, которые видит платформенная смена.
- 1. Дрейф токена. Статический bearer в ConfigMap без календаря ротации и overlap даёт серию
401в момент, когда ImageUpdateAutomation уже отправил webhook, а шлюз ещё не перечитал секрет. - 2. Ложная канарейка. Процентное расщепление без заголовка корреляции и без отдельной ветки проб приводит к ситуации, когда метрики «зелёные», а бизнес-функция на периметре OpenClaw всё ещё на старой ревизии из-за кэша на одном из узлов clustervps.
- 3. Шум без digest. Сырой поток ошибок из Receiver и из пробы шлюза перегружает чат дежурств; без усечённого JSON digest и без merge doctor невозможно понять, это инфраструктура региона или регрессия образа.
Матрица: Flux ImageUpdateAutomation против Argo Rollouts в этом сценарии
Явно фиксируем границу ответственности, чтобы не дублировать контур, описанный в статье про Rollouts: там триггер — AnalysisRun, здесь — GitOps commit после обновления манифеста образа.
| Критерий | Flux + ImageUpdateAutomation | Argo Rollouts |
|---|---|---|
| Триггер продвижения | Webhook Receiver → reconcile → новый тег в Git | Canary step / AnalysisRun / manual promote |
| Источник политики тега | ImagePolicy + semver / regex | Обычно Helm values или отдельный image updater |
| Граница канарейки | Шлюз OpenClaw: процент, cookie, заголовок | Сервисный mesh / веса Service |
| Типовой риск | Рассинхрон секрета и ingress на Mac-узле | Залипание метрик AnalysisRun |
Контракт webhook: заголовки, тело, идемпотентность
Контракт в Git рядом с Flux: POST, путь /hooks/flux/image, Authorization: Bearer, поле digest как ключ идемпотентности. Шлюз OpenClaw на узле clustervps отвечает 202 после постановки в очередь — иначе notification-controller задушит ретраями.
Тело — плоский JSON: репозиторий, namespace, ImageUpdateAutomation, старый и новый тег, unix-время. Без сырого CI в webhook: иначе шум на Mac mini M4 и слабый digest.
Срезы конфигурации многоузлового кластера
На регион clustervps — свой values: ingress URL, таймауты проб, доля канарейки, каталог состояния OpenClaw. Каркас в Git, срезы через kustomize overlay без ручного YAML по SSH.
- Метка региона в каждом артефакте
doctorпосле merge — обязательна для корреляции с digest. - Секреты только из внешнего хранилища; на узле храните лишь ссылку и срок действия.
- Очередь webhook с ограничением параллелизма «один активный образ на шард», чтобы не смешивать два semver в одном окне канарейки.
Пробы канарейки на шлюзе: пороги отказа и откат
Пробы — через ту же TLS/SNI/маршрут, что и клиент. Три не-2xx подряд за 30 с закрывают канарейку; jitter backoff гасит краткий джиттер до Mac-узла.
Задержка доставки логов в стор — предупреждение без аварийного отката, чтобы не путать сеть и регрессию кода.
Широковещание digest сбоев: что уходит в канал дежурств
Digest: digest, регион, код пробы, тело ответа шлюза до 2 КБ, хвост лога OpenClaw, фрагмент openclaw doctor. Тот же адаптер, что при promote, но другой severity и дедуп ключом (digest,region,probe) за 15 минут.
Шесть шагов минимальной воспроизводимости
- Секрет bearer: создать
Secretс двумя ключами для overlap, смонтировать в notification-controller и в конфигурацию шлюза на каждом узле clustervps; календарь ротации — в runbook. - Receiver + ImageUpdateAutomation: включить фильтр репозитория, semver-политику и путь webhook на ingress; проверить руками
curlс токеном из staging. - Канареечное расщепление: задать процент и заголовок
X-Canary: 1для внутренних проб; стабильный трафик остаётся на предыдущей ревизии до ручного или автоматического promote. - Пробы: описать три последовательных проверки с разными путями API; порог отказа и таймауты вынести в срез региона.
- Merge
openclaw doctor: на каждом узле запуск поlaunchdили CI после деплоя; результаты склеить скриптом с нормализацией кодировки UTF-8 и меткой региона. - Digest и алерт: подключить адаптер к чату дежурств; при успешном promote отправлять короткое резюме, при провале — полный digest из предыдущего раздела.
FAQ: Flux, OpenClaw и эксплуатация на Mac-узлах
- Нужен ли отдельный контроллер канарейки в кластере? В описанной схеме нет: веса и проценты живут на шлюзе OpenClaw, а Flux гарантирует доставку манифеста с новым тегом.
- Как не перепутать с Argo Rollouts? Если нужен
AnalysisRunи пошаговый анализ метрик под контролем Rollouts — используйте другой runbook; здесь акцент на ImageUpdateAutomation и Receiver. - Что делать при шторме 401? Проверить overlap секрета, кэш ingress и расхождение часов NTP между узлами clustervps.
- Обязателен ли merge doctor перед promote? Для межрегиональной пары узлов — да: иначе вы не отличите локальный сбой диска от регрессии образа.
Итог для GitOps-команды
Когда Flux владеет политикой тега, а OpenClaw — периметром канарейки и пробами, вы получаете тонкий, проверяемый контур без дублирования Argo Rollouts. Срезы по регионам, строгий контракт webhook, bearer с overlap и merge openclaw doctor снимают типовой хаос многоузловой среды на clustervps. Закрепите digest сбоев как обязательный артефакт смены — тогда дежурство перестаёт гадать по сырому логу.