© 1995-2022 Компания «Инфосистемы Джет»
Использование контейнеризации в enterprise: взгляд практика и кейсы
Вычислительные комплексы Вычислительные комплексы

Почему Kubernetes — это уже не хайп, а неизбежная реальность? Какие стадии зрелости проходят компании, использующие контейнеры? С какими вопросами чаще всего сталкиваются заказчики?

Главная>Вычислительные комплексы>Контейнеризация в enterprise: взгляд практика
Вычислительные комплексы Тема номера

Контейнеризация в enterprise: взгляд практика

25.10.2021

Посетителей: 424

Просмотров: 600

Время просмотра: 2.6 мин.

Авторы

Автор
Юрий Семенюков Руководитель департамента инфраструктурных решений компании «Инфосистемы Джет»

 

Почему Kubernetes — это уже не хайп, а неизбежная реальность?

 

Какие стадии зрелости проходят компании, использующие контейнеры?

 

С какими вопросами чаще всего сталкиваются заказчики?

 

В 2019 г. эксперты Gartner говорили, что 30% организаций по всему миру используют контейнерные приложения, а к 2022 г. эта цифра вырастет до 75%.

Спустя 2 года их прогноз кажется точным. Компании все чаще используют технологии контейнеризации для запуска приложений микросервисной архитектуры. Платформа контейнерной оркестрации на базе Kubernetes — уже не хайповая технология, а полноценная часть стратегии развития ИТ. На российском рынке этому способствуют три тренда.

 

Первый — широкое применение Kubernetes во время пандемии COVID-19. В 2020 г. изменился ландшафт использования ИТ-услуг: массовый переход на удаленку, активность онлайн-магазинов, сервисы доставок. Бизнесу нужно было быстрее выводить продукты на рынок. Микросервисные технологии играли здесь ключевую роль, потому что давали гибкость и скорость. Поскольку Kubernetes фактически считается стандартом при запуске таких приложений, его позиции значительно укрепились.

 

Второй тренд: новые типы нагрузок — Data Science, Machine Learning, AI или Edge Computing — все чаще запускают в среде Kubernetes. 

 

Третий тренд касается применения Kubernetes в production-средах. Системы, которые разрабатывали и тестировали в среде контейнеризации (в тестовых и препродуктивных контурах), выходят в промышленную эксплуатацию. Соответственно, все больше продуктивных нагрузок запускается в среде Kubernetes.

 

Все это привело к тому, что за последний год количество проектов, обращений и консультаций с заказчиками по этой теме заметно выросло. Контейнерные приложения легче в обслуживании, их проще переносить, они запускаются в любой среде, где есть соответствующий движок. 

 

В то же время инфраструктура под Kubernetes еще не стала таким же хорошо отлаженным и понятным механизмом, как, например, классические среды виртуализации. ИТ-службы ищут правильные подходы и методы ее реализации. Именно на этом основана наша шкала зрелости российских компаний, использующих контейнеры.

На заметку

 

Дисклеймер: наша шкала зрелости компаний — анализ происходящего на российском рынке, основанный на нашей практике и обширном опыте. Впервые мы начали применять ее в 2019 г., с тех пор регулярно дорабатывали и актуализировали детали.

 

 

 

Контейнерные приложения легче в обслуживании, их проще переносить, они запускаются в любой среде, где есть соответствующий движок. 

 

Шкала зрелости использования контейнеров

 

Стадия 1: зарождение интереса

 

Контейнеры только появляются в компании. С ними имеют дело разработчики, а ИТ-эксплуатация понимает, что нужно развивать новые компетенции, поскольку уже скоро потребуется принимать системы и отвечать за SLA. При этом у эксплуатации отсутствует нужная экспертиза и нет понимания того, с какой стороны подступиться к проблеме. То есть появилась потребность, но что и как делать — не ясно.

 

Пример: телеком-оператор

 

Служба эксплуатации жила в парадигме традиционной ИТ-инфраструктуры, пока внутренние команды разработки и вендоры — поставщики ПО — не начали приносить код в контейнерах. У специалистов эксплуатации при этом еще появилась соответствующая экспертиза. Похожие случаи мы наблюдаем довольно часто.

 

Решение

 

