Comments 13
У нас было 5 дисков usb3, Raspberry Pi Model B, CubbieBoard 1, Banana Pi M1, а ещё нетбук HP и Fire TV. Не то, чтобы это всё нужно было для разработки «домашних» задач, но раз начал коллекционировать отладочные платы, то иди в своём увлечении до конца. Единственное, что меня беспокоило — это Raspberry Pi. В мире нет никого более беспомощного, безответственного и безнравственного, чем человек c k8s control plane на Raspberry Pi. И я знал, что довольно скоро мы в это окунёмся.
Я тоже пробовал играться на нескольких малинках. Запускалось все это дело очень медленно, хоть и не пришлось таймауты менять, а так же один только кубернетс отожрал примерно треть доступных ресурсов, коих там итак немного( Потом попробовал докер сварм, да так на нем и остался, проще, легче, для пет проектов идеально
Если нужно локально… Ну, эм. Для разработки есть minikube/minishift. А вот для продакшн использования — уже появляются тулинги и дистрибутивы. Например, openshift (okd) бесплатен и раскатывается легко из ansible плейбуков, с которыми он поставляется. Есть еще варианты вроде rke — только дай виртуалок нужное количество и задать основные параметры.
Посмотрите
habr.com/post/427323
habr.com/company/mailru/blog/425343
а кубернетс нужен только в больших компаниях, ибо сложность поддержки неоправданно большая
Не совсем тема статьи, но раз уж это в нашем блоге… Мы так не считаем и в этом своём мнении основываемся на опыте поддержки множества небольших клиентов, которые очень довольны Kubernetes'ом под ключ (он просто работает, обеспечивает понятные удобства — и всё это за разумные деньги, потому что у нас «завод»). Год назад мы затрагивали эту тему в данной статье.
Я не спорю, что его можно применять для небольших проектов, тут проблем нет. Вопрос в другом, вы говорите о том, что вы настраиваете его для других, и имеете хороший опыт, и, естественно, для вас это не сложно. А я смотрю на это с другой стороны, со своей, а именно, если его разворачивать, надо выбирать реализацию сетей, в чем разница я не шарю, в это надо вникнуть, надо вникнуть в RBAC, в поды, что тоже хоть и не сложно, но отличается от привычного докера. А сумме то получается довольно таки высокий порог входа, и мне, например, уже не особо это все нужно, хотя и бывает временами интересно
Еще раз — брать готовый куб — проще всего. Там все уже за вас продумали. И сетевой плагин, и персистенцию данных, etc.
Если самому разворачивать поверх Compute Instance (VM) или Bare Metal — да, начинаются приключения и нужно продираться сквозь все уровни абстракций.
но отличается от привычного докера.
не уверен в целесообразности "привычного докера". Он тащит за собой такой пласт знаний для работы и такой пласт проблем (скажем так — особенностей). Что и подумаешь — а не проще ли по старинке — накатывать серваки из "золотых" образов, благо сейчас появились тулинги для автоматизации их создания и тестирования (напр. — HashiCorp Packer)
если отказоустойчивый, то один усб3 до рейд-коробки жы уж явно видится, как возможная причина отказа всей системы…
пс: малинка б первая на 256мб озу, апельсинка ван, Tritium 2GB Basic Kit Special с неработающим еммц и нанописи-т4…
Docker должен быть установлен с помощью специального скрипта — convenience script (так указано для случая использования Raspbian).Через deb пакет для Debian (у них свой APT репозиторий).
Начну с конца. Многих приложений ещё нет в докеризованном виде под арм. Придется собирать самому.
Хорошая новость — уже есть базовые образы (alpine, ubuntu, docker etc.) доступные через докерхаб именно под эту архитектуру. Т.е. уже есть от чего оттолкнуться. Минус, что в моем понимании — скорее всего желательно собирать докер образы под целевую платформу arm на другом таком же arm. В первую очередь — если внутри Dockerfile есть императивщина вроде сборки кода из исходников. С другой стороны, если закрыть на это глаза, то докер образ — это просто бинарь, блоб с файловой системой и манифестами. И поэтому принципиально непреодолимых проблем для кросссборок (собираю под arm, но на x86) я не вижу
Приключения с домашним Kubernetes-кластером