Orbstack действительно классный инструмент, с отличной интеграцией Docker и хорошей поддержкой Linux-сервисов из коробки. Lima полностью open-source, что важно для меня, Lima легко переносится между Mac и Linux, Lima дает больше контроля над конфигурацией VM (ресурсы, сеть, монтирование). OrbStack безусловно удобнее "из коробки" и имеет красивый UI, но для моих задач важнее была прозрачность, открытость кода и возможность глубокой кастомизации. Плюс Lima отлично интегрируется с nerdctl/containerd экосистемой, что мне подходит.
MacBook моя основная рабочая машина. Стабильных и долгоиграющих ноутов на Linux/Windows я пока не нашёл. Все Linux-задачи гоняю в виртуалках и через VMWare, но сейчас через Lima, получается чистая, предсказуемая среда. Собственно, поэтому и сделал драйвер чтобы DevOps на macOS был не болью, а нормальным рабочим процессом
Если не хочется заморачиваться с docker desktop можно было бы попробовать драйвер vfkit (Virtualization.framework kit) — это легковесная утилита командной строки, которая использует встроенный в macOS фреймворк Virtualization.frameworк. $minikube start --driver vfkit
Да, согласен, звучит немного противоречиво)) На практике получилось так: обе Orange Pi стоят в кластере Proxmox, но большую часть ВМ я держал на одном устройстве, просто ради эксперимента проверить пределы по памяти. Второй узел при этом был больше как резерв и для тестов миграций.
На Orange Pi 5 Plus с 4 ГБ будет очень тесно: сам Proxmox забирает около 1 ГБ, и на пару ВМ по 2 ГБ памяти места почти не остаётся. Если вместо «тяжёлого» Kubernetes использовать k3s, то потребление памяти заметно ниже — для тестов и пары нод этого может хватить, если цель просто посмотреть, как всё запускается. У меня, например, кластер Proxmox из двух Orange Pi 5 Plus по 16 ГБ. Жалею, что не взял по 32 ГБ. Поднял 3 control-plane и 3 worker-ноды, все ВМ запускаются на одном устройстве. Итог: одна ВМ так и не вышла из Provisioning, своп быстро вырос, идёт постоянная борьба за память https://drive.google.com/file/d/1cjgkdGBA47yzQgS5-SBOn6i0hSqEU5dK/view?usp=sharing . По CPU ещё есть запас, но RAM упирается. В LXC нагрузка распределяется лучше и всё работает нормально, но, например, IONOS LXC не поддерживает, поэтому остаются только ВМ.
И еще забыл сказать что Cluster API работает не только с Proxmox, а ещё и с разными облачными провайдерами. Это позволяет описывать кластеры декларативно и одинаково управлять ими в любой среде. В статье акцент что я запустил эту технологию на arm64
Да, согласен — если ресурсов немного и задача просто поднять один кластер, то логичнее брать готовый шаблон ВМ в Proxmox и собирать из него. Это реально быстрее и без лишних «прослоек». Cluster API в моём случае — скорее про инфраструктуру «как код»: когда нужно описывать кластеры декларативно, поднимать несколько окружений, обновлять/масштабировать их автоматом и встраивать всё это в GitOps-подход.
Orbstack действительно классный инструмент, с отличной интеграцией Docker и хорошей поддержкой Linux-сервисов из коробки. Lima полностью open-source, что важно для меня, Lima легко переносится между Mac и Linux, Lima дает больше контроля над конфигурацией VM (ресурсы, сеть, монтирование). OrbStack безусловно удобнее "из коробки" и имеет красивый UI, но для моих задач важнее была прозрачность, открытость кода и возможность глубокой кастомизации. Плюс Lima отлично интегрируется с nerdctl/containerd экосистемой, что мне подходит.
MacBook моя основная рабочая машина. Стабильных и долгоиграющих ноутов на Linux/Windows я пока не нашёл. Все Linux-задачи гоняю в виртуалках и через VMWare, но сейчас через Lima, получается чистая, предсказуемая среда. Собственно, поэтому и сделал драйвер чтобы DevOps на macOS был не болью, а нормальным рабочим процессом
Если не хочется заморачиваться с docker desktop можно было бы попробовать драйвер vfkit (Virtualization.framework kit) — это легковесная утилита командной строки, которая использует встроенный в macOS фреймворк Virtualization.frameworк. $
minikube start --driver vfkitПри условии если у вас macOS.
Да, согласен, звучит немного противоречиво)) На практике получилось так: обе Orange Pi стоят в кластере Proxmox, но большую часть ВМ я держал на одном устройстве, просто ради эксперимента проверить пределы по памяти. Второй узел при этом был больше как резерв и для тестов миграций.
На Orange Pi 5 Plus с 4 ГБ будет очень тесно: сам Proxmox забирает около 1 ГБ, и на пару ВМ по 2 ГБ памяти места почти не остаётся. Если вместо «тяжёлого» Kubernetes использовать k3s, то потребление памяти заметно ниже — для тестов и пары нод этого может хватить, если цель просто посмотреть, как всё запускается. У меня, например, кластер Proxmox из двух Orange Pi 5 Plus по 16 ГБ. Жалею, что не взял по 32 ГБ. Поднял 3 control-plane и 3 worker-ноды, все ВМ запускаются на одном устройстве. Итог: одна ВМ так и не вышла из Provisioning, своп быстро вырос, идёт постоянная борьба за память https://drive.google.com/file/d/1cjgkdGBA47yzQgS5-SBOn6i0hSqEU5dK/view?usp=sharing . По CPU ещё есть запас, но RAM упирается. В LXC нагрузка распределяется лучше и всё работает нормально, но, например, IONOS LXC не поддерживает, поэтому остаются только ВМ.
И еще забыл сказать что Cluster API работает не только с Proxmox, а ещё и с разными облачными провайдерами. Это позволяет описывать кластеры декларативно и одинаково управлять ими в любой среде. В статье акцент что я запустил эту технологию на arm64
Да, согласен — если ресурсов немного и задача просто поднять один кластер, то логичнее брать готовый шаблон ВМ в Proxmox и собирать из него. Это реально быстрее и без лишних «прослоек». Cluster API в моём случае — скорее про инфраструктуру «как код»: когда нужно описывать кластеры декларативно, поднимать несколько окружений, обновлять/масштабировать их автоматом и встраивать всё это в GitOps-подход.
Спасибо за дополнение! Я поправил)
Спасибо за комментарий! CAPMOX (Cluster API Provider for Proxmox VE) это следующий этап в моей лаборатории.