Не обязательно, вы можете арендовать железки и получать выгоду уже от этого.
Основная проблема bare metal - это сложность обслуживания, именно поэтому люди идут в cloud. Они просто не хотят тратить своё время/деньги на поддержание всего стека своими силами.
Облачные провайдеры это понимают и делают наценку на каждом уровне абстракции, стараются максимально уплотнить сервисы между тенантами. Спускаясь на уровень ниже вы получаете больше контроля над своей инфраструктурой, лучший перформанс и ниже цены.
С другой стороны растет и операционный оверхед. Платформы вроде Cozystack призваны снизить нагрузку на поддержание своей инфраструктуры принося гибкость облаков и возможность запускать managed-сервисы на собственном оборудовании.
Если вы хотите добавить свои приложения, на данный момент есть два варианта:
in-tree, в этом случае достаточно прислать pull-request на гитхабе, желательно предварительно обсудить с командой возможность включения данного сервиса в платформу и возможные варианты реализации.
out-tree, в этом случае придется подготовить отдельный репозиторий и подключить его в Cozystack. Мы хотим поддерживать такой сетап, но инструкции пока нет.
В любом случае проще всего будет начать дискуссию в нашем ТГ канале t.me/cozystack или t.me/cozystack_ru
Мейнтейнеры подскажут в каком направлении двигаться дальше.
Приходите на наш комьюнити-мит. Будем рады новым контрибьютерам 👋
Несмотря на схожесть, это немного разные продукты решающие совсем разные задачи.
Cozystack - это платформа для предоставления managed-сервисов. Deckhouse - это дистрибутив Kubernetes преднастроенный для использования.
Насколько мне известно на данный момент Deckhouse не умеет запускать полнофункциональные кластера Kubernetes по кнопке, как и предоставлять остальные managed-сервисы в мультитенантной среде.
Например у вас есть три машины, и на них равёрнут etcd кластер. Тогда вы можете описать systemd unit, который будет запускать произвольный процесс с помощью etcd-await-election.
Если вы запустите три таких процесса в рамках одного lock name, только один из них возьмёт lease и будет выполняться, оставльные будут ждать смерти первого.
Как только первый умрёт, лок возьмёт кто-то другой и запустит ваш процесс уже на новой ноде.
Kubernetes очень сильно поменял подходы в отношении архитектуры ПО. Современное ПО строится из соображений что всегда что-то может пойти не так:
Ваше железо непременно умрёт (главное чтобы не одновременно).
Сеть будет лагать
Виртуалка - это средство изоляции, а не непотопляемый корабль.
Другими словами вам больше не нужна live-миграция и HA на уровне виртуальных машин. Теперь это достигается другими методами и инструментами.
Принцип KISS научил нас тому что чем система проще - тем стабильнее она работает. Когда появился Oauth2, он в большинстве случаев заменил LDAP именно из-за своей простоты и надёжности. Тоже сейчас происходит и с системами виртуализации.
Современные системы виртуализации всё чаще имплементируют более простой облачный паттерн, где отдельно взятая виртуалка может умереть и это не заафектит всю систему в целом. А если ваше приложение умеет работать в такой среде, то у вас получается простое и надёжное решение, которое выживет где угодно.
Я не говорю что VMware - это плохое решение, но похоже что настало время менять подходы и переходить на свободные технологии.
Наличие хотя бы одной резервной ноды — это хорошая практика, прежде всего потому, что необходимо иметь ресурсы, позволяющие вашей рабочей нагрузке переехать на другую ноду в случае отказа. На самом деле резервная нода не обязана постоянно находиться в режиме простаивания, она может функционировать как обычная нода в кластере. Я бы рекомендовал загружать ваши узлы не более чем на 75%-85% в зависимости от объёма самой ноды, чтобы оставался небольшой запас по ресурсам.
В этой схеме (как и в целом в Kubernetes) большинство компонентов запускается без сохранеия состояния. А значит их можно легко обновлять просто применив в кластер манифесты с новыми версиями.
Перекатывание воркеров происходит так же как и в любом облаке, путем удаления старых виртуалок и введения в кластер новых
Насчёт thin lvm соглашусь, но мы его и не поддерживаем. Если брать классический LVM, то потерять на нём данные нужно ещё постараться. Это же по сути просто раздел диска, чуть более динамический но всё же.
В ZFS файловую систему вообще разрабатывают исходя из принципа что "ваше железо непременно умрёт". Вон @gmelikov не даст соврать:
Одно дело развернуть кубер для своих внутренних сервисов. Совсем другое дело организовать систему которая позволит запускать кластера по клику, будет переносимой и поддерживать все функции облачного Kubernetes.
Не обязательно, вы можете арендовать железки и получать выгоду уже от этого.
Основная проблема bare metal - это сложность обслуживания, именно поэтому люди идут в cloud. Они просто не хотят тратить своё время/деньги на поддержание всего стека своими силами.
Облачные провайдеры это понимают и делают наценку на каждом уровне абстракции, стараются максимально уплотнить сервисы между тенантами.
Спускаясь на уровень ниже вы получаете больше контроля над своей инфраструктурой, лучший перформанс и ниже цены.
С другой стороны растет и операционный оверхед. Платформы вроде Cozystack призваны снизить нагрузку на поддержание своей инфраструктуры принося гибкость облаков и возможность запускать managed-сервисы на собственном оборудовании.
Верно, всё управление будет доступно только через Talos API
Да, всё верно, после применения конфига на Talos Linux запущенный в Maintenance-режиме, он скачивает установочный образ и применяет его на диск
Не встречал такого, спасибо. Проверял у нескольких провайдеров на KVM.
Видимо специфичный кейс для Hyper V
Привет, у нас есть дока по базовому устройству Cozystack
https://cozystack.io/docs/development/
Если вы хотите добавить свои приложения, на данный момент есть два варианта:
in-tree, в этом случае достаточно прислать pull-request на гитхабе, желательно предварительно обсудить с командой возможность включения данного сервиса в платформу и возможные варианты реализации.
out-tree, в этом случае придется подготовить отдельный репозиторий и подключить его в Cozystack. Мы хотим поддерживать такой сетап, но инструкции пока нет.
В любом случае проще всего будет начать дискуссию в нашем ТГ канале t.me/cozystack или t.me/cozystack_ru
Мейнтейнеры подскажут в каком направлении двигаться дальше.
Приходите на наш комьюнити-мит. Будем рады новым контрибьютерам 👋
Зашёл сюда написать этот комментарий, а он уже написан :D
Несмотря на схожесть, это немного разные продукты решающие совсем разные задачи.
Cozystack - это платформа для предоставления managed-сервисов.
Deckhouse - это дистрибутив Kubernetes преднастроенный для использования.
Насколько мне известно на данный момент Deckhouse не умеет запускать полнофункциональные кластера Kubernetes по кнопке, как и предоставлять остальные managed-сервисы в мультитенантной среде.
Они переводили время на гипервизоре на несколько месяцев назад и продолжали использовать)
Думаю в рамках одного дистрибутива обновление будет происходить проще, но увидим, главное что экспертиза теперь есть
Да, примерно для такого кейса и создавалось.
Например у вас есть три машины, и на них равёрнут etcd кластер.
Тогда вы можете описать systemd unit, который будет запускать произвольный процесс с помощью etcd-await-election.
Если вы запустите три таких процесса в рамках одного lock name, только один из них возьмёт lease и будет выполняться, оставльные будут ждать смерти первого.
Как только первый умрёт, лок возьмёт кто-то другой и запустит ваш процесс уже на новой ноде.
Спасибо за статью, наконец-то кто-то разложил по полочкам! Добавил в избранное, буду использовать как референс для тех кто не верит.
BTW. Было бы очень интересно услышать ваше мнение насчёт ZFS'ного dRAID, насколько он эффективен и за счёт чего решает вышеобозначенные проблемы.
Время сейчас такое, меняется софт и подходы.
Kubernetes очень сильно поменял подходы в отношении архитектуры ПО.
Современное ПО строится из соображений что всегда что-то может пойти не так:
Ваше железо непременно умрёт (главное чтобы не одновременно).
Сеть будет лагать
Виртуалка - это средство изоляции, а не непотопляемый корабль.
Другими словами вам больше не нужна live-миграция и HA на уровне виртуальных машин.
Теперь это достигается другими методами и инструментами.
Принцип KISS научил нас тому что чем система проще - тем стабильнее она работает.
Когда появился Oauth2, он в большинстве случаев заменил LDAP именно из-за своей простоты и надёжности. Тоже сейчас происходит и с системами виртуализации.
Современные системы виртуализации всё чаще имплементируют более простой облачный паттерн, где отдельно взятая виртуалка может умереть и это не заафектит всю систему в целом.
А если ваше приложение умеет работать в такой среде, то у вас получается простое и надёжное решение, которое выживет где угодно.
Я не говорю что VMware - это плохое решение, но похоже что настало время менять подходы и переходить на свободные технологии.
Наличие хотя бы одной резервной ноды — это хорошая практика, прежде всего потому, что необходимо иметь ресурсы, позволяющие вашей рабочей нагрузке переехать на другую ноду в случае отказа. На самом деле резервная нода не обязана постоянно находиться в режиме простаивания, она может функционировать как обычная нода в кластере. Я бы рекомендовал загружать ваши узлы не более чем на 75%-85% в зависимости от объёма самой ноды, чтобы оставался небольшой запас по ресурсам.
В этой схеме (как и в целом в Kubernetes) большинство компонентов запускается без сохранеия состояния. А значит их можно легко обновлять просто применив в кластер манифесты с новыми версиями.
Перекатывание воркеров происходит так же как и в любом облаке, путем удаления старых виртуалок и введения в кластер новых
Насчёт thin lvm соглашусь, но мы его и не поддерживаем. Если брать классический LVM, то потерять на нём данные нужно ещё постараться. Это же по сути просто раздел диска, чуть более динамический но всё же.
В ZFS файловую систему вообще разрабатывают исходя из принципа что "ваше железо непременно умрёт". Вон @gmelikov не даст соврать:
По крайней мере в случае чего эти данные всегда можно достать из backing storage обычным dd
Да имелось ввиду это, описывать и менеджить такой конфиг как код не удобно
И подхватила, проект был передан ControlPlane вместе со всей core-командой разработчиков.
По идее да, но такая возможность сильно не тестировалась, возможно столкнётесь с nodeAntiAffinity :)
Одно дело развернуть кубер для своих внутренних сервисов. Совсем другое дело организовать систему которая позволит запускать кластера по клику, будет переносимой и поддерживать все функции облачного Kubernetes.