На данном этапе важно показать заказчику общую картину мира: какую инфраструктуру ждут от эксплуатации команды разработки, какие задачи будут стоять перед администраторами, какие компетенции потребуются. Чаще всего мы проводим серию вебинаров, встреч и обсуждений со специалистами эксплуатации, на которых рассказываем, как правильно выстраивать контейнерную платформу. Показываем лучшие мировые практики и подходы, современные технологии и инструменты, объясняем технические нюансы, помогаем формировать команду. Наша задача — помочь заказчику определить итоговую цель и наметить понятный roadmap.

 

Стадия 2: осознанная потребность

 

ИТ-эксплуатация принимает системы у разработчиков. Либо последние не в состоянии обеспечить нужный SLA, либо служба эксплуатации сама хочет изучить технологию, чтобы накопить важные в будущем компетенции. В большинстве случаев разработанные решения основаны на продуктах Open Source. То есть это сложный конструктор, правила работы которого знают буквально несколько человек в компании. При этом многие нефункциональные требования к ПО, такие как HA/DR (высокая доступность/катастрофоустойчивость), не проанализированы и не выполняются, а для ИБ вся эта конструкция существует в слепой зоне.

 

Пример: розничный банк

 

У нашего клиента работала контейнерная платформа на Open Source, в которой были развернуты тестовые системы. Решили передать ее на поддержку в эксплуатацию, а приложения начать выводить в продуктив. И тут выяснилось, что заказчик не знает, как обеспечить правильный SLA, защищать свое приложение, какое хранилище использовать и как делать бэкап. Служба ИБ, в свою очередь, не понимала, как встроиться в процесс DevOps.

 

Решение 

 

Заказчику необходимо наметить конкретные шаги по переводу контейнерной платформы в продуктив. Поскольку риски на данном этапе высоки, стратегия должна быть максимально продуманной. Мы разработали для банка техническую политику, в которой детально расписали целевую архитектуру решения. Определили технологический ландшафт решения вплоть до конкретных компонентов, а также спланировали процессы его построения и миграции сервисов. Причем прорабатывать нужно в том числе и вопросы ИБ. В итоге банк получил согласованный roadmap и подготовился к переходу к production-внедрению, согласовав новые решения со службой ИБ.

Вероятно, в среднесрочной перспективе продукты на базе Kubernetes начнут замещать решения для классической серверной виртуализации

 

Стадия 3: продуктивная эксплуатация

 

Чаще всего компании начинают с Open Source и могут успешно пройти с этими решениями первые стадии нашей шкалы. Но при широком использовании контейнеров начинаются проблемы: происходят аварии, причины которых не удается установить, SLA не выполняется, а на апгрейды, настройку и отладку уходит много времени. Появляется потребность в большом количестве сотрудников с глубокой экспертизой, поэтому поддержка становится очень дорогой. К тому же у продуктов с открытым кодом нестабильный жизненный цикл и регулярно возникают проблемы на стыках. Компании начинают думать о переходе на коммерческие решения.

 

Оговорюсь: этот этап проходят не все. Некоторые компании могут нормально жить на Open Source, но, как правило, в этом случае систему обслуживают несколько десятков человек, которые в совокупности могут стоить значительных денег (сотни тысяч долларов и больше). 

 

Пример: телеком-оператор

 

Оператор из большой тройки достаточно активно использовал контейнерные технологии и строил их на основе решений с открытым кодом. Однако в обширной ИТ-инфраструктуре с жесткими SLA их поддержка обходилась довольно дорого.

 

Решение 

 

Мы предлагаем варианты коммерческих решений — enterprise-продукты с фиксированной вендорской поддержкой. Заказчик получает стабильную систему, протестированную с точки зрения интеграции отдельных компонентов, и гарантированный сервис. В ее составе может быть несколько вендорских продуктов (например, платформа контейнеризации, программное хранилище данных и СРК). В этом случае вопросы интеграции компонентов и их поддержку берем на себя мы — в рамках аутсорсинга. Миграцию сервисов на новый технологический стек тоже выполняем своими силами.



Стадия 4: развиваем платформу

 

Как правило, на этом этапе система отстроена и работает, но при этом либо остаются небольшие блоки, которые нужно закрыть, либо появляются новые потребности. Это могут быть задачи по оптимизации, масштабированию, повышению уровня ИБ. Либо нужно расширить функционал платформы (например, появились новые типы нагрузок или задачи по хранению данных), который нужно доработать и прикрутить, ничего принципиально не меняя. То есть идет эволюционное развитие нормально выстроенной инфраструктуры.

 

Пример: розничный банк

 

В банке уже был внедрен Red Hat OpenShift и выстроена разработка кода в контейнерах, но не были реализованы меры по обеспечению ИБ в контейнерном окружении. 

 

Решение

 

Мы помогли заказчику решить задачу точечной модернизации платформы. Благодаря тому, что мы обладаем экспертизой по всем ведущим продуктам для защиты контейнерных сред и проверяем решения на демостендах, мы провели proof-of-concept и подобрали для заказчика оптимальный функционал. В данном случае важно иметь опыт работы с разными решениями, не быть замкнутым на одном вендоре. 

 

Гайд «5 вопросов к контейнерам»

 

Если вы читаете эту статью, то наверняка находитесь на одной из описанных выше стадий и тоже сталкиваетесь с вопросами, касающимися контейнеров, «в полях», а не на бумаге. Ниже я подробно рассмотрю самые актуальные из них. 

 

Open Source vs Enterprise

 

Один из самых распространенных вопросов, которые встают на пути внедрения контейнерных сред в компании: стоит ли обращаться к чистым Open Source или взять вендорский продукт? 

 

Ответ на него определяется огромным количеством факторов и зависит от конкретной ситуации. Решения Open Source позволяют сэкономить на лицензионных отчислениях и затратах на поддержку, но только если у вас уже есть сильная внутренняя экспертиза. По мере выхода все большего количества систем в продуктив, особенно у компаний с высокими требованиями к критичности сервисов (банков, ритейлеров, промышленных предприятий), надежность и стабильность становятся ключевыми факторами. Экономия на стоимости внедрения может быть быстро перечеркнута потерями от простоев. 

 

У вендорских решений есть три основных преимущества. Первое: они предоставляют уже скомпонованную, интегрированную и отлаженную экосистему для работы контейнерной платформы из коробки. Этот конструктор уже собрали за вас. Второе: вендор обеспечивает поддержку с понятными SLA, в случае каких-либо проблем вы не окажетесь один на один с community. Третье: вендор предоставляет понятный roadmap развития и жизни платформы, что позволяет заниматься долгосрочным планированием и исключает ситуацию, когда тот или иной компонент Open Source перестает поддерживаться сообществом (в данной среде это не редкость). 

 

Количество вендоров, предлагающих решения на базе Kubernetes, растет. Практически все крупные производители серверных платформ и систем виртуализации уже имеют такие продукты в своем портфеле. 

 

Инфраструктура

 

Вероятно, в среднесрочной перспективе продукты на базе Kubernetes начнут замещать решения для классической серверной виртуализации. Пока большая часть инсталляций Kubernetes реализована поверх слоя гипервизора, в виде виртуальных машин. Но уже сейчас распространение получают решения класса Kubernetes over bare metal, в рамках которых Kubernetes не только играет роль среды для запуска приложений поверх «виртуалок», но и полностью закрывает слой между железом и прикладным софтом. 

 

Пример такого решения — платформа Red Hat OpenShift Container Platform. Она существует и в более привычном варианте (поверх виртуальных машин), и как bare metal. Такой подход, с одной стороны, позволяет сократить количество технологических слоев решения и совокупную стоимость владения системой. С другой стороны, его определенные аспекты все еще требуют проработки (например, тот же слой подключения внешнего хранилища к кластеру с использованием гипервизора реализовать проще, чем без него). 

На заметку

 

Red Hat OpenShift Container Platform — это Kubernetes-платформа для компаний Enterprise-сегмента. Решение обеспечивает разработку, развертывание и эксплуатацию классических и контейнерных приложений. 

 

Преимущества для разработчиков приложений

 

OpenShift Container Platform предоставляет оптимальную платформу для подготовки, сборки и развертывания приложений и их компонентов в режиме самообслуживания. Средства автоматизации, наподобие встроенной конвертации S2I (source-to-image), упрощают сборку контейнерных образов в формате docker на основе кода, извлеченного из системы контроля версий.


Преимущества для специалистов по эксплуатации ИТ-систем

 

Встроенные средства кластеризации, планирования и оркестрации обеспечивают балансировку нагрузки и автомасштабирование. Функции безопасности полностью устраняют риски вмешательства tenant-клиентов в работу других приложений или хоста. Возможность подключения постоянного хранилища непосредственно к контейнерам Linux позволяет одновременно использовать эту платформу для приложений stateful и stateless.

 

Пройти обучение по Red Hat Openshift Container Platform и получить сертификацию можно на www.inventa.ru

 

Построение платформы продуктивного уровня

 

