Приложения, созданные с учетом облачных технологий, или контейнеризированные приложения, стали мейнстримом. По данным Форума по облачным нативным вычислениям (CNCF), до 82% предприятий уже используют Kubernetes в производственной среде. В 2023 году этот показатель составлял 66%. А целых 98% организаций имеют как минимум некоторые облачные нативные приложения, заявляет отраслевая организация. Однако переход приложений в облачные нативные среды означает не только создание нового кода. Это также требует адаптации инфраструктуры. Вычислительные мощности, сетевое оборудование и хранилища данных должны работать с контейнерными средами. Далеко не все системы могут делать это «из коробки», особенно когда речь идет об оборудовании, установленном на территории предприятия (on-premise). В то же время ИТ-архитекторам предприятий необходимо учитывать требования устаревших приложений и виртуальных машин (ВМ), которые не обновляются. Кроме того, предприятия захотят максимально эффективно использовать свое оборудование для хранения данных, независимо от сред их приложений. Переход на контейнеры означает адаптацию технологии, которая не предназначалась для постоянного хранения данных, для работы с критически важными для бизнеса данными.
Состояния без сохранения состояния
Контейнеризированные приложения изначально были без сохранения состояния (stateless) или эфемерными. Разработчики никогда не предполагали, что контейнеры будут хранить постоянные данные. Они ожидали, что микросервисы или контейнеризированные приложения не будут использовать энергонезависимое хранилище и будут отбрасывать содержимое памяти, и даже свои настройки, после завершения задач. Вместо этого контейнеризированные приложения полагаются на внешнее хранилище данных, как правило, базу данных или кэш. У такого подхода есть свои преимущества. К ним относятся более простое развертывание, легкое масштабирование, отказоустойчивость и восстановление, а также переносимость приложений. Но большинству бизнес-приложений, если не всем, требуются постоянные данные. «Большинству бизнес-приложений требуется хранилище. В реальности, если вы не переводите Фаренгейты в Цельсии и обратно, вы что-то где-то храните», — говорит Дэн Чирули, вице-президент и генеральный менеджер по облачным нативным технологиям в Nutanix. И необходимость работы с постоянными данными становится еще более важной, поскольку предприятия рассматривают контейнеры как альтернативу традиционным виртуальным машинам. Но это означает переосмысление того, как работают приложения. И это требует от ИТ-архитекторов обновления их систем хранения данных для поддержки модернизированных, облачных нативных приложений. Это может быть сделано напрямую, когда производители массивов поддерживают контейнеры, или через плоскость управления (control plane), такую как Portworx от Nutanix или Everpure. Почти неизбежно изменения обусловлены искусственным интеллектом (ИИ), поскольку предприятия стремятся поддерживать свои ресурсоемкие рабочие нагрузки ИИ в современных облачных нативных средах. Но есть и другие факторы, включая тенденцию к переносу виртуализированных приложений в контейнеры и необходимость контроля затрат. «Kubernetes может быть старше десяти лет, но он продолжает развиваться по мере того, как ИИ трансформирует способы обработки данных. Уже сейчас Kubernetes вышел за рамки времен, когда он создавался только для эфемерных, без сохранения состояния приложений», — говорит Майкл Кейд, глобальный технический директор по полевым операциям в Veeam Software. «Сегодня приложения с сохранением состояния (stateful), такие как базы данных, конвейеры машинного обучения и потоковые системы, теперь рассматриваются как первоклассные объекты [в контейнеризированных средах] и получили специализированные инструменты, необходимые им для процветания».
Подключения к хранилищу
Однако подключение хранилища к Kubernetes зависит от поддержки как разработчиков приложений, так и поставщиков оборудования. Основным способом подключения хранилища к контейнерным средам является интерфейс хранения контейнеров (CSI). CSI должна поддерживаться непосредственно поставщиком хранилища, будь то производитель оборудования, облачный сервис или поставщик программно-определяемого хранилища (SDS). Как отмечается на странице Kubernetes CNCF: «CSI был разработан как стандарт для предоставления произвольных блочных и файловых систем хранения контейнеризированным рабочим нагрузкам в системах оркестрации контейнеров, таких как Kubernetes». CSI позволяет сторонним поставщикам хранилищ писать и развертывать подключаемые модули (plug-ins) для хранения данных без изменения основного кода Kubernetes. Технологии SDS, в свою очередь, также используют драйверы CSI, но работают на стандартном оборудовании, а не на выделенных массивах хранения, а также на гиперконвергентной инфраструктуре. Сюда входят и варианты с открытым исходным кодом, такие как OpenEBS, Longhorn и Ceph. «Каждой среде нужен бэкенд хранения с драйвером CSI, который подключает его к Kubernetes. Предоставление драйвера CSI — задача поставщика хранилища», — говорит Найджел Пултон, автор и независимый эксперт по Kubernetes и контейнерам. «Большинство драйверов CSI создают как минимум один StorageClass, который сопоставляется с уровнем хранения и его возможностями. Например, драйвер CSI может создать StorageClass с именем ‘fast-replicated’ (быстрое реплицирование), который сопоставляется с высокоскоростным флэш-хранилищем с автоматической репликацией в удаленное местоположение. Любое приложение, использующее этот класс, автоматически получает этот уровень и набор возможностей», — добавляет он. Такой уровень абстракции очень полезен для разработчиков приложений, поскольку им больше не нужно беспокоиться о физических возможностях системы хранения данных. Этим занимаются драйверы CSI. «Драйверы CSI позволяют нам предоставлять доступ к хранилищу из контейнеризированного приложения, но [позволяют фирмам] по-прежнему администрировать хранилище так же, как они администрируют хранилище, работающее под их ВМ», — говорит Чирули из Nutanix. «И это большое преимущество». Он также видит, что клиенты устанавливают Kubernetes на кластеры на «голом железе» (bare metal). Это также сохраняет разделение между рабочими нагрузками Kubernetes и базовым оборудованием хранения данных. На бумаге, по крайней мере, предприятия могут перемещать свои контейнеризированные приложения на другую платформу или к другому поставщику, или на новое оборудование для хранения данных, без переписывания кода и с минимальными перебоями. На практике крупномасштабные миграции приложений Kubernetes между платформами все еще относительно редки. Предприятия склонны разрабатывать приложения для работы на Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure или локальном оборудовании, в зависимости от их бизнес-потребностей. Переносимость приложений, поддерживаемая CSI, является полезной страховкой, даже если между платформами существует достаточно различий, чтобы проявлять осторожность. «Нам действительно не нужно становиться экспертами в том, как работает EBS [Elastic Block Store] по сравнению с Azure Disk, или локальный SSD [твердотельные накопители] и как это работает», — говорит Грег Мускарелла, генеральный менеджер Portworx в Everpure. «Если вам приходится управлять этими вещами, это становится несколько сложным. Компании склонны концентрироваться на одной облачной среде». Он предполагает, что немногие организации имеют код, который они могли бы «нажать кнопку и перенести в другое облако», не в последнюю очередь из-за различий в архитектурах хранения данных как у поставщиков оборудования, так и у облачных провайдеров. Однако предприятия переносят все больше приложений в облачные нативные среды. И это все чаще включает базы данных и приложения, которые ранее работали в традиционных виртуальных машинах.
Новые платформы
Одной из наиболее значимых тенденций в модернизации приложений является перенос как виртуальных машин, так и приложений, управляемых базами данных, в контейнеры. Стоимость, избежание привязки к поставщику и необходимость консолидации на меньшем количестве платформ — все это является движущими силами. «Граница между „контейнеризированным“ и „виртуализированным“ размывается», — предполагает Кейд из Veeam. «Долгое время контейнеры и ВМ рассматривались как два отдельных силоса. Но по мере развития приложений с сохранением состояния, а поскольку ВМ по сути являются типичной рабочей нагрузкой с сохранением состояния, мы наблюдаем значительный рост числа предприятий, запускающих их непосредственно в Kubernetes с использованием таких платформ, как Red Hat OpenShift Virtualization». Пултон согласен. Он видит, как все больше организаций переносят виртуализированные рабочие нагрузки в контейнеры с помощью таких инструментов, как KubeVirt. Но, хотя организации и портируют виртуализированные приложения и базы данных, ИТ-архитекторы должны быть уверены, что все требования приложения удовлетворяются уровнем хранения данных. «Базы данных имеют гораздо более высокие требования, включая упорядоченный запуск, репликацию, автоматическое переключение при сбое и резервное копирование», — предупреждает он. «Два самых больших изменения — это обеспечение наличия драйвера CSI для системы хранения данных и, возможно, развертывание оператора». Оператор Kubernetes предоставляет детали о специфических требованиях базы данных, а иногда и хранилища. Поддержка операторов необходима для того, чтобы базы данных могли обеспечивать корпоративные рабочие нагрузки через Kubernetes. Опять же, оператор поддерживает современную цель приложений — отделение кода от массива хранения данных или облачного сервиса хранения. Например, Percona предоставляет операторы для MySQL, PostgreSQL и MongoDB, а также Everest. «Операторы — это, по сути, меняющие правила игры факторы», — говорит Кейт Обидиххата, генеральный менеджер компании по облачным нативным технологиям. «Они кодируют знания человека-администратора баз данных (DBA) в программном обеспечении, и у вас автоматизированы все эти важнейшие компоненты устойчивости: резервное копирование, переключение при сбое, репликация и обновления». Операторы, добавляет она, помогают предприятиям принимать гибридные архитектуры или стратегии мультиоблачности, обеспечивая переносимость данных без необходимости переписывать приложения. Но рабочие нагрузки, работающие на ВМ, не будут автоматически работать в контейнерах, говорит она. Фирмам потребуется тщательно планировать и тестировать свои развертывания. «Существуют специальные сценарии (playbooks), которые следует применять, и методологии, которые явно отличаются от классической настройки базы данных на ВМ», — говорит Обидиххата. «Но все это выполнимо, и многие компании сейчас запускают эти базы данных на Kubernetes. У них просто другой сценарий для смягчения этих проблем». Фирмам также необходимо учитывать, как они будут запускать портированные приложения в производстве. Разработка, что понятно, привлекает много внимания. Но то, как системы работают с «Дня второго» и далее, имеет решающее значение. Это включает в себя выделение и тирирование хранилища, а также резервное копирование, восстановление и безопасность. Драйверы CSI берут на себя большую часть сложной работы, но предприятия, вероятно, будут стремиться инвестировать в новое оборудование или даже в хранилища от поставщиков, ориентированных на облачные нативные среды, чтобы облегчить миграцию на контейнеры. «Обычно это достигается путем развертывания новых архитектур хранения данных, либо через новые продукты хранения от существующих поставщиков, но все чаще путем взаимодействия с новыми поставщиками», — говорит Пултон. Он добавляет, что предприятия могут по-прежнему использовать старые аппаратные системы, но вряд ли будут использовать их для Kubernetes.
Facebook*, Instagram* и WhatsApp* принадлежат компании Meta* Platforms Inc., деятельность которой признана экстремистской и запрещена на территории Российской Федерации.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Stephen Pritchard
