В итоге у нас есть свой форк, который мы поддерживаем и патчи, которые сопровождаем в актуальном состоянии в соответсвии с нашим форком.
Единственное что мы не законтрибьютили, это ipam и vmi-router позволяющий строить роуты к виртуалкам из vmCIDRs. Так как на данный момент это скорее компонент Deckhouse, а не KubeVirt. В дальнейшем все эти изменения, включая наше API и router планируется вынести в отдельный независимый virtualization-controller.
Про virtlink не слышал, спасибо, выглядит очень интересно ?
Но у меня куча вопросов:
Написали свой маленький runtime shim для собственного runtimeClass
Ого. А виртуалки-то в итоге в подах запускаются? Есть где посмотреть/почитать на эту тему?
Слышал подобное можно реализовать через VirtualKubelet. На DevConf.cz был безумный доклад, где чел запускал Google Chrome на Raspberry PI через Kubernetes :)
Оказалось, что OCI-hook'ов достаточно, чтобы запровиженить блочные устройства и macvtap. CNI у нас на основе OpenvSwitch - macvtap пробрасывается на порты в нём.
А где сами диски хранятся? Я правильно понимаю что CSI-плагин в вашей схеме не задействован?
1) ClusterVirtualMachineImage шаблоны хранятся в реджистри, скачиваются когда из них создаётся VirtualMachineDisk. Позже будет добавлен VirtualMachineImage (неймспейсед аналог для пользователей) и возможность кэширования имаджей в кластере
2) Это по сути тот же podCIDR но определенный для виртуалок. Маршруты для него прописываются автоматически, так что это может быть любой неиспользуемый рейндж
Думаю на данный момент нет варианта с репликацией быстрее чем DRBD. А в случае если репликация не требуется (например если база умеет самостоятельно в репликацию), можно создавать неотказоучтойчивые тома с одной лишь репликой.
В статье нет ни слова про RW-ФС, все решения тестировались исключительно в блочном режиме.
Классический LVM действительно умеет делать снапшоты, но они достаточно сильно влияют на производительность оригинального тома. По этой причине эта же возможность намеренно выпилена некоторыми вендорами в их софте.
Например Proxmox и LINSTOR не позволяют делать снапшоты на классическом LVM.
Привет из 2023, тут наконец такой интерфейс разработали, у нас всё хорошо :-)
https://habr.com/ru/companies/flant/articles/751746/
Спасибо за обмен опытом, с удовольствием буду следить за вашей активностью ?
Мы законтрибьютили в апстрим, но на данный момент наши ПР'ы повисли на стадии рассмотрения:
https://github.com/kubevirt/kubevirt/pull/7648
https://github.com/kubevirt/kubevirt/pull/7768
Патчи силиума тоже не прошли по тем или иным причинам:
https://github.com/cilium/cilium/pull/24098
https://github.com/cilium/cilium/pull/23712
В итоге у нас есть свой форк, который мы поддерживаем и патчи, которые сопровождаем в актуальном состоянии в соответсвии с нашим форком.
Единственное что мы не законтрибьютили, это ipam и vmi-router позволяющий строить роуты к виртуалкам из vmCIDRs. Так как на данный момент это скорее компонент Deckhouse, а не KubeVirt. В дальнейшем все эти изменения, включая наше API и router планируется вынести в отдельный независимый virtualization-controller.
Про virtlink не слышал, спасибо, выглядит очень интересно ?
Но у меня куча вопросов:
Ого. А виртуалки-то в итоге в подах запускаются? Есть где посмотреть/почитать на эту тему?
Слышал подобное можно реализовать через VirtualKubelet. На DevConf.cz был безумный доклад, где чел запускал Google Chrome на Raspberry PI через Kubernetes :)
А где сами диски хранятся? Я правильно понимаю что CSI-плагин в вашей схеме не задействован?
Здравствуйте,
1) ClusterVirtualMachineImage шаблоны хранятся в реджистри, скачиваются когда из них создаётся VirtualMachineDisk. Позже будет добавлен VirtualMachineImage (неймспейсед аналог для пользователей) и возможность кэширования имаджей в кластере
2) Это по сути тот же podCIDR но определенный для виртуалок. Маршруты для него прописываются автоматически, так что это может быть любой неиспользуемый рейндж
Дельное замечание, спасибо, поправил
Все таки под бд LINSTOR норм заходит.
Думаю на данный момент нет варианта с репликацией быстрее чем DRBD. А в случае если репликация не требуется (например если база умеет самостоятельно в репликацию), можно создавать неотказоучтойчивые тома с одной лишь репликой.
Превосходно! Помнится одно время игрался с GameBoy Camera, был такой девайс:
Меня всегда завораживали получаемые картинки, вот тут есть немного моего творчества.
Хотя конкретно эти фотки сделаны не на GameBoy Camera, а на уже поздней Nintendo DS с дополнительным фильтром.
На всякий случай скажу что в open source есть уже готовое решение:
https://github.com/LINBIT/linstor-gateway
LINSTOR можно накатить поверх ZFS и получить отказоустойчивый сторадж с репликацией, снапшотами, автоматическими бэкапами и прочими плюшками
Браво! Это нейронка написала? Отличная паста! :)
Хабы: Информационная безопасность xD
Спасибо за замечание, версии ZFS и LVM добавил в статью.
По поводу recordsize: изменялся параметр volblocksize, результаты и обсуждение здесь:
https://t.me/sds_ru/52676
del
LINSTOR позволяет делать это. Мы на каждый сетап генерим три StorageClass: linstor-r1, linstor-r2 и linstor-r3 (по количеству реплик)
Если приложению не нужна репликация на уровне стораджа можно использовать r1. А linstor-scheduler всегда отправит под на нужную ноду.
Проект OpenEBS использовал Longhorn в качестве основного бэкенда пока не появился cStor, который заимствовал код у ZFS и запускал его в user-space.
Судя по отзывам оба решения были достаточно медленными и Mayastor должен был решить все проблемы. По этой причине тестировался только он.
Нет, но было очень интересно посмотреть на результаты.
В статье нет ни слова про RW-ФС, все решения тестировались исключительно в блочном режиме.
Классический LVM действительно умеет делать снапшоты, но они достаточно сильно влияют на производительность оригинального тома. По этой причине эта же возможность намеренно выпилена некоторыми вендорами в их софте.
Например Proxmox и LINSTOR не позволяют делать снапшоты на классическом LVM.
Разумеется тесты проводились неоднократно, во всех случаях результаты были достаточно схожи.
Отлично, куда слать пулреквесты? ?
Неплохая идея!
Скажите, а вы как-то решили проблему словарей? Ведь проверка правописания, как правило, работает только для одной раскладки - текущей.