Open Source-инструменты для запуска виртуальных машин в нативном облаке

Унаследованные рабочие нагрузки мешают вам перейти в нативную облачную среду? Независимый эксперт Кристофер Тоцци рассказывает на портале ITPro Today о четырех открытых решениях для запуска виртуальных машин (ВМ) в нативной облачной среде с минимальными изменениями.

Как и многие другие современные ИТ-специалисты, вероятно вы хотите перейти на нативные облачные технологии. Но у вас есть унаследованные рабочие нагрузки, например, монолиты, которые могут работать только на ВМ.

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

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

Зачем запускать ВМ в нативной облачной среде?

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

Основная причина проста: ВМ, на которых размещаются унаследованные рабочие нагрузки, остаются, но поддерживать отдельные среды хостинга для их запуска — обременительно.

Между тем, приведение унаследованных рабочих нагрузок в соответствие с нативно-облачными стандартами может оказаться невозможным. Конечно, в теории у вас может быть время и инженерные ресурсы для рефакторинга таких нагрузок, чтобы они могли работать в нативной облачной среде, но в реальном мире это далеко не всегда так.

Поэтому вам нужны инструменты — например, одно из четырех описанных ниже Open Source-решений, — которые позволят унаследованным ВМ мирно сосуществовать с нативными облачными рабочими нагрузками.

1. Запуск виртуальных машин с помощью KubeVirt

Вероятно, самым популярным решением для развертывания ВМ в нативной облачной среде является KubeVirt, который работает путем запуска ВМ внутри Kubernetes Pods. Если вы хотите запустить ВМ вместе с контейнерами, то просто установите KubeVirt в существующий кластер Kubernetes с помощью:

export RELEASE=v0.35.0

# Deploy the KubeVirt operator

kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${RELEASE}/kubevirt-operator.yaml

# Create the KubeVirt CR (instance deployment request) which triggers the actual installation

kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${RELEASE}/kubevirt-cr.yaml

# wait until all KubeVirt components are up

kubectl -n kubevirt wait kv kubevirt —for condition=Available

Затем создайте и примените YAML-файл, описывающий каждую ВМ, которую вы хотите запустить.

KubeVirt запускает каждую машину внутри контейнера, поэтому с точки зрения Kubernetes ВМ является обычным Pod (с некоторыми ограничениями, которые обсуждаются в следующем разделе). Однако вы по-прежнему получаете образ ВМ, постоянное хранилище и фиксированное распределение процессора и памяти, как и в случае с обычной ВМ.

Это означает, что KubeVirt не требует практически никаких изменений в вашей ВМ. Все, что вам нужно сделать, это установить KubeVirt и создать развертывания для ваших ВМ, чтобы они работали как Pods.

2. Подход Virtlet

Если вы хотите примкнуть к приверженцем подхода к ВМ как к подгруппам, вам может понравиться Virtlet, инструмент с открытым исходным кодом от Mirantis.

Virtlet похож на KubeVirt тем, что также позволяет запускать ВМ внутри Kubernetes Pods. Однако ключевое различие между этими двумя инструментами заключается в том, что Virtlet обеспечивает более глубокую интеграцию ВМ в спецификацию Kubernetes Pod. Это означает, что с помощью Virtlet можно управлять ВМ как частью DaemonSet или ReplicaSet, чего нельзя сделать с помощью KubeVirt (в нем есть аналогичные возможности, но они являются дополнениями, а не нативными компонентами Kubernetes).

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

3. Поддержка Istio для виртуальных машин

Что если вы не хотите управлять своими ВМ как контейнерами? Что если вы хотите обращаться с ними как с ВМ, но при этом позволить им легко интегрироваться с микросервисами?

Вероятно, лучшим решением будет подключение ВМ к Istio, сервисной сетке с открытым исходным кодом. При таком подходе вы можете развертывать и управлять ВМ с помощью стандартных инструментов для ВМ, а управление сетями, балансировку нагрузок и т. д. осуществлять через Istio.

К сожалению, процесс подключения ВМ к Istio довольно утомителен, и в настоящее время его трудно автоматизировать. Он сводится к установке Istio на каждую из ВМ, которые вы хотите подключить, настройке пространства имен для них, а затем подключению каждой ВМ к Istio.

4. Контейнеры и виртуальные машины бок о бок с OpenStack

Техники, которые мы рассмотрели до сих пор, предполагают использование нативных облачных платформ, таких как Kubernetes или Istio, и добавление к ним поддержки ВМ.

Альтернативный подход заключается в том, чтобы взять не нативную облачную платформу, которая позволяет запускать ВМ, а затем привить к ней нативный облачный инструментарий.

Именно это вы получите, если запустите ВМ и контейнеры вместе на OpenStack. Эта платформа изначально была разработана как способ развертывания ВМ (среди прочих типов ресурсов) для создания частного облака. Но теперь на OpenStack может также работать Kubernetes.

Таким образом, вы можете использовать OpenStack для развертывания и управления ВМ и одновременно запускать нативно-облачные, контейнерные рабочие нагрузки с помощью Kubernetes. В итоге у вас будет два уровня оркестровки — базовая установка OpenStack и среда Kubernetes, поэтому такой подход более сложен с точки зрения администрирования.

Однако его главное преимущество заключается в том, что у вас будет возможность держать ваши ВМ и контейнеры относительно отдельно друг от друга, поскольку ВМ не будут частью Kubernetes. Вы также не будете ограничены инструментарием Kubernetes для управления ВМ. Вы сможете обращаться с ВМ как со стандартными ВМ, а с контейнерами — как со стандартными контейнерами.

Заключение

Экосистема Open Source предлагает ряд подходов, помогающих ВМ сосуществовать с нативными облачными рабочими нагрузками. Лучший выбор для вас зависит от того, хотите ли вы использовать подход, ориентированный на Kubernetes (в этом случае вам подойдет KubeVirt или Virtlet), или вы хотите позволить своим ВМ существовать рядом с контейнерами, не будучи тесно интегрированными с ними (в этом случае наиболее целесообразно использовать OpenStack). А если вам нужна интеграция только на сетевом уровне, но не на уровне оркестровки, рассмотрите возможность подключения ВМ к Istio.