ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА»
(СПбГУТ)
Факультет Института магситратуры
Кафедра Инфокоммуникацонных систем
Допустить к защите
Заведующий кафедрой Зарубин А.А.
____________________
(подпись)
«11» июня 2021 г.
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
11 11 11 11 11 11 1«Разработка платформы Интернета Вещей» 11 11 11 11 11
(тема ВКР)
Вид выпускной квалификационной работы:
11 Магистерская диссертация 11 1 11 11 11 11 11 11 11 11 1111111111111111
(бакалаврская работа, дипломная работа, дипломный проект, магистерская диссертация)
Направление/специальность подготовки:
1111.04.02 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
(код и наименование направления/специальности)
11Инфокоммуникационные технологии и системы связи 11 11 11 11 11 11 11
Направленность (профиль):
11Системы управления инфокоммуникациями 1111111111111111111111111
(наименование)
Квалификация:
11Магистр 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 111111111111111 111
(наименование квалификации в соответствии с ФГОС ВО / ГОС ВПО)
Студент:
1Мордвинов Егор Юрьевич, ИКТС-93м1
(Ф.И.О. Группа)
Руководитель:
1к.т.н., доцент, Кисляков Сергей Викторович1
(Уч.степень, должность, кафедра, Ф.И.О.)
Санкт-Петербург
2020
СОДЕРЖАНИЕ
ВВЕДЕНИЕ .............................................................................................................. 3
ГЛАВА 1 ИНТЕРНЕТ ВЕЩЕЙ В ТЕЛЕКОММУНИКАЦИЯХ ........................ 7
1.1 Описание концепции Интернета Вещей ..................................................... 7
1.2 Услуги Интернета Вещей ........................................................................... 10
1.3 Протоколы Интернета Вещей .................................................................... 11
1.4 Технологии Интернета Вещей ................................................................... 12
1.5 Выводы ......................................................................................................... 16
ГЛАВА 2 ПЛАТФОРМА КАК ОСНОВА ДЛЯ ПОДДЕРЖКИ
ПРИЛОЖЕНИЙ ..................................................................................................... 18
2.1 Определение платформы ............................................................................ 18
2.2 Характеристики платформы ...................................................................... 21
2.3 Преимущества платформы ......................................................................... 23
2.4 Новые требования к платформе от уровня приложений ........................ 24
2.5 Выводы ......................................................................................................... 32
ГЛАВА 3 АРХИТЕКТУРНАЯ ОСНОВА СОВРЕМЕННОЙ ПЛАТФОРМЫ 37
3.1 Модель системы оркестрации ................................................................... 37
3.2 Архитектура Kubernetes ............................................................................. 40
3.3 Логические компоненты Kuberenetes ....................................................... 45
3.4 Выводы ......................................................................................................... 55
ГЛАВА 4 АНАЛИЗ ОСОБЕННОСТЕЙ ОРКЕСТРАЦИИ ПРИЛОЖЕНИЙ
ИНТЕРНЕТА ВЕЩЕЙ .......................................................................................... 57
4.1 Дополнительные требования к системе оркестрации ............................. 57
4.2 Методы машинного обучения ................................................................... 60
4.3 Проверка методов ....................................................................................... 62
4.4 Анализ полученной системы ..................................................................... 70
4.5 Выводы ......................................................................................................... 75
ЗАКЛЮЧЕНИЕ ..................................................................................................... 77
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ........................................... 79
2
ВВЕДЕНИЕ
Современные IT решения с использованием технологий Интернета
Вещей становятся все более востребованными и популярными. Новые бизнесзадачи часто сталкиваются с необходимостью развития в направлении
Интернета Вещей. Автоматизация производства, мониторинг объектов,
контроль и обеспечение безопасности – все это лишь малая часть того, какие
задачи
может
позволить
решить
Интернет
Вещей.
Также
из-за
востребованности сервисов Интернета Вещей в новых сферах появляются
другие требования по задержке и безопасности при передаче сообщений. При
этом помимо разработки самих IT-решений важными остаются задачи
создания окружений для развертывания и поддержки таких приложений.
Технологии Интернета Вещей и подходы в создании приложений постоянно
совершенствуются и изменяются, что делает задачу разработки платформы,
отвечающую всем новым требованиям, все более актуальной. Платформа при
этом рассматривается как промежуточное программное обеспечение, которое
позволит не только упростить процесс эксплуатации приложений, но также
ускорит цикл разработки, интеграции и тестирования.
Для определения задач и требований к платформе Интернета Вещей
предлагается использование модель PaaS, то есть рассмотрение платформы
“as-a-service” (как услуги). Согласно такой модели вышележащим уровнем,
который является потребителем услуг PaaS, является SaaS – Software as a
Service (программное обеспечение как услуга). При этом сама платформа
опирается на уровень IaaS – Infrastructure as a Service (инфраструктура как
услуга). Разработка платформы Интернета Вещей подразумевает учёт всех
требований согласно модели “as-a-service” для дальнейшего построения IT
решения в области Интернета Вещей на ее основе.
Почти
всегда
инфраструктура
для
современных
приложений
выстраивается согласно архитектуре cloud computing (облачные вычисления).
3
Такой подход также можно встретить и в области Интернета Вещей, но в
условиях возрастающих требований к сети по задержке данная архитектура
становится менее актуальной. Для таких целей более подходящими становятся
архитектура fog computing (туманные вычисления). Применение туманных
вычисления в области Интернета Вещей позволяет получить ряд преимуществ
для поддерживаемых приложений:
Низкие показатели по задержке в сравнении с привычными
облачными
вычислениями,
что
необходимо
для
пользователей
Интернета Вещей в новых областях применения.
Данные от объектов Интернета Вещей могут обрабатываться “на
краю” сети, то есть ближе к конечному пользователю или устройству,
что позволяет выносить логику на оконечные узлы и отправлять в
“облако” уже агрегированные данные.
Инфраструктура при использовании fog computing значительно изменяется и
это должно учитываться при разработке платформы Интернета Вещей.
Значительные изменения также происходят и на уровне программного
обеспечения.
Новые
способы
разработки
приложений
стремятся
к
уменьшению времени, упрощению упаковки и миграции готового решения к
заказчику, переходя к более гибким CI/CD (непрерывной интеграции и
доставки) методологиям с использованием контейнеризации. Это, как и
другие
сопутствующие
контейнеризации
процессы
оркестрации
и
кластеризации, являются основным критерием для программного обеспечения
уровня PaaS.
Принимая во внимание вышеперечисленные особенности можно
сформулировать одну из проблем – планирование и размещения контейнеров
с запущенными приложениями на fog узлах сети согласно изменяющемуся
спросу и нагрузке. Так как ресурсы узлов на краю сети намного меньше по
сравнения с объектами облачных вычислений, а трафик поступающий на них
4
постоянно
изменяется,
появляется
необходимость
прогнозирования
возможной нагрузки и принятия решений на ее основе для масштабировании
контейнеров. Существующие платформы частично реализуют подобную
идею,
давая
возможность
задания
параметров
для
автоматического
масштабирования. Указывая пороговые значения для определенных метрик и
необходимые действия, инженер может задать простой алгоритм для
автоматического масштабирования контейнера. Но такой подход требует
периодического участия человека в процессе и образует пробел в
автоматизации. Также с целью оптимального использования всех доступных
ресурсов на fog узлах придется все чаще повторять данное действие в
зависимости от создаваемой нагрузки в каждый момент времени.
Таким
образом
предметом
исследования
является
платформа
Интернета Вещей на базе модели PaaS, fog сетевой инфраструктуры с
применением контейнеризации приложений.
Объектом является методология предсказания поступающей нагрузки
на приложения Интернета Вещей, размещенных на edge/fog узлах сети внутри
платформы с применением технологий контейнерной разработки.
Цель исследования – получением алгоритма для прогнозирования
нагрузки на приложения, размещенные в контейнерах на edge/fog узлах сети
для дальнейшего его применения при автоматизированном масштабировании.
Исследуемая гипотеза – применение алгоритмов предсказания
поступающей нагрузки повысит эффективность использования ресурсов на
узлах сети и повысит степень автоматизации платформы.
Задачами исследования становятся:
рассмотрение архитектуры существующих PaaS для поддержки
приложений с применением контейнеризации
5
определение метрик, которые позволят составить прогноз для
поступающей нагрузки
создание тестового окружения с использованием одной из
существующих PaaS с возможностью мониторинга и сбора
метрик
выбор и анализ методов для прогнозирования нагрузки
проверка
выбранных
методов
и
оценка
результатов
прогнозирования
описание полученных результатов и возможной интеграции
разработанной модели в существующие платформы
6
ГЛАВА 1 ИНТЕРНЕТ ВЕЩЕЙ В ТЕЛЕКОММУНИКАЦИЯХ
1.1 Описание концепции Интернета Вещей
Концепция
IoT
(Internet
of
Things)
представляет
из
себя
инфраструктуру, основанную на взаимодействии физических и виртуальных
вещей, объединенных в одну сеть с помощью выбранной среды коммуникации
и набором протоколов для связи между собой или с внешними сетями, и
нацеленную на предоставление ряда услуг.
Истоками Интернета Вещей можно считать более ранние концепции
M2M [1] (межмашинного взаимодействия), в которых использовались
машины, а также технологии, который позволяли передавать информацию
между ними. Впервые термин IoT возник во время презентации RFID
технологии. Данная технология позволяет производить идентификацию
какого-либо объекта физического мира беспроводным способом и является
одной из предпосылок к возникновению концепции IoT. К 2009 году
количество подключенных объектов Интернета Вещей превысило население
планеты, тем самым в значительной степени установив вектор развития телеи инфокоммуникационных технологий на ближайшие годы.
Интернет Вещей, являясь бурно развивающимся направлением в
телекоммуникациях, порождает множество определений. Одной из главных
организаций
в
области
стандартизации
Интернета
Вещей
является
Международный союз электросвязи. Также в разные промежутки времени в
этом принимали участие другие партнерские проекты: oneM2M, 3GPP, а также
Европейский институт телекоммуникационных стандартов со специально
созданным техническим комитетом SmartM2M. Для описания общих
положений и модели Интернета вещей стоит обратиться к рекомендации ITUT Y.2060 [2] «Обзор Интернета вещей», в которой дано определение
7
Интернету Вещей как «глобальной инфраструктуре для информационного
общества, которая обеспечивает возможность предоставления более сложных
услуг путем соединения друг с другом (физических и виртуальных) вещей на
основе существующих и развивающихся функционально совместимых
информационно-коммуникационных технологий». Также была предложена
эталонная модель, которая представлена на рисунке 1 и состоит из четырех
уровней:
уровень приложений;
уровень поддержки услуг и поддержки приложений;
уровень сети;
уровень устройств.
Рис.1 Эталонная модель Интернета Вещей согласно рекомендации ITU-T
Y.2060
На уровне устройств все объекты можно разделить согласно
возможностям на обычные устройства и шлюзы. Возможности устройств
8
состоят из непосредственного взаимодействия с сетью (передача и получение
информации
в
сеть
связи
без
использования
шлюза),
непрямого
взаимодействия с сетью при помощи шлюза, организации специальных сетей
с повышенной масштабируемостью и поддержки «спящего режима» в целях
экономии энергии. Возможности шлюзов состоят из поддержки нескольких
интерфейсов (как со стороны устройств, так и со стороны сети) и
преобразования протоколов в зависимости от используемых на каждом из
уровней.
Уровень сети соответствует сетевому уровню модели OSI и в его
возможности
входят
организация
сетей,
подключение
устройств
с
нижележащего уровня, а также транспортировки данных и сигнальных
сообщений, относящихся к IoT.
Уровень поддержки услуг и приложений содержит общие функции по
обработке и хранению данных для совместного пользования разными
приложениями, а также специальные функции для определенных видов
приложений. Уровень приложений содержит приложения Интернета Вещей.
Возможности управления и обеспечения безопасности, также как и на
уровне поддержки услуг и приложений, разделяются на общие и
специализированные. В случае управления к общим относятся управление
устройствами (активация, обновление, деактивация), топологией сети и
трафиком при возникновении перегрузок на узлах сети. Для безопасности к
общим
возможностям
относят
идентификацию,
аутентификацию
и
авторизацию устройств, сохранение конфиденциальности пользовательских и
сигнальных
требованиями
данных.
от
Специализированные
конкретных
приложений.
возможности
Для
связаны
управления
с
такими
критериями могут быть приложения для мониторинга промышленной
системы с необходимостью комплексного мониторинга и реагирования на
9
возникающие изменения, а дополнительные возможности для безопасности
возникают в случае приложений IoT, связанных с электронной коммерцией.
1.2 Услуги Интернета Вещей
Возможности,
предлагаемые
IoT,
позволяют
разрабатывать
многочисленные приложения для различных областей применения. На данный
момент уже сформировалась тенденция, согласно которой Интернет Вещей
находит большое применение в общественной сфере, промышленности и в
области контроля и мониторинга окружающей среды [3]. Примеры
использования IoT для некоторых областей:
Умные Города: Интернет вещей играет важную роль для
улучшения городов, включая в себя множество приложений для
мониторинга парковочных мест, мониторинга состояния зданий и
мостов, контроля загрязнения в разных зонах города, мониторинга
транспортных средств и пешеходов на улицах, контроль освещения
уличных фонарей, а также информирование о чрезвычайных событиях,
авариях, пробках и так далее.
Сельское хозяйство и водные ресурсы: IoT может помочь
улучшить сельскохозяйственную деятельность, контролируя влажность
почвы для поддержания количества микроэлементов, тем самым
добиваться максимизации производства продукции и ее качества.
Изучение погодных условий на полях для прогнозирования информации
о погоде, наступление засухе, контроль уровня температуры также
возможно с помощью Интернета Вещей. Роль IoT в управлении
водными ресурсами включает изучение качества воды, контроль
давления в трубах, а также мониторинг изменений уровня воды в реках,
плотинах и водохранилищах.
10
Розничная торговля и логистика: Внедрение IoT в управление
цепочками поставок дают много преимуществ, включающие в себя не
только отслеживание местоположение товара, но и условий его
хранения. В розничной торговле IoT предлагает возможные приложения
для автоматизированного подбора необходимого товара и новые
платежные решения.
Здравоохранение: Применение IoT в здравоохранении нацелено на
создание условий для мониторинга состояния пациента в реальном
времени где бы он не был, а также уведомления врача в режиме
реального времени о жизненных показателях в случае опасности для
пациента. Все это позволяет получать больше данных о состоянии
человека в любой момент времени, дает возможность раннего выявления
отклонений от нормы и заболеваний при анализе полученных данных, а
также сократить время реагирования и принятия решений в случае
экстренной ситуации.
Безопасность: IoT позволяет повысить безопасность в тех
условиях, где это является жизненно важным и необходимым
процессом.
Для
предотвращения
последствий
и
возможных
чрезвычайных ситуаций, вызванных утечкой газа на промышленном
производстве, повышением уровня реки, изменением радиационного
фона и так далее, могут использоваться сенсоры и датчики, данные с
которых постоянно поступают в систему и подвергаются анализу.
1.3 Протоколы Интернета Вещей
Очевидно, что для связи устройств между собой и приложением,
требуется разработка протоколов. На данный момент появляется множество
общедоступных, а также и проприетарных протоколов для подключения и
11
управлениями устройствами Интернета Вещей. Ключевыми особенностью в
этом являются большое разнообразие устройств, разные топологии на уровне
локальной сети, ограничения в вычислительных ресурсах, а также различные
сценарии работы (в режиме реального времени или активация по времени).
Различные протоколы для физического уровня разрабатываются с учетом этих
критерием.
Протоколы верхних уровней в основном создаются с применением
паттернов «издатель-подписчик» и «клиент-сервер» [4]. При создании
протоколов на основе архитектуры «клиент-сервер» главным объектом
становится сессия, которая устанавливается между клиентов и сервером для
обмена информацией. В случае использования «издатель-подписчик» вместо
сессий для обмена информацией используются сообщения. При этом
существуют объекты сети, которые могут быть издателями или подписчиками.
С помощью промежуточного брокера каждый объект сети может получать
информацию о необходимых событиях и темах, отправляя запрос о подписке
на них. Так же можно издавать сообщения, отправляя запрос к брокеру о
публикации. Такой подход нашел большое применение в контексте IoT из-за
простоты обмена сообщениями, отсутствия необходимости изменений при
масштабируемости сети, а также поддержки критериев на физическом уровне
– использование сообщений вместо создания сессий требует меньшего объема
ресурсов.
1.4 Технологии Интернета Вещей
Интернет Вещей является совокупностью многих технологий, которые
были созданы ранее или специально разработаны в рамках IoT проектов, но
при этом объединены одной целью – реализовывать задачи, который
появляются в процессе создания новых приложений.
12
Одной из таких ключевых технологий, которая повлияло не только на
разработку приложений Интернета Вещей, является концепция «облачных
вычислений».
Предшествующий этому подход для запуска приложений предполагал
использование локальной сети с подключенными в нее персональными
компьютерами или корпоративного сервера, который также размещался в
непосредственной близости к предприятию. Новая концепция облачных
вычислений предлагает отказаться от такого подхода в пользу использования
вычислительных ресурсов «облака» - удаленного центра обработки данных.
После такого перехода пользователь продолжает работать с приложением, при
этом освобождаю и значительно разгружая свои персональные компьютеры.
При этом всю ответственность с соответствующими SLA на себя берет
провайдер «облачных услуг», выбирая оптимальный сервер или выделяя
необходимые вычислительные ресурсы для запуска виртуальной машины –
процессоры, оперативную память, хранилище, а также сетевые ресурсы для
бесперебойного доступа к запущенному приложению.
Облачные вычисления могут быть разделены на три вида [5]:
Публичные облака – создаются отдельными провайдерами для
предоставления своих услуг предприятиям и частным лицам.
Частные облака – создаются предприятиями для собственных
нужд и предоставления услуг работникам для внутреннего
использования.
Гибридные облака – одновременное сочетание публичных и
частных облаков.
Из преимуществ облачных вычислений можно отметить уменьшение
расходов на поддержку собственной инфраструктуры, так как не требуется
заниматься закупкой, настройкой и обслуживанием оборудования. И также
уменьшаются затраты при возникновении внештатных ситуаций, в таких
13
случаях
провайдер
облачных
ресурсов
производит
ряд
действий
самостоятельно для минимизации времени простоя. С развитием и
увеличением объемов разработки, а также при временном повышенном
запросе со стороны пользователей, возникает необходимость расширения
вычислительных ресурсов, что стало бы крайне экономически неэффективным
при поддержке собственной инфраструктуры. Для таких случаев провайдеры
облачных ресурсов предлагают услуги масштабирования – объем ресурсов
может быть увеличен по запросу от клиента на какой-то промежуток времени
или наоборот снижен в зависимости от потребностей.
Главной основной «облака», которая способствовала его быстрому
распространению и совместному использованию сразу большим количеством
пользователей, является технология виртуализации. Ее использование
позволяет проще распределять вычислительные и сетевые ресурсы, создавая
промежуточный уровень, на котором каждый из пользователей может
отследить арендуемый объем ресурсов. Самым используемым примером
виртуализации является создание виртуальных машин: выбирая основной хост
с определенными фиксированными характеристиками можно абстрагировать
пользователя от аппаратной части, предоставив ему в пользование гостевой
хост – виртуальный хост, созданный и управляемый промежуточным
программным обеспечением и использующий выделенный объем ресурсов
основного.
Другим, относительно новым, типом организации ресурсов стали
туманные вычисления [6]. Главным отличием от облачных вычислений
является децентрализованная обработка данных с использованием уже не
крупных центров обработки данных, а распределенных устройств сети,
которые находятся ближе к оконечному пользователю.
Туманные
вычисления
призваны
решить
проблему
обработки
большого объема данных, создаваемого при введении в работу приложений
14
Интернета Вещей. Увеличение количества подключаемых устройств, в том
числе устройств IoT, влечет за собой возрастание объемов трафика на сети при
передаче их в центры обработки данных. В целях соблюдения параметров
качества предлагается использовать ресурсы узлов сети, которые находятся
ближе к пользователям, производя обработку информации с их помощью.
Стоит отметить, что туманные вычисления не являются полноценной заменой
для облачных, а скорее созданы как расширение, позволяя производить
первичную обработку на краю сети и передавать уже агрегированные данные
в облако как это показано на рисунке 2.
Рис.2 Место туманных вычислений в сети
Примерами устройств сети, которые могут выполнять эти задачи,
являются маршрутизаторы на границе сети доступа или мобильные базовые
станции в сети сотовой связи. Так как первоначально эти устройства были
15
введены в эксплуатацию для выполнения других задач, то перед началом
процедуры следует производить проверку возможности обработки запросов со
стороны
туманных
вычислений
во
избежание
ухудшения
качества
обслуживания при предоставлении основных услуг.
1.5 Выводы
Тенденция
роста
количества
объектов
Интернета
Вещей
и
востребованность в этой технологии со стороны бизнеса для решения
реальных задач и предоставления качественно новых услуг закрепили IoT в
качестве одного из приоритетных направлений в теле- и инфокоммуникациях.
С быстрым ростом количества устройств Интернета Вещей происходит
резкое увеличение объемов данных, производимых ими, поэтому приобретают
актуальность вопросы управления трафиком от таких устройств. Каждое
устройство производит трафик с разными параметрами по интенсивности,
частоте и объему передаваемых данных. В связи с этим существующая модель
«облачных вычислений», которая получила повсеместное распространение и
втом числе для приложений Интернета Вещей, становится не такой
эффективной, так как обработка генерируемых данных от большого
количества источников в значительной степени влияет на загруженность сети
и ее пропускную способность. Помимо этого появляются новые критерии со
стороны самих услуг и приложений Интернета Вещей. При предоставлении
услуг с помощью технологий IoT в области здравоохранения критическими
становятся параметры задержки. Эти проблемы в первую очередь призвана
решить
новая
модель
«туманных
вычислений».
Распределяя
централизованное «облако» на множество устройств, можно сразу добиться
лучших показателей по задержке, а также освободить сеть от избыточного
16
трафика, выполняя большинство вычислений на узлах сети ближе к
пользователю и отправляя в «облако» обработанные данные.
Туманные вычисления, являясь одной из главных технологий для
развития
Интернета
Вещей,
в
свою
очередь
также
ставят
перед
разработчиками ряд вопросов и проблем при реализации. Туманные
вычисления
предполагают
применение
гетерогенных
устройств,
использующих различные аппаратные базы в отличие от однотипных серверов
в центрах обработки данных, что усложняет организацию выполнения
процессов туманных вычислений. Также в силу ограниченности ресурсов по
сравнению с возможностями облачных вычислений, а также постоянной
задачи предоставления основных услуг помимо туманных вычислений на
каждом
устройстве,
возникает
необходимость
создания
механизмов
приоритизации и масштабирования: необходимо выбирать доступные узлы
для обслуживания туманных вычислений в данный момент, перераспределять
используемые ресурсы на них или производить выбор другого узла в пределах
подсети туманных вычислений.
17
ГЛАВА 2 ПЛАТФОРМА КАК ОСНОВА ДЛЯ ПОДДЕРЖКИ
ПРИЛОЖЕНИЙ
2.1 Определение платформы
В
зависимости
от
контекста
понятие
«платформа»
может
восприниматься по-разному. Зачастую в области инфокоммуникаций
платформой
называют
промежуточное
программное
обеспечение,
позволяющее упростить разработку новых приложений и дальнейшую их
эксплуатацию. В данной работе предлагается рассмотрение понятия
платформы для Интернета Вещей с использованием концепции облачных
сервисов.
В предыдущей главе были описаны сетевые архитектуры для
предоставления доступа к вычислительным ресурсам – облачные и туманные
вычисления. С точки зрения потребителя этих ресурсов в зависимости от
квалификации и задач могут возникать разные потребности в продуктах.
Базовым уровнем является инфраструктура, содержащая вычислительные
ресурсы, хранилище и сетевые возможности – это является основой для всех
моделей централизованных и распределенных вычислений. С использованием
инфраструктуры многие задачи, связанные с управлением и обслуживание
физического центра обработки данных и физической инфраструктуры
(сервера, дисковые хранилища, локальные сети и т.д.), абстрагируются и
становятся доступными как набор сервисов, к которым можно получить
доступ с помощью web-интерфейса или набора API. Задачи разработки
приложений и администрирования все также остаются актуальными при таком
подходе, но нет необходимости в закупках и установке физических серверов.
С виртуальной инфраструктурой доступ к ней может быть получен по запросу
в любой момент времени. Таким образом, инфраструктура предоставляет
возможности виртуального центра обработки данных, чтобы потребители
18
услуг
может
больше
сосредоточиться
на
создании
и
управлении
приложениями и меньше на управление центрами обработки данных и
инфраструктурой. На рынке в данный момент существует множество
поставщиков услуг инфраструктуры. Глобальными провайдерами в этой
области являются Amazon Web Services, Google Cloud, Azure и Digital Ocean.
Последним уровнем являются сервисы - полноценные приложения для
потребителя
услуги.
Пользователю
лишь
необходимо
произвести
персональную настройку для начала эксплуатации готового решения
Примерами
таких
приложений
могут
быть:
системы
управление
взаимоотношениями с клиентами (CRM), программное обеспечение для
бухгалтерского учета, редакторы для совместного составления документов и
многое другое. Потребители получают готовый функционал и не занимаются
задачами поддержки нижележащих уровней, управлением инфраструктурой и
так далее. Промежуточным уровнем между приложениями и инфраструктурой
в классической модели облачных сервисов является платформа. Пользуясь
возможностями уровня инфраструктуры, платформа предлагает свои услуги
вышележащему уровню приложений. Целью применения платформы является
абстрагирование разработки от сторонних задач, которые возникают во время
разворачивания, обновления и эксплуатации программного обеспечения,
давая возможность больше сфокусироваться на реализации бизнес логики
приложений. Платформа дает возможность развертывания на базе облачной
инфраструктуры
программирования,
приложений,
библиотек
созданных
и
с
инструментов,
помощью
языков
поддерживаемых
поставщиком услуг платформы, оставляя для пользователя возможность
конфигурации среды размещения и параметров запуска приложений.
Согласно описанным уровням, изображенных на рисунке 3, существует
три основных модели обслуживания «как сервис» [7]:
Infrastructure as a Service (IaaS) – инфраструктура как сервис;
Platform as a Service (IaaS) – платформа как сервис;
19
Software as a Service (IaaS) – программное обеспечение как сервис.
Рис.3 Модель услуг «as a service»
Пользователю
предлагается
предоставление
ресурсов
согласно
выбранной модели зачастую на основе подписки. Общей характеристикой для
такой
архитектуры
является
степень
ответственности
провайдера и
пользователя. При эксплуатации программного обеспечения согласно PaaS
модели задачи поддержки и обновления приложения находятся на стороне
провайдера услуг. При использовании инфраструктуры для создания
собственных приложений провайдер услуг выполняет задачи обеспечения
SLA только на уровне вычислительных ресурсов.
20
2.2 Характеристики платформы
Общее описание платформы как открытого и гибкого решения, которое
упрощает, процесс разработки, интеграции и управления приложениями с
применением разных типов облачных вычислений можно разделить на
несколько групп основных характеристик:
мультиарендность;
масштабирование;
мониторинг и управление.
В контексте облачных вычислений мультиарендность - это способность
облака организовывать вычислительные ресурсы, которые используются
совместно разными пользователями одновременно. Изоляция при этом
определяется как способность воспринимать специализированную среду как
часть общей базовой инфраструктуры. Полная изоляция приложений,
добавляемых в платформу, может быть достигнута с помощью технологий
виртуализации. Примером этой технологии являются виртуальные машины. С
применением гипервизора – специального программного обеспечения,
которое позволяет абстрагировать аппаратные возможности основного хоста,
становится возможным выделение определенного объема ресурсов по
запросу. При этом множество виртуальных машин, запущенных на одном
физическом сервере могут независимо обслуживать разные приложения, а
также создавать разные среды для распределенных команд разработки и
тестирования.
Масштабируемость - основная характеристика для приложений внутри
платформы.
Масштабируемость
говорит
о
способности
базовой
инфраструктуры адаптироваться к требованиям приложения, учитывая
множество требований: количество одновременных пользователей, время
отклика приложения, количество открытых соединений и так далее.
21
Масштабируемость является показателем способности увеличивать и
уменьшать используемые ресурсы в зависимости от ряда характеристик в
каждый
момент
масштабируемости:
времени.
Обычно
горизонтальную
и
рассматривают
вертикальную.
два
типа
Горизонтальная
масштабируемость относится к количеству объектов, которые должны быть
активными в данный момент для обслуживания возникшей нагрузки.
Вертикальная масштабируемость относится к размеру объектов и, таким
образом, связана с количеством ресурсов, необходимых для достижения
требуемой конфигурации. На примере виртуализации аппаратных ресурсов в
качестве объекта может выступать виртуальная машина, количество или
выделенные ресурсы которой будут изменяться в зависимости от выбранного
режима
масштабирования.
Правильное
сочетание
двух
этих
тактик
удовлетворения требований позволяет достичь бесперебойной и точной
работы приложений внутри платформы.
Задачи мониторинга и управления для платформы в основном
сосредоточены вокруг выполнения SLA и соблюдения уровня QoS.
Управление
SLA
-
ключевой
аспект
предоставления
коммерчески
жизнеспособного предложения уровня PaaS. У управления SLA есть две
стороны. Первый - это соглашение об уровне обслуживания между
поставщиком PaaS и пользователем PaaS. Второй - это соглашение об уровне
обслуживания между поставщиком PaaS и различными поставщиками
инфраструктуры, которые он может использовать для запуска приложений
пользователей. Следует отметить, что последнее сильно влияет на SLA,
которое может предложить поставщик PaaS, и поэтому рассматривается в этом
разделе в качестве основного. Чтобы обеспечить надлежащее качество
обслуживания
для
выполнения
приложений,
необходимо
установить
соглашения об уровне обслуживания, которые описывают требования к
выполнению приложений между поставщиком PaaS и поставщиками IaaS.
22
2.3 Преимущества платформы
Одним из
основных
преимуществ
PaaS является повышение
производительности труда разработчиков приложений. PaaS обеспечивает
прямую поддержку всего процесса – ускорение разработки путем внедрения
частой поставки готового решения с новым функционалом с применением
методов
непрерывной
интеграции
и
автоматического
развертывания
приложений. Системы PaaS позволяют реализовать следующие преимущества
облачных вычислений:
масштабируемость, включая быстрое выделение и освобождение
ресурсов с помощью модели оплаты по мере использования;
уменьшение капитальных затрат;
самообслуживание с уменьшенными затратами на администрирование;
поддержка совместной работы группы разработчиков, а также других
отделов, влияющих на разрабатываемый продукт.
Поддержка
автоматизации
производительности,
автоматизацией
так
связана
и
обеспечивает
также
как
последовательность
возможность
сближения
сред
повышение
доставки.
С
разработки,
тестирования и производства, что опять же повышает согласованность и
надежность доставки - это один из аспектов гибкой разработки. В системы
PaaS обычно встроены функции безопасности и защиты данных, в том числе
возможности устойчивости, такие как репликация и резервное копирование.
Это может повысить безопасность и снизить потребность в навыках
внутренней безопасности. Предоставление таких готовых возможностей в
качестве услуг позволяет быстро создавать и развивать приложения,
отвечающие быстро развивающимся бизнес-требованиям, что особенно важно
в контексте
Интернета вещей. Бизнес-приложения обычно
требуют
интеграции и включают агрегацию данных и сервисов из нескольких
23
существующих систем - системы PaaS обычно содержат готовые компоненты
интеграции и агрегации для ускорения и упрощения необходимых работ по
разработке. Системы PaaS позволяют разделить ресурсы между несколькими
командами разработчиков, избегая необходимости распределения нескольких
активов одного типа в отдельных хранилищах.
2.4 Новые требования к платформе от уровня приложений
Платформа, являясь основой для уровня программного обеспечения, во
многом зависит от требований и характеристик приложений, которые
разрабатываются на ее основе. Применяемые методики влияют на архитектуру
IT-продуктов, которые требуют новых технологий для своей реализации.
Одним из таких новых подходов является микросервисная архитектура [8].
Привычная архитектура приложений и программного обеспечения в
целом состоит из набора слоев со своими задачами. Пример такой стандартной
архитектуры приведен на рисунке 4.
Рис.4 Пример архитектура монолитного приложения
24
Единое монолитное приложение содержит в себе полноценное
решение для реализации набора бизнес-задач. Такой шаблон становится
неэффективным при развитии и усложнении всей системы, вводя ряд
ограничений при разработке нового функционала. Поддержка и внесении
изменений становятся затратными процессами в силу связанности всей
архитектуры. При определенных условиях развитие проекта возможно
согласно этому шаблону, но с появлением новых бизнес-направлений и задач
вопрос пересмотра архитектуры становится все более актуальным. Как раз это
становится одной из главных причин перехода к микросервисной архитектуре.
В такой архитектуре присутствует ряд компонентов, которые были получены
путем разделения единого приложения согласно бизнес-задачам. Каждая
компонента ориентирована на выполнение одной конкретной задачи. На
рисунке 5 представлена возможная микросервисная архитектура.
Рис.5 Пример микросервисной архитектуры
25
Переход к такой архитектуре дает сразу несколько преимуществ.
Разделение на компоненты делает возможным назначение для каждого из них
своей задачи, делая их независимыми, и как следствие во многом ускоряет
процесс разработки и тестирования. Отсутствие связанности между сервисами
позволяет производить изменения в каком-то сервисе без необходимости
внесения правок в другом. С применением такой архитектуры процессы
разработки и тестирования новых функций могут производиться разными
распределенными командами с использованием различных технологий на
каждом уровне.
Ранее уже обсуждалось, что одной из главных характеристик для
платформы является одновременная поддержка большого количества
пользователей
вычислительных
за
счет
ресурсов.
применения
Аппаратная
технологии
виртуализации
виртуализация
и
создание
виртуальных машин были основными принципами для решения задач
распределения и масштабирования общих ресурсов
инфраструктуры.
Альтернативным решением является использование контейнеризации [9] для
реализации микросервисной архитектуры.
Контейнеризация
основывается
на
виртуализации
на
уровне
операционной системы. Создаваемые контейнеры разделяют между собой
единую хост-платформу в виде операционной системы вместо аппаратной
части в случае виртуальных машин. Разница между использование
виртуальных машин и контейнеров показана на рисунке 6.
Рис.6 Сравнение компонент для создания виртуальных машин и контенеров
26
Преимущество
использования
контейнеров
по
сравнению
с
виртуальными машинами заключается во времени запуска каждого из
экземпляров. Помимо необходимых приложений для запуска виртуальная
машина содержит образ операционной системы, что может увеличивать время
запуска с нескольких минут до десятков. Предъявляемые требования к PaaS по
бесперебойной
работе
и
миграции
приложений
в
облаке
создают
необходимость в использовании более легковесных решений. Применение
контейнеров позволяет упростить процесс эксплуатации приложений в облаке
на каждом этапе.
Развитие ядра операционной системы Linux в новых дистрибутивах
позволило реализовать концепцию контейнеризации. Новые механизмы
пространства имен и контрольные группы (namespace и cgroups), появившиеся
в ядре kernel [10], делают возможным изоляцию процессов при использовании
одной операционной системы.
Пространства имен является уровнем абстракции и позволяют
разделять группы процессов, не позволяя им видеть ресурсы в других группах.
Различные пространства имен используются контейнерными технологиями
для изоляции процессов, сетевых интерфейсов, доступа к межпроцессному
взаимодействию, точек монтирования файловых систем и так далее.
Основными функциями, которые разделяются с помощью пространства имен,
являются:
PID (Process Identifier) Namespaces: эта функция гарантирует
изоляцию процессов из разных пространств имён.
Network Namespaces: изоляция контроллера сетевого интерфейса,
iptables, таблиц маршрутизации и других сетевых инструментов более
низкого уровня.
27
Mount Namespaces: монтирует файловую систему таким образом,
чтобы область файловой системы была изолирована и имела доступ
только к смонтированными директориями.
User Namespaces: изолирует пользователя в пространстве имён,
чтобы избежать конфликта user ID между пространствами.
В результате такой изоляции каждое пространство имен создает
независимый набор, тем самым формируя подобие виртуальных машин.
После получения независимых процессов необходимо контролировать
потребляемые ими ресурсы. Для этих целей были созданы cgroups –
контрольные
группы.
Cgroups
позволяют
организовать
процессы
в
иерархическую систему, создавая набор групп содержащих внутри процессы
из пространств имен, накладывать ограничения на вычислительные ресурсы
(CPU, RAM) и давая возможность программного управления над ними.
Первая реализация идеи контейнеров использовала именно эти
принципы и была представлена в рамках проекта LXC (Linux containers).
Другие
реализации,
получившие
широкое
распространение
среди
пользователей, основывались на технологии LXC.
Одним из таких проектов, который стал почти стандартом среди
контейнерных технологий, является Docker [11]. Развиваясь на основе LXC с
целью построения публичной PaaS платформы, Docker к 2015 году получил
собственный набор программный интерфейсов для виртуализации и
взаимодействия с ядром kernel, был добавлен в новые дистрибутивы Linux, а
также получил поддержку во многих публичных облачных платформах. С
появлением Docker произошли значительные изменения в процессах упаковки
и доставки приложений. Он гарантирует воспроизводимость при передачи
готового решения от окружения к окружению, сводя к минимуму ситуации
при которых одно и тоже приложение отрабатывало по-разному в зависимости
от используемого хоста.
28
В состав программных средств Docker входит ряд компонент:
1. Docker daemon – серверная часть Docker, запускаемая на хостмашине, задачами которой является обработка запросов от клиента и
взаимодействия с другими компонентами, описанными ниже.
2. Docker CLI – клиентская часть Docker, реализованная как
командный интерфейс с набором клиентских средств и команд.
3. Docker Image, Container и Dockerfile – используемые образы,
готовые
контейнеры
и
специфичные
клиентские
реализации
контейнеров для сборки.
Базовой единицей для контейнера является образ. Как и в случае с
виртуальными машинами контейнер основывается на образе выбранной
операционной системы, но в данном случае используется более легковесный
и упрощенный образ. Образ для контейнера можно рассматривать как набор
файлов, которые содержат все необходимое для запуска приложений только с
помощью
Docker
daemon
без
необходимости
установки
third-party
зависимостей. В целях оптимизации хранения образ представляется как набор
слоев файловых систем, которые все вместе образовывают объединенную
файловую систему. Это дает возможность повторного использования одних и
тех же слоев для формирования различных образов. Например образы для
базы данных, API сервера и клиентского web-приложения могут быть
основаны на одном и том же слое с операционной системой.
При
необходимости каждый следующий слой может изменить структуру
предыдущего, но так как базовые слои должны оставаться неизменяемыми, то
они имеют характеристику read-only, а все необходимые изменения
происходят на верхнем уровне, который образовывается в момент запуска
контейнера с использованием образа. Доступные образы не всегда могут
иметь весь необходимый функционал. Помимо самих приложений в
создаваемый контейнер необходимо включать разные зависимости и
библиотеки, которых может нет быть в базовом образе. Для таких целей
29
необходимо использовать набор инструкций, представляемых как Dockerfile.
Пример содержания Dockerfile показан на рисунке 7.
Рис.7 Пример Dockerfile
В данном случае рассматривается пример для Python приложения.
Каждая строка в файле создает новый слой в образе. В качестве базового
образа используется образ с предустановленной версией Python 2.7. Далее
производится создание и выбор рабочей директории, копирование файла с
зависимостями, их установк с помощью пакетного менеджера, который также
был в базовом образе, и в самом конце запуск приложения. Как было сказано
ранее, в случае изменения одного из слоев (например, обновление списка
зависимостей для установки) все предыдущие слои будут переиспользованы
без изменений при сборке нового образа, что экономить место для их хранения
на хосте, а также время в случае сборки больших образов с более комплексной
конфигурацией. Для передачи и совместного использования образов могут
быть использованы Docker registry – репозитории с уже готовыми образами
для множества задач, построенные по принципу распределенных систем
управления версиями.
30
На данный момент можно сделать промежуточный вывод об
использовании контейнеризации в качестве удобного подхода для быстрой
кроссплатформенной разработки микросервисной архитектуры за счет
принципов разграничения ресурсов и процессов, переиспользования готовых
образов, экономии аппаратных ресурсов и значительного ускорения при
разворачивании приложения на выбранном окружении. Все эти преимущества
во многом влияют на выстраивание и переработку старых CI/CD [12] подходов
(непрерывного процесс интеграции и доставки) для готового решения. Docker
и другие технологии контейнеризации становятся главным участниками в CI
процессе, позволяя наладить работу при разработке и тестировании
приложений. После завершения CI части необходимо осуществлять доставку
приложений на рабочие окружения. Для малых объемов это может быть
выделенный хост или виртуальная машина с предустановленным Docker
daemon, на котором лишь остается получить последнюю версию образа
приложения и запустить на ее основе контейнер. Этот сценарий успешно
показывает себя при определенных показателях взаимодействия оконечных
пользователей с ним, когда создаваемая нагрузка может быть обслужена всего
лишь одним контейнером с запущенным приложением, а критерии по качеству
имеют не первый приоритет. Но в случае больших промышленных решений,
когда количество пользователей, которые одновременно могут пользоваться
приложением постоянно возрастает и понижается, а требования по
отказоустойчивости являются основными, возникает необходимость в
организации управления такой системой. В связи с этим появляются понятия
кластеризации и оркестрации набора контейнеров.
С повышением спроса со стороны пользователей и появлением
необходимости предоставления услуг с минимальным временем простоя
поддержка лишь одного контейнера становится недостаточным условием,
возникает необходимость запуска двух и более, настройки их совместной
работы
и
создания
балансировки
31
для
равномерного
распределения
поступающих запросов между ними. Также необходимо поддерживать уже
существующий CD процесс и плановое обновление приложения после выхода
новых версий. До определенного момента это возможно сделать в ручном
режиме, но со временем возникает необходимость автоматизации и
централизованного управления динамически развивающейся системой. Таким
образом кластеризация происходит при добавлении новых копий контейнеров,
а также хост узлов, когда эта необходимо, а оркестрация подразумевает
настройку взаимодействия образующихся узлов с целью согласованной
работы получившихся узлов в кластере. Также оркестрация решает задачи
запуска
большого
количества
контейнеров
на
нескольких
узлах,
последовательного их обновления, репликации контейнеров, группировку
отдельных контейнеров по заданным алгоритмам, балансирования нагрузки
между контейнерами, а также их масштабирования в зависимости от нагрузки
в каждый момент времени.
2.5 Выводы
Платформа согласно модели «as a service» является важным уровнем в
современной архитектуре при разработке программного обеспечения. Являясь
промежуточным уровнем между инфраструктурой и уровнем приложений,
платформа призвана упростить работу с аппаратным уровнем, предоставить
общее окружение для совместной работы на каждом этапе разработки ПО, а
также дать инструменты для управления и администрирования всеми
объектами системы.
Платформа дает ряд преимуществ, помогая выстроить процесс
непрерывной интеграции и доставки приложений, уменьшить расходы для
поддержки узлов, на которых разворачиваются готовые приложения,
32
динамически масштабируя нижележащую инфраструктуру в зависимости от
требований в каждый момент времени.
Предоставляя услуги для уровня программного обеспечения согласно
модели «as a service», платформа должна согласовываться с условиями,
которые появляются вместе с приложениями. В данной области сейчас
наблюдается переход к микросервисной архитектуре. Микросервисы – это
альтернативный способ разработки программного обеспечения. В отличие от
традиционного монолитного способа, где приложение представляет собой
единое унифицированное решение, архитектура микросервисов – это набор
более мелких, независимых друг от друга модулей. Каждый модуль выполняет
процесс приложения как отдельный сервис. Все сервисы имеют свою
собственную логику и базу данных, а также выполняют определенные
функции. Микросервисы нельзя назвать какой-то одной конкретной
технологией, их рассматривают как эволюцию давней концепции сервисориентированной архитектуры (Service Oriented Architecture – SOA),
дополненной появлением концепции контейнеров, и повышением уровня
автоматизации за счет таких подходов к развитию, как непрерывная доставка
(CD) и непрерывная интеграция (CI). Для больших проектов развитие
монолитного приложения со временем становится невозможным в силу
большой взаимосвязи функций, именно поэтому распределенная архитектура
микросервисов с назначением каждому из них выполнения одной задачи
является решением для независимого и быстрого выстраивания процесса
разработки, тестирования и развертывания. Также к преимуществам
микросервисной архитектуры можно отнести более стабильную разработку
без влияния компонентов друг на друга. Как следствие этого каждый из
микросервисов может развиваться с разным набором программных средств. В
случае проблемы с каким-то из компонентов пользователь скорее всего не
потеряет полный доступ к приложению и сможет продолжить его
использование.
33
Все описанные принципы микросервисной арзитектуры могут быть
реализованы с помощью технологий контейнеризации. Получив свое развитие
с добавлением новых функций в ядро операционной системы Linux,
контейнеры на данный момент стали развиваться во многих проектах на самых
разных платформах. Привычный подход с использованием виртуализации
аппаратных ресурсов и виртуальных машин начал замещаться новым типом
виртуализации на уровне операционной системы, что является главным
принципом при создании контейнеров. Использованием контейнеров во
многом сокращает расходы вычислительных ресурсов и помогает быстрее
создавать и развивать новый функционал. В контексте микросервисной
архитектуры контейнерная технология Docker стала стандартом для упаковки
и доставки приложений. Контейнеры позволяют реализовать большинство
принципов микросервисной архитектуры, размещая каждый из компонентов в
изолированную среду, при этом делая их независимыми друг от друга. Docker
также привносит ряд новых понятий как часть своей системы, представляя
образ для создания контейнера как многослойную абстракцию, где каждый из
уровней является частью общей файловой системы. Также Docker дает
возможность полного управления над составляющими будущего образа с
помощью описания их в специальном конфигурационном файле Dockerfile, в
котором можно выбрать базовый образ, настроить установку сторонних
библиотек и выбрать способ запуска приложения уже внутри контейнера.
После перехода к использованию контейнеров возникает необходимость
грамотного управления и администрирования получившейся системы. С
повышением количества контейнеров и формирования целых кластеров для
задач отказоустойчивого облуживания появляются задачи орекстрации, то
есть единого способа управления большим количеством контейнеров с целью
их обновления и масштабирования.
Таким образом можно сформировать базовые требования к платформе.
С переходом от виртуальных машин к контейнеризации базовой единицей
34
становится именно контейнер, который нуждается в программных средствах
для его запуска. Поэтому платформа должна обладать минимальным набором
программных интерфейсов для взаимодействия с контейнером. Также при
повышении
количества
контейнеров
платформа
должна
позволять
одновременно работать с таким количеством, предоставляя интерфейсы для
единого управления над ними. При больших объемах контейнеры также
должны оставаться независимыми, а платформа также должна отслеживать
используемые ими ресурсы предотвращая аварийные ситуации и выход их из
строя. Ключевой особенностью для платформы является способность
масштабирования, поэтому в зависимости от поступающей нагрузки
платформа автоматически должна создавать необходимое количество новых
контейнеров для удовлетворения всех запросов согласно установленного SLA,
а также прекращать их обслуживания после прохождения пика и уменьшения
спроса, тем самым помогая снизить расходы на нижележащий уровень
инфраструктуры и вычислительных ресурсов.
Все эти требования являются общими для разных платформ. В случае
платформы для приложений IoT главной архитектурой для инфраструктуры
становятся сочетание туманных и облачных вычислений. Как уже было
описано, туманные вычисления строятся с применением гетерогенных узлов,
в отличии от типового набора аппаратных средств для создания серверов в
центрах обработки данных, что накладывает ряд ограничений на запускаемые
на них приложения. Также ограниченные ресурсы и необходимость
выполнения первостепенных задач на узлах туманных вычислений требуют
правильного распределения и масштабирования для запускаемых приложений
в рамках выполнения задач для туманных вычислений. Два этих основных
требования также должны удовлетворены со стороны платформы. Первое
условие может быть выполнено как раз с применением контейнеров, одна из
базовых идей которых как раз заключается в едином выполнении вне
зависимости от хоста, на котором происходит запуск. Второе условие
35
дополняет уже обозначенную главную характеристику для программного
продукта уровня PaaS.Таким образом платформа для приложений в контексте
Интернета Вещей становится критически важным уровнем, который должен
обеспечить бесперебойную слаженную работу большого набора контейнеров
с
условием
их
масштабируемости
по
запросу
или
возникновении
определенных условий. На данный момент уже разработано множество
технологий, которые позволяют это реализовать на практике. В следующей
главе будет рассмотрено одно из таких решений на примере open-source
программного продукта Kubernetes – инструмента для управления и
оркестрации контейнерной средой разработки.
36
ГЛАВА 3 АРХИТЕКТУРНАЯ ОСНОВА СОВРЕМЕННОЙ
ПЛАТФОРМЫ
3.1 Модель системы оркестрации
Главным выводом предыдущей главы стала идея о том, что основой для
программного продукта уровня PaaS в современных условиях разработки
новых сервисов с применением контейнеризации в контексте Интернета
Вещей становится система оркестрации. В свою очередь платформа конечно
не ограничивается только этим, так как по мере развития возникает множество
смежных задач по администрированию и управлению итоговой системой.
Стоит отметить, что система оркестрации не является новым инструментом
для разворачивания приложений в облачной среде. Оркестрация [13] в
контексте контейнеризации определяет новым уровень и подходы того как
потребляются ресурсы уровня инфраструктуры.
Первая особенность, которая повлияла на современную модель
оркестрации, является новый процесс поставки данных. Перед началом
запуска приложения почти всегда возникает необходимость установки
зависимостей,
задания
определенной
конфигурации
и
приведения
виртуальной машины в нужное состояние. Первым подходом для выполнения
этого процесса была установка заданного набора библиотек с помощью
пакетного менеджера. Такой подход конечно затрачивал большое количество
времени, а также допускал риск возникновения человеческой ошибки. На
смену этому пришла концепция Infrastructure as Code. Этот подход был
основан на описании целевой конфигурации и внесении изменений с
применением разных методов доставки в зависимости от того, кто это
иницирует: целевой хост сам может запросить изменения или получить
команду от управляющего сервера. Недостатки такого подхода в основном
связаны с миграцией приложения между версиями, при которой могут
37
оставаться и неправильно применяться необходимые зависимости. Решением
этого стал переход к концепции образов, которая уже была описана в
предыдущей главе. При таком подходе все операции уже проводятся над
итоговой
файловой
системой,
которая
содержит
все
необходимые
конфигурации и зависимости.
Вторая особенность, связанной с системой оркестрации, является
изоляция. Это свойство уже упоминалось как один из важных критериев для
платформы. В традиционном подходе для этого использовались виртуальные
машины. Главным их преимуществом является безопасность, так как
происходит полная изоляция. При переходе к контейнерам возникает другой
уровень изоляции уже на уровне операционной системы при котором
изолируются группы процессов. Из-за этого возникает уязвимость на уровне
ядра операционной системы и возможность размещения разных сервисов от
пользователей
согласно
принципу
мультиарендности
становится
недопустимой. Для решения таких задач используется комбинация из
применения виртуальных машин и контейнеров, что позволяет создать
полностью
изолируемую
среду
и
дальше
использовать
со
всеми
преимуществами контейнерной эксплуатации приложений.
Изначально для выполнения набора операций для выделения набора
серверов, их конфигурации и разворачивания приложений использовались
разные системы, степень автоматизации и взаимоинтеграции между собой был
крайне мала. Система оркестрации, являясь новым подходом для в
выстраивании целого CD процесса, призвана объединить все эти подсистемы
в себе и вывести как главную сущность на первое место сам сервис. Описание
сервиса в свою очередь уже содержит необходимую информацию, которая
понадобится этим подсистемам: используемые образы, выделение сетевых
ресурсов, настройка политик доступа и так далее. Одной из таких подсистем,
важность которой возрастает в контексте распределенных облачных и
туманных вычислений, является подсистема локализации, которая отвечает за
38
выбор наилучшего узла в кластере для размещения сервиса с учетом его
возможных требований и связей с другими сервисами в этом кластере.
Итоговая модель системы оркестрации представлена на рисунке 8.
Рис.8 Модель оркестрации
Центральным элементом является состояние кластера в каждый момент
времени с описанием необходимых контейнеров, которые должны быть
запущены. Модель содержит первоначальный список всех пользователей
проектов и сервисов. Подсистемы CD отвечают за выбор хоста в кластере для
размещения сервиса, выделения ресурсов под него, выбора конфигурации с
помощью образа и сценария для разворачивания, используя данные из модели
и оперируя над состоянием кластера и внося в него изменения. Container engine
использует составленное состояние кластера и выполняет операции по
удалению и добавлению необходимых контейнеров.
39
Система оркестрации не ограничивается только лишь механикой
размещения контейнеров. Для более удобного использования и эксплуатации
сервисов
возникает
централизированного
необходимость
сбора
логов,
в
сборе
их
предоставления
метрик,
создания
пользовательского
интерфейса и так далее.
3.2 Архитектура Kubernetes
Kubernetes [14] — это крупный открытый проект и экосистема с
большим количеством кода и богатой функциональностью. Kubernetes
является платформой для оркестрации развертывания и масштабирования
контейнерных приложений и управления ими. Автор Kubernetes — компания
Google, но со временем этот проект присоединился к организации Cloud Native
Computing Foundation (CNCF) и стал явным лидером в области контейнерных
приложений.
Основная функция Kubernetes заключается в планировании рабочей
нагрузки на контейнеры в рамках вашей инфраструктуры, и это далеко не все.
Далее перечислены некоторые дополнительные возможности Kubernetes:
распространение секретной информации;
репликация узлов с приложениями;
применение автомасштабирования;
балансирование нагрузки;
мониторинг ресурсов;
доступ к журнальным файлам и их обработка;
предоставление аутентификации и авторизации.
Kubernetes не является готовым решением уровня PaaS, предоставляя
выбор для большинства важных функций платформы, которая может быть
40
создана на его основе. Kubernetes от готового решения уровня PaaS отличают
следующие характеристики:
Kubernetes не предлагает никаких встроенных служб для обмена
сообщениями, обработки данных, СУБД и т.п.
Kubernetes не имеет своего набора готовых сервисов для
размещения в один клик.
Kubernetes не размещает исходный код и не собирает приложения.
Процессы непрерывной интеграции (CI) поддерживаются, но их
реализация оставлена для других инструментов.
Аналогично для систем журналирования и мониторинга, которые
могут быть построены с независимо и по выбору пользователя.
Основная функция Kubernetes заключается в оркестрации контейнеров,
то есть планировании работы контейнеров разной степени загруженности на
физических
и
виртуальных
устройствах.
Контейнеры
должны
быть
эффективно упакованы, им необходимо соблюдать ограничения, налагаемые
средой развертывания и конфигурацией кластера. Кроме того, платформа
Kubernetes должна следить за всеми запущенными контейнерами и заменять
те из них, которые вышли из строя, перестали отвечать или испытывают какието другие сложности.
Kubernetes имеет свою собственную архитектуру представленную на
рисунке 9. Также Kubernetes определяет ряд терминов и определений в
контексте своей платформы.
Кластер — это набор компьютеров, хранилищ данных и сетевых
ресурсов, с помощью которых Kubernetes выполняет различные задачи в
вашей системе. Стоит отметить, что система может состоять из нескольких
кластеров.
41
Worker
узел
—
это
отдельный
компьютер
(физический
или
виртуальный). Его задача состоит в запуске подов. Каждый узел в Kubernetes
содержит несколько компонентов, таких как kubelet и прокси kube.
Master узел — это панель управления Kubernetes. Он состоит из
нескольких компонентов, таких как API-сервер, планировщик и диспетчер
контроллеров, и отвечает за глобальное (уровня кластера) планирование
работы подов и обработку событий. Обычно все ведущие компоненты
размещаются на едином узле, однако внутри высокодоступного или очень
большого кластера могут распределяться между несколькими узлами.
Рис.9 Архитектура Kubernetes
Kubectl – клиентский инструмент командной строки для взаимодействия
с кластером, который может быть использован для развертывания
42
приложений, проверки и управления ресурсов кластера, а также для просмотра
логов.
Под (pod) — это единица работы в Kubernetes. Каждый под содержит
один или несколько контейнеров. Поды всегда работают совместно, то есть на
одном компьютере. Все контейнеры внутри пода имеют одни и те же IP-адрес
и пространство портов, они могут общаться между собой через локальный
сервер или посредством межпроцессного взаимодействия. Кроме того, все
контейнеры имеют доступ к общему локальному хранилищу данных узла, на
котором находится под. Такое хранилище может быть подключено к каждому
контейнеру. При этом сами контейнеры не являются объектами Kubernetes и
не управляются им: Kubernetes управляет подами, но контейнеры внутри этого
пода используют общее сетевое пространство имён, включая IP адреса и
порты, и могут обращаться друг к другу через localhost. Поды обеспечивают
отличное решение для управления группами тесно связанных между собой
контейнеров,
которые
для
выполнения
своей
задачи
должны
взаимодействовать на одном и том же узле. Поды считаются фиктивными
расходными сущностями, которые при желании можно удалить или заменить.
Вместе с подом уничтожается любое хранилище данных, которое в нем
находилось. Каждый экземпляр пода получает уникальный идентификатор
(unique ID, или UID), чтобы при необходимости их можно было различить.
Таким образом всю архитектуру можно разделить на две плоскости:
управления и исполнения. Компоненты плоскости управления master узла
отвечают за основные операции кластера, а также обрабатывают события
кластера (например, задачи связанные с поддержанием заданного состояния).
Сервер API предоставляет доступ к Kubernetes REST API. Он не
обладает состоянием и хранит все данные в кластере etcd, поэтому его
несложно горизонтально масштабировать. API-сервер олицетворяет собой
панель управления Kubernetes.
43
Etcd — это высоконадежное распределенное хранилище данных.
Kubernetes хранит в нем все состояние своих кластеров. В небольших
временных кластерах etcd можно запускать в единственном экземпляре и на
одном узле с ведущими компонентами. В важных системах, требующих
избыточности и высокой доступности, etcd обычно работает в виде кластера,
состоящего из трех или даже пяти узлов. Диспетчер контроллеров Kube
представляет
собой
набор
различных
управляющих
инструментов,
упакованных в единый двоичный файл. Он содержит контроллер репликации,
pod-контроллер, контроллер сервисов, контроллер оконечных точек и т. д. Все
эти
инструменты
отслеживают
работу кластера
через
API
и
при
необходимости приводят его в нужное состояние.
Компонент scheduler занимается планированием развертывания подов
на узлах. Это крайне сложная задача, которая требует учета множества
факторов, зависящих друг от друга, например:
требований к ресурсам;
требований к сервисам;
политики аппаратных/программных ограничений;
принадлежности и непринадлежности узлов;
местонахождения данных;
При необходимости особой логики планирования, не предусмотренной
в scheduler, возможно создать собственный планировщик и запускать его
независимо или в сочетании с scheduler, чтобы он управлял лишь
определенным подмножеством подов.
Компонент control-manager объединяет в себе контроллеры запущенные
контроллеры. Существует много различных типов контроллеров. Наиболее
используемым из них является контроллер количества запущенных подов.
44
Узлам кластера необходимы определенные компоненты, с помощью
которых они взаимодействуют с ведущими узлами, а также принимают и
выполняют размещение подов, информируя кластер об их состоянии.
Прокси-сервер Kube отвечает за низкоуровневые сетевые функции на
каждом узле. Он предоставляет локальный доступ к сервисам Kubernetes. Для
поиска IP-адресов в кластере используются переменные среды или DNS.
Kubelet — это представитель Kubernetes в узле. Он отвечает за
взаимодействие с ведущими компонентами и управляет запущенными подами.
Его обязанности:
загрузка конфиденциальных данных пода с API-сервера;
подключение томов;
запуск контейнера пода;
уведомление о состоянии узла и каждого экземпляра пода;
проверка работоспособности контейнеров.
3.3 Логические компоненты Kuberenetes
Основные
архитектурные
компоненты
Kubernetes
могут
быть
представлены с помощью независимых хостов или виртуальных машин.
Остальные компоненты являются набором уровней абстракций, которые
помогают реализовать дополнительные необходимые наборы функций для
подов, добавить описание для них с помощью иерархии параметров,
организовать их совместную работу и обеспечить доступ извне.
Для
описания
компонент
в
Kubernetes
используются
конфигурационные файлы. Описание компонент происходит с помощью
языка разметки YAML. Хранение конфигураций в формате файлов имеет ряд
преимуществ, позволяя описывать параметры в более удобном виде с
45
применением разных структур данных вместо передачи их в командную
строку при применении команд пользователем. Также хранение конфигурации
в файлах делает возможным применения системы контроля версий для
удобного версионирования и совместной разработки. Пример структуры
конфигурационного файла представлен на рисунке.
Файл имеет четыре обязательных раздела. Первый раздел apiVersion
содержит значение для версии API Kubernetes. Создание разных компонент
возможно в зависимости от выбранной версии. Второй раздел kind определяет
создаваемый компонент, например под или сервис. Раздел metadata содержит
общие данные о создаваемом компоненте для его идентификации. Главный
раздел spec содержит специфичное для каждого из компонент описание в
заданном формате. Пример файла показан на рисунке 10.
Рис.10 Структура конфигурационного файла
С появлением множества объектов вместо одного приложения
возникает необходимость в назначении определенных имен для них.
Монолитное приложение после перехода в плоскость контейнеризации
подвергается разделению на множество контейнеров, а далее подов, для
работы с которыми нужно иметь идентификаторы. Механизм меток позволяет
решить эту задачу. Метки являются парами в формате «ключ-значение»,
46
которые описывают объекты Kubernetes. Пример использования меток
представлен на рисунке 11. Они формируются относительно значения для
пользователя и никак не связаны со спецификой работы Kubernetes, тем самым
давая пользователю выбор для выстраивания собственной иерархии объектов.
В дальнейшем полученный набор характеристик с помощью описанного
формата для каждого объекта может быть использован для выбора
подмножества и общего количества. Метки связаны определенными
ограничениями, и это сделано намеренно. Каждая метка объекта должна иметь
уникальный ключ, соответствующий строгому синтаксису. Он должен
состоять из двух частей — префикса и имени. Префикс необязателен и
отделяется от имени косой чертой (/). Он должен представлять собой
корректный поддомен DNS и не может содержать свыше 253 символов. Имя
обязано быть, его длина ограничена 63 символами. Имена должны начинаться
и заканчиваться алфавитно-цифровыми символами (a — z, A — Z, 0–9) и
содержать только буквы, цифры, точки, тире и подчеркивания. Значения
подчиняются тем же правилам, что и имена. Следует отметить, что метки
предназначены лишь для идентификации объектов, а для внедрения
произвольных метаданных используются аннотации.
Рис.11 Пример использования меток
47
Селекторы являются обратным компонентом, которые используют
полученные метки. Селекторы поддерживают логические операции, что
позволяет
создавать
необходимые
условия
для
получения
нужного
подмножества объектов. Полученные подход во многом напоминает запрос
данных из базы данных, при котором описываются поля, ограничения и
условия для выбора ряда записей. Селекторы могут быть использованы при
описании более сложных структур или при формировании запроса к кластеру
от пользователя через инструменты командной строки как это показано на
рисунке 12.
Рис.12 Пример использования селекторов
Связывать
произвольные
метаданные
с
объектами
позволяют
аннотации. Kubernetes всего лишь хранит аннотации и делает доступными их
метаданные. В отличие от меток они не имеют строгих ограничений
относительно допустимых символов и длины. Метаданные всегда необходимы
в сложных системах и Kubernetes предоставляют их в стандартной версии,
чтобы не приходилось проектировать собственное хранилище метаданных и
связывать его с объектами. Пример использования аннотации на рисунке 13.
48
Рис.13 Пример использования аннотации
После получения набора подов с контейнерами вместо монолитного
приложения
возникает
необходимость
настройки
корректного
взаимодействия их между ними на каждом уровне и выдаче нужных точек для
обращения к ним со стороны пользователя. Запрос может приходить на под,
содержащий
в
себе
фронтенд-приложение,
но
далее
необходимо
перенаправить его к другим подсистемам для формирования ответа. Для
выстраивания
такого
взаимодействия
внутри
и
снаружи
кластера
используются сервисы. Прежде всего сервисы необходимы для обеспечения
сетевого взаимодействия на транспортном и сетевом уровне. Типовая задача,
которую позволяет решить сервис, представлена на рисунке 14. После
создания пода с приложением в контейнере внутри на выбранном узле
необходимо получить нему доступ. Внутри узла существует собственная сеть
с другой адресацией и обращение напрямую к поду по его ip-адресу будет
некорректно. Как раз для такой цели может быть использован сервис. Данная
абстракция позволяет создать условие, которое бы перенаправляла все
запросы для комбинации «ip-адрес узла – номер порта» на нужный под.
Исходя из этого различают несколько видов сервисов:
1. NodePort
2. ClusterIp
49
3. LoadBalancer
4. Ingress
Рис.14 Процесс создания сервиса NodePort
Первый пример уже был рассмотрен. Стоит добавить, что сам сервис
внутри узла имеет свой собственный ip-адрес и порт. Таким образом
выстраивается цепочка из трех портов: узла, сервиса и целевого пода. Пример
создания описания такого сервиса представлен на рисунке 15. Для выбора
нужного пода, на который будет перенаправляться трафик, используется пара
селекторов для названия и типа приложения, которые были заданы ранее на
этапе создания пода.
Рис.15 Пример конфигурационного файла для сервиса NodePort
50
При выходе из строя одного из контейнеров Kubernetes способен
возобновить его работу, но при этом происходит потеря данных и они никак
не будут доступны в дальнейшем. Также возникают ситуации при которых
контейнеры в одном и том же поде нуждаются в одинаковом источнике
данных. Абстракция томов позволяется решить эту проблему. Kuberntes
поддерживает разные типы томов. При объявлении пода можно задать том и
путь монтирования к образу, который является основой для иерархии
файловой системы. После удаления пода Kubernetes удалит все данные,
оставив прикрепленный том без изменений, позволяя подключить его еще раз.
Пример задания тома для пода показан на рисунке 16.
Рис.16 Пример использования тома
В данном примере используется заранее созданный том при помощи
облачного сервиса Amazon Web Services Elastic Block Store.
Kubernetes также позволяет создавать виртуальные кластеры внутри
одного из созданных. Механизм пространства имен позволяет разграничить
внутри кластера между собой несколько групп подов. Такой функционал
может быть полезен для реализации ряда задач. При совместной разработке и
51
использовании единого кластера разные команды могут эксплуатировать
одинаковые ресурсы и сервисы, тем самым создавая конфликт в разных
конфигурациях. Используя пространства имен можно логически разделить
кластер на два изолированных пространства, настроить доступ и авторизацию
к ним определенных пользователей, что позволит совместно использовать
один кластер разными командами. Также с помощью отдельных окружений
можно определить лимиты для ресурсов инфраструктуру, которые будут
доступны для каждой команды. Второй сценарий использования связан с
совместным использованием ресурсов. Различные окружения, полученные
при помочи механизма пространства имен, нуждаются в одних и тех же
сервисах, например для мониторинга и логирования. Для этих целей подобные
сервисы также объединяются в группу и совместно используются другими
окружениями. При этом не возникает необходимости в дублировании такого
набора сервисов для каждого из окружений. Еще одним вариантом
использования пространства имен является поддержка blue-green deployment
– сценарий обновления рабочего окружения с минимальным временем отказа
и простоя, главной целью которого является обслуживание каждого
поступающего запроса. При этом рабочая и новая версия приложения
создаются с использованием пространства имен и находятся в разных
окружениях.
Еще одним важным компонентов Kuberntes являются контроллеры.
Поды являются изменяемыми компонентами и могут выходить из строя по
разным причинам, например из-за недостатка ресурсов, теряя при этом все
контейнеры внутри. Контроллеры предназначены для выбора подходящего
места размещения и замены вышедшего из строя пода независимо от причины.
Существует несколько типов контроллеров, но все они объединены единой
целью – поддержание заданного количества подов для выбранной группы
приложений. Первый тип контроллеров ReplicaSet регулирует количество
реплик подов. Конфигурация контроллера реплик использует шаблон для
52
создания пода и число желаемых копий. После объявления контроллера
реплик создается набор подов из шаблона. В случае несоответствия
количества подов заданному значению контроллер стремится заменить и
создать новый, тем самым привести группу подов в desired state. Контроллер
реплик описывается с помощью конфигурационного файла, используя
механизм меток и селекторов для определения группы подов, за состоянием
которой необходимо следить. Уровнем выше в иерархии Kubernetes находится
компонент Deployment. Такой тип компонент объединяет в себе абстракции
подов и ReplicaSet, позволяя оперировать ими в декларативном режиме. При
таком подходе пользователь определяет желаемое количество подов и шаблон,
применяет измененную конфигурацию, а система дальше сама производит
необходимые изменения. Такой тип компонент рекомендуется использовать
вместо ReplicSet, так как он предоставляет полный набор функций для
размещения
приложений
обладающих
высокой
доступностью
с
возможностью изменения конфигурации без прерывания работы приложения.
Другой тип контроллеров DaemonSet предназначен для запуска одного
единственного пода на каждом из рабочих узлов. Из названия данного
контроллера можно сделать вывод о ключевом назначении – запуска daemon
процессов, которые выполняются на каждом из хостов в фоновом режиме.
Главным сценарием применения такого компонента является размещения
систем мониторинга и сбора логов на кажждом из узлов. Для реализации таких
задач мог бы подойти и ReplicaSet контроллер, но этот тип контроллеров
работает с ограниченным набором подов. В случае использования DaemonSet
при добавлении и удалении узлов из кластера размещение пода будет
производится автоматически, что было бы невозможно при использовании
ReplicaSet. Третьим типом контроллеров является StatefulSet, применяемый
для stateful приложений. Для начала необходимо дать определение такому
типу приложений. Примерами таких приложений являются все базы данных
или любое другое, которое отслеживает текущее состояние для его
сохранения. Stateless приложения являются противоположностью и не
53
сохраняют состояние, воспринимая каждый запрос у нему как абсолютно
новый, основанный только на данных которые поступили вместе с ним.
Типичный сценарий предполагает использование stateless приложения как
прокси системы, которая в свою очередь обращается к stateful приложению.
Например при получении данных из базы данных с помощью HTTP запроса
он сначала проходит через API сервер, который знает лишь текущие
параметры и не хранит это состояние. Как уже было сказано для размещения
stateless приложений лучше всего подходит абстракция Deployment. Их
масштабирование
происходит
в
стандартном
режиме.
Новые
поды,
полученные при таком процессе, будут идентичными и взаимозаменяемым,
созданы или удалены в случайном порядке и объединены одним сервисом
балансировки
нагрузки.
При
использовании
StatefulSet
механизм
идентификации работает иначе чем Deployment, назначая каждому новому
экземпляру
свой
определенный
номер,
который
не
меняется
при
перепланировании подов. Это необходимо при увеличении количества подов,
так как могут возникнуть ситуации несоответствия данных, если позволить
нескольким подам читать и записывать данный. Вместо этого предлагается
выбрать один под с правами для записи и чтения, при этом все остальные
могут лишь читать данные. Поды не имеют доступа к единому физическому
хранилищу данных. Несмотря на то, что они оперируют над одними и теми же
данными, они не используют одно хранилище, а используют реплики к
которым под имеет доступ. Это означает что каждая реплика в каждый момент
времени должна содержать такие же данные как и другие. Для достижения
такого результата применяется механизм непрерывной синхронизации. Все
изменения и новые записи в данных, совершенные через главный под, должны
распространиться на остальные реплики. При обновлении конфигурационного
файла и добавлении нового пода происходит копирование данных от
предпоследней реплики и также начинает происходить непрерывная
синхронизация.
54
3.4 Выводы
Принципы
модели
оркестрации
эволюционируют
вместе
с
продуктовыми IT решениями, разработка которых поддерживается и
продвигается с помощью программных реализаций в области интеграций и
доставки
готовых
приложений.
Оркестрация,
являясь
ключевой
характеристикой для современного подхода CI/CD, сочетает в себе множество
особенностей и становится основой для развития публичных сервисов уровня
платформы для предоставления услуг большому количеству пользователей с
различными запросами на размещения своих приложений.
На данный момент можно выделить несколько особенностей, которые
повлияли на становление современного процесса оркестрации. Задачи
подготовки окружения перед размещением и запуском приложения всегда
были крайне актуальными и нуждались в удобной и автоматизированной
реализации. Первыми из таких программных решений, которые получили
большое распространение и остаются актуальными и на данный момент, были
приложения, реализующие архитектуру Infrastructure as Code. Такой подход
получил большое распространение для автоматизации работы с виртуальными
машинами в облачной среде, в том числе и для публичных облаков.
Примерами таких инструментов, сочетающих в себе декларативные и
императивные подходы для описания конфигураций, являются Terraform для
работы с уровнем инфраструктуру и Ansible для всевозможной конфигурации
полученного хоста. Условия мультиарендности в публичных облачных
окружениях накладывают ряд ограничений связанных с политиками
безопасности на использование контейнеризации, к которой стремится
современный процесс разработки приложений. Решением этого становится
использование виртуальных машин в качестве основы, что вызывает
востребованность в инструментах для работы с ними, примеры которых были
55
приведены выше. Современная система оркестрации призвана объединить в
себе множество задач, которые раньше могли выполняться распределенными
и малосвязанными системами, предоставив возможность для комплексного
управления и администрирования.
Одним их таких проектов, целью которого является реализация
вышеперечисленных принципов, является Kubernetes. На данный момент
Kubernetes является стандартом в области оркестрации контейнеров и
выступает основой для создания PaaS. Примерами платформ, основанных на
Kubernetes, являются публичное облако Google Cloud Platform и OpenShift,
который может быть выстроен на гибридном облаке. Сам Kubernetes с такими
характеристиками как отсутствие встроенных CI процессов и систем для
мониторинга не может быть полноценным решением уровня PaaS, но при этом
становится неотъемлемым компонентом для их создания.
Архитектурные особенности и требования Kubernetes позволяют
развивать его с использованием почти любой базовой инфраструктуру.
Встроенные компоненты, которые логически разделяют и позволяют работать
с архитектурными объектами системы, могут удовлетворить почти любые
требования, связанные с масштабируемостью и отказоустойчивостью
размещаемых приложений. Развивающиеся смежные проекты стремятся
дополнить Kubernetes, упрощаю работу с ним и предоставляя недостающий на
данный момент набор функций.
56
ГЛАВА 4 АНАЛИЗ ОСОБЕННОСТЕЙ ОРКЕСТРАЦИИ
ПРИЛОЖЕНИЙ ИНТЕРНЕТА ВЕЩЕЙ
4.1 Дополнительные требования к системе оркестрации
Одной из главных задач у системы оркестрации как было сказано ранее
является своевременная реакция на запросы от пользователей, выполнение
которой происходит с помощью механизмов масштабирования приложений.
Kubernetes автоматизирует управление распределенными приложениями,
состоящими из большого количества реплик, поддерживая заданное
состояние. Однако, учитывая непостоянный характер нагрузки, которая часто
меняется со временем, непросто понять, как должно выглядеть желаемое
состояние кластера. Точное определение, сколько ресурсов потребуется
контейнеру и сколько реплик службы должно быть запущено в данный момент
для выполнения соглашений об уровне обслуживания, требует времени и
усилий. Kubernetes позволяет легко изменять объем ресурсов контейнера,
число реплик службы или узлов в кластере. Такие изменения могут
происходить вручную или автоматически, в соответствии с определенными
правилами.
Kubernetes может не только следовать фиксированным настройкам
подов и кластера, но также следить за уровнем нагрузки и событиями,
связанными с изменением объемов ресурсов, анализировать текущее
состояние
и
масштабироваться
для
достижения
желаемой
производительности. Эта способность позволяет Kubernetes адаптироваться
приложения, основываясь на показателях в каждый момент времени.
Есть два основных подхода к масштабированию любых приложений:
горизонтальное и вертикальное. Под горизонтальным масштабированием в
мире Kubernetes подразумевается создание большего количества реплик пода.
57
Под вертикальным масштабированием подразумевается увеличение объема
ресурсов для контейнеров, управляемых подами. Определение конфигурации
приложений для автоматического масштабирования на общей облачной
платформе избегая влияния на другие смежные системы, чтобы не нарушить
работу других служб и самого кластера, является сложной задачей. Kubernetes
предлагает ряд средств и методов, помогающих определить настройки для
приложений в условиях автоматического масштабирования.
Вертикальное и горизонтальное масштабирование представлены в
Kubernetes как компоненты HorizontalPodAutoscaler и VerticalPodAutoscaler. В
случае создании конфигурационного файла HorizontalPodAutoscaler поле spec
имеет ряд параметров: минимальное количество реплик, максимальное
количество реплик, целевой компонент для масштабирования и метрики.
Алгоритм работы при этом следующий:
1. Извлечение
метрик
для
компонент,
которые
подлежат
масштабированию. Метрики выбираются согласно требованию и
доступны через определенное API. По умолчанию используются
метрики использования процессора и оперативной памяти.
2. Вычисление необходимого количества реплик подов на основе
текущего и целевого значения метрик. Производится оценка каждой из
метрик и выбирается наибольший результат.
3. Конечное результат вычислений – целое число, представляющее
количество желаемых реплик, которое поможет удержать измеренное
значение метрик ниже желаемого порогового значения.
Главным условием для успешного применения горизонтального
масштабирования является достаточное количество вычислительных ресурсов
на узлах при котором возможно создание необходимого количества реплик.
В условиях ограниченного количества ресурсов более подходящим
становится подход вертикального масштабирования, который позволяет
58
автоматически устанавливать значения для ресурсов, которые будут доступны
для каждого из подов. Основная цель вертикального автоматического
масштабирования – уменьшить потери ресурсов и минимизировать риск
снижения
производительности,
вызванных
различными
внутренними
ошибками (например, ошибки типа «out of memory», при которых текущее
значение оперативной памяти является недостаточным).
Составление
конфигурационного
файла
для
вертикального
масштабирования мало чем отличается от горизонтального. Единственное
значимое отличие - это поле updateMode, определяющее режим для
обновления ресурсов контейнера. Существует несколько вариантов его
значения:
1. Off – обновление ресурсных требований не происходит, вместо
этого предоставляется только рекомендация;
2. Initial – запрос ресурсов происходит только на этапе запуска
подов;
3. Recreate – обновление пода при возникновении различий между
рекомендациями и текущим значением использования ресурсов;
4. Auto – применение Auto режима без перезапуска пода, на данный
момент находится в разработке.
Как уже было сказано область Интернета Вещей в текущем состоянии
основывается на инфраструктуре, построенной с использованием не только
облачных, но и туманных вычислений, главными отличиями которых является
гетерогенность узлов и ограниченные ресурсы. Применение Kubernetes
позволяет учесть эти особенности, работая с использованием контейнеров что
позволяет абстрагироваться от особенностей рабочего узла, а также
использовать механизм вертикального масштабирования для контроля в
условиях сравнительно меньшего объема ресурсов. Требования по качеству
обслуживания в новых приложениях Интернета Вещей создают новые задачи,
59
в том числе для процесса масштабирования, который является одним из
основных для обеспечения оптимального использования ресурсов в условиях
постоянно изменяющейся нагрузки и количества запросов. Вертикальное
масштабирование во многом позволяет реализовать эти задачи, но не дает
возможности расчета потенциальной нагрузки в будущем для лучшего
планирования ресурсов и автоматизации всего процесса. С этой целью
предлагается рассмотреть возможные методы, которые могут позволить
производить прогнозирование нагрузки. В качестве математической модели
для составления прогноза предлагается рассмотреть методы машинного
обучения.
4.2 Методы машинного обучения
Машинное обучение [15] – это набор методов для анализа данных,
которые предоставляют результат на основе решения множества схожих
задач, путем выявления закономерностей с минимальным участием человека.
Возможность обработки большого массива данных при малом вовлечении
человека в процесс актуализирует применением методов машинного обучения
для решения реальных задач.
Методы машинного обучения имеют большую классификацию, в
основном разделяясь на два направления: обучение с учителем и обучение без
учителя. «Учитель» в терминах машинного обучения – это вмешательство в
процесс обработки данных. Цель машинного обучения – обработка исходных
данных, их анализ и нахождение закономерностей.
Методы обучения с учителем решают задачи классификации и
регрессии. В свою очередь для решения каждой из задач используется ряд
различных алгоритмов. К классификации относятся всевозможные задачи
60
распознавания объектов по набору признаков. Исторически этот тип задач
возник из-за появления машинного зрения, поэтому часто для классификации
употребляется синоним распознавание объектов. В классической задаче
классификации обучающая выборка 𝑋 = {𝑥𝑖 }𝑛𝑖=1 - подмножество значений для
настройки используемой модели алгоритма, характеризующаяся вектором
признаков 𝑥𝑖 = (𝑥𝑖,1 … 𝑥𝑖,𝑚 ). Для решения задачи требуется построить
алгоритм, который по вектору признаков вернул бы вектор оценок
принадлежности выбранного объекта из подмножества к каждому из классов.
Число классов может быть любое с условием, что оно будет конечным и
больше 1. Если количество классов равно 2, то классификация называется
бинарной. Примером применения классификации может быть распознавание
спам сообщений или определение диагноза в медицине. В обоих случая для
каждого из классов – итоговых групп, куда будет отнесен анализируемый
объект, существует ряд характеристик, которые описывают его. Чем больше
таких признаков, тем выше эффективность работы алгоритма. Примерами
алгоритмов для задач классификации могут быть логистическая регрессия для
решения задач бинарной классификации и алгоритм k-ближних в случае
количества классов больше двух. Методы регрессии предназначены для
прогнозирования вещественных значений. Методы такого типа оценивают
зависимую величину 𝑌, зная независимую 𝑋. Задача регрессии заключается в
нахождении функции, которая бы описывала связь между 𝑋 и 𝑌 так, чтобы для
известных значений 𝑥𝑖 предсказанные ей значения 𝑦𝑖 были верны. Примером
использования регрессии может быть прогнозирование количество обращений
в контакт-центр.
Методы обучения без учителя решают задачи кластеризации и снижения
размерности. К кластеризации относят задачи разделения объектов на группы.
При этом заранее заданные классы и характеристики групп отсутствуют и
выбранный алгоритм формирует их самостоятельно – это главное отличие от
классификации. Задачи снижения размерности связаны с необходимостью
61
уменьшения признаков для принятия решения. В условиях ограниченного
количества наблюдений увеличение признаков может негативно влиять на
алгоритмы. Например, при прогнозировании цены недвижимости существует
множество характеристик и для облегчения процесса можно уменьшить
количество признаков.
4.3 Проверка методов
Для проверки методов машинного обучения с целью прогнозирования
нагрузки, поступающей на под в узле Kubernetes, необходимо решить ряд
задач:
1. Создание тестового окружения на базе Kubernetes.
2. Размещение системы мониторинга для учета выбранной метрики,
на основе которой будет формироваться вывод о нагрузке.
3. Разработка модуля для сбора данных из системы мониторинга и их
подготовка для анализа.
4. Выбор и анализ методов машинного обучения с полученными
данными для формирования вывода и возможности их использования
для прогнозирования.
Для реализации этих задач на практике был выбран провайдер облачных
сервисов Amazon Web Services. На базе сервиса Elastic Compute Cloud был
развернут виртуальный сервер с образом операционной системы Ubuntu 20.04,
с аппаратными ресурсами 2 СPU и 2GB RAM. Для создания кластера
Kubernetes был выбран дистрибутив Minikube, позволяющий создать кластер
на одной виртуальной машине, размещая ведущий и рабочий узлы вместе. В
качестве тестового приложений был выбран образ echoserver из публичного
62
репозитория Google Containers Registry. С помощью компонент Pod и Service
был запущен контейнер и создан доступ по заданному порту при обращении
по публичному ip-адресу виртуальной машины. Запущенное приложение
отображает web-страницу с параметрами HTTP запроса и ответа на него.
Для мониторинга и сбора метрик о работе приложения был использован
Prometheus [16] - бесплатное программное обеспечение, используемое для
мониторинга событий и оповещения в контейнерных окружениях. Однако он
также
может
быть
использован
для
мониторинга
традиционной
инфраструктуры на базе виртуальных машин. Размещение Prometheus в
кластере происходит с помощью Helm – пакетного менеджера для Kubernetes.
Зачастую для создания комплексного приложения в Kubernetes одного
конфигурационного
файла,
например
с
использованием
компонента
Deployment, недостаточно, так как возникают задачи для создания доступа из
вне, выдачи прав на доступ и так далее. Все эти задачи решаются созданием
новых конфигурационных файлов, но написание, применение и их отладка
может занимать большое количество времени. Для ускорения этого процесса
и минимизации ошибок предлагается использовать готовые схемы для
размещения приложений. Helm как и другие пакетные менеджеры предлагает
API для работы в CLI, с помощью которого можно найти и установить любое
приложение из общего репозитория.
Последующий анализ предполагает наличие структурированного
набора данных. Для этого необходимо собрать метрику и записать ее в
табличном виде. В качестве метрики нагрузки на приложение было выбрано
значение потребления ресурсов центрального процесса. Для сбора и
подготовки данных в виде CSV таблицы был написан скрипт на языке Python,
использующий REST API системы Prometheus для получения данных и
формирующий таблицу с полями временной отметки и значением метрики.
Для дальнейшего анализа данных используются Python библиотеки Pandas и
NumPy для работы с большим массивом данных, Statsmodels и Sklearn для
63
статистического анализа и создания моделей машинного обучения, Matplotlib
для создания графиков, а также Jupyter Notebook в качестве окружения для
написания отчета.
Начальные данные представляют из себя временной ряд, то есть пары
значений времени и потребления CPU, измеренные через постоянный
промежуток времени для выбранного pod. Перед применением моделей
машинного обучения необходимо произвести статистическую проверка
массива
данных
на
стационарность
[17].
Нестационарные
данные
непредсказуемы и не могут быть смоделированы или спрогнозированы из-за
изменения математического ожидания и дисперсии с течением времени.
Чтобы получить надежные результаты, их следует прежде всего преобразовать
в
стационарные
статистический
данные
анализ.
и
Для
только
потом
проверки
выполнять
стационарности
дальнейший
используется
расширенные тест Дики Фуллера. Стандартный тест Дики Фуллера
представляет из себя проверку нулевой гипотезы о не стационарности ряда
против альтернативной гипотезы о его стационарности. Суть этого метода
заключается в поиске единичных корней. Временной ряд имеет единичные
корни если его первые разности образуют стационарный ряд. Проверку
наличия единичных корней производят с помощью авторегрессионного
уравнения. Авторегрессионная модель связывает значения временного ряда в
данный момент времени со значения в предыдущий момент с помощью
линейной функции:
𝑝
𝑋𝑡 = 𝑐 + ∑ 𝑎𝑖 ∙ 𝑋𝑡−𝑖 + 𝑒𝑡
𝑖=1
где 𝑎𝑖…𝑎𝑝 – параметры модели, p – порядок, c – константа, e – белый шум.
Для первого порядка авторегрессионной уравнение (2) будет выглядеть
следующим образом:
𝑦𝑡 = a ∙ 𝑦𝑡−1 + 𝑒𝑡 (2)
64
Если a = 1, то процесс имеет единичный корень, в этом случае ряд 𝑦𝑡 не
стационарен. Приведенное авторегрессионное уравнение (5) первого порядка
можно представить следующим образом:
Δ𝑦𝑡 = b ∙ 𝑦𝑡−1 + 𝑒𝑡 (3)
b = a − 1 (4)
Δ𝑦𝑡 = 𝑦𝑡 − 𝑦𝑡−1 (5)
Поэтому проверка гипотезы о единичном корне в данном представлении
означает проверку нулевой гипотезы о равенстве нулю коэффициента b, а
альтернативной гипотезой является гипотеза о том, что коэффициент b меньше
нуля. Статистика теста (DF-статистика) — это обычная t-статистика для
проверки
значимости
коэффициентов
линейной
регрессии.
Однако,
распределение данной статистики отличается. Распределение DF-статистики
выражается через винеровский процесс и называется распределением Дики —
Фуллера. Расширенный тест Дики Фуллера предполагает использование
авторегрессионной модели более высокого порядка. Для полученного набора
данных с помощью метода из библиотеки Python Statsmodel был произведен
расширенный
тест
Дикки-Фуллера,
результат
которого
показал
стационарность временного ряда.
Прогнозирование полученного набора данных возможно с помощью
алгоритмов регрессии, где независимая переменная это отметка времени, а
зависимая переменная это значение потребления CPU в этот момент. В
качестве основного алгоритма будет использоваться дерево принятия
решения.
Зачастую в статистике для уменьшения влияния случайных изменений
предлагается усреднение результатов нескольких наблюдений и получение в
результате более надежной оценки. Эта идея используется в создании
ансамблей алгоритмов машинного обучения – объединении слабых моделей и
их комбинирование с помощью усреднения для получения лучшего
65
результата. Примером слабой модели может служить дерево принятий
решений, которые часто используются в агрегирующих алгоритмах. Дерево
принятия решений – модель со структурой из ребер и узлов, целью которой
является прогнозирование целевой переменной на основе нескольких
переменных на входе. Ветки содержат условия из набора входных
переменных, а узлы целевую переменную в зависимости от выбранного
критерия.
Дерево принятия решений для задач регрессии строится на основе
последовательного деления набора значений Y по условию переменной X с
целью минимизации суммарного значения сумм квадратов ошибок (6) (RSS –
root sum square (7)). Если имеется набор пар значений переменных
𝑥1,2,3…𝑛 𝑦1,2,3…𝑛 , то условие для деления и составления первой пары узлов будет
следующим:
min(𝑅𝑆𝑆1 + 𝑅𝑆𝑆2) (6)
RSS1 = ∑𝑖1(𝑦𝑖 − 𝜇1 )2 ; RSS1 = ∑𝑛𝑖+1(𝑦𝑛 − 𝜇2 )2 (7)
При этом 𝜇 для каждого из уравнений является средним значением выбранных
𝑦 (8), то есть прогнозирование происходит по среднему значению:
𝜇1 =
∑𝑖1 𝑦𝑖
𝑖
; 𝜇2 =
∑𝑛
𝑖+1 𝑦𝑛
𝑛−𝑖
(8)
То есть задача построения дерева сводится к выбору оптимальных наборов 𝑌
для деления согласно условию о минимальной сумме сумм квадратов ошибок.
После принятия решения о делении можно определить 𝑥𝑡 из набора 𝑋, по
которому были сделаны выборки: больше этого значения – узел 1, меньше – 2
и так далее. Деление происходит до момента получения единичных значений
𝑌 в узлах. Для составления прогноза 𝑌 новых значения 𝑋 с использование
полученного дерева необходимо последовательно брать значение из набора 𝑋
и определять дальнейший узел по условию 𝑥𝑡 пока не будет получен 𝑌 в
66
оконечном узле. Для исследования были выбраны три алгоритма для решения
задач регрессии: случайный лес, градиентный бустинг и стекинг. В общем
виде эти алгоритмы можно представить из трех этапов: формирование набора
данных, использование алгоритма и обработка результата. Разные способы
исполнения каждого из этих этапов отличают между собой выбранные
алгоритмы. Общим для них является использование алгоритма дерева
принятия решения. Случайный лес является примером использования
бэггинга (bagging – bootstrap agregation): на первом этапе из исходного набора
данных формируются разные наборы данных (bootstrap выборки), которые
далее параллельно используются в алгоритмах, а обработка результата
происходит усреднением полученных значений от каждого алгоритма. Метод
бустинга
последовательно
выстраивает
этапы
формировния
данных,
использования алгоритма и обработки результата, каждый раз повторяя этот
цикл с результатом от предыдущего, уделяя внимание случаям в которых была
допущена ошибка. Метод стекинга предполагает наличие одинаковых наборов
данных на входе, а алгоритмы используются разные, имея один решающий
алгоритм для обработки результатов.
Все алгоритмы для обучения были получены из библиотеки Python
Sklearn. Данные предварительно были разделены на обучающую и тестовую
выборку в отношении 80/20. Первая выборка используется для обучения
алгоритма, а тестовая для проверки и дальнейшей оценки алгоритма. В
результате были получены графики, показывающие зависимость уровня
использования CPU для под в кластере Kubernetes от времени для реальных и
спрогнозированных
данных.
Графики
для
результатов
применения
алгоритмов случайного леса, градиентного бустинга и стекинга регрессии
представлены на рисунках 4, 5 и 6 соответственно.
67
Рис.17 Графики зависимости реальных и спрогнозированных значений
потребления CPU для алгоритма случайного леса
Рис.18 Графики зависимости реальных и спрогнозированных значений
потребления CPU для алгоритма градиентного бустинга
Рис.19 Графики зависимости реальных и спрогнозированных значений
потребления CPU для алгоритма стекинга
68
Для оценки качества полученных результатов алгоритма используется
коэффициент детерминации. Эта метрика принимает значения от 0 до 1 и
показывает, насколько полученный прогноз отражает целевую переменную.
Если модель делает максимально точный прогноз, то значение коэффициента
детерминации будет равно 1. Формула для коэффициента детерминации (9)
выглядит следующим образом:
2
𝑅 =1−
∗ 2
∑𝑛
𝑖=1(𝑦𝑖 − 𝑦𝑖 )
+ 2 (9)
∑𝑛
𝑖=1(𝑦𝑖 − 𝑦𝑖 )
(𝑦𝑖 − 𝑦𝑖∗ )2 – сумма квадратичной ошибки
(𝑦𝑖 − 𝑦𝑖+ )2 – разница между значением и средним
Результаты
оценки
качества
алгоритмов
с
помощью
коэффициента
детерминации представлены в таблице 1.
Таблица 1
Случайный лес
Значение
0.856806
Градиентный
Стекинг
бустинг
регрессии
0.691057
0.896197
коэффициента
детерминации
На основе полученных результатов можно сделать вывод о
преимуществе
алгоритма
стекинга
регрессии
для
решения
задачи
прогнозирования временного ряда данных об использовании ресурсов CPU
под внутри кластера Kubernetes.
69
4.4 Анализ полученной системы
После рассмотрения методов машинного обучения можно сделать
вывод о возможности их применения для прогнозирования нагрузки и
потенциальных показателей потребления ресурсов у подов. В текущем
состоянии представляется возможным создать под с контейнером, который
будет построен на образе с реализованным выше приложением. Такая
реализация позволит в ручном режиме отслеживать потенциальное значение
потребления ресурсов и принимать решение о конфигурации ресурсов
размещения приложений. При увеличении количества приложений в кластере
для поддержки такой подход становится крайне неэффективным и
подверженным появлению случайной ошибке со стороны эксплуатации. Для
устранения этой проблемы необходимо решить ряд задач, которые обеспечат
автоматизацию описанного процесса.
Описание необходимых шагов и действий в предлагаемом алгоритме
необходимо начать с определения цели, которую можно сформулировать
следующим образом – последовательное периодическое отслеживание
выбранных ресурсов, анализ их метрик потребления вычислительных
ресурсов и обновление соответствующих свойств в конфигурационном файле.
Исходя из этого первой задачей является создание процесса постоянного
отслеживания появления новых ресурсов.
В предыдущей главе были рассмотрены основные компоненты
архитектуры системы Kubernetes. Одним из главных среди большого
количества абстракций является контроллер компонентов. Контроллеры в
системе Kubernetes осуществляют одни из самых важных функций по
приведению всего кластера в «desired state». Контроллеры постоянно
проверяют определенные ресурсы и применяют ряд действий, если текущее
состояние не совпадает с желаемым. Отслеживание изменений контроллерами
70
происходит
посредством
API
сервера.
Например,
при
обновлении
конфигурационного файла для Deployment ресурса с новым параметром
реплик пода происходит создание нового запроса к API серверу Kubernetes. В
ответ на это API сервер публикует эти изменения всем подписчикам, которые
отслеживают подобные изменения. Deployment контроллер, получив это
уведомление инициализирует создание новых подов для соответствия
заданным настройкам. Все изменения происходят в декларативном стиле,
оставляя
программную
реализацию
процесса
полностью
в
области
контроллеров. Несмотря на то, что стандартного набора контроллеров в
большинстве случаев полностью хватает для реализации всех нужд при
размещении приложений, Kubernetes позволяет расширить существующий
набор контроллеров [18] без внесения изменений в исходный код. Проект
Kubernetes написан с использованием языка программирования Go и имеет
готовый набор библиотек для интеграции с API и быстрой разработки новых
дополнений. С момента появления возможности создания пользовательских
расширений, контроллеры получили ряд изменений и на данный момент могут
быть классифицированы на две группы: пользовательские контроллеры и
операторы. Пользовательские контроллеры работают с нативным ресурсами
Kubernetes, такими как Deployment и Pod. Операторы напротив вместо
использования
стандартных
ресуров
создаются
для
работы
с
пользовательскими ресурсами и используются для решения комплексных
задач. Для решения задачи отслеживания появления новых ресурсов
необходимо создать пользовательский контроллер, так как оперировать он
будет над новыми ресурсами Deployment или Pod. Библиотека сlient-go
содержит ряд пакетов для базового создания контроллера, оставляя на
разработчике только реализацию пользовательского запроса.
Весь процесс разделен на пользовательскую и нативную часть,
выполняемую средствами пакетов библиотеки client-go. Нативная часть
контроллера является общей для всех и состоит из нескольких компонент:
71
информер
и
индексер.
Информер
наблюдает
за
API
сервером
и
определенными типами ресурсов. Это может быть встроенный ресурс
Kubernetes или пользовательский, созданный отдельно. Когда информер
получает уведомление от API об отслеживаемом ресурсе он добавляет его, а
также событие (создание, обновление, удаление), в рамках которого
обрабатывается объект ресурса, в очередь. В данном случае контроллер будет
отслеживать
только
добавление
и
обновление.
Полученный
объект
сохраняется в индексере и передается в обработчик событий со стороны
пользовательской части контроллера. Ключ полученного объекта сохраняется
в очереди. Пользовательский контроллер забирает ключ из очереди и передает
его главному обработчику, который обращается к индексеру по ключу объекта
за его свойствами и реализует необходимую логику нового контроллера.
Диаграмма описанного процесса представлена на рисунке 20.
Рис.20 Диаграмма классов контроллера
72
Обработчик
пользовательского
контроллера
должен
выполнить
несколько действий перед обновлением конфигурационного файла ресурса.
Для начала необходимо получить накопленные метрики для ресурса. Это
может быть обеспечено сторонними средствами для мониторинга как
Prometheus или встроенной компонентой Kubernetes Metric, которая
используется ресурсами Horizontal и Vertical Pod Autoscaling. Для запуска
анализа полученного набора данных может быть использован ресурс Job. Job
создает один или больше подов, выполняя в них определенный набор действий
пока не будет получен желаемый результат. После выполнения этого условия
все поды будут удалены. Такой вариант подходит для создания временного
пода на базе образа Python с необходимы библиотеками, используемыми при
создании прогноза значения метрики. Важным при этом является период с
которого начинает анализироваться метрики, то есть промежуток времени
после которого имеется достаточное количество показаний выбранной
метрики для использования в прогнозировании. Недостаток показаний
метрики может значительно снизить качество предлагаемого прогноза. После
получения прогноза необходимо изменить конфигурационный файл ресурса,
в котором описаны новые значения для ресурсов, а VerticalPodAutoscaler
отследит изменение и перезапустит под. Также важно выбрать частоту с
которой будет происходить прогнозирование и обновление, так как слишком
частые изменения могут создать значительную нагрузку на кластер. Итоговая
схема всего процесса представлен на рисунке 21. Стоит отметить, что
предложенный процесс производит создание нового ресурса Job, который на
схеме обозначен отдельным подпроцессом. Как и все ресурсы Kubernetes
создание происходит с использованием планировщика и хранилища данных
etcd. При получении запроса на создание Job происходит назначение рабочего
узла для пода, создание контейнера и обновление состояния кластера.
73
Рис.21 MSC диаграмма процесса обновления ресурсов
Вертикальное
масштабирование
на
данный
момент
является
относительно новым функционалом и сейчас активно развивается в рамках
разработки
новых
версий
Kubernetes.
Составление
рекомендаций
и
обновление ресурсов в автоматическом режиме происходит на основе
показаний метрик в каждый момент времени. При постоянно изменяющейся
нагрузке
количество
запросов
на
обновление
ресурсов
возрастает.
Составление прогноза позволяет выбрать оптимальный объем ресурсов на
определенный период времени и избежать лишнего обновления подов на узлах
Kubernetes.
74
4.5 Выводы
Kubernetes имеет большой потенциал для применения в области
Интернета Вещей. Механизмы оркестрации позволяют отвечать запросам
пользователей и динамически управляют состоянием кластера. Kubernetes
постоянно сравнивает текущее состояние кластера с заданной конфигурацией
и приводит его к желаемому состоянию. Два главных механизма
масштабирования в системе Kubernetes позволяют реализовать эти принципы
в условиях изменяющейся нагрузки. Для облачных вычислений, где объем
ресурсов может быть увеличен в любое время за счет дополнительных хостов
и виртуальных машин, Kubernetes предлагает масштабирование приложений
путем увеличения подов. Для узлов туманных вычислений, на которых
базируются
современные приложения
масштабирования
не
подходит
Интернета
из-за
Вещей,
такой
тип
ограниченности
узлов
по
вычислительным ресурсам, которые в первую очередь решают свои основные
задачи, связанные, например, с обслуживанием мобильной сети, и только
потом дают возможность размещения приложений. В таких условиях
предлагается использование другого типа масштабирования, когда для пода
может быть выделено дополнительный объем CPU и RAM.
Вертикальное масштабирование позволяет анализировать текущее
потребление ресурсов для пода, составлять рекомендации и автоматически
производить обновление. Для более эффективного использования такого типа
масштабирования предлагается применение методов прогнозирования и
получение значений нагрузки, которые могут улучшить алгоритм обновления
подов. В качестве алгоритмов были рассмотрены методы машинного
обучения. Выбранные методы машинного обучения с учителем для решения
задач регрессии позволяют успешно спрогнозировать временной ряд для
потребления ресурсов CPU.
75
В целях улучшения процесса вертикального масштабирования было
предложено добавление нового контроллера. Kubernetes позволяет расширить
стандартные возможности с помощью добавления новых типов ресурсов и
контроллеров. Kubernetes предлагает готовый набор библиотек для создания
контроллеров, что позволяет упростить процесс их разработки и внедрения в
итоговую систему. Полученная структура контроллера с описанным
процессом обновления подов при вертикальном масштабировании позволяет
сделать
процесс
обновления
подов
более
эффективным.
Главное
преимущество по сравнению с существующим подходом, когда производится
оценка потребления ресурсов и составление рекомендаций в каждый момент
времени независимо, заключается в прогнозировании значений, на основе
которых
выделение
необходимых
превентивно.
76
ресурсов
будет
осуществляться
ЗАКЛЮЧЕНИЕ
Разработка платформы для Интернета Вещей на данный момент
является крайне актуальной темой анализа на фоне развивающихся областей
инфокоммуникаций, на стыке которых происходит ее создание. Изменение
подходов к созданию платформы происходит на фоне развития технологий
Интернета Вещей и процессов разработки приложений. Определение
направлений в этих областях позволяет описать структуру платформы и
задачи, которые она должна решать.
Описание задач, которые должны решаться на уровне платформы,
можно составить с помощью модели доставки облачных услуг «as a service».
Согласно данной модели платформа является промежуточным уровнем,
связывая инфраструктуру и уровень приложений. К основным задачам
платформы можно отнести выделение аппаратных ресурсов инфраструктуры,
предоставление средств для администрирования и управления ими,
выстраиване CI/CD процессов для приложений и организацию процесса
оркестрации.
Современные решения в области Интернета Вещей создаются с
применением топологий на базе туманных вычислений с использованием
сетевых устройств вне центра обработки данных для обработки для обработки
данных ближе к пользователю. Повышения спроса и необходимость в
поддержке заданных параметров качества повышает востребованность такого
подхода для обработки данных от оконечных устройств. Особенности сетевых
устройств в свою очередь создают задачи для приложений, способа их
доставки и размещения на узлах туманных вычислений.
Развитие практик разработки приложений привело к получению
микросервисной архитектуры, основные принципы которой выстроены вокруг
идеи декомпозиции приложения на отдельные малосвязанные компоненты с
77
целью более эффективной и быстрой разработки нового функционала.
Технологии контейнеризации позволяют реализовать эти принципы и
становятся стандартом для доставки новых разрабатываемых приложений,
позволяя снизить требования к вычислительным ресурсам и обеспечить
независимость при исполнении на разных устройствах.
В качестве основы для создания платформы может быть использован
Kubernetes, который позволяет управлять процессами доставки приложений в
рамках распределенной инфраструктуры с использованием контейнеризации.
Kubernetes предоставляет большой набор готовых компонент для размещения
приложений
балансировки
с
помощью
нагрузки
контейнеров
и
с
применением
масштабирования
механизмов
приложений.
Задачи
масштабирования в условиях ограниченных ресурсов на узлах туманных
вычислений становятся крайне актуальными. Встроенные механизмы
позволяют успешно осуществлять масштабирование с использованием
облачной инфраструктуры, но при переходе к туманным вычислениям на
данный момент присутствует ряд нерешенных задач.
В данной работе был произведен анализ текущего состояния в областях
разработки новых решений на базе Интернета Вещей и современных
архитектур программного обеспечения, рассмотрены компоненты и цели для
применения приложений уровня платформы, технологические основы
платформы на примере продукта с открытым исходным кодом Kubernetes. В
результате был получен ряд специфичных для платформы задач при
управлении приложениями Интернета Вещей. В качестве решения были
применены методы машинного обучения и получены сравнительные оценки
для каждого из них, а также описан сценарий их внедрения для оптимизации
задач масштабирования приложений на базе туманных вычислений.
78
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Jan Holler, From Machine-to-Machine to the Internet of Things:
Introduction to a New Age of Intelligence - Elsevier Ltd, 2014. - 331 p.
2. Обзор интернета вещей. Рекомендация МСЭ-T Y.2060 [Электронный
ресурс]. – С. 1. – Режим доступа: https://www.itu.int/rec/T-REC-Y.2060201206-I. – Дата доступа: 29.03.2021.
3. Mahmoud Elkhodr, Seyed Shahrestani, Hon Cheung, Internet of Things
Applications: Current and Future Development, 2016. Innovative Research
and Applications in Next-Generation High Performance Computing
pp.397-427.
4. Marco Lombardi, Francesco Pascale, Domenico Santaniello Internet of
Things: A General Overview between Architectures, Protocols and
Applications - MDPI, 2020. – 20 p.
5. Larry Coyne, Joe Dain, Eric Forestierm, IBM Private, Public, and Hybrid
Cloud Storage Solutions - Packt Publishing, 2018. – 186 p.
6. Ashkan Yousefpour, Caleb Fung, Tam Nguyenc // Journal of Systems
Architecture. - 2019. - №5. - pp.289-330.
7. Kris Jamsa, Cloud Computing SaaS, PaaS, IaaS, Virtualization, Business
Models, Mobile, Security and More - Jones & Bartlett Learning, 2012. 324 p.
8. Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, Mike Amundsen,
Microservice Architecture Aligning Principles, Practices, and Culture O'Reilly Media, 2016. - 146 p.
9. Richard Bullington, McGuire, Andrew K. Dennis, Michael Schwartz
Docker for Developers - Packt Publishing, 2020. - 468 p.
79
10. Raghu Bharadwaj Mastering Linux Kernel Development - Packt
Publishing, 2017. - 354 p.
11. James Turnbull, The Docker Book - James Turnbull, 2014. - 386 p.
12. Onur Yilmaz, Cloud-Native Continuous Integration and Delivery - Packt
Publishing, 2018. - 148 c.
13. Randall Smith, Docker Orchestration - Packt Publishing, 2017. - 284 p.
14. Сайфан Джиджи, Осваиваем Kubernetes. Оркестрация контейнерных
архитектур, "Издательский дом ""Питер""", 2018. 400 c.
15. Бринк Х., Ричардс Дж., Феверолф М.. Машинное обучение. СПб.:
Питер, 2017. 336 с.
16. Brian Brazil Prometheus: Up & Running: Infrastructure and Application
Performance Monitoring - O’Reilly Media Inc., 2018. - 369 p.
17. Элбон К. Машинное обучение с использованием Python. СПб.: БХВПетербург, 2020. 384 c.
18. Bilgin Ibryam, Roland Hub Kubernetes Patterns - O'Reilly Media, 2019.
- 266 p.
80
