OpenShift virtualization (апстрим проект – Kubernetes: KubeVirt, см. здесь и здесь), в девичестве Container-native Virtualization, был представлен, как функционал платформы OpenShift, который предназначен для развертывания и управления виртуальными машинами (ВМ), как базовыми сущностями Kubernetes. Такого рода задача является технически сложной, по причине фундаментальных различий технологий. Для того, чтобы добиться поставленной цели, были использованы всем знакомые технологии на базе Red Hat Enterprise Linux и KVM, которые с нами не один год и доказали свою эффективность.
В этой статье мы рассмотрим технические аспекты OpenShift virtualization, которые делают возможным сосуществование ВМ и контейнеров в рамках одной платформы, которая управляет ими, как единым целым.
Контейнеры задействуют механизмы Linux-ядра, такие как namespaces и cgroups, для изоляции процессов и управления ресурсами. Обычно под процессами понимаются приложения Python, Java или исполняемые файлы, но на самом деле это могут быть любые процессы, тот же bash, Emacs или vim.
А что такое виртуальная машина? С точки зрения гипервизора – это тоже процесс. Но только не процесс приложения, а KVM-процесс, отвечающий за выполнение конкретной ВМ.
Контейнерный образ содержит в себе все инструменты, библиотеки и файлы, необходимые для виртуальной машины KVM. Если проинспектировать pod работающей ВМ, то мы увидим там хелперы и процессы qemu-kvm. Кроме того, у нас есть доступ к KVM-инструментам для управления виртуальными машинами, таким как qemu-img, qemu-nbd и virsh.
Поскольку виртуальная машина – это pod, она автоматом наследует всю функциональность pod’а в Kubernetes. К ВМ-pod’ам точно так же, как и обычным pod’ам, применяются схемы и критерии планировщика вроде taints, tolerations, affinity и anti-affinity. Также вы получаете преимущества в виде высокой доступности и т.д. Однако есть одно важное отличие: обычные pod’ыне мигрируют с хоста на хост в привычном нам смысле. Если узел отключается, то pod на нем прерывается и переназначается на другой узел в кластере. А в случае виртуальной машины мы ожидаем увидеть живую миграцию.
Для устранения этого пробела был создан custom resource definition (CDR), описывающий механизм живой миграции, который отвечает за инициализацию, мониторинг и управление живыми миграциями ВМ между рабочими узлами.
При деактивации узла для тех его виртуальных машин, у которых в качестве eviction strategy задано Live Migration, автоматически создаются задачи миграции. Таким образом можно контролировать поведение виртуальных машин, при перемещении между нодами кластера. Вы можете как настроить Live Migration, так и управлять ВМ, как и всеми остальными подами.
Любая Kubernetes-система обеспечивает связь между узлами и pod’ами с помощью программных SDN-сетей. OpenShift не исключение и начиная с 3-й версии по умолчанию использует для этого OpenShiftSDN. Кроме того, в OpenShift 4 появился еще одна новая функция под названием Multus, которая позволяет сделать доступным несколько сетей и подключать к ним pod одновременно.
С помощью Multus администратор может задать дополнительные сети CNI, которые потом будут развертываются и настраиваются на кластере специальным оператором Cluster Network Operator. После чего pod’ы подключаются к одной или нескольким из этих сетей, обычно к стандартному OpenShiftSDN и дополнительному интерфейсу. Устройства SR-IOV, стандартные Linux Bridge, устройства MACVLAN и IPVLAN – все это тоже можно использовать, если это нужно вашей ВМ. На рисунке ниже показано, как задать Multus CNI для bridge сети на интерфейсе eth1:
Применительно к OpenShift virtualization это означает, что ВМ можно подключить к внешней сети напрямую, минуя SDN. Это важно для виртуальных машин, перенесенных на OpenShift из Red Hat Virtualization или VMware vSphere, так как при наличии доступа на второй уровень OSI не будет смены сетевых настроек. Это также означает, что ВМ может иметь сетевой адрес, обращения к которому минуют SDN. Таким образом, мы можем эффективно использовать специализированные сетевые адаптеры, или подключаться по сети к СХД напрямую…
Подробнее узнать о том, как создавать и подключать виртуальные машины OpenShift virtualization к сети можно здесь. Кроме того, nmstate operator, развертываемый в составе OpenShift virtualization, предлагает еще один хорошо знакомый вам способ создания и управления сетевыми конфигурациями на физических узлах, которые используются под гипервизорами.
Подключение и управление дисками виртуальных машин в рамках OpenShift virtualization выполняется с использованием таких Kubernetes-концепций как StorageClasses, PersistentVolumeClaims (PVC) и PersistentVolume (PV), а также стандартных для среды Kubernetes протоколов хранения. Таким образом, администраторы Kubernetes и отвечающие за приложения команды получают единый и привычный механизм управления как для контейнеров, так и для виртуальных машин. А для многих администраторов сред виртуализации эта концепция может показаться знакомой, поскольку в ней используются тот же принцип разделения файлов конфигурации ВМ и дисков, который применяется в OpenStack и на многих других облачных платформах.
Однако нельзя просто каждый раз создавать новый диск для ВМ, так как при миграции с гипервизора в OpenShift, нам необходимо сохранить данные. Да даже когда мы разворачиваем новую ВМ, это всегда быстрее сделать из шаблона, чем создать с нуля. Таким образом нам необходим функционал импорта имеющихся дисков.
Для упрощения этой задачи OpenShift virtualization разворачивает проект Containerized Data Importer (CDI), который сводит импорт дисковых образов дисков из нескольких источников к созданию записи в PVC.
Именно эта запись и активирует CDI, запуская последовательность действий, показанных на рисунке ниже:
После того, как CDI отработает, PVC будет содержать диск виртуальной машины готовый к использованию и приведённый в стандартный для OpenShift формат…
При работе с OpenShift virtualization также пригодится OpenShift Container Storage (OCS), решение Red Hat на основе файловой системы Ceph, реализующее функционал постоянного хранилища для контейнеров. В дополнение к стандартным PVC-методам доступа – RWO (блочный) и RWX (файловый) – OCS предоставляет RWX для устройств raw block, что очень полезно при организации совместного блочного доступа для приложений с высокими требованиями к производительности. Кроме того, OCS поддерживает новый стандарт запроса группы объектов Object Bucket Claim, позволяющий приложениям напрямую использовать объектное хранилище данных.
Если вам интересно проверить, как это работает, то знайте, что OpenShift virtualization уже доступна в варианте Tech Preview в составе OpenShift 3.11 и выше. Владельцы действующей подписки на OpenShift могут воспользоваться OpenShift virtualization совершенно бесплатно и без каких-либо дополнительных телодвижений. На момент выхода этого поста актуальными являются OpenShift 4.4 и OpenShift virtualization 2.3, если вы используете предыдущие версии, то для получения последних функций стоит обновиться. Полностью поддерживаемая версия OpenShift virtualization должна выйти во второй половине 2020 года.
Для получения дополнительной информации обратитесь к документации по OpenShift за инструкциями по установке, включая раздел по настройке Multus, где приводятся сведения о настройке внешних сетей.
В этой статье мы рассмотрим технические аспекты OpenShift virtualization, которые делают возможным сосуществование ВМ и контейнеров в рамках одной платформы, которая управляет ими, как единым целым.
Вычислительные задачи
Контейнеры задействуют механизмы Linux-ядра, такие как namespaces и cgroups, для изоляции процессов и управления ресурсами. Обычно под процессами понимаются приложения Python, Java или исполняемые файлы, но на самом деле это могут быть любые процессы, тот же bash, Emacs или vim.
А что такое виртуальная машина? С точки зрения гипервизора – это тоже процесс. Но только не процесс приложения, а KVM-процесс, отвечающий за выполнение конкретной ВМ.
Контейнерный образ содержит в себе все инструменты, библиотеки и файлы, необходимые для виртуальной машины KVM. Если проинспектировать pod работающей ВМ, то мы увидим там хелперы и процессы qemu-kvm. Кроме того, у нас есть доступ к KVM-инструментам для управления виртуальными машинами, таким как qemu-img, qemu-nbd и virsh.
Поскольку виртуальная машина – это pod, она автоматом наследует всю функциональность pod’а в Kubernetes. К ВМ-pod’ам точно так же, как и обычным pod’ам, применяются схемы и критерии планировщика вроде taints, tolerations, affinity и anti-affinity. Также вы получаете преимущества в виде высокой доступности и т.д. Однако есть одно важное отличие: обычные pod’ыне мигрируют с хоста на хост в привычном нам смысле. Если узел отключается, то pod на нем прерывается и переназначается на другой узел в кластере. А в случае виртуальной машины мы ожидаем увидеть живую миграцию.
Для устранения этого пробела был создан custom resource definition (CDR), описывающий механизм живой миграции, который отвечает за инициализацию, мониторинг и управление живыми миграциями ВМ между рабочими узлами.
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstanceMigration
metadata:
name: migration-job
spec:
vmiName: fedora
При деактивации узла для тех его виртуальных машин, у которых в качестве eviction strategy задано Live Migration, автоматически создаются задачи миграции. Таким образом можно контролировать поведение виртуальных машин, при перемещении между нодами кластера. Вы можете как настроить Live Migration, так и управлять ВМ, как и всеми остальными подами.
Сеть
Любая Kubernetes-система обеспечивает связь между узлами и pod’ами с помощью программных SDN-сетей. OpenShift не исключение и начиная с 3-й версии по умолчанию использует для этого OpenShiftSDN. Кроме того, в OpenShift 4 появился еще одна новая функция под названием Multus, которая позволяет сделать доступным несколько сетей и подключать к ним pod одновременно.
С помощью Multus администратор может задать дополнительные сети CNI, которые потом будут развертываются и настраиваются на кластере специальным оператором Cluster Network Operator. После чего pod’ы подключаются к одной или нескольким из этих сетей, обычно к стандартному OpenShiftSDN и дополнительному интерфейсу. Устройства SR-IOV, стандартные Linux Bridge, устройства MACVLAN и IPVLAN – все это тоже можно использовать, если это нужно вашей ВМ. На рисунке ниже показано, как задать Multus CNI для bridge сети на интерфейсе eth1:
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
additionalNetworks:
- name: multus1
rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam":
{ "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }'
type: Raw
Применительно к OpenShift virtualization это означает, что ВМ можно подключить к внешней сети напрямую, минуя SDN. Это важно для виртуальных машин, перенесенных на OpenShift из Red Hat Virtualization или VMware vSphere, так как при наличии доступа на второй уровень OSI не будет смены сетевых настроек. Это также означает, что ВМ может иметь сетевой адрес, обращения к которому минуют SDN. Таким образом, мы можем эффективно использовать специализированные сетевые адаптеры, или подключаться по сети к СХД напрямую…
Подробнее узнать о том, как создавать и подключать виртуальные машины OpenShift virtualization к сети можно здесь. Кроме того, nmstate operator, развертываемый в составе OpenShift virtualization, предлагает еще один хорошо знакомый вам способ создания и управления сетевыми конфигурациями на физических узлах, которые используются под гипервизорами.
Хранение
Подключение и управление дисками виртуальных машин в рамках OpenShift virtualization выполняется с использованием таких Kubernetes-концепций как StorageClasses, PersistentVolumeClaims (PVC) и PersistentVolume (PV), а также стандартных для среды Kubernetes протоколов хранения. Таким образом, администраторы Kubernetes и отвечающие за приложения команды получают единый и привычный механизм управления как для контейнеров, так и для виртуальных машин. А для многих администраторов сред виртуализации эта концепция может показаться знакомой, поскольку в ней используются тот же принцип разделения файлов конфигурации ВМ и дисков, который применяется в OpenStack и на многих других облачных платформах.
Однако нельзя просто каждый раз создавать новый диск для ВМ, так как при миграции с гипервизора в OpenShift, нам необходимо сохранить данные. Да даже когда мы разворачиваем новую ВМ, это всегда быстрее сделать из шаблона, чем создать с нуля. Таким образом нам необходим функционал импорта имеющихся дисков.
Для упрощения этой задачи OpenShift virtualization разворачивает проект Containerized Data Importer (CDI), который сводит импорт дисковых образов дисков из нескольких источников к созданию записи в PVC.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: "fedora-disk0"
labels:
app: containerized-data-importer
annotations:
cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2"
spec:
storageClassName: ocs-gold
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Именно эта запись и активирует CDI, запуская последовательность действий, показанных на рисунке ниже:
После того, как CDI отработает, PVC будет содержать диск виртуальной машины готовый к использованию и приведённый в стандартный для OpenShift формат…
При работе с OpenShift virtualization также пригодится OpenShift Container Storage (OCS), решение Red Hat на основе файловой системы Ceph, реализующее функционал постоянного хранилища для контейнеров. В дополнение к стандартным PVC-методам доступа – RWO (блочный) и RWX (файловый) – OCS предоставляет RWX для устройств raw block, что очень полезно при организации совместного блочного доступа для приложений с высокими требованиями к производительности. Кроме того, OCS поддерживает новый стандарт запроса группы объектов Object Bucket Claim, позволяющий приложениям напрямую использовать объектное хранилище данных.
Виртуальные машины в контейнерах
Если вам интересно проверить, как это работает, то знайте, что OpenShift virtualization уже доступна в варианте Tech Preview в составе OpenShift 3.11 и выше. Владельцы действующей подписки на OpenShift могут воспользоваться OpenShift virtualization совершенно бесплатно и без каких-либо дополнительных телодвижений. На момент выхода этого поста актуальными являются OpenShift 4.4 и OpenShift virtualization 2.3, если вы используете предыдущие версии, то для получения последних функций стоит обновиться. Полностью поддерживаемая версия OpenShift virtualization должна выйти во второй половине 2020 года.
Для получения дополнительной информации обратитесь к документации по OpenShift за инструкциями по установке, включая раздел по настройке Multus, где приводятся сведения о настройке внешних сетей.
