Comments 5
Если честно, немного непонятно, чем не угодил matchbox, ignition и coreos. Тоже самое, только в профиль и уже готовое :)
0
Про CoreOS и ignition отвечу. Здесь основная фишка в подготовке образа а не в конфигурации.
Под капотом у LTSP обычная убунта, а следовательно все что можно установить на обычной убунте, можно так же прописать и здесь в Dockerfile.
Когда как CoreOS не позволяет с той же лёгкостью добавлять кастомные модули ядра и пакеты на этапе сборки загрузочного образа.
Под капотом у LTSP обычная убунта, а следовательно все что можно установить на обычной убунте, можно так же прописать и здесь в Dockerfile.
Когда как CoreOS не позволяет с той же лёгкостью добавлять кастомные модули ядра и пакеты на этапе сборки загрузочного образа.
0
Мне известно, что такое LTSP, даже пользовал её по назначению. Потому и вопрос — зачем он для нодов кластера k8s, когда для этого есть специализированные готовые решения.
То есть — в чем профит от LTSP против CoreOs? Просто я придерживаюсь мнения, что хостовая система на ноде должна быть минимальной.
То есть — в чем профит от LTSP против CoreOs? Просто я придерживаюсь мнения, что хостовая система на ноде должна быть минимальной.
0
зачем он для нодов кластера k8s, когда для этого есть специализированные готовые решения.
Ну, как я уже писал раньше — LTSP это просто пачка готовых скриптов для организации сетевой загрузки. Плюс в том, что тут мы получаем обычную Ubuntu в минимальной версии и к тому же сохраняем возможность установить любой пакет, собрать любой модуль ядра.
Специализированные готовые решения не предоставляют такой возможности установить любой модуль, любое ядро с той же легкостью как здесь.
хостовая система на ноде должна быть минимальной.
Здесь я с вами согласен, и если вы подготавливаете систему с debootstrap у вас есть полный контроль над происходящим. Внутрь образа попадут только действительно нужные пакеты.
0
del
0
Sign up to leave a comment.
Строим загружаемую по сети ферму серверов для Kubernetes с помощью LTSP