По мере увеличения объема микросервисов в общей доле приложений в компаниях, особенно в продуктивных контурах, все больше внимания будет уделяться вопросам создания инфраструктуры контейнерных платформ. Под этим термином мы понимаем не только сам кластер Kubernetes (это лишь вершина айсберга), но и набор сопутствующих компонентов, без которых функционирование и эксплуатация кластера невозможны или не имеют смысла. Это системы мониторинга (как самого кластера, так и работающих в нем сервисов), логгирования, трассировки, внешнего хранения и резервирования данных, интеграции с внешними источниками и приемниками данных, интеграции с CI/CD-системами. Компаниям необходимо научиться собирать из огромного количества существующих компонентов работоспособный механизм для стабильной работы платформы. Для этого нужны либо сильная внутренняя экспертиза, либо надежный партнер.

 

Здесь можно отметить решения для внешнего хранения данных — Persistent Storage. Несмотря на то что изначально Kubernetes не был предназначен для запуска stateful-нагрузок, в последнее время такой сценарий встречается все чаще. Видимо, удобства использования контейнерных технологий превышают возможные минусы. Традиционные методы подключения внешних дисковых массивов здесь не подходят, требуется дополнительный технологический слой управления дисковыми емкостями — некий провайдер для кластера, который позволит контейнерам работать с внешними томами в динамическом режиме. 

 

Одни производители традиционных дисковых массивов дополняют и адаптируют функционал своих решений до состояния Kubernetes-aware, другие изначально разрабатывают решения под Kubernetes, обычно на базе подхода Software Defined Storage. Среди последних — Pure Storage с решением Portworx, которое, на наш взгляд, с технологической точки зрения является одним из лидеров рынка. Всего же подобных решений более 60, при этом одна часть из них не развивается, другая функционально непригодна для продуктива при серьезных нагрузках.

 

Дополнительно ситуацию усложняет тесная взаимосвязь решений для внешнего хранения данных с технологиями резервирования кластеров между разными площадками. Эти два аспекта необходимо продумывать совместно на ранних этапах разработки целевой архитектуры. К сожалению, большая часть решений Open Source пока не обладает таким функционалом, поэтому при наличии подобной потребности выбор часто делается в сторону вендорских продуктов. В них эти вопросы уже проработаны из-за специфики enterprise-рынка. Мы рассчитываем на то, что в ближайшей перспективе решения Open Source будут подтягиваться до стабильного и функционального уровня, пригодного для продуктивных нагрузок, и что экосистема в целом будет выходить на достаточный уровень зрелости технологий.

На заметку

 

Portworx от Pure Storage — это полностью интегрированное решение для постоянной СХД, защиты данных, аварийного восстановления, безопасности данных, переноса данных, в том числе между облаками, и автоматизированного управления емкостью для приложений, работающих на Kubernetes.

 

По сравнению с аналогами продукт Portworx уникален в первую очередь своей функциональностью: он запускается не только в Kubernetes, имеет возможность переноса данных между кластерами и площадками, содержит инструменты для резервного копирования и репликации данных.

 

GigaOm Research присудил Portworx 1-е место из 20 платформ СХД Kubernetes. Это одна из причин, по которым ИТ-команды полагаются на Portworx при производстве в Global 2000.

 

Централизованное управление

 

Следующий пункт — вопросы управления контейнерной платформой. Одно дело — управлять одним тестовым кластером, другое — множеством кластеров в разных, часто изолированных контурах и в разных дата-центрах, в том числе у внешних провайдеров. Поскольку сегодня гибридная модель инфраструктуры превалирует на рынке, последний пункт особенно актуален. 

 

Перед ИТ-службой встают сразу два вопроса. Первый: как обеспечить единую точку управления всеми средами, контурами и окружениями? Нужны централизованные средства мониторинга и эксплуатации и инструменты решения повседневных задач «второго дня». Второй вопрос: как обеспечить синхронизацию и консистентность состояния кластеров и сервисов? Обе эти задачи требуют наличия единых средств управления, которые позволят обслуживать все имеющиеся кластеры, где бы они ни размещались.

 

В сегменте приватных инфраструктур такие средства пока представлены недостаточно широко, но предложения уже есть. Кроме того, с учетом большого количества сред и еще большего количества изменений, происходящих с микросервисными приложениями, становится актуален вопрос автоматизации управления. Здесь упор нужно делать на GitOps. При таком подходе основной задачей ИТ-служб и отделов разработки является грамотное описание целевого состояния системы, а соответствующий инструментарий отвечает за отслеживание текущего состояния и его приведение к целевому в автоматическом режиме. 

 

Вся идеология Kubernetes, строящаяся на декларативном описании требуемого состояния ресурсов, хорошо ложится на такой подход и способствует его внедрению. Таким образом, средства автоматизации и подходы Infrastructure as Code становятся еще более актуальными по мере роста количества кластеров, увеличения числа сервисов и продуктовых команд. В это направление обязательно нужно инвестировать время и ресурсы.

 

Вопросы безопасности

 

Последнее, о чем хотелось бы поговорить, — это вопросы информационной безопасности. Сложность в том, что технически и организационно обеспечение ИБ в контейнерных средах сильно отличается от привычных подходов. Большое количество новых сущностей в микросервисных архитектурах и совершенно другой подход при доставке ПО создают свою специфику. 

 

По нашему опыту, практически в каждом первом случае компании сталкиваются с тем, что существующие ИБ-подходы не работают, а регламенты для новых типов сред еще не написаны. Очевидна и нехватка экспертизы. Как показывает практика, чем раньше в процесс разработки целевой архитектуры будет вовлечена служба ИБ, тем проще пройдет внедрение и тем меньше изменений потребуется вносить потом. 

Короткий, но важный вывод

 

Контейнерные технологии и Kubernetes стали важной частью ИТ-ландшафта enterprise-компаний. Нет никакого смысла сопротивляться этому тренду. Микросервисная архитектура позволяет быстрее разрабатывать и выводить в продакшн новые сервисы, а работает она именно в контейнерах. Классическая инфраструктура не позволит выпускать релизы так же часто. 

 

Не нужно откладывать модернизацию своих систем. Напротив, пора активно внедрять новые платформы и копить компетенции. Если затянуть с этим, то прямо сейчас вы, вполне возможно, ничего не потеряете, но в долгосрочной перспективе гарантированно отстанете от конкурентов. 

Уведомления об обновлении тем – в вашей почте

Как компании подготовиться к внедрению Open Source ПО? Чек-лист

Плюсы и минусы ПО с открытым кодом? Check-up Open Source — оцените свои ИТ перед внедрением?

Не СХД, а болид «Формулы-1»: тестируем Huawei OceanStor Dorado 18000 V6

Сколько серверов нужно, чтобы выжать максимум из новой СХД? Насколько выгоден Dorado 18000 V6 с финансовой точки зрения? Зачем к тестам подключался специалист 3-й линии поддержки?

Программно-определяемые грузоперевозки

Еще недавно слово «аппаратный» было синонимом надежности и производительности. Каждая задача – на своем сервере. Все сетевые устройства непременно аппаратные, в массивных корпусах и с большим количеством лампочек.

«С точки зрения инфраструктуры мы находимся в переходном периоде»

Почему «МультиКарта» продолжает использовать ПО, созданное в 2000-х? Можно ли считать Open Source двигателем ИТ-индустрии? В каком случае контейнеризация не имеет смысла?

Облачная НЕбезопасность и как с ней бороться

Риски частных, публичных инфраструктурных облаков и облачных приложений. Как защитить компанию при переходе в cloud-среду?

«Бояться новых подходов в ИТ — все равно что бояться дышать»: что такое Инфраструктура 3.0 и почему она неизбежно наступит

Какие технологии характерны для Инфраструктуры 3.0? За счет чего новый подход может быть выгоднее имеющейся инфраструктуры? Как хождение по граблям решает кадровый вопрос?

Как хранят и резервируют данные в 2021 г.

Как правильно управлять критичными данными и защититься от их потери? Основные технологии, применяемые для оптимизации времени восстановления при сбоях? Что умеют решения NetApp?

«Все, что можно автоматизировать, мы будем автоматизировать»

Какие подходы и технологии Инфраструктуры 3.0 реализует «Леруа Мерлен»? Почему прообразом для одной из ИТ-платформ компании послужило животное окапи? Для каких задач стоит привлекать аутсорсеров, а когда лучше развивать свою команду?

Как настроить инфраструктуру, чтобы защититься от вирусов-шифровальщиков

Можно ли защититься от вирусных атак не только с помощью антивируса и других инструментов ИБ? Почему вирусы-шифровальщики стали одной из главных угроз для бизнеса? Как опознать атаку и минимизировать урон? Что такое стратегия «3-2-1»?

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня