Я взял свой домашний Nextcloud (700 МБ/с, своя железка, никаких облаков) и переехал с него на Kubernetes с управляемыми сервисами. Postgres и Valkey теперь крутятся как Managed Services: обновления и бэкапы — это не моя забота. NetBird Self-Hosted тоже переехал в «куб». Cursor помогал. Всё работает.
Всем привет, я Дмитрий Гайворонский, Business Development Manager в команде Deckhouse Data Orchestration компании «Флант». Недавно я рассказывал, как заменил «Яндекс Диск» на свой Nextcloud и разогнал синхронизацию до 700 МБ/с на старом Mac mini — без инженерного бэкграунда, с помощью Cursor.
Кстати, история получилась очень своевременной: 3 июня 2026 года «Яндекс» поменял модель доступа к десктопному приложению «Яндекс Диска» — облачные функции стали доступны только по платной подписке «Яндекс 360». Без неё в приложении остаются только локально сохранённые файлы, а работа с облаком напрямую отключена.
Если интересно, как можно уйти с «Яндекс Диска» на своё решение без потери скорости и комфорта, — читайте в первой части.
В этой статье я продолжаю историю, и для того, чтобы быть в контексте, лучше (но не обязательно) прочитать первую часть.
Дальше я кратко расскажу и покажу, какие у меня железо и софт, почему и какой выбрал Kubernetes и можно ли его заменить. Но если хотите сразу перейти к делу — кликайте сюда.
Зачем вообще кластер? Почему бы не купить один мощный компьютер?
Давайте посмотрим на цены. Mac Studio M4 с 128 ГБ памяти или MacBook Pro с аналогичным объёмом стоят от 400 тысяч до миллиона рублей. За эти же деньги можно купить новенькую Lada Granta. Десктоп по цене автомобиля — это нормально?
А память? Комплект из двух планок DDR5 по 64 ГБ стоит около 130 тысяч рублей на заказ. И это только память!
![Оперативная память Kingston FURY Beast Black [KF556C40BBK2-64] 64 ГБ. Цена за один комплект — от 65 тысяч рублей.](https://habrastorage.org/r/w1560/getpro/habr/upload_files/2ae/5ed/78c/2ae5ed78caf99d6bdbd384426a75cbc0.png "Оперативная память Kingston FURY Beast Black [KF556C40BBK2-64] 64 ГБ. Цена за один комплект — от 65 тысяч рублей.")
И что делать тем, у кого нет таких денег? Не все могут выложить миллион за железо, особенно если нет уверенности, что получится это окупить и реализовать задуманное.
Я вижу такой выход: начинать с того, что уже есть или что доступно по бюджету, и наращивать ресурсы постепенно. Инвестировать в дорогое железо стоит лишь после того, как гипотеза подтвердилась на практике и ты понял — это действительно нужно и будет приносить пользу.
К концу первой части я собрал вот такой сетап, на котором экспериментировал и запустил свой первый домашний сервис:
Коммутатор TP-Link TL-SG105M (5 портов × 2,5 Гбит/с)
Mac mini Late 2014: i5, 8 ГБ ОЗУ, 4 ТБ SSD (SATA III)
Mac mini 2018: i7, 64 ГБ ОЗУ, 128 ГБ SSD + внешний 1 ТБ NVMe Gen4 (Thunderbolt 3)
Понял, что хочу двигаться дальше, но железо «кусалось» по цене. Поэтому решил однозначно: продолжаю эксперименты поэтапно, на имеющейся базе, и смотрю, как пойдёт. В этот момент задумался — как это всё объединять? Какие подходы и технологии позволяют заставить разрозненные узлы работать как единое целое? Так я вышел на Kubernetes. Захотелось проверить его в деле, прежде всего ради объединения физических машин, а не просто виртуализации. Стал искать Mac mini, обязательно с поддержкой 10-гигабитной сети — раз уж речь о кластере.
В итоге за несколько месяцев на «Авито» собрал вот такой сетап:
коммутатор TP-Link TL-SX105 (5 портов × 10 Гбит/с);
1× Mac mini 2014 Late (i5, 8 ГБ) — 2,5G Ethernet через USB-адаптер;
3× Mac mini 2018 (i7, 64 ГБ) — 10G Ethernet. Накопители изначально были разные, но я выровнял их, заменив на одинаковые по объёму NVMe-диски;
мини-стойка Deskpi T1 Plus.
Почему Mac mini? Мне просто нравится экосистема Apple. Форм-фактор идеально подходит для дома: компактный, без внешних блоков питания, тихий и эстетичный. Разве что немного греется. Модель 2018 года — последняя на Intel, куда можно поставить Windows или Ubuntu. Память легко апгрейдится до 64 ГБ, а под заказ доступны модули 10-гигабитного Ethernet.
Конечно, это не самый оптимальный выбор для Kubernetes-кластера, но у него есть решающее преимущество — тишина. Его можно спокойно поставить в спальне рядом с кроватью. Главный минус — отсутствие GPU.
Кстати, про 10-гигабитную сеть: сейчас понимаю, что она не была строго необходима. Это был мой «бзик» — казалось, что если тестировать OLAP-движок или Data Lake, то быстрая сеть обязательна. В теории да, но на практике стандартные 1 Гбит/с или 2,5 Гбит/с тоже отлично справляются.
Если говорить о современном железе вроде Minisforum и аналогов — тут всё однозначно: по производительности и возможностям они выигрывают. Мой следующий кластер уже будет на такой платформе. Подробности расскажу в отдельной статье.
В итоге вот что у меня получилось:
Почему Kubernetes? Откуда я узнал о нём
Я занимался темой платформы данных и судьба привела меня во «Флант», где ребята много лет работают с Kubernetes, а ещё они недавно выпустили первый релиз с Managed Postgres/Storage. Мне понравился этот подход: для поставщика дата-платформы самому заниматься инфраструктурой и безопасностью — это всегда боль. Я верю в эту тему и присоединился к компании в роли Business Development Manager. Соответственно, как может быть сапожник без сапог? А можно Kubernetes дома? А это не опасно? А оно работает?
В Kubernetes я увидел возможность объединить несколько старых узлов в единую систему — буквально в один «оркестр».
Сначала я решил просто проверить: насколько платформа доступна, стабильна и надёжна для домашних задач. Уверенности добавил Cursor — благодаря ему я понял, что смогу во всём разобраться. Честно говоря, без этого AI-ассистента я бы в Docker и Kubernetes никогда не полез. Даже близко. Без подсказок мой «DevOps-уровень» заканчивается на AppStore.
Ванильный Kubernetes? Нет. Готовый продукт на его базе — уже другое дело. Но как его получить? Вариант «покупать» сразу отпадает. Поэтому я пошёл к своим и попросил по блату выдать лицензию на Deckhouse Kubernetes Platform Enterprise Edition (DKP EE) (платная редакция DKP с расширенным функционалом), включая managed-сервисы. Лицензию получил. Но сразу предупрежу: для вас, господа присяжные заседатели, бесплатно доступна только Community-версия и managed-сервисов в ней нет.
Цель этой статьи — в том числе проверить, есть ли у вас (у читателей) интерес к подобным возможностям. Если есть, то в будущем я постараюсь согласовать внутри компании их добавление в Community-версию. Хотя бы в ограниченном виде.
Развернул платформу чётко по инструкции через UI. Алгоритм простой: ставишь Docker на Mac, настраиваешь SSH-доступ к узлам, запускаешь установщик — и кластер поднимается. У меня всё заняло около часа-двух, с учётом времени на исправление собственных ошибок.
Роль control plane (мастера) я отдал старому Mac mini 2014 года. Три Mac mini 2018 стали воркерами. Старичок 2014-го, конечно, пыхтит — загрузка CPU держится около 30 %, — но свою задачу решает. Ему и не нужно больше ничего: только поддерживать работу системы и принимать входящий трафик.
Кстати, DKP поддерживает и контейнеризацию, и виртуализацию. Благодаря виртуализации, например, можно поднимать Kubernetes-кластеры поверх виртуальных машин. Но для моей задачи установка Deckhouse прямо на железо подошла лучше — мне нужен всего один кластер. Промышленные серверы я купить не могу (дорого, шумно, занимают много места). Зато могу собрать кластер из нескольких Mac mini, запускать всё на одном кластере и переносить нагрузку туда, где есть свободные ресурсы.
А ещё мне было важно проверить на начальном уровне архитектуру, которую можно переносить в корпоративную среду, где десятки, сотни узлов и совсем другие требования к отказоустойчивости и доступности приложений. На одном большом сервере с виртуализацией такой опыт гораздо сложнее получить.
Deckhouse Managed Services — собираем пазл
Теперь возвращаемся к исходной прикладной задаче — развёртыванию Nextcloud. Как мы его развернём с учётом новых возможностей?
Схема узлов и распределение компонентов. Распределение условно: в кластере расположение пода (процесса) может меняться динамически:
В Nextcloud есть: PHP, Postgres, Redis, Cron-задачи, Nginx/Caddy. А в DKP есть: Ingress, Secrets, Certificates, Prometheus/Grafana, Managed Postgres, Managed Valkey, Cron… Ну естественно, появилось желание попробовать поменять.
Итак, мы поставили кластер на железо. Теперь у меня Kubernetes дома! Не может быть…
Дальше — снова работа с Cursor по деплою Nextcloud. Первым делом я решил без выпендрёжа развернуть стандартный Nextcloud с его Redis и Postgres. Удивительно, но деплой прошёл ощутимо легче. Конечно, я уже наблатыкался с Cursor: научился правильно его готовить. Как изучать задачу, понимать, правильно ли он меня понял, составлять план, действовать по шагам, подтверждать любые изменения, хранить версии. В общем более-менее приручил — хотя всё равно выкидывает что-нибудь.
Второй важный момент — API и документация Deckhouse. Я постоянно прошу Cursor сначала изучить сайт, затем попробовать — и только потом работать с кластером. Это ключевое. Главная сложность была в том, что Nextcloud и NetBird в документации описаны только с деплоем в Docker. Вроде Kubernetes рядом, образы те же самые — но изоляция компонентов и stateless добавили сложностей. Пришлось сильно помучить Cursor, чтобы найти конфигурацию для NetBird, которая взлетела. Я сначала запускал сервис, а потом изучал, как это вообще работает.
Nextcloud заработал в «кубе». Все показатели — как и были. Скорость такая же. Дальше — задача по замене Postgres на Managed Postgres и Managed Valkey. И всё получилось. Nextcloud подхватил два «внешних» компонента, и теперь их образы — это уже забота Deckhouse. Обновления, бэкапы — всё это больше не мои проблемы. Я только на всякий случай организовал репликацию своих личных данных на отдельный носитель, чтобы вообще не зависеть ни от каких технологий.
Приватность: облако есть, провайдера нет
И вот тут я понял главное. Managed Services — это концепция облачных провайдеров, которые управляют железом, обновлениями, бэкапами. Вы просто их используете и платите.
Теперь у меня есть это облако. Но провайдера нет.
Я получаю все блага облака:
автоматические обновления Postgres и Valkey;
резервные копии на отдельном хранилище;
высокую доступность (3 реплики, автоматический failover);
мониторинг и алерты;
масштабируемость — если понадобится, добавлю узлы.
При этом у меня нет проблем с конфиденциальностью. Нет проблем с задержками связи. Нет зависимости от политики провайдера. Мои данные лежат дома, на моём оборудовании, в моём кластере, которым я управляю.
Это приватное облако. Облако с контролем.
Переключение на Managed Services
Переключение на Managed Services оказалось даже слишком лёгким. Буквально изменил пути к Postgres и Redis в конфиг-файлах. Смотрю в DKP только через консоль («для домохозяек», как говорят наши разработчики) и через Grafana. Никакой командной строки. В целом всё переехало в Kubernetes, я отключил все хостовые сервисы. Nextcloud/NetBird полностью крутятся в DKP.
Снова прошу поддержки
Я попробую уломать команду Deckhouse, чтобы что-то из Managed Services включили и в Community Edition — тогда всё это будет доступно всем бесплатно. Насыпьте, пожалуйста, плюсов этой статье, чтобы поддержать идею.
Сложности с NetBird
Не было официальных Helm-чартов. Cursor создавал их на основе docker-compose. Проблема в том, что в NetBird сразу 4 независимых сервиса: Management, Dashboard, Relay, Signal. В Docker они поднимались вместе. В «кубе» — всё раздельно. Все пути и связи поехали.
Пришлось долго разбираться. Все 4 сервиса вызываются по одному домену с одним именем — нужно было настроить Ingress так, чтобы на разных портах запускались разные службы. Заработало с двумя Ingress’ами: для HTTP и для gRPC. Ещё какие-то сниппеты и rewrite-правила.
Для меня это был тёмный лес. Почти половину токенов за месяц потратил, чтобы Cursor во всём разобрался и предложил рабочий конфиг. Я лично не могу оценить, насколько это правильно с точки зрения сетей — нужен спец. Но работает так, как я хотел: без 4 поддоменов, а с одним именем. Клиенты на Mac, Linux, iOS.
И ещё раз скажу: выбрал NetBird из-за рабочего приложения в AppStore. Как Tailscale self-hosted работает — не знаю.
Разгоняю скорость синхронизации до 1,1 ГБ/с
Вот тут начались эксперименты. Я начал с базовой конфигурации Nextcloud в Kubernetes. Скорость была приемлема, но я хотел понять: сколько максимально может дать эта сеть?
Шаг 1: MTU (Maximum Transmission Unit)
По умолчанию MTU на сетевых интерфейсах стоит 1500 байт. Но для 10-Гбитной сети это неоптимально — слишком много overhead на разделение трафика на пакеты.
Я настроил Jumbo Frames — MTU 9000 байт. Это означает, что каждый сетевой пакет может быть в 6 раз больше. Меньше пакетов → меньше overhead → быстрее скорость.
Шаг 2: параллельные соединения в Nextcloud
Nextcloud client по умолчанию открывает отдельное соединение для каждого файла при синхронизации. Это значит:
если качаю один большой файл (кино) → 700 МБ/с;
если качаю два файла параллельно → 1–1,1 ГБ/с;
если качаю несколько файлов → близко к потолку 10GbE-сети.
Результат: 1,1 ГБ/с
Nextcloud client теперь синхронизирует несколько файлов параллельно. В момент пика сеть работает на пределе:
Под капотом в этот момент сеть работает на пике:
Почему Managed Postgres и Valkey поднялись относительно легко: в Nextcloud это внешние сервисы, конфигурируемые в официальных Helm-чартах. Достаточно было подставить новые пути — и всё поднялось. Это благодаря раздельной архитектуре Nextcloud. Если бы компоненты были интегрированы кастомнее, было бы гораздо сложнее. А совместимость самих сервисов — это уже заслуга свежих образов Postgres и Valkey.
Вот так выглядит Helm-конфиг Nextcloud до и после (никакого кода, только замена адресов):
internalDatabase: enabled: false externalDatabase: enabled: true type: postgresqu host: "d8ms-pg-nextcloud-rw.nextcloud.svc.cluster.local:5432" database: "" user: "" password: "" existingSecret: enabled: true secretName: d8ms-pg-nextcloud-app usernameKey: user passwordkey: password databaseKey: dbname postgresql: enabled: false persistence: enabled: true storageClass: Localpath-system size: 20Gi nextcloudData: enabled: true storageClass: localpath-system size: 50Gi redis: enabled: false externalRedis: enabled: true host: "d8ms-vlk-nextcloud.nextcloud.svc.cluster.local" port: "6379" password: "" existingSecret: enabled: false secretName: "" passwordKey: "password"
Результат
NetBird работает в кластере DKP в два этапа: сначала устанавливает соединение между пирами, потом поднимает VPN-туннель для их взаимодействия. Чтобы это заработало, нужны три вещи:
Доменное имя и публичный IP (~1000 руб). Регистрируем домен, заказываем IP-адрес у провайдера, настраиваем A-записи. Проверяем, что имена резолвятся в адреса.
Port forwarding на роутере. Проксируем порты 80/443 на master-узел кластера (где включен Ingress-контроллер nginx). Порт 80 закрываем после выписки сертификатов — в бою нужен только 443-й.
Правильный Ingress — самое сложное. NetBird состоит из 4 независимых сервисов (Management, Dashboard, Relay, Signal), и в Kubernetes каждый требует отдельной маршрутизации. Пришлось настроить два Ingress-контроллера: один — для HTTPS, другой — для gRPC. Они перенаправляют запросы на нужный под, где бы он ни крутился в кластере, — это основная фишка Kubernetes.
Как только клиент подключен, он попадает во внутреннюю VPN mesh-сеть и видит остальные пиры. Запросы к Nextcloud идут через VPN-туннель. Снаружи всё выглядит как один домен с одним IP — внутри система сама разбирается, куда маршрутить.
А это архитектура Nextcloud до и после:
Уровень Cloud Native (*на мой скромный взгляд): было 2–3/10, стало 6–7/10.
Слева — стандартный Nextcloud: берём PHP, Redis, Postgres, настраиваем вручную. Справа — на Deckhouse: авторизация через OIDC (Dex), веб-фронт на Ingress, кеш на Managed Valkey, база на Managed Postgres и репликация на SDS-Replicated-Volume. Всё остальное (обновления, бэкапы, мониторинг, сертификаты) — забота платформы.
Также я добавил в NetBird кастомную DNS-зону. Это решило две проблемы сразу:
локальное разрешение имён — внутри сети домен резолвится в локальные IP-адреса, а не ходит в публичный DNS;
отключение VPN-туннеля в LAN — если клиент в одной локальной сети с сервером, он может обращаться к нему напрямую по IP-адресу, без VPN. А VPN-туннель режет скорость — в моём случае это было критично.
Дополнительно добавил статические DNS-записи на роутер — точно такие же. Теперь DNS работает в трёх местах и разных сценариях:
извне → через публичный адрес и NetBird VPN;
внутри локальной сети → прямо по локальному IP-адресу, без VPN;
с отключённым NetBird → всё равно работает через роутер локально.
Публичные DNS-записи нужны только для получения публичного сертификата. Я зарегистрировал домен, выставил A-записи на публичный IP-адрес, прошёл валидацию и получил сертификат, который нужен не только для «замочка» в браузере и красивого URL. Это критично для iOS-приложений. Apple проверяет сертификаты жёстко. Приложение Nextcloud на iOS вообще не откроется без корректного SSL-сертификата. Это про безопасность.
Как только сертификат получен, я удаляю A-записи. Они больше не светятся наружу. Домен исчезает из публичного интернета. Потом через три месяца снова открою ради обновления сертификатов — и всё. Реальные DNS-записи работают в NetBird.
И ещё рассмотрим архитектуру отказоустойчивого деплоя Nextcloud
Managed Postgres работает в режиме HA с 3 репликами: 2 синхронные (готовы взять трафик в любой момент) + 1 асинхронная (отстаёт на несколько миллисекунд, но зато не тормозит запись).
Managed Valkey крутится без диска — это просто кеш. Если под упадёт, поднимется новый и заполнит себя данными из Postgres. Быстро.
Nextcloud хранит файлы на дисках, которые реплицируются между 3 узлами через SDS (Storage Distributed System) с DRBD (Distributed Replicated Block Device). Если под Nextcloud упадёт или узел отказал — система поднимает его на другом узле, и данные уже там.
И ещё совсем немного про архитектуру
Авторизация — Dex через OIDC. Веб-фронт — Ingress nginx. Секреты, сертификаты, обновления, мониторинг — всё на Deckhouse. От Nextcloud остался только backend.
Философская интерлюдия: о зависимости от ИИ
Система работает. Всё поднялось. Nextcloud крутится, база синхронизируется, бэкапы делаются автоматически. Cursor написал конфиги, Kubernetes их применил, и готово.
Но вот стоп. Я не могу оценить, что именно сделал Cursor. Я не понимаю всех деталей. Я не знаю, что может пойти не так. И это уже две большие глобальные проблемы:
Тотальная зависимость — я не могу обойтись без ИИ. Без Cursor я бы этого не сделал.
Неизвестность — я не знаю, что он наворотил. Безопасно ли это? Откроет ли это дыры в моей сети? Будут ли мои данные украдены?
Это как с моим «умным домом» — у меня есть доступ к устройствам, но я не знаю, как они работают на самом деле.
Почти 70 лет назад, в 1958 году, Айзек Азимов написал рассказ «Чувство силы» (The Feeling of Power). В рассказе люди полностью зависят от компьютеров. Они не умеют считать в уме, не знают основ математики. Когда один человек случайно учится считать вручную, это становится сенсацией и угрозой — люди боятся потерять «чувство силы», которое дают им компьютеры.
Сейчас происходит ровно то же самое. Например, я не знаю, как работает Linux. Не знаю, как работает Kubernetes. Не знаю, как работают конфиги YAML. Но я могу создать инфраструктуру, потому что ИИ это делает за меня.
Ещё страшнее думать о следующем поколении. Если я сейчас не знаю основ, то мои дети будут знать ещё меньше. Они вообще не смогут понять, как работает интернет, как работает компьютер, как хранятся данные.
И это реальная проблема. Не теоретическая. Именно это Азимов и предсказал.
Я понимаю, что без ИИ уже будет крайне тяжело. Или даже невозможно. Но я могу сделать три вещи:
Разбираться в матчасти
Когда я прошу Cursor сделать что-то, то сперва изучаю тему с Perplexity в режиме диалога-лекции. Мне не надо знать все детали — я не инженер. Но я пытаюсь понять:
Как это работает в общих чертах?
Какие могут быть опасности?
Что может пойти не так?
Я не должен уметь это делать. Я должен понимать, что происходит. Это две разные вещи.
Защищаться от ИИ
Да, ИИ помогает. Но это не значит, что нужно слепо ему верить. Важно:
хранить данные приватно (как я и делаю дома);
строго контролировать доступы;
не давать ИИ полный контроль над критичными системами;
всегда иметь «кнопку отключения».
Читать фантастику
Это звучит странно. Но фантасты — это люди с воображением, которые задумываются о будущем. Азимов, Кларк, Чапек — они не были инженерами. Но они предсказали проблемы, потому что думали.
Я читаю рассказы про ИИ, про роботов, про технологии. И я вижу, что большинство проблем, которые описаны в фантастике, сейчас происходят в реальности.
Это помогает не потерять голову и помнить, что технология — это инструмент. Не спасение. Не ответ на всё.
А как вы считаете, есть ли в этом проблема и в чём она, на ваш взгляд, заключается?
Итого: что я получил
Проверил, что Open Source стабильно и быстро работает на старом железе. Linux/Ubuntu вполне дружелюбны — при удалённой работе с приложениями не чувствуется корпоративная сложность.
Проверил стабильность: варварски выключал сервер, удалял поды — смотрел, как всё восстанавливается. Используешь gold.yaml-конфиги и с нуля переподнимаешь до идентичного состояния за ~5 минут. У Cursor теперь задача — только менять параметры кластера. В систему он больше не лезет. С Kubernetes появилась живучесть: ещё надо постараться, чтобы положить сервис.
Также помогаю ребятам тестировать и шатать самый свежий релиз Alfa.
Но самое главное — теперь я могу реализовывать свои замыслы с помощью ИИ: готовить демо, MVP, новые сценарии, чего раньше в принципе не мог себе даже представить.
Кроме того, собранную в этой статье архитектуру я уже использовал в работе и даже провёл вебинар (запись, презентация), где показал возможности DKP в части управляемых сервисов на примере деплоя Nextcloud.
Общий итог: от «Яндекс Диска» до домашнего кластера
Если отмотать назад — всё началось просто: надоело платить за облако и хотелось понять, можно ли сделать своё. Без инженерного бэкграунда, с Cursor вместо рук и старым Mac mini вместо сервера.
Проект Nextcloud мне помог пройти такие этапы:
Переход с «Яндекс Диска» на Nextcloud на старом Mac mini. Задача относительно простая, но именно она мотивировала попробовать вайб-кодинг.
Эксперименты со скоростью ради перфекционизма. Благодаря этому я уже смог переходить к сложным сценариям.
Построение кластера и переход на Kubernetes. Понял, что за разумные деньги можно объединять старые узлы и решать более серьёзные задачи. Теперь планирую перевести все домашние сервисы в полностью автономный режим.
Проверка «своего» продукта в реальных условиях. Убедился, что решение надёжно работает на бытовых задачах, и теперь успешно использую этот же кластер в работе — для демо и запуска MVP.
Путь от HDD к Kubernetes: как росла скорость:
Фаза | Нода | Диск | Сеть | Софт | Результат | Комментарий |
Начало: старый Mac + HDD | Mac mini 2014 late i5 8GB | HDD LaCie 2TB | 1 Гбит, | Ubuntu/Snap Nextcloud | 90–100 МБ/с | Ограничение сети — 1 Гбит/с |
Kubernetes: первый запуск | Mac mini 2018 i7 64GB 1TB 10GbE | NVMe 1TB + SSD Sata 3 в корпусе TB3 | 10 Гбит, роутер Netcraze Ultra + коммутатор 5*10 TP-Link TL-SX105 | Deckhouse Nextcloud NetBird Self-Hosted | 400–800 МБ/с через адаптер TB3/10Gbit | Удалось запустить это всё в K8s, разброс результатов не очень понимал — то с диска, то из памяти, основной целью было вообще запустить это всё |
Kubernetes: финал | Mac mini 2018 i7 64GB 1TB 10GbE | NVMe 1TB + SSD Sata 3 в корпусе TB3 | 10 Гбит, роутер Netcraze Ultra + коммутатор 5*10 TP-Link TL-SX105 | Deckhouse Managed PG Managed Valkey Nextcloud NetBird Self-Hosted | 987 МБ/с через адаптер TB3/10Gbit, 150–160 МБ/с при Wi-Fi 6E (2401 Мбит/с по роутеру) | Получилось! Результат был достигнут при чтении дважды двух и более больших файлов. Выяснил, что скорость 650 МБ/с — это предел для 1 файла. Те клиент Nextcloud распараллеливает загрузку через соединения к файлам. 2–3 фильма в папке синхронизации, прогрев пару раз и полка достигнута! А ларчик просто открывался… |
Но если честно, главный вывод не про скорость.
Про железо и практичность. Лучшее соотношение цена/результат — фаза 3: старый Mac mini, второй SSD на 4 ТБ, адаптер 2,5 Гбит/с. Всё остальное быстрее, но дороже и сложнее. Если ваша задача — просто своё облако вместо «Яндекс Диска», это уже работает. Переход на 10 Гбит/с оправдан, только если есть другие нагрузки, любопытство или перфекционизм — и то, и другое, и третье у меня нашлось.
Про Kubernetes. Проработал с Kubernetes несколько месяцев и понял, что на самом деле я не вижу его. Я взаимодействую с ним через Cursor. А Cursor работает через API — универсальный язык между человеком и машиной, который легко понимает ИИ. Поэтому это всё так легко завелось.
Мне не надо думать об инфраструктуре, узлах, операционных системах и других аппаратных деталях отдельно. Я собрал кластер, им управляет Deckhouse через API, и всё. Дальше для меня это единое целое.
Про Managed Services. Самый неожиданный момент: переключение Postgres и Valkey на управляемые сервисы оказалось буквально заменой двух строчек в конфиге. И теперь обновления и бэкапы — не моя забота. В этом и есть смысл.
Про ИИ-инструменты. Cursor сделал возможным то, во что я бы раньше вообще не полез. Но главное — я научился его готовить: изучить сначала документацию, составить план, подтверждать каждый шаг, хранить версии. Без этого он рано или поздно запишет что-нибудь не туда.
Ну а пока ребята-разработчики пилят новые Managed Engines/Storage, у меня есть ещё одна задача:
Алиса, ты подслушиваешь?
Нет, я не подслушиваю…
P. S.
Читайте также в нашем блоге: