В течение большей части последнего десятилетия «облачный родной» был синонимом роста контейнеров и, соответственно, медленной эрозии виртуальных машин в качестве доминирующей абстракции для рабочих нагрузок. Но в этом году Kubecon EU в Лондоне повествование начало меняться. В коридовых треках, проектных павильонах и выступлениях на основе неотъемлемых переговоров всплыла повторяющаяся тема: виртуальные машины не уходят; Они сходится с (или, по крайней мере, становятся прилегающими к) контейнерами, а Kubernetes становится универсальной плоскостью управления для обоих.
Это растущее перекрытие сигнализирует больше, чем просто сосуществование рабочей нагрузки. Это отмечает начало основной волны для реплики, где Kubernetes не просто организует стручки, но и становятся операционной моделью для запуска виртуальных машин, устаревших приложений и будущих рабочих нагрузок. То, что формируется, — это не просто техническая миграция, но и перепроектирование того, как инфраструктурные группы думают о границах системы, оперативной ответственности и абстракциях, которые они используют для развертывания и безопасных приложений.
Некоторые из наиболее показательных подсказок были выставлены в Kubecon, где импульс с открытым исходным кодом, рыночное давление и новый инструмент начали укрепить идею «Однажды»: Kubernetes в качестве субстрата для всех рабочих нагрузок. И с этим приходят некоторые увлекательные последствия.
Срочное требование куда -нибудь двигаться
Предполагается, что длительный период «стабильности» подходит к концу, особенно когда мы говорим о виртуализированных рабочих нагрузках. Действующая платформа для виртуальных рабочих нагрузок в настоящее время вызывает различные типы суматохи для своих клиентов и конечных пользователей. Ожидается, что изменения в лицензировании значительно увеличат эксплуатационные расходы, заставляя мелких и средних клиентов быстро найти альтернативы. Кроме того, удаление гибкости при выборе того, какие продукты фактически требуются, и требование клиентов приобретает весь портфель, снова увеличивает затраты, заставляет сложную платформу и использование более ненужных ресурсов.
К сожалению, на данный момент будущее не является уверенным, поскольку люди пытаются определить, где это «где-то» будет там, где они переплатформируют свои виртуальные рабочие нагрузки. При этом, это был Кубекон. Это безопасное предположение, что Kubernetes (если не еще не) функционировать в качестве платформы для рабочих нагрузок в их инфраструктуре в ближайшее время. Это неизбежно приводит к разговору о том, что требуется для создания потенциальной беседы «одна платформа для всех рабочих нагрузок»!
Какие компоненты необходимы для создания облачной нативной виртуальной машины
Основой для платформы VM следующего поколения неизбежно станет Kubernetes, которая, к сожалению, имеет немного (лично) плохую репутацию за то, что его трудно на самом деле встать. Возможно, это было более верно в первые дни Kubernetes, где различные сертификаты OpenSSL и копирование обратно и обратно требовались вместе с различными повреждениями.
Хорошие новости, однако, эти дни очень позади нас, в проекте Kubernetes есть такие инструменты, как Kubeadm или Cluster-API, который автоматизирует стояние узлов Kubernetes или даже весь кластер. Кроме того, если вам нужен полный опыт работы с ящиком, то существует ряд сертифицированных, поддерживаемых поставщиками Kubernetes Distributions, которые обеспечат установку и поддержку корпоративного уровня.
Экосистема вокруг Kubernetes и Cloud Native, возможно, является одной из самых процветающих, поэтому неудивительно, что было создано несколько проектов, чтобы обеспечить использование виртуальных машин наряду с вашими рабочими нагрузками. Быстрый поиск вокруг GitHub имеет несколько проектов, которым старше 9 лет! Тем не менее, стало ясно, что один проект стал де -факто стандартом для включения виртуальных рабочих нагрузок на Kubernetes, и это проект Kubevirt, который также является тем же проектом, на котором основаны большинство предложений Enterprise Kubernetes!
Этот проект упаковывает все компоненты, необходимые для запуска виртуальной машины на хосте Linux (а именно QEMU, Libvirt и других вспомогательных инструментов), и еще больше улучшает Kubernetes с дополнительными объектами, такими как виртуальная машина. Теперь одна плоскость управления может извлечь бегущие стручки с kubectl Get Pods или виртуальными машинами с kubectl, чтобы получить виртуальные машины одинаково.
Мигрирующие рабочие нагрузки
За эти годы было несколько типов миграции рабочей нагрузки, и в настоящее время мы находимся в эпохе «Модернизируя в облачный родной». Однако до того, как все эти рабочие нагрузки должны были быть перенесены на виртуальную платформу, и это было в значительной степени сделано через программное обеспечение P2V, которое является физическим в виртуальное преобразование. Процесс для этого часто заключался в установке агента в физическом компьютере, который мог бы прочитать содержимое диска (ах), этот агент затем подключится к виртуальной платформе, где будет создана целевая виртуальная машина с копированием диска. Однако простой процесс звучания, физические машины имеют огромное разнообразие физических устройств, каждая из которых потребует различных драйверов устройств. Часто, после P2V, вы обнаружите, что ваша виртуальная машина больше не будет загружаться правильно, так как эти драйверы устройств не найдут аппаратное обеспечение, или устройства теперь будут выглядеть по -другому.
Эти проблемы существуют сегодня, переход от одного гипервизора к другому называется V2V и до сих пор поставляется с теми же предостережениями, что и разные гипервизоры, подражающие различным устройствам. Переезд в Кубевирт обычно означает перемещение к устройству Virtio, что снова может означать систему, которая запутана/сломана, когда оно загружается после перемещения.
Silo’d Experize
Большая часть разговора привлекла в фокус большого количества времени и инвестиций, которые многие компании уже вложили в наем и обучение команды для управления своей текущей платформой виртуализации. Это поднимает большие вопросы о том, кто (какая команда) собирается создать платформу, как рабочие нагрузки делятся платформой, должен быть кластер на рабочую нагрузку (виртуальные машины и контейнеры) и, в конечном счете, будет работать и владеть кластером с повседневной точки зрения.
Создание совершенно новой платформы из необходимых компонентов с открытым исходным кодом потребует значительного опыта работы с Kubernetes и может предоставить возможности для запуска виртуальных рабочих нагрузок. Тем не менее, не секрет, что этот опыт использования этой платформы будет миром вдали от того, к чему люди будут привыкли раньше. Чистый пользовательский интерфейс для создания виртуальных машин или перемещения виртуальной машины в другую сеть просто не существует. Как и во всех вещах Kubernetes, это будет Yaml, и много Yaml.
Как потенциально выглядит будущее?
К счастью, это не все гибель и мрак! Большая работа выполняется для улучшения опыта. Ряд проектов изначально, по -видимому, обрабатывал работу виртуальных машин; Тем не менее, экосистема, по -видимому, обосновалась, что Кубевирт стал очевидным выбором. Это привело к притоку комитетов к проекту Kubevirt, добавив несколько новых функций и улучшения стабильности. Кроме того, разработаны сквозные решения для снижения операционной сложности, таких как проект Harvester от виртуализации SUSE или OpenShift из Red Hat.
Для того чтобы любая новая платформа виртуализации была успешной, безусловно, будет несколько ключевых вещей, которые потребуют решения:
- Ожидается, что подобные функции, которые приведены в их текущей действующей платформе, необходимо будет реализовано, подумайте о динамическом управлении ресурсами в сочетании с возможностями миграции рабочей нагрузки
- Чистый и эффективный метод перемещения виртуальных машин с одной платформы на другую
- Снижение эксплуатационных накладных расходов, позволяя легко управлять новой платформой виртуализации
В текущем состоянии альтернативных платформ виртуализации все еще есть пробелы (построенные на Kubernetes), однако, потому что все это открытый исходный код, никто не мешает никому предотвратить и помогать двигать!
Мы видим первую волну этого с виртуальными машинами, которые доставляются под зонтиком Kubernetes. Но посмотрите ближе, и вы найдете аналогичные столкновения по всему стеку: балансировщики нагрузки, становящиеся сетками обслуживания, брандмауэры, работающие внутри переключателей с поддержкой DPU, и трубопроводы наблюдения, питающиеся непосредственно в двигатели безопасности. То, что раньше было жесткими границами, становится размытыми зонами сходимости.
Если виртуальные машины и контейнеры больше не являются противоположностями, а сверстниками на одной и той же платформе, какие еще дихотомии находятся рядом с падением?
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом.
