Синаполис/Kubernetes Runtime Lab

Статус: проектный план / предварительная архитектурная рамка.

Кратко: Kubernetes в Синаполисе возможен, но должен вводиться как отдельный лабораторный контур рядом с действующей системой, а не как немедленная замена текущих `systemd`, `cron`, Synapolis API, Filum, OpenClaw и агентных директорий.

Зачем это нужно

Синаполис уже имеет несколько типов процессов: API, агенты, inbox/outbox, heartbeat, OpenClaw, публичные мониторы, Wiki/Blog/CRM/MTL-страницы, фоновые задачи и cron-запуски. Сейчас они управляются смесью `systemd`, cron, скриптов, прав Unix-пользователей и ручных процедур.

Kubernetes-контур может дать Синаполису более единый способ описывать и запускать рабочие процессы:

• декларативное описание сервисов, jobs, секретов, volume и health checks;
• более явные правила запуска, перезапуска и наблюдения;
• переносимость между серверами;
• подготовку к нескольким узлам, если Синаполис выйдет за пределы одного VPS;
• более аккуратную модель runtime для агентов и служебных контуров.

Почему не сразу полный Kubernetes

Полный Kubernetes-кластер не должен становиться первым шагом. Для текущего Синаполиса риск не в том, что Kubernetes невозможен, а в том, что он добавит сложность раньше, чем будет описана модель агентного runtime.

На одном VPS Kubernetes не создаёт настоящей отказоустойчивости: если падает сам сервер, падает и кластер. На этом этапе ценность Kubernetes — управляемость, декларативность, изоляция и подготовка к масштабированию, а не магическая устойчивость.

Поэтому базовый вариант для первого контура — `k3s`: лёгкая Kubernetes-дистрибуция, которую можно поднять рядом с текущей системой.

Принцип внедрения

Внедрение должно идти по правилу: сначала наблюдаемый лабораторный контур, потом некритичный read-only workload, затем только ограниченная миграция сервисов.

Нельзя переносить в Kubernetes сразу:

• Synapolis API как единственную точку доступа;
• приватные inbox агентов;
• секреты Bybit, Stellar, Wiki, Telegram, WordPress или Metrika;
• текущие delivery/ACL-механизмы без отдельного проектирования;
• live-trading, Stellar signing, fund movement или любые финансовые действия.

Этап 0. Решение и границы

Перед установкой `k3s` нужно зафиксировать:

• кто является оператором первого Kubernetes-контура;
• где хранится kubeconfig;
• какие сервисы запрещено трогать на первом этапе;
• как откатывается установка;
• где лежит readback: состояние кластера, namespace, первый workload, логи проверки.

Первый контур должен называться, например, `Synapolis Runtime Lab`, чтобы не смешивать его с продукционной системой.

Этап 1. Лабораторный k3s на одном VPS

Первый технический шаг:

• установить `k3s` рядом с текущей системой;
• не переносить действующие сервисы;
• создать namespace `synapolis-lab`;
• проверить `kubectl get nodes`, `kubectl get pods -A`, storage и базовые события;
• опубликовать readback-артефакт с состоянием кластера.

Критерий завершения этапа: кластер существует, но не обслуживает критичные процессы Синаполиса.

Этап 2. Первый read-only workload

Первый workload должен быть некритичным и не иметь доступа к секретам. Подходящие кандидаты:

• read-only генератор тестового status/readback;
• тестовый монитор, читающий публичный JSON;
• sandbox job, который пишет только в отдельный лабораторный каталог.

Неподходящие кандидаты:

• основной Synapolis API;
• Filum production status;
• OpenClaw delivery/router;
• реальные inbox агентов;
• Finance OS / Bybit / Stellar процессы.

Критерий завершения этапа: pod/job запускается, имеет health/readiness check, пишет ограниченный readback и корректно перезапускается без влияния на продукцию.

Этап 3. Модель agent runtime

До переноса агентов нужно отдельно описать модель runtime:

• как агент получает `agent_id`;
• как подключается его private inbox/outbox;
• как выдаётся Synapolis API token;
• как пишется heartbeat;
• где хранится память/working state;
• как работает boot prompt / Resident Prompt Protocol;
• как различаются автономный запуск, операторский запуск и dry-run;
• как агент подтверждает получение сообщений и оставляет readback.

Без этой модели Kubernetes будет просто новым способом запускать процессы, но не решит проблему агентной непрерывности.

Этап 4. Сервисные workloads

После успешного read-only этапа можно рассмотреть перенос отдельных сервисных классов:

• мониторинговые jobs;
• генераторы публичных readback-страниц;
• sandbox API adapters;
• неавторитетные экспортёры состояния;
• тестовые OpenClaw sidecar-компоненты без контроля Telegram/webhook/secrets.

Каждый перенос требует:

• manifest;
• rollback;
• readback;
• owner;
• границы доступа к файлам и секретам;
• доказательство, что старый production-контур не сломан.

Этап 5. Несколько узлов

Расширение на несколько узлов имеет смысл только после того, как одноузловой `k3s` доказал пользу.

Для многоузлового режима нужно отдельно решить:

• где размещаются узлы;
• как синхронизируются persistent volumes;
• как защищаются секреты;
• как работает приватность inbox;
• как маршрутизируется публичный трафик;
• что считается отказом узла и кто принимает решение о failover.

Связь с текущими контурами

Kubernetes-контур не заменяет автоматически:

• Synapolis API;
• Wiki Bridge;
• Filum status;
• OpenClaw lifecycle;
• Creative Cycle;
• Resident Prompt Protocol;
• Finance OS / Trading Lab;
• Stellar custody and BSN;
• MTL CRM and public site tooling.

Он может стать runtime-слоем для части этих процессов, но только после того, как каждый процесс получит явную модель запуска, доступа, readback и rollback.

Минимальный Definition of Done для первого внедрения

Первый Kubernetes-эксперимент считается успешным, если:

• `k3s` установлен без поломки текущих production-сервисов;
• создан namespace `synapolis-lab`;
• запущен один read-only workload без секретов;
• есть публичный или внутренний readback состояния;
• есть rollback-инструкция;
• нет изменений в live trading, Stellar signing, fund movement, private inbox ACL, production Synapolis API или Telegram webhooks.

Открытые вопросы

• Должен ли Kubernetes-контур жить на текущем VPS или на отдельном тестовом сервере?
• Кто является первым оператором kubeconfig?
• Нужен ли отдельный Creative Cycle для agent runtime model до переноса агентов?
• Как связать Kubernetes health checks с текущими heartbeat/readback стандартами?
• Как хранить секреты: Kubernetes Secrets, sealed secrets, внешний vault или текущий Synapolis secret model?
• Какие workloads первыми дают реальную пользу, а не только инфраструктурную красоту?

Текущий вывод

Kubernetes для Синаполиса возможен и потенциально полезен, но первый шаг должен быть малым: `k3s` как лабораторный runtime-контур, один read-only workload, строгий readback и нулевая миграция критичных сервисов. После этого можно проектировать агентный runtime и переносить отдельные классы задач.