Как стать автором
Обновить

KubeVirt: внутреннее устройство и сеть. Как достигнуть совершенства? (обзор и видео доклада)

Уровень сложностиСредний
Время на прочтение15 мин
Количество просмотров11K
Всего голосов 38: ↑37 и ↓1+43
Комментарии8

Комментарии 8

Спасибо! Отличная статья.

Кроме KubeVirt можно ещё посмотреть Virtink. Он легче KubeVirt: обходится без долгоживущего launcher'а, без libvirt и даже без QEMU (вместо него Stratovirt). К сожалению, не поддерживает блочные устройства: VM-ки грузятся с docker-образов, как обычные контейнеры.

Нам, правда, не подошло ни то, ни другое. Написали свой маленький runtime shim для собственного runtimeClass, который вместо runc сразу запускает либо QEMU, либо Stratovirt (напрямую без libvirt) и управляет lifecycle'ом VM-ки через QMP. Аналога virt-handler'а нет. Оказалось, что OCI-hook'ов достаточно, чтобы запровиженить блочные устройства и macvtap. CNI у нас на основе OpenvSwitch - macvtap пробрасывается на порты в нём.

Про virtlink не слышал, спасибо, выглядит очень интересно ?

Но у меня куча вопросов:

Написали свой маленький runtime shim для собственного runtimeClass

Ого. А виртуалки-то в итоге в подах запускаются? Есть где посмотреть/почитать на эту тему?

Слышал подобное можно реализовать через VirtualKubelet. На DevConf.cz был безумный доклад, где чел запускал Google Chrome на Raspberry PI через Kubernetes :)

Оказалось, что OCI-hook'ов достаточно, чтобы запровиженить блочные
устройства и macvtap. CNI у нас на основе OpenvSwitch - macvtap
пробрасывается на порты в нём.

А где сами диски хранятся? Я правильно понимаю что CSI-плагин в вашей схеме не задействован?

Виртуалки, конечно, в подах запускаются. Абъюзим аннотации подов для их конфигурации и для управления lifecycle'ом. Зато не нужен отдельный шедулер. Конечный пользователь, разумеется, сам под не создает: есть отдельный контроллер для нашего CRD, который уже разбирается с тем, что именно надо вписать в ресурс пода и как его изменить, чтобы, например, произошел graceful shutdown. В KubeVirt, если мне память не изменяет, для этого есть отдельный CRD типа Action. К сожалению, руки не доходят, чтобы на эту тему статью писать, хотя в планах было. Показать пока тоже не могу - процесс опенсорсинга сильно бюрократизирован.

Писать свой kubelet - это, по-моему, уже перебор. Для достаточной нам функциональности вполне хватает собственного шима отвечающего вот этой спеке. В репозитории containerd есть код скелета шима, который просто надо наполнить своим "мясом". Вообще, архитектура containerd и его плагинная система заслуживает отдельного разговора. Кроме того, недавно там появился SandboxAPI, облегчающий запуск тасков внутри виртуалок. Но это решение ориентировано именно на таски. Для ваших задач (и наших) поможет не сильно.

Диски хранятся в локальном LVM ноды. Используется собственный CSI плагин, который нарезает диски из LVM в момент, когда под уже зашедулен на ноду. CSI - тоже большая тема, поскольку ориентирована на remote storage, а не на local. Наше решение довольно простецкое - OCI-хук скачивает образ и заливает его в готовое устройство на этапе createRuntime. Хотя, наверное, идеологически правильнее применить для local storage готовый populator (ссылку быстро найти не могу, искать лучше по имени Patrick Ohly - он этой темой занимался, когда PMEM был ещё big thing в Intel).

Спасибо за обмен опытом, с удовольствием буду следить за вашей активностью ?

Вы законтрибьютили в апстрим или поддерживаете свой форк?

Поддерживаем свое.

Мы законтрибьютили в апстрим, но на данный момент наши ПР'ы повисли на стадии рассмотрения:

Патчи силиума тоже не прошли по тем или иным причинам:

В итоге у нас есть свой форк, который мы поддерживаем и патчи, которые сопровождаем в актуальном состоянии в соответсвии с нашим форком.

Единственное что мы не законтрибьютили, это ipam и vmi-router позволяющий строить роуты к виртуалкам из vmCIDRs. Так как на данный момент это скорее компонент Deckhouse, а не KubeVirt. В дальнейшем все эти изменения, включая наше API и router планируется вынести в отдельный независимый virtualization-controller.

Давно собирался потрогать KubeVirt, да руки не доходили, а тут такой подробный разбор!
Спасибо за статью!
Сложилось впечатление что слой контейнеров немного мешает управлению виртуализации. Мне нравится идея k8s работы с ресурсами и реакция на их изменение, но в случае виртуализации хочется упростить слой c kubelet с абстракцией подов... а на такое нужно много человеческих ресурсов... эээх

Зарегистрируйтесь на Хабре, чтобы оставить комментарий