На текущий момент есть 5 “мини” серверов в разных локациях (3 страны).
Обьеденены в сеть через self-hosted netbird.
Каждая машина имеет Debian + docker + Portainer.
Из сервисов
gitlab + runners - для хранения кода, сборки CI/CD, документация по проектам
minio, nextcloud - хранилище документов, фото, видео и т.д.
rabbitMq - связующий между сервисами
jupyter, code-server (vscode) - для разработки в браузере
ollama и litellm - точка доступа для приложений использующих модели ИИ.
open-webui - общение с моделями, для поиска хороших промтов.
n8n - быстрое прототипирование, проверка идей
и другие сервисы типа qbittorrent, jellyfin, nginx-proxy-manager и т.д.
Особености, 3 и 5 серверов c arm64v8 (есть NPU) + 2 c GPU.
Всё смешенно, личные и командные доступы, т.к участвую в разных стартап проектах.
С течение времени становится всё сложнее обслуживать, приходится вручную искать место под новый сервис, связывать его в существующей сети с другими. И пришла идея всё перестроить, сделать единое облако.
Я смотрю в сторону Debian + k8s (или k3s) + Rancher + Helm.
Но возможно Вы подскажите что то лучше, вижу что используют Proxmox VE Cluster, не знаю насколько он хорошо будет работать при больших пингах, и в целом пока не ясно зачем нужен будет Proxmox в таком домашнем облаке.
Напишите пожалуйста что вы об этом думаете и буду благодарен за разные идеи.
На некоторых есть NPU и GPU, к которым должна быть привязка сервисов.
Ну и распределено все, в рамках интернета с большими задержками.
Что можем
k8s рассматривать можно, но учитывать
необходимость обмазываться привязкаами к нодам, чтобы сервис, требующий GPU запускался на нодах с GPU
и сам шаринг GPU в кубере не так просто делается, как в PVE, но я лично таким не занимался
Могут быть привязки же архитектуре, например, сервис упал на x64 ноде и поднимается на arm, а под нее нет образа
Raft достаточно требователен к задержкам, рекомендуется не больше 10-15мс пинг, если больше, то надо тюнить + сам etcd ооооочень нагружен в кубере. Поэтому, split-brain получить в вашем случае как пить дать.
Kubeproxy ооочень крутая штука, но есть шанс, что приложение размажется по серверам и будет гонять трафик через интернет например, сервис на одном сервере, а redis его на другом + вопрос с приземлением трафика, будут ли пользователи через VPN подключаться или через интернет. Часто будет ситуация, когда трафик приходит на одну ноду, потом отправляется в сервис на второй ноде, а потом в под на третьей.
Надо будет подумать над тем, чтобы сами поды имели доступ между нодами, тут или vxlan или маршрутизировать через L3, в любом случае надо выбирать правильный CNI
Академический K8S говорит, что надо выделять отдельно master ноды и отдельно worker, а etcd не должен быть на worker нодах
Для снижения проблем с raft может быть имеет смысл запустить control plate + etcd на одном выделенном сервере, а все остальные поднять как worker node. В этом случае в случае потери связи между нодами они просто не смогут получать команды на обновление состояния, и через некоторое время control plate начнет запускать поды на доступных нодах, а отсоединенные продолжат работать, после появления связи control-late постарается убить более старые поды (тут вообще все зависит от настроек и типа развертывания)
k3s
неплох для однонодового исполнения, но кластеризация у него не самая хорошая и оптимальная (я только в теории про нее читал, а k3s пользовал только в однонодовом исполнении. Там вместо etcd используется sqlite, что проще, но не кластеризируется.
Возможно тут будет даже проще реализовать 8 пункт из k8s
По поводу Rancher ничего сказать не могу т.к. на практике с ним не приходилось сталкиваться
Proxmox cluster не рекомендую сразу
использует corosync, который totem, но тоже raft + я прям вижу, как его начинает колбасить при нестабильном линке. И тут TOTEM тоже требует задержки меньше 10-20мс. В общем, это самое плохое решение, которое можно придумать.
Он рулит контейнерами и виртуалками, а не приложениями (писал об этом тут), поэтому имеет “немного” другой уровень абстракции, нежели K8S.
Komodo
делится на сервер и периферию, по аналогии с control plate и worker node в k8s, но нет функционала кластеризации сервисов и CNI, поэтому надежней. Максимум, что напишет, что нода и сервис не доступен в данный момент.
Выбор сервера для разворачивания ложится полностью на пользователя (надо в выпадающем списке выбрать)
Есть очень крутая ролевка, поэтому легко настроить доступы
Про него я уже много расписывал тут, и планирую еще несколько сценариев добавить. По аналогии с K8S + helm можно сделать полный IaC с хранением всего в git репозитории и удобной админкой.
Еще мысли
Для 12 factor app, который взят за остнову k8s говорит, что сервисы должны быть stateles, будете ли Вы делать распределенные или внешние хранилища? или просто будут создаваться каталоги на ноде? PVC по мне так это одна из самых проблемных вещей в self managed кластерах.
Трушный кластер будет сделать сложно и опасно. Какой-то простенький панелью управления на одном из серверов будет сделать явно надежней и проще, пробросить GPU с komodo КМК проще.
Все ли можно в docker развернуть из ваших сервисов?