Sheeternetes против Kubernetes, Docker Swarm и Nomad: первое нагрузочное тестирование и реальные бенчмарки
Вопрос о любом оркестраторе рано или поздно упирается в производительность: сколько контейнеров он способен обслуживать, как быстро реагирует на изменения и какой объём данных выдерживает его control plane. Для Sheeternetes этот вопрос особенно интересен: его управляющая часть полностью размещена внутри электронной таблицы.
Именно поэтому команда проекта провела нагрузочное тестирование и сравнила результаты с привычными системами оркестрации. В испытаниях участвовали два варианта хранения - локальная книга `.xlsx` и Google Sheets, - а также синтетические данные на ноутбуке и реальные Docker-образы на облачной виртуальной машине.
Краткий вывод оказался ожидаемым лишь частично. По параметрам, связанным с масштабированием, Sheeternetes уступает Kubernetes, Docker Swarm и Nomad на несколько порядков. Зато в сценариях, где важны наглядность, переносимость состояния и управление инфраструктурой через привычную таблицу, проект предлагает необычную альтернативу.
Как устроен Sheeternetes
Sheeternetes - экспериментальный оркестратор контейнеров, в котором Deployments, Nodes, Pods, Events, Images и Layers представлены отдельными вкладками электронной таблицы. Планировщик читает значения из ячеек, рассчитывает желаемое состояние и записывает результат обратно. На другом конце находятся настоящие Docker-контейнеры, а не их симуляция.
Таким образом, таблица здесь не является отчётом или визуализацией уже работающего кластера. Она выполняет роль самого control plane. Основной процесс `apiserver.py` объединяет функции API-сервера и планировщика Kubernetes. Он работает с книгой через `openpyxl`, запускает reconcile на каждом heartbeat кубелета и обновляет список требуемых подов.
Архитектура сознательно построена вокруг одного процесса, одной книги и одного writer. Это одновременно сильная сторона концепции и её главный предел: вся нагрузка проходит через последовательную обработку одного файла.
Проект развивается в рамках Sheet-Native Computing Foundation - инициативы, посвящённой приложениям, где электронные таблицы используются как исполняемая среда и хранилище состояния. В экосистему входят стандарт контейнеров SICF, демонстрационные проекты и инструменты упаковки образов.
Что именно проверяли
Тестовая программа состояла из четырёх направлений:
- число подов в одной книге;
- размер контейнерного образа, который можно сохранить в ячейках;
- количество независимых кластеров, обслуживаемых одним хостом;
- максимальная длина строки в ячейке.
Подробное [нагрузочное тестирование Kubernetes, Docker Swarm и Nomad](https://habr.com/ru/articles/1078406/?utm_campaign=1078406&utm_source=habrahabr&utm_medium=rss) обычно оценивает не только скорость обработки объектов, но и сетевые задержки, отказоустойчивость, восстановление после сбоев и горизонтальное масштабирование. В случае Sheeternetes исследование сосредоточилось на базовой пропускной способности его табличного control plane.
Для экспериментов использовались Mac, облачная VM с Docker и утилита `sheetbuild`, предназначенная для упаковки SICF-образов. Важной частью стали не только синтетические тесты, но и обратная проверка: образ удаляли с машины, затем восстанавливали исключительно из данных, сохранённых в таблице.
Производительность reconcile
На небольших и средних объёмах обработка объектов демонстрирует почти линейную зависимость от количества подов. Средняя стоимость составляет около 0,022 мс на один pod.
| Поды | Reconcile | Размер файла | Пиковая RAM |
|---:|---:|---:|---:|
| 1 000 | 0,030 с | 0,03 МБ | 0,9 МБ |
| 5 000 | 0,110 с | 0,11 МБ | 8,9 МБ |
| 10 000 | 0,224 с | 0,21 МБ | 12,9 МБ |
Десять тысяч подов обрабатываются примерно за 0,22 секунды, а сама книга занимает около 0,21 МБ. При этом ограничение связано не с форматом Excel: технически он способен хранить значительно больше строк. Потолок задаёт необходимость перечитывать, изменять и сохранять всю книгу на каждом heartbeat.
Линейная экстраполяция даёт около 2,2 секунды на цикл для 100 тысяч подов. На таком уровне задержка уже становится заметной, а при дальнейшем росте кластера последовательная модель обработки превращается в основное узкое место.
Контейнерные образы внутри ячеек
Вторая серия экспериментов была посвящена SICF-образам. Слои кодируются в Base64, адресуются по SHA-256 и хранятся непосредственно в ячейках книги.
Для синтетических тестов использовались плохо сжимаемые данные. Затем результаты проверили на реальных образах Docker. Скорость импорта составила примерно 0,06 секунды на мегабайт. Экспорт выполнялся в два-три раза быстрее. Итоговый размер `.xlsx` оказался сопоставим с архивом, созданным через `docker save`: увеличение Base64 компенсировалось ZIP-сжатием книги.
Наиболее показателен следующий round-trip:
1. Docker-образ импортируется в таблицу.
2. Локальная копия удаляется командой `docker rmi`.
3. Образ экспортируется обратно из ячеек.
4. Выполняется `docker load`.
5. Контейнер запускается и проверяется.
| Образ | Размер tar | Импорт | Экспорт | Строк Layers | Проверка |
|---|---:|---:|---:|---:|:---:|
| `alpine:latest` | 4 МБ | 0,30 с | 0,15 с | 172 | Пройдена |
| `nginx:alpine` | 29 МБ | 1,67 с | 0,68 с | 1 285 | Пройдена |
| `python:3.12-slim` | 47 МБ | 2,88 с | 0,96 с | 2 056 | Пройдена |
Удаление локального образа между импортом и экспортом важно методологически: восстановленный контейнер действительно был собран из данных таблицы. Целостность подтверждалась тремя способами - внутренней проверкой SHA-256 в `sheetbuild`, валидацией Docker и фактическим запуском контейнера.
Где Sheeternetes проигрывает
Если рассматривать производительность оркестрации контейнеров в промышленном смысле, Sheeternetes не может конкурировать с Kubernetes, Docker Swarm или Nomad. У зрелых оркестраторов распределённая архитектура, независимые компоненты control plane, репликация состояния и механизмы горизонтального масштабирования.
В Sheeternetes запись в одну книгу становится общей точкой конкуренции. Чем больше объектов и чаще происходят изменения, тем выше стоимость полного цикла обработки. Нет привычного разделения на API-сервер, планировщики, контроллеры и распределённое хранилище. Поэтому прямое сравнение Kubernetes, Docker Swarm и Nomad по производительности показывает разрыв в пользу специализированных платформ.
В рамках запроса "Kubernetes или Docker Swarm или Nomad - что выбрать" для production-среды ответ обычно зависит от требований к отказоустойчивости, экосистеме и сложности эксплуатации. Sheeternetes в эту тройку не встраивается как универсальная замена: его ниша - демонстрационные стенды, учебные эксперименты, переносимые конфигурации и необычные сценарии управления через таблицу.
Где проект выигрывает
Главное преимущество Sheeternetes - прозрачность. Состояние кластера можно открыть и рассмотреть в привычном интерфейсе: увидеть поды, образы, события и узлы без дополнительных dashboard-систем. Для обучения это особенно удобно: каждое изменение видно непосредственно в структуре данных.
Второе достоинство - переносимость. Книга выступает одновременно конфигурацией, хранилищем состояния и контейнерным архивом. Её можно сохранить, передать другому пользователю, сравнить с предыдущей версией или использовать как воспроизводимый артефакт эксперимента.
Наконец, проект наглядно показывает, насколько сильно выбор архитектуры определяет итоговые показатели. Эти бенчмарки оркестраторов контейнеров не доказывают, что таблицы способны заменить распределённые системы. Напротив, они демонстрируют цену удобства, визуальности и простоты входа.
Что означают результаты
Итоги тестов можно разделить на две группы. По числу объектов, скорости reconcile, работе с несколькими кластерами и устойчивости к постоянным изменениям Sheeternetes существенно уступает зрелым решениям. Это закономерно: один процесс и одна книга не рассчитаны на роль высоконагруженной распределённой платформы.
Зато эксперимент с образами оказался практичнее, чем можно было ожидать. Sheeternetes способен упаковать реальные Docker-образы в таблицу, восстановить их после удаления локальной копии и запустить контейнеры без потери целостности. Для лабораторных демонстраций и переносимых стендов это необычный, но рабочий подход.
В итоге ответ на вопрос "Kubernetes или Docker Swarm или Nomad" нельзя свести к одному числу. Если нужны масштабирование и отказоустойчивость, следует выбирать специализированный оркестратор. Если же требуется максимально наглядная модель кластера, воспроизводимый табличный артефакт или эксперимент на стыке DevOps и spreadsheet computing, Sheeternetes становится любопытным инженерным полигоном. Именно в таком контексте [сравнение Kubernetes, Docker Swarm и Nomad по производительности](https://habr.com/ru/articles/1078406/?utm_campaign=1078406&utm_source=habrahabr&utm_medium=rss) помогает увидеть не только победителей, но и границы каждого архитектурного подхода.
