Комментарии 31
А как же k3s? Он же вроде сделан для запуска на таких устройствах типа малинок
однако мне не нравится такой подход из-за ограничений виртуализации
Какие ограничения, вроде виртуалки в основном дают преимущества, в виде абстракции от железа?
Я стремлюсь создать кластер, который можно использовать в реальном бизнесе и который обеспечит надежность в случае сбоев.
Звучит несколько, странно. Учитывая что материал про одноплатник на арм, что далеко не про универсальность.
Идея была в том, что порой хочется протестировать механизмы на реальном "железе", а позволить себе несколько машин дома не каждый может.
Также, если я работаю в относительной небольшой организации и хочу запустить веб приложение для рабочих нужд, мне нужно быть уверенным что оно проработает с определенной степенью отказоустойчивости. В виртуалке запускать удобно, но в случае сбоя гипервизора я получу риск издержек в случае простоя, с несколькими одноплатниками же этого можно избежать.
Если речь не о игрушке после работы, то вопросов нет, но при разговоре о рабочей нагрузке сразу вспоминается, что "кроилово ведёт к попадалову" это неизбежный принцип. Альтернатив виртуализации сейчас нет, особенно если говорить о сравнении мощностей серверов и лёгкости резервирования и восстановления. Для маленьких компаний давно есть шикарный бесплатный proxmox, который позволяет приемлемую отказоустойчивость и многонодность.
Слышал, интересно. Расскажете про особенности кластеризации гипервизоров? Сложность развертывания и обслуживания? Используете в рабочей среде?
libvirt уже достаточно давно умеет передавать по сети стейт kvm-машины, соответственно достаточно сделать shared storage, например на основе ceph, и можно невозбранно переносить виртуалки между гипервизорами без их остановки. Proxmox даже умеет настраивать для вас внутрикластерный ceph через веб-интерфейс админки proxmox. Также ceph и запущенный внутри vm guest-agent позволяют делать снимки дисков виртуалок по-живому (для серверов СУБД так делать нельзя). От своих промышленных аналогов вроде OpenStack Proxmox отличается отсутствием API и, соответственно, terraform-провайдеров для настройки всего кодом, но для SMB подход "всё как код" обычно чрезмерен.
На работе я развернул 3 qemu/kvm и держу на них все сервера для организации, но отказоустойчивость, если это можно назвать отказоустойчивостью, пока обеспечиваю бекапами veeam. Но тут всегда возникает вопрос, что будет при отказе железа гипервизора. Пока из бекапа все восстановится, пройдет уйма времени. Здорово будет создать такой кластер о котором вы рассказали и не переживать за такие случаи. Спасибо.
Cоветую рассмотреть NUTANIX. HCI из коробки. В т.ч. встроенный cross-cluster backup (горячей миграции VMs на другой кластер в CE версии нет).
Сразу получаете CFS с необходимым replication factor (типа Ceph, но круче, с экспортом как NFS )
NUTANIX безусловный лидер среди HCI систем. CE версию можно попробовать на одной ноде, а можно развернуть кластер из 4 нод - полнофункциональный, но с ограничением числа нод.
Я админил больше 10 NUTANIX кластеров в течение 4 лет (CE и Enterprise) и по моему мнению это самая удобная система виртуализации.
Eсть TF provider, мы реализовали гибридный k8s cluster: используем on-prem nodes по максимуму, спайки добираем в cloud.
а почему же в Proxmox отсутствует API? может не такой разухабистый, но виртуалки я вполне себе создавал терраформом еще несколько лет назад. Сейчас чекнул - на гитхабе даже два terraform провайдера, вполне себе актуальных.
То есть, получается у вас одна orange pi используется чисто как управляющий узел, а вторая уже на себе тащит контейнеры? И в будущем еще одну вы добавите для реализации отказоустойвичости?
А кубернетис не умеет и управляющую ноду и рабочий узел размещать да оной физической машине? Или управляющая нода и так чем то загружена и ее лучше выносить отдельно?
И расскажите пожалуйста как происходит процесс восстановления работы контейнеров при отказе одной из рабочих нод (при условии что их две или больше). Сами контейнеры хранятся где? На управляющей ноде и деплояться на рабочие ноды? Или только на рабочей ноде?
Все верно, на текущий момент один узел рабочий, другой - управляющий. Заранее зарезервировал адрес для дополнительного рабочего узла. Но кастомизировать мы можем и дальше, например добавить еще один управляющий узел и 2 рабочих. Все зависит от нашего бюджета и потребности.
Касательно того, где поды - они находятся на рабочих узлах, которые периодически связываются с управляющий узлом и сообщают о своей доступности. Если управляющий не получает сообщения о доступности от работающего узла, он переключается на другой рабочий и работает с репликами подов.
Спасибо за ответ. А что будет если откажет управляющий узел? Как в таком случае его восстанавливать не прерывая работу подов на рабочих узлах.
Наш API кластера работает на управляющем узле/узлах. Поэтому есть 2 варианта:
Хороший вариант-управляющих узлов несколько. В таком случае API будет доступен и поды будут в работе. Мы сможем уточнить токены и подключить заново настроенный управляющий (либо восстановить его из бекапа)
Плохой вариант - управляющий один и он умер. Тут я подозреваю что поды продолжат работу, но вот доступа к ним без балансировщика может и не быть не говоря уже об управляемости.
Ну а по восстановлению, думаю по класике, понять причину через логи, статусы служб, и попытаться точечно восстанвить, если там не слишком все критично.
Ну стоит помниить, что система регулярных и автоматических бекапаов по правилу 321 - должна быть обязаловкой.
А кубернетис не умеет и управляющую ноду и рабочий узел размещать да оной физической машине?
Года три назад пробовал запускать k3s на 4 малинках с 2гб ram, там если разместить и управляющую и рабочий узел на одной то прям очень плохо было.
Сколько проживут microSD карты при такой нагрузке?
Для быстродействия и надежности перенести на eMMC(8GB) бутлодер и систему через nand-sata-install
microSD отформатировать в btrfs и использовать по инструкции:
https://docs.docker.com/storage/storagedriver/btrfs-driver/
Свежий(Build Date: Jul 12, 2024) minimal images с Debian 12 (Bookworm) - systemd-networkd and netplan, systemd-timesyncd
https://www.armbian.com/orangepi3-lts/
wget https://github.com/armbian/community/releases/download/24.8.0-trunk.369/Armbian_community_24.8.0-trunk.369_Orangepi3-lts_bookworm_current_6.6.36_minimal.img.xz
sudo apt install xz-utils pv
xzcat Armbian_community_24.8.0-trunk.369_Orangepi3-lts_bookworm_current_6.6.36_minimal.img.xz | pv | dd of=/dev/mmcblkX bs=1MИли собрать свой кастомный образ за 15-20 мин
https://github.com/armbian/build
Прикольно. Я буквально это делал года три назад для вебинара ребрэйна. Выглядело примерно так
Мне кажется одноплатники в будущем твердо займут свою нишу в нашей индустрии. Компактны и хороши для своих задач.
Ну, хрен его знает. Мне больше всего одноплатники понравились в деле подъёма лаб для интересных сетевых конфигураций. Например, на том вебинаре я запускал самописный cni плагин на баше и экспериментировал с foo-over-udp. Кубер в этом плане вполне достойно и на виртуалках гонять, если эксперименты с сетью не нужны. А ещё я бв с удовольствием юзал одноплатники в качестве домашних серваков.
А почему бы не использовать мини пк по типу Intel Nuk . По цене не катастрофически дороже, зато уже намного ближе к реальному железу. Да и можно на барахолке набрать зоопарк из б/у разных. И вот это уже будет реальное тестирование на реальном железе, да и с корпусами возиться не надо, можно использовать разные типы дисков, объемы памяти ...
В теории, если на работе много лишнего железа то можно сделать и так. Но текущая цель была все же потестировать одноплатники на ARM и их применимость в подобной роли.
У x86 есть преимущество с кодовой базой - не все приложения собраны для ARM.
Вот кто бы показал реальное энергопотребление N100 ноды (единственный, по моему, конкурент ARM SBC)?
Orange PI 5 (8 cores, 16GB ram, SDcard) потребляет в пике 20ватт, в простое - меньше 10.
А зачем в командах на создание нового пользователя, вы старому пользователю orangepi задаете новый пароль и тут же через одну команду этого пользователя orangepi удаляете?
Интересно было бы посмотреть как сделать объединение нод на arm и x86.
Готовим k8s кластер на OrangePi 3 LTS