А вот по вопросу, честно говоря, не совсем понял. Подойдут любые 2-3 сервера выше требуемых ресурсов, можно и 1 сервер если не в продакшене, так же платформа поддерживает вложенную виртуализацию и, если это поддерживает железо, можете развернуть кластер на виртуалках.
Сомневаюсь что метрика по количеству подов релевантна, но их 121 в моей конфигурации) По ресурсам без нагрузки есть скрины htop'а под катом под конец статьи
Полноценный. Хотелось совместить декларативность кубов и виртуализацию так как решение домашнее, забыв про развёрнутое кривое веб приложение "наружу" не хочется получить у себя в сети нежелательных гостей, поэтому просто взял готовую платформу виртуализации на кубах.
Пока что только сервер nextcloud и крутится, никак не доберусь даже чтобы развернуть упомянутый gitlab, не хочу вводить в заблуждение ответом, если вспомню то принесу ответ как дойдут руки.
В Kubernetes, за хранилище ответственны csi плагины, соответственно, вы можете найти тот который поддерживает интересный вам тип хранилища и использовать вместо(может и вместе) с sds-replicated-volume.
Необходимости, как таковой, нет. Вы можете использовать и две и одну машины (пожалуйста, не делайте так в продакшене)). Конкретно мой выбор обоснован следующими факторами: 1) На кластере из одной машины системные компоненты откушивают приличное количество процессорного времени на дешёвом железе, а переплачивать за мощный процессор нет смысла (пользователь либо один в лице меня, либо несколько человек). 2) Надёжность, возможно даже излишняя для дома, все диски существуют в трёх репликах (в данном случае по одной на каждый мини пк) и если один пк сгорит то можно просто подключить в кластер новый пк заместо старого (предположим импульс пожёг вообще всё внутри) или просто заменить ссд, все данные будут в сохранности. 3) Психологически показалось что одной машины под полезные нагрузки не хватит, поэтому взял две, к сожалению тут нет ни расчётов, ни прикидок, я так чувствовал)
Согласен, но это "заделка на будущее", чтобы один раз сделать и больше не думать где хостить тг ботов, мелкие веб приложения для себя. Но главное, конечно, это то что это домашний проект и все логические доводы падут под "мне так захотелось и я сделал")
Нежелательно, но можно так как нагрузка не должна делить ресурсы с управляющими компонентами. По умолчанию не будет работать, в Kubernetes реализован механизм taints который не даст запуститься нагрузке на мастер узле, нужно удалить с него taint с ключом node-role.kubernetes.io/control-plane, но не делайте так на продакшене пожалуйста)
Совет "загляните в контакты телеграма" не совсем уместен. Опишу как было у меня: при смене телефона не стал переносить несколько контактов по причине ненадобности, в телеграме эти люди зарегистрированы не были, соответственно, в контактах телеграма их не было. В момент регистрации их в телеграме мне таки пришли уведомления и они добавились в контакты.
Вполне, необходимости запускать виртуалки на мастере у меня нет (пока что по крайней мере) А 10 процентов на воркерах не выглядят чем-то пугающим.
В случае смерти мастера останется ещё две ноды хранилища на которых хранятся pv дисков, будет неприятно но не смертельно, пусть и с простоем.
Спасибо за заботу о моих финансах. Подскажите пожалуйста, вам часто оплачивают личные проекты за счёт компании?
Можно менять умерший ссд на воркере, что, надеюсь, в скором времени делать не потребуется...)
Спасибо за добрые слова)
А вот по вопросу, честно говоря, не совсем понял. Подойдут любые 2-3 сервера выше требуемых ресурсов, можно и 1 сервер если не в продакшене, так же платформа поддерживает вложенную виртуализацию и, если это поддерживает железо, можете развернуть кластер на виртуалках.
Сомневаюсь что метрика по количеству подов релевантна, но их 121 в моей конфигурации) По ресурсам без нагрузки есть скрины htop'а под катом под конец статьи
Полноценный. Хотелось совместить декларативность кубов и виртуализацию так как решение домашнее, забыв про развёрнутое кривое веб приложение "наружу" не хочется получить у себя в сети нежелательных гостей, поэтому просто взял готовую платформу виртуализации на кубах.
Пока что только сервер nextcloud и крутится, никак не доберусь даже чтобы развернуть упомянутый gitlab, не хочу вводить в заблуждение ответом, если вспомню то принесу ответ как дойдут руки.
В Kubernetes, за хранилище ответственны csi плагины, соответственно, вы можете найти тот который поддерживает интересный вам тип хранилища и использовать вместо(может и вместе) с sds-replicated-volume.
Звучит как интересная метрика, которую, к сожалению, не снимал пока что. Постараюсь не забыть и вернуться когда проведу такие замеры
Данный логический переход, в основном, формируется в том что я психанул, в статью, по понятным причинам, такой аргумент приносить не хотелось)
К сожалению, пока что таких тестов не проводил
Необходимости, как таковой, нет. Вы можете использовать и две и одну машины (пожалуйста, не делайте так в продакшене)). Конкретно мой выбор обоснован следующими факторами: 1) На кластере из одной машины системные компоненты откушивают приличное количество процессорного времени на дешёвом железе, а переплачивать за мощный процессор нет смысла (пользователь либо один в лице меня, либо несколько человек). 2) Надёжность, возможно даже излишняя для дома, все диски существуют в трёх репликах (в данном случае по одной на каждый мини пк) и если один пк сгорит то можно просто подключить в кластер новый пк заместо старого (предположим импульс пожёг вообще всё внутри) или просто заменить ссд, все данные будут в сохранности. 3) Психологически показалось что одной машины под полезные нагрузки не хватит, поэтому взял две, к сожалению тут нет ни расчётов, ни прикидок, я так чувствовал)
Мне кажется что в таких экспериментах не набёртся материала на отдельную статью, но спасибо)
Согласен, но это "заделка на будущее", чтобы один раз сделать и больше не думать где хостить тг ботов, мелкие веб приложения для себя. Но главное, конечно, это то что это домашний проект и все логические доводы падут под "мне так захотелось и я сделал")
Нежелательно, но можно так как нагрузка не должна делить ресурсы с управляющими компонентами. По умолчанию не будет работать, в Kubernetes реализован механизм taints который не даст запуститься нагрузке на мастер узле, нужно удалить с него taint с ключом node-role.kubernetes.io/control-plane, но не делайте так на продакшене пожалуйста)
Безумный учёный в наши дни.
Совет "загляните в контакты телеграма" не совсем уместен. Опишу как было у меня: при смене телефона не стал переносить несколько контактов по причине ненадобности, в телеграме эти люди зарегистрированы не были, соответственно, в контактах телеграма их не было. В момент регистрации их в телеграме мне таки пришли уведомления и они добавились в контакты.