Ограничения

Что nkt сознательно не делает или пока не умеет.

Платформа

• Только Linux (amd64, arm64, 32-битный ARM). На Windows и macOS работает только режим снапшота fixtures.
• Обновления пакетов ОС, подготовка нового хоста хабом, уязвимости внутри гостей — только Debian/Ubuntu (apt-get, dpkg).

Один хост — одна база

Каждый nkt управляет одним хостом: своя карта, свои конфиги, своя база. Несколько хостов — только через хаб, который проксирует к каждому, а не через общую модель данных.

Сеть и firewall

• Пишутся правила ufw и firewalld; редактирование iptables напрямую намеренно не поддерживается. Читаются iptables/ip6tables, ufw и firewalld — чистый nftables (без слоя iptables-nft) не разбирается.
• Правилу declared-not-listening нужен ss. Оно молчит, если таблица сокетов не подтверждает ни одного объявленного порта (читается другое сетевое пространство имён). Опубликованные порты контейнеров этим правилом не проверяются: при userland-proxy: false Docker пробрасывает их DNAT, слушателя на хосте нет.

Веб-серверы и рантаймы

• Поддерживаются nginx, haproxy и Caddy. Traefik и Envoy потребовали бы нового парсера в internal/parse.
• Классический LXC (lxc-ls/lxc-info) не поддерживается — только LXD. Podman Quadlet не разбирается — виден только список работающих контейнеров.
• Экран по SPICE — только обычный (не только TLS) порт; последовательная консоль машины не передаёт размер окна, гость считает экран 80×24.
• Пароль гостя libvirt ставится через qemu-guest-agent, пользователь должен уже существовать; у LXD недостающий пользователь заводится.

Сертификаты

• Сверка «что реально отдаёт сокет» — одно TLS-соединение на сертификат, к его первому известному адресу. Несколько сертификатов по SNI на одном порту — проверяется первый. В fixtures не выполняется.
• Самоподписанный сертификат не убирает предупреждение браузера. Директивы TLS в конфиг вставляются руками через редактор (с той же проверкой и автооткатом).
• Выпуск Let's Encrypt — --standalone: без wildcard, на время выпуска и продления nginx/haproxy останавливаются.

Уязвимости

• Уязвимости внутри гостей — только пакеты Debian/Ubuntu. У VM LXD пакеты читаются через lxd-agent, у машин libvirt — через qemu-guest-agent; без агента гость пропускается с предупреждением.
• В узле машины на карте ресурсов — последний скан самого хоста; скан, который делает хаб, там не отражается.

Режим fixtures

Проверка конфигов в fixtures всегда «проходит» — путь отказа тестируется на проверочном стенде или на реальном хосте. Пробы и метрики симулируются.

Хаб

• Хаб — единая точка доступа ко всем хостам; относитесь к нему как к машине с продакшен-доступом.
• Одна реплика: реестр — SQLite. Горизонтального масштабирования и отказоустойчивой пары нет — есть экспорт/импорт.
• Кластеры Kubernetes из хаба — экспериментально: отката нет, 3 control plane — только k3s, начинайте с сухого прогона.
• Сценарии — экспериментально: отката нет, произвольных shell-команд в языке намеренно нет.
• Зеркало registry кэширует только публичные образы.

Выкладки

• Сборки образов нет — это дело CI или ваше.
• Опрос и слежение за registry начинаются после первой выкладки кнопкой.

Автоматизация и боты

• API-токены есть только у хаба; одиночный nkt на хосте их не принимает.
• Токену с пределами недоступны конвейеры кластеров и сценариев хаба — только compose-стеки, все хосты которых в его пределах.
• Через nkt-edge — только подписанные запросы токена (Bearer не проходит).
• Бот Telegram опрашивает Telegram сам: один токен бота — один хаб (второй хаб с тем же токеном забирал бы обновления у первого).
• Slack без входа в хаб не работает: нужен nkt-edge с ролью «колбэки» или хаб, доступный из интернета.
• Узел n8n не опубликован в npm: ставится архивом из релиза или сборкой из репозитория.