Как KubeVirt устраняет разрыв между контейнерами и виртуальными машинами

С тех пор как контейнеры появились на сцене не так давно, концепция контейнеризации привлекла внимание каждого предприятия. Большинство предприятий либо уже используют контейнерные рабочие нагрузки, либо работают над пилотными проектами. Контейнеры против виртуальных машин были постоянными спорами на протяжении веков. Многие организации признают недостатки виртуальных машин и работают над переносом своих рабочих нагрузок в контейнеры, в то время как другие колеблются или просто предпочитают виртуализированные рабочие нагрузки.

Виртуальные машины еще не умерли

Контейнеры всегда считались началом конца виртуализированных рабочих нагрузок. Организациям было легко увлечься этой идеей изолированных вычислительных компонентов, которым требуется лишь часть ресурсов, потребляемых виртуальными машинами. Однако, как с тех пор осознали многие организации, виртуальные машины еще не достигли конца пути. Чтобы точно понять, почему избавиться от виртуальных машин пока невозможно, нам нужно углубиться в функции, которые отличают виртуальные машины от контейнеров.

Проще говоря, виртуальная машина — это абстракция физической машины. Несколько виртуальных машин могут быть построены поверх хост-сервера, при этом каждая виртуальная машина будет полностью изолирована от хоста и других виртуальных машин в сети. Виртуальные машины могут быть построены в соответствии с требованиями рабочей нагрузки. Виртуальные машины могут быть созданы для запуска целых приложений или только их частей. Однако у виртуальных машин есть свои недостатки. Для каждой виртуальной машины требуется отдельный образ ОС, что увеличивает нагрузку на хранилище. Кроме того, виртуальные машины могут загружаться и работать медленнее, что делает их менее подходящими для большинства современных рабочих нагрузок. Контейнеры, однако, представляют собой абстракции меньшего размера, которые совместно используют ядро хоста, а это означает, что им требуется меньше места для хранения. Контейнеры также быстрее и портативнее, что делает их идеальными для рабочих нагрузок CI/CD. Однако контейнеры могут быть немного сложными, когда дело доходит до сети, и, поскольку все они имеют общее ядро, всегда существует более высокий риск атак.

Различия между двумя решениями очевидны. Однако для принятия и реализации решения о миграции требуется много размышлений и планирования. Миграция должна быть постепенной, а это означает, что за одну итерацию следует декомпозировать только несколько компонентов виртуализированных рабочих нагрузок. Это означает, что во время миграции виртуальные машины и контейнеры будут работать в тандеме. Если миграция определенных компонентов невозможна или просто нецелесообразна, учитывая стоимость миграции, вы все равно можете выбрать декомпозицию определенных компонентов, которые не создают такой же проблемы. В любой из этих ситуаций у вас будут виртуальные машины и контейнеры, работающие одновременно в ваших рабочих нагрузках. Итак, как вы можете обеспечить бесперебойную работу контейнеров и виртуальных машин друг с другом?

KubeVirt это ответ

По-прежнему существуют различные организации, которые выполняют большую часть своих рабочих нагрузок на виртуальных машинах. Организации, которые в той или иной степени хотели бы включить контейнеры в свои рабочие нагрузки, иногда вообще уклоняются от миграции из-за дополнительных затрат и отсутствия необходимого набора навыков. Для управления виртуальными машинами и контейнерами организациям потребуется инвестировать в две разные платформы для управления ими (например, vSphere и Kubernetes). Организациям также придется нанимать ресурсы, которые специализируются на любой платформе. Некоторые организации могут счесть миграцию нецелесообразной. Но именно здесь на сцену выходит KubeVirt. С KubeVirt вы можете запускать свои виртуальные машины в модулях Kubernetes вместе с контейнерами.

KubeVirt от RedHat был принят CNCF. KubeVirt — это проект с открытым исходным кодом, который расширяет возможности Kubernetes с помощью CRD (Custom Resource Definition KPI). В K8s ресурсы представляют собой набор похожих объектов API. Пользователи могут создавать собственные ресурсы с помощью CRD API с заданным именем и схемой, которые после создания управляются K8s. KubeVirt предоставляет CRD под названием VirtualMachine. Этот ресурс состоит из различных объектов VM, которые определяют свойства VM, такие как тип процессора или машины, размер RAM и VCPU, а также различные сетевые карты, необходимые для VM. Вы не можете просто поднять и переместить целые виртуальные машины в модули Kubernetes и на этом остановиться. Чтобы запустить виртуальные машины, вам нужно больше, чем просто ресурсы виртуальной машины. В то время как Kubernetes заботится о сети, планировании и хранении, нам нужен агент, который работает в кластере и обеспечивает функциональность виртуализации для наших виртуальных машин K8s. Этот агент предоставляется KubeVirt. Давайте взглянем на различные компоненты KubeVirt.

virt-controller: этот агент работает в кластере и отвечает за виртуализацию всего кластера. Virt-controller проверяет любой новый объект виртуальной машины и создает модули для запуска этих виртуальных машин. Этот компонент KubeVirt также отслеживает CRD виртуальных машин/VMI и управляет их последующими жизненными циклами модулей.

virt-handler: как и virt-controller, этот компонент постоянно проверяет наличие любых обновлений объекта VM. Его работа заключается в том, чтобы обеспечить модификацию виртуальной машины в соответствии с указанными требованиями или модификациями. Каждый хост запускает на нем экземпляр virt-handler.

virt-launcher: этот компонент работает в основном контейнере модуля и отвечает за запуск процесса виртуальной машины всякий раз, когда запланирован запуск объекта виртуальной машины, связанного с этим конкретным модулем. Virt-launcher также предоставляет контрольные группы и пространства имен, необходимые для размещения процесса виртуальной машины. virt-handler передает объект виртуальной машины в virt-launcher всякий раз, когда ресурс виртуальной машины настроен на начало. virt-launcher использует локальный компонент libvirtd для запуска процесса. Virt-launcher отслеживает процесс ВМ и завершается, когда процесс завершается. Virt-launcher также гарантирует, что процесс виртуальной машины будет успешным, даже если его продолжительность превышает время выполнения Kubernetes.

libvirtd: этот компонент присутствует в каждом модуле VM/VMI и помогает virt-launcher управлять процессами VM/VMI. libvirtd также используется virt-handler для подачи сигнала кластеру о создании домена.

KubeVirt можно установить или удалить в существующих кластерах Kubernetes, не создавая их с нуля. Это позволяет пользователям добавлять новые виртуальные машины к существующим полностью контейнеризованным рабочим нагрузкам. С KubeVirt организациям не нужно тратить дни на контейнеризацию приложений, прежде чем они начнут миграцию, поскольку они просто перемещают свои виртуальные машины на K8 и постепенно разлагают их на контейнеры. Точно так же KubeVirt помогает избежать хлопот, связанных с фрагментацией сложных монолитных приложений, которые трудно поместить в контейнеры.

KubeVirt, виртуальные машины и контейнеры: мирное сосуществование

KubeVirt — это инструмент для организаций, которые все еще находятся на грани миграции. Многие организации осознали, что виртуальные машины еще не закончились. В идеале рабочая нагрузка выполняется как на виртуальных машинах, так и на контейнерах, и KuberVirt — это способ преодолеть разрыв между ними. Не все нужно раскладывать по контейнерам. Более тяжелые и менее часто изменяемые компоненты могут по-прежнему размещаться на виртуальных машинах, а более мелкие и более динамичные компоненты могут размещаться в контейнерах. С KubeVirt виртуальные машины и контейнеры будут не просто сосуществовать, но и без проблем работать вместе. В будущем многие организации захотят использовать этот инструмент, чтобы найти идеальный баланс между традиционным и современным способом вычислений. По мере развертывания 5G в не столь отдаленном будущем KuberVirt сможет еще больше помочь организациям. С увеличением скорости сети любые проблемы с задержкой и производительностью, возникающие в таких гибридных контейнерных рабочих нагрузках, будут решены, что приведет к еще более безупречной работе. KubeVirt все еще довольно молод и развивается каждый день. Будет интересно посмотреть, сколько он может предложить.