В одном чате по куберу меня спросили единственное, что реально важно, когда ты собрал оркестратор контейнеров внутри таблицы: а сколько оно вообще тянет? Сколько подов, пока не ляжет. Какой образ влезает в ячейки. Сколько кластеров держит одна машина. И — раз уж мы фонд с серьёзным лицом — как это смотрится рядом с настоящими: Kubernetes, Docker Swarm, Nomad.
Поэтому мы провели честное нагрузочное тестирование. Четыре измерения, два бэкенда (.xlsx на диске и живая Google-таблица), синтетика на ноутбуке и реальные Docker-образы на облачной виртуалке. А потом поставили цифры рядом со взрослыми оркестраторами.
Короткая версия: по каждой оси, которая имеет значение, мы проигрываем на 3–5 порядков. По осям, которые значения не имеют, — выигрываем вчистую. И один наш давний «факт» оказался неверным — бенчмарк нас поправил. Поехали.
Впервые тут? Что это вообще. Sheeternetes — оркестратор контейнеров, у которого весь control plane живёт внутри электронной таблицы: Deployments, Nodes, Pods, Events — это вкладки Google Sheets или Excel, планировщик читает и пишет ячейки, а на другом конце крутятся настоящие Docker-контейнеры. Таблица не симулирует кластер — она и есть кластер. Проект входит в Sheet-Native Computing Foundation (SNCF) — вендор-нейтральный дом для sheet-native computing, работающую пародию на CNCF: 30+ проектов, стандарт контейнеров SICF, верифицируемая сертификация инженеров и живые демо на настоящих таблицах.
Ссылки: sncfoundation.github.io · github.com/sncfoundation · Telegram t.me/stncf · Slack sheetncf · LinkedIn company/sheetncf
Подробности: https://habr.com/ru/articles/1077612/
Что именно мы мерили
apiserver.py — это весь control plane: kube-apiserver + kube-scheduler в одном маленьком Python-процессе. Он читает и пишет книгу (вкладки Deployments/Nodes/Pods/Events/Images/Layers) через openpyxl, гоняет планировщик на каждый heartbeat кубелета и пишет желаемые поды обратно. Один процесс, одна книга, один кластер — и он single-writer, в этом вся суть того, где находится потолок.
Четыре теста:
A — объекты в одной книге. Время reconcile (load + schedule + write + save) vs число подов.
B — SICF-образы в ячейках. Сколько мегабайт образа влезает и какой ценой.
C — число кластеров. Сколько независимых книг-кластеров reconcile’ит один хост.
D — длина строки в ячейке. Сколько символов переживает значение, пока не испортится.
Машины: Mac (лёгкие точки), облачная VM на Cozystack с Docker (round-trip реальных образов) и инструмент sheetbuild из sci для упаковки образов.
A — поды в одной книге
Reconcile строго линеен: около 0.022 мс на под. Десять тысяч подов reconcile’ятся за 0.22 с, а файл — погрешность округления, 0.21 МБ.

поды | 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 МБ |
Формат Excel тут не предел — влезут миллионы строк. Предел — время reconcile одного openpyxl-процесса, потому что он перечитывает и переписывает всю книгу на каждый heartbeat. Экстраполяция: 100k подов ≈ 2.2 с на цикл. Вот тут кластер и начинает ощущаться как ходьба по смоле.
B — какой образ влезает в ячейки
Это вопрос SICF — образ, хранящийся как base64 в ячейках, адресуемый по sha256. На маке мы паковали синтетические несжимаемые слои; на VM — реальные Docker-образы и запускали их обратно. Обе серии ложатся на одну линию: ~0.06 с/МБ на import, export в 2–3 раза быстрее, а .xlsx выходит примерно того же размера, что и tar от docker save (раздувание base64 компенсируется zip-сжатием книги).
Реальный round-trip — то, ради чего всё затевалось. Тянем настоящий образ, пакуем в книгу, удаляем локальную копию, пересобираем чисто из ячеек и запускаем:

Три реальных образа, по три независимых проверки целостности у каждого — внутренний sha256 в sheetbuild, собственная валидация docker load и реально запущенный контейнер:
образ | tar | import | export | .xlsx | строк Layers | verify | запуск |
|---|---|---|---|---|---|---|---|
| 4 МБ | 0.30 с | 0.15 с | 4 МБ | 172 | ✅ | ✅ |
| 29 МБ | 1.67 с | 0.68 с | 28 МБ | 1 285 | ✅ | ✅ |
| 47 МБ | 2.88 с | 0.96 с | 45 МБ | 2 056 | ✅ | ✅ |
Поскольку между import и export локальный образ был удалён (docker rmi), пересобранный образ доказуемо пришёл из таблицы, а не из кэша. Вот как он лежит в ячейках — слои нарезаны в base64, по строке на чанк, с адресацией по дайджесту:

RAM скромная (пик 191 МБ на образе 47 МБ, ~4× tar). Честный потолок — суммарные байты → секунды import и RAM; образ 500 МБ был бы ~30 с import на 1-vCPU. Нативный SICF — для маленьких образов: статические бинарники, scratch/alpine, WASM. Ровно то, для чего формат и задумывался.
C — сколько кластеров на одном хосте — и вот тут настоящий разрыв
Одна книга (200 подов) reconcile’ится за ~15 мс, так что один хост клирит ~650 книг-кластеров за 10-секундный интервал. Excel масштабируется вширь прекрасно.
Google Sheets — нет. Один reconcile там 1.47 с (сеть + пара API-вызовов), и ты упираешься в жёсткую квоту 60 записей в минуту на пользователя:
интервал reconcile | макс. Google-таблиц-кластеров на аккаунт |
|---|---|
каждые 10 с | ~5 |
каждые 30 с | ~15 |
каждые 60 с | ~30 |
каждые 5 мин | ~150 |
Итого: ~650 Excel-кластеров на хост, ~5 Google-кластеров на аккаунт. В облаке потолок ставит квота, а не ёмкость — разница ~130× и реально полезная вещь, если ты вдруг (не надо) соберёшься на этом строить.
D — сколько строка живёт в ячейке, и развенчанный миф
Вот этот тест нас поправил. Мы повторяли, в том числе в статье про DOOM, которая скоро выйдет, что Google Sheets тихо портит длинные строки после ~2000 символов. Бенчмарк говорит: не через API.
бэкенд | целостно до | свыше |
|---|---|---|
Excel / openpyxl | 32 767 | тихая обрезка ровно до 32 767 |
Google Sheets API v4 | 50 000 | явная ошибка HTTP 400, не порча |
Прогоняя base64 туда-обратно и сверяя sha256, Google Sheets держал идеальную целостность ровно до 50 000 символов (документированный лимит ячейки) и отклонил 55 000 громким "more than the maximum of 50000 characters" — ошибкой, а не тихой порчей. Та порча, что мы видели раньше, — артефакт Apps Script-бэкенда (облачный путь Code.gs), а не самого Google Sheets. Хорошо. Бенчмарк, который только подтверждает твои убеждения, — не бенчмарк.
Схватка
А теперь то, ради чего вы сюда мотали. Вот таблица рядом с настоящими оркестраторами — по метрикам, для которых они, собственно, и построены:

Это публичные цифры: собственные пороги SIG Scalability у Kubernetes (150 000 подов, 5 000 нод, 300 000 контейнеров на кластер); демо Docker 2015 года — Swarm на 30 000 контейнеров и 1 000 нод; и C2M-прогон HashiCorp 2020 года — два миллиона контейнеров на 6 100 нодах, зашедулено примерно за 22 минуты. Мы упираемся в район 10 000 подов в одной линейной книге.
На этом графике мы не последние. Мы всего лишь в 200 раз позади предпоследнего.

Где мы честно проигрываем
Без виляния — вот где таблице нечего делать рядом с вашей инфраструктурой:
Масштаб: ~10k подов/книга против 150k (K8s) против 2M (Nomad). Четыре-пять порядков.
Задержка: 0.22 с на reconcile при 10k подов и 1.47 с на reconcile в Google Sheets. Kubernetes шедулит за миллисекунды и стартует поды с предзагруженным образом в рамках SLO в 5 секунд.
Нет HA control plane. Один openpyxl-writer на книгу. etcd, Raft-менеджеры Swarm и Raft-серверы Nomad держат кворум из 3–5 нод. У нас один файл и молитва.
Облачный бэкенд ограничен квотой до горстки кластеров на аккаунт.
Где мы «побеждаем»
И тем не менее:
Стоимость control plane: $0. LibreOffice бесплатен. Ни etcd-кластера, ни control-plane нод.
Зависимости: LibreOffice или браузер — против etcd + kubelet + kube-proxy + CNI + CoreDNS.
Состояние правится руками. Под редактируется мышкой.
kubectl edit— это курсор. Попробуй так с etcd.Реестр в комплекте. Образ живёт в том же файле, что и кластер (SICF). Ни Harbor, ни внешнего реестра.
Онбординг: любой стажёр-финансист на земле прочитает control plane. Не нужно учить HCL или
kubectl.Восстановление после сбоя: Ctrl+Z. Google Sheets бесплатно хранит полную историю ревизий. Откати кластер к 9:41 сегодняшнего утра кнопкой «восстановить эту версию».
Ничего из этого не важно. В этом и шутка. Но каждый пункт — правда, а пара из них (реестр-внутри-артефакта, человекочитаемое желаемое состояние, бесплатный DR через историю ревизий) — это идеи, за которые серьёзные системы заставляют попотеть.
Итог
Таблица — оркестратор на четыре-пять порядков хуже Kubernetes, и теперь мы можем доказать это цифрами, а не ощущениями. По дороге нагрузочный тест показал, что сам формат — едва ли узкое место (узкое место — single-writer reconcile-петля), что реальные образы round-trip’ятся без потерь и запускаются, что .xlsx стоит примерно как tar, и что «тихая порча», в которой мы винили Google Sheets, всё это время была нашим же Apps Script.
Вот эта последняя часть — и есть смысл бенчмарка. Не запускайте на этом прод. Запустите бенчмарк — он честный и поправит вас.
Воспроизвести самому: harness (бэкенды Excel + Google, все четыре теста) и сырой results.csv — в sci; round-trip реального образа — четыре команды на любом Docker-хосте.
Присоединяйтесь
Harness бенчмарка + стандарт SICF: github.com/sncfoundation/sci
Sheeternetes: github.com/sncfoundation/sheeternetes
Slack sheetncf, Telegram t.me/stncf, LinkedIn company/sheetncf
It reconciles.

