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

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

Машина как обычная нагрузка

Виртуализацию обеспечивает KubeVirt. Идея у него такая: виртуальная машина — это процесс, который запускается в поде, а управляется как всё остальное в кластере.

Из этого следует то, что для человека из мира vSphere звучит непривычно. Планировщик Kubernetes выбирает узел для машины так же, как для приложения. Ресурсы считаются теми же запросами и пределами. Права выдаются тем же RBAC.

Гипервизор при этом честный — KVM, тот же, что в любом Linux.

Два объекта вместо одного

Здесь главное отличие от привычной модели, и его спрашивают.

Диск создаётся отдельно и живёт своей жизнью. Содержимое он берёт одним из четырёх способов, и их стоит различать: загрузка по ссылке (http), клон подготовленного образа платформы (image), выгрузка файла со своей машины (upload) и пустой источник {} — чистый диск без содержимого, когда нужно просто место под данные.

Третий объект модели — VMImage, подготовленный образ, который платформа хранит у себя. Команда публикует условную Ubuntu один раз, а новые диски клонируют её через source.image.name вместо того, чтобы каждый раз тянуть файл из интернета.

Ниже всё это — обычное хранилище Kubernetes: диск существует как PersistentVolumeClaim, а наливает в него образ компонент CDI (Containerized Data Importer) через объект DataVolume. Руками их здесь не трогают, но на нижних слоях встретите именно их.

Размер машины задаётся не числами, а именованным типом инстанса (instance type) вроде u1.medium — это механизм самого KubeVirt, серии U, O, CX, M и RT. Не путайте его с пресетами тенанта и управляемых приложений: строка u1.medium валидна и там, и там, но системы разные. Смотрите, что размеряет вопрос: тенант и приложение берут пресет, VMInstance — тип инстанса.

Как попасть внутрь

Здесь заканчиваются привычки и начинается специфика.

cloud-init — стандартный механизм облачных образов: при первом запуске система читает описание и настраивает себя. Пароль, ключи, пакеты, команды. Это ближайший аналог Customization Specification, только описанный текстом рядом с самой машиной.

virtctl — отдельная утилита для консоли, экрана и проброса портов. Путей внутрь три, и машину в них называют голым именем:

virtctl console <имя>              # текстовая консоль через последовательный порт
virtctl vnc <имя>                  # графический экран, он же путь к Windows
virtctl ssh <пользователь>@<имя>   # повседневная работа с гостевым Linux

Сценарий из вопросов звучит так: сеть внутри машины сломана, SSH не отвечает — что сработает? virtctl console: последовательная консоль не зависит от гостевой сети, поэтому и остаётся последним средством, в том числе при разборе ранней загрузки.

Отдельная оговорка про ограниченный доступ. Тенанту консоль выдают как подресурс запущенного экземпляра, а не объекта машины целиком, и под такими правами цель называют с префиксом типа: virtctl console --namespace=tenant-acme vmi/vm-instance-app. Голое имя в этом случае попадает не туда и возвращает отказ.

Что умеет и чего не умеет

Экзамен любит вопросы про возможности — и здесь важно не перепутать, чего платформа не делает, с тем, что она делает иначе.

Живая миграция есть. Работающая машина переезжает на другой узел без остановки — этим пользуются, когда узел нужно вывести на обслуживание.

Снимки состояния есть. Их обеспечивает слой хранилища.

Проброс видеокарт есть, причём настраивается автоматически. Список устройств, которые разрешено пробрасывать, задаёт платформа, а не тенант.

Здесь стоит запомнить и то, что именно изменилось в версии 1.5, — на этом строят отдельный вопрос. Сам проброс существовал и раньше, но подготовку узлов приходилось делать руками: размечать узлы с видеокартами и вписывать разрешённые устройства прямо в настройки KubeVirt командой kubectl patch. В 1.5 автоматизировали ровно это. Группа узлов, в которой объявлены видеокарты, теперь сама получает нужную метку, а платформа сама заполняет список разрешённых устройств. Формулировка «проброс появился только в 1.5» неверна — появилась автоматическая подготовка узлов, а не сама возможность.

Чего действительно нет — автоматической балансировки нагрузки между узлами. В vSphere этим занимается DRS: он сам решает, что машину пора перевезти, и везёт. Здесь такого нет. Планирование ёмкости и перевоз машин во время обслуживания делаются осознанно, а не сами собой.

Разница тонкая, но именно на ней строят вопросы: миграция как инструмент есть, миграция как постоянно работающая автоматика — нет.

Если узел умрёт

Вопрос, который задаёт любая команда перед переездом с vSphere: перезапустятся ли машины на другом узле сами. Честный ответ для версии 1.5 — нет, и он же правильный на экзамене.

Причина не в недоделке, а в устройстве. Когда узел перестаёт отвечать, кластер не знает, что с ним: он выключился, или потерял сеть и продолжает работать. Для обычного приложения разницы нет — лишняя копия никому не мешает. Для виртуальной машины с диском разница принципиальная: запустить вторую копию той же машины, пока первая, возможно, ещё пишет на диск, — это порча данных. Поэтому безопасный автоперезапуск требует фенсинга (fencing) — гарантированного отключения подозрительного узла, прежде чем машину поднимут заново. В поставке такого механизма нет, и в восстановлении после отказа узла остаются ручные шаги.

Живая миграция здесь не помогает и помочь не может: она переносит работающую машину с живого узла. Это плановая эвакуация перед обслуживанием, а не реакция на аварию.

Отдельно — чтобы не смешивать две разные вещи. У тенантных кластеров Kubernetes рабочие узлы это тоже виртуальные машины, но там проверка здоровья узлов и замена сломанных работают и включены по умолчанию. Только это не «перезапуск той же машины», а замена: неисправную машину удаляют и создают новую, чистую, взамен. Для узла тенантного кластера это нормально — его состояние в кластере не хранится. Для вашей собственной виртуалки с данными на диске — неприемлемо, и именно поэтому к ней тот же механизм не применяют.

Машина работает. Пакеты до неё довозит сеть — а там четыре компонента, которые легко перепутать между собой.

Подробнее: виртуализация · хранилище