Казалось бы, после перехода к контейнерам от виртуальных машин и виртуализации эта технология должна быть отправлена на свалку. Но, как и в большинстве случаев в корпоративных вычислениях, старые технологии просто так не уходят. Фабиан Дойч, старший менеджер команды инженеров Red Hat, рассказал порталу The New Stack о возможной синергии контейнеров и виртуальных машин на примере проекта KubeVirt.
Перемены всегда пугают. Когда в начале
Когда тем же администраторам и архитекторам пришло время понять и принять контейнеры Linux, эта тенденция консолидации ресурсов продолжилась. Вместе с этим произошло значительное упрощение развертываемых активов, уменьшение их размера и устранение огромного количества зависимостей и избыточности операционных систем.
Казалось бы, после перехода к контейнерам от виртуальных машин и виртуализации эта технология должна быть отправлена на свалку так же, как в свое время односерверное приложение (single-server application). Но, как и в большинстве случаев в корпоративных вычислениях, старые технологии не просто уходят, они остаются и часто «продолжают делать свое дело».
Совместная работа
Фабиан Дойч — мейнтейнер проекта KubeVirt (о том, насколько он важен для Red Hat, говорит хотя бы то, что OpenShift 4.15 включает KubeVirt в качестве основы виртуализации), который начинался как попытка внедрить виртуальные машины в Kubernetes. С момента старта проекта в 2016 г. он уделял этому основное внимание и сегодня гордится прогрессом, которого добился этот подпроект Kubernetes. Теперь Дойч полностью сосредоточен на подготовке проекта к выпуску в рамках Cloud Native Computing Foundation (CNCF).
Основной целью проекта было обеспечить первоклассную поддержку виртуальных машин в облаке. «Мы переняли менталитет и API Kubernetes, чтобы связать его с богатой экосистемой CNCF и позволить виртуальным машинам пользоваться ее преимуществами, — говорит Дойч. — Мы усилили эту экосистему и привнесли облачные API, которые были приняты многими другими проектами. Самым сильным преимуществом KubeVirt является то, что он почти нативно связан с платформой Kubernetes и поэтому может использоваться со многими проектами на базе Kubernetes, такими как Prometheus, Tekton, CRIO или Argo CD. В случае с Argo CD мы добавили немного клея, чтобы Argo CD работал с виртуальными машинами так же, как с контейнерами».
После трех лет работы в «песочнице» CNCF и почти полного пребывания в инкубаторе CNCF, KubeVirt близок к выпуску. Хотя для достижения этой цели еще предстоит поработать, конечные пользователи уже должны знать, что KubeVirt является зрелой и многофункциональной системой, говорит Дойч.
Все знакомо
KubeVirt основан на KVM, так что это все те же знакомые инструменты и виртуализация, которые широко использовались в Open Source-виртуализации на протяжении последних двух десятилетий. Основные концепции, производительность и совместимость с гостевой ОС, с которыми знакомы пользователи KVM, сохранились и в KubeVirt. Основное отличие заключается в том, что пользователи могут настраивать его через выбранную ими платформу Kubernetes, например OpenShift Virtualization, наследуя такие функции, как RBAC, управляемое идентификацией хранилище и сетевые абстракции, предоставляемые самой платформой.
Это имеет два последствия для KubeVirt. Во-первых, существующие пользователи виртуализации, знакомые с KVM, могут ожидать, что KubeVirt будет запускать их существующие виртуальные машины так же, как и в случае обычной автономной виртуализации. Во-вторых, благодаря его интеграции с Kubernetes такие проекты CNCF, как Tekton для конвейеров, Argo CD для непрерывного развертывания и Istio для работы с сетями, часто почти естественным образом работают и с виртуальными машинами.
По словам Дойча, это дает пользователям множество преимуществ.
«Перемены — это тяжело. И если оператор решает перейти на новую платформу, нужно подумать о следующем: когда я делаю серьезные инвестиции в переход на новую платформу, хочу ли я сохранить статус-кво или хочу занять позицию, в которой я смогу воспользоваться преимуществами большой экосистемы и иметь платформу, которая позволит мне и моим конечным пользователям развиваться? Это означает изменение методов работы операторов или развертывания конечными пользователями приложений на платформе. Для операторов контейнеры — это возможность автоматизировать свою работу, а для конечных пользователей — средство доставки приложений различными и более эффективными способами», — говорит он.
По словам Дойча, есть и другие преимущества, «потому что это эффективнее или быстрее, или новые сотрудники хотят поставлять приложения в виде контейнеров, а не виртуальных машин, потому что это проще. У них есть новые инструменты, новые IDE, новое ПО, а владельцы платформы, предоставляющей эти вычислительные возможности конечным пользователям, теперь могут делать это с помощью самообслуживания, на основе которого была создана Kubernetes. Наличие современной гибкой платформы самообслуживания также помогает нанимать и удерживать талантливых специалистов».
Хотя сегодня в KubeVirt доступны многие традиционные функции виртуализации, в ней появляются новые возможности, а поскольку база пользователей расширяется практически ежедневно, возникают и новые требования к платформе. «С BootC у нас появились загружаемые контейнеры. Мы унифицировали пути доставки контейнеров и виртуальных машин. И хотя уже сегодня наблюдается синергия, это еще не конец», — говорит Дойч.
В планах на будущее — улучшение документации. По словам Дойча, с увеличением количества рабочих нагрузок, переходящих на KubeVirt, возрастает потребность в разнообразной поддержке, и именно на этом сейчас сосредоточена работа команды.
«Одна большая вещь, которую мы хотим сделать, — это выпуск проекта. Нам нужно решить некоторые вопросы, связанные с процессом и управлением в KubeVirt. Нам нужно уделить больше внимания другим сторонам KubeVirt после того, как мы добавили так много функций за последние несколько лет», — говорит Дойч. По его словам, цель состоит в том, чтобы настроить проект на успешное развитие в течение следующих пяти лет. «Мы уделили много внимания „трудным моментам“ — более традиционным функциям, которые противоречили Kubernetes, например, горячему подключению. Мы завершили работу над горячим подключением процессора и памяти, а также расширяем сотрудничество с OVN-Kubernetes для улучшения сетевых решений», — рассказывает он.
«Мы не спешили с KubeVirt, — признается Дойч. — Мы не хотели торопиться. Мы старались создать лучшее решение на базе Kubernetes и интегрировать его с Kubernetes правильным образом. KubeVirt — уже не молодой проект, но сейчас самое время попробовать его. Мы достигли зрелости».
