Изд. № 29

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

Взаимосвязь между контейнерами, модулями и узлами наглядно представлена на рисунке 13. Каждый модуль имеет свой собственный IP-адрес и содержит один или несколько контейнеров, каждый из которых запускает приложение.

Рисунок 13 - Взаимосвязь между контейнерами, модулями и физическими рабочими узлами

3.3. Запуск приложения в Kubernetes

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

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

30

Как описание приводит к запуску контейнера

Когда сервер API обрабатывает описание приложения, планировщик назначает указанные группы контейнеров доступным рабочим узлам, исходя из вычислительных ресурсов, требуемых каждой группой, и нераспределенных ресурсов на каждом узле в данный момент. Агент Kubelet на этих узлах затем поручает среде выполнения контейнеров (например, Docker) извлечь из хранилища требуемые образы контейнеров и запустить контейнеры.

Развёртывание приложений в Kubernetes показано на рисунке 14. В описании приложения перечислены четыре контейнера, сгруппированных в три набора. Эти наборы называются модулями (подами). Первые два модуля содержат всего один контейнер, тогда как последний содержит два. Это означает, что оба контейнера должны работать совместно и не должны быть изолированы друг от друга. Рядом с каждым модулем также вы увидите число, представляющее количество реплик каждого модуля, которые должны выполняться параллельно. После отправки дескриптора в Kubernetes он запланирует использование указанного количества реплик каждого модуля на доступных рабочих узлах. Затем агенты Kubelet на узлах поручают Docker извлечь образы контейнеров из реестра образов и запустить контейнеры.

Рисунок 14 - Базовый вид архитектуры Kubernetes и приложения, работающего поверх нее

31

Обеспечение бесперебойной работы контейнеров

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

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

Масштабирование количества копий

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

Системе Kubernetes может потребоваться перемещать контейнеры пользователя по кластеру. Это может произойти, если узел, на котором они выполнялись, аварийно завершил свою работу либо они были вытеснены из узла, чтобы освободить место для других контейнеров. Если контейнер предоставляет службу внешним клиентам или другим контейнерам, работающим в кластере, то каким образом они могут правильно использовать контейнер, если он постоянно перемещается по кластеру? И как клиенты могут подключаться к контейнерам, предоставляющим службу, когда эти контейнеры реплицированы и разбросаны по всему кластеру?

Для того чтобы клиенты могли легко находить контейнеры, обеспечивающие определённую службу, можно сообщить Kubernetes, какие контейнеры предоставляют одну и ту же службу, и Kubernetes обеспечит доступ ко всем контейнерам по единому статическому IP-адресу и предоставит доступ к этому адресу всем приложениям, работающим в кластере. Это делается через переменные среды, но клиенты могут также

32

обращаться к IP-службам через старый добрый DNS. Прокси-сервер kube, kube-proxy, будет обеспечивать балансировку нагрузки подключений к службе во всех контейнерах, предоставляющих службу. IP-адрес службы остаётся постоянным, поэтому клиенты всегда могут подключаться к ее контейнерам, даже если они перемещаются по кластеру.

3.4. Преимущества использования Kubernetes

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

Упрощение развертывания приложений

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

По сути, все узлы теперь представляют собой единую группу вычислительных ресурсов, которые ждут, когда приложения будут их потреблять. Разработчик обычно не заботится о том, на каком сервере работает приложение, если сервер может предоставить приложению достаточный объём системных ресурсов.

Существуют случаи, когда разработчик заботится о том, на каком оборудовании должно работать приложение. Если узлы неоднородны, то бывают случаи, когда требуется, чтобы некоторые приложения запускались на узлах с определёнными возможностями и запускали другие приложения на других. Например, одно из ваших приложений может потребовать запуска в системе с твердотельными накопителями (SSD) вместо жёстких дисков, в то время как другие приложения отлично работают на жёстких дисках. В таких случаях, очевидно, что разработчик захочет убедиться, что конкретное приложение всегда запланировано на узле с SSD.

Без использования Kubernetes системный администратор выберет один конкретный узел с SSD и развернёт там приложение. Но при использовании Kubernetes вместо выбора конкретного узла, на котором должно выполняться приложение, уместнее поручить Kubernetes выбирать только узлы с SSD.

33

Повышение эффективности задействования оборудования

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

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

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

Проверка «здоровья и самолечение»

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

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

Если инфраструктура имеет достаточно свободных ресурсов, чтобы позволить нормальную работу системы даже без вышедшего из строя узла,

34

системным администраторам и не нужно реагировать на аварийный сбой сразу же, например в 3 часа ночи, они могут спать спокойно и разбираться с вышедшим из строя узлом в обычные рабочие часы.

Автоматическое масштабирование

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

Если Kubernetes работает в облачной инфраструктуре, где добавлять дополнительные узлы так же просто, как запрашивать их через API поставщика облачных услуг, Kubernetes даже может автоматически масштабировать размер всего кластера вверх или вниз в зависимости от потребностей развёрнутых приложений.

Упрощение разработки приложений

Функции, описанные в предыдущем разделе, в основном приносят пользу системным администраторам. Но как насчет разработчиков?

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

Далее следует упомянуть тот факт, что разработчикам не нужно реализовывать функционал, которым они обычно занимались. Он включает обнаружение служб и/или узлов в кластеризованном приложении. Kubernetes делает это вместо приложения. Как правило, приложение должно только отыскивать определённые переменные среды или выполнять поиск в DNS. Если этого недостаточно, приложение может запросить сервер API Kubernetes напрямую, чтобы получить эту и/или другую информацию. Подобного рода запрос сервера API Kubernetes может даже сэкономить усилия разработчиков по необходимой реализации сложных механизмов, таких как выбор лидера.

35

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

На основании изложенного выше можно сделать следующие выводы.

1.Монолитные приложения проще развертывать, но сложнее поддерживать с течением времени, а иногда и невозможно масштабировать.

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

3.Контейнеры Linux предоставляют те же преимущества, что и виртуальные машины, но гораздо облегчённее и обеспечивают лучшую степень задействованности оборудования.

4.Платформа Docker улучшила существующие контейнерные технологии Linux, позволив упростить и ускорить создание контейнеризированных приложений вместе с окружением их операционных систем.

5.Система Kubernetes обеспечивает доступ ко всему дата-центру как к единому вычислительному ресурсу для запуска приложений.

6.Разработчики могут развёртывать приложения с помощью Kubernetes без помощи системных администраторов.

7.Администраторы знают, что система Kubernetes отслеживает узлы, аварийно завершившие свою работу, и автоматически переносит компоненты приложения на другие узлы.

Контрольные вопросы к разделу 3

1. Что такое Kubernetes?

2.Какая архитектура кластера Kubernetes?

3.Что такое плоскость управления?

4.Что такое рабочие узлы, в чем различие с мастер узлом?

5.Что такое модуль (pod)?

6.В чем заключается преимущество Kubernetes?

7.Сколько можно запускать контейнеров на модуле (pod)?

8.Какими сервисами обладают узлы Kubernetes?

9.Где применяется Kubernetes?

36

4. Российские решения на базе технологии контейнеризации

4.1. Назначение цифровой программной платформы «СинтезМ»

Рассмотрим применение технологий контейнеризации на примере разработки цифровой программной платформы «СинтезМ» (далее - ЦПП) российской компании АО «Финтех» [2].

Основным назначением программной платформы «СинтезМ» является ее применение при построении территориально-распределенных автоматизированных систем в защищенном исполнении (далее – АСЗИ) в соответствии с требованиями нормативной базы ФСБ России, ФСТЭК России (в т.ч. приказ ФСТЭК России № 31, профилям защиты операционных систем и т.д.).

В состав платформы входят компоненты, обеспечивающие выполнение всех функций, необходимых для построения, функционирования и эксплуатации АСЗИ, в т.ч. для создания мультисервисной системы специальной связи:

-защищенная серверная операционная система «СинтезМ» с сертифицированной средой виртуализации, обеспечивающая построение защищенных отказоустойчивых центров обработки данных (ЦОД), а также применение гостевых операционных систем в т.ч. с унаследованным специальным программным обеспечением (функционирующим в среде ОС

Windows, Linux-Centos, Linux-RedHat, Linux-Debian и др.);

-программные средства защиты информации (далее – ПСЗИ), обеспечивающие построение АСЗИ как многопользовательских систем с разными правами доступа (требования по классу защищенности – не менее 1Г, а также требованиям приказа ФСТЭК России № 31);

-интегрированные средства управления АСЗИ, обеспечивающие: сбор, обработку данных мониторинга состояния АСЗИ (технические и программные средства, виртуальная среда, комплексы средств автоматизации и АСЗИ в целом); обеспечение безопасности информации; подготовку и управления конфигурацией системы и ее отдельных частей; управление средой виртуализации в высоконагруженных ЦОД; управление режимами работы системы; резервное копирование образов виртуальных машин, дампов баз данных и файловых хранилищ;

-средства ведения территориально-распределенных репозиториев эталонных дистрибутивов программного обеспечения (входят в состав ПСЗИ

«СинтезМ»), функционирующего в среде ОС Linux и Windows с целью

37

обеспечения версионности программного обеспечения АСЗИ, управления дистрибутивами при создании новых виртуальных машин, физических серверов и рабочих станций, а также обновления программного обеспечения с учетом требований по разграничению прав доступа (включая необслуживаемые территориально-распределенные программно-аппаратные комплексы);

-средства ведение реестров сервисов в территориальнораспределенных системах с обеспечением управления доступом к этим сервисам различных пользователей, а также доступ к сервисам в высоконагруженном, отказоустойчивом режиме работы;

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

Платформа «СинтезМ» сертифицирована по требованиям ФСБ России и предназначена для построения АСЗИ с обработкой информации, содержащей государственную тайну.

В настоящее время на отечественном рынке отсутствует платформа с аналогичными возможностями, включая доверенную среду виртуализации, программные средства защиты информации, интегрированные средства управления, а также состав функциональных сервисов. Имеющиеся аналоги платформы (ОС Astra Linux, “Циркон-36С” и ряд других) существенно уступают платформе «СинтезМ» по характеристикам операционной системы, по возможностям среды виртуализации и не содержат в себе требуемый состав компонентов, обеспечивающий построение, масштабирование и эксплуатацию отказоустойчивых, высоконагруженных ЦОД и в целом территориально-распределенных АСЗИ.

Применение платформы «CинтезМ» при построении территориальнораспределенных АСЗИ в интересах органов государственной власти и ФСО России обеспечивает возможность поэтапного их развития, масштабирования и расширения возможностей посредством наращивания группировки технических средств (серверов, сетевого оборудования, узлов систем хранения данных и резервного копирования) и программного обеспечения без выведения УМСС из эксплуатации и без необходимости организации дорогостоящих НИОКР по их модернизации и дальнейшей дополнительной аттестации.

38

Платформа «CинтезМ» обеспечивает адекватную замену среды виртуализации VMware, Hyper-V, а также программных средств интеграции и управления этими средами (например, IBM Tivoli для VMWare), что подтверждается результатами нагрузочных испытаний, проведенных ОАО «РЖД» и ООО «РТ-Инвест Транспортные системы».

4.2. Состав цифровой программной платформы «СинтезМ»

Как отмечалось выше, программная платформа «СинтезМ» предназначена для построения защищенных центров обработки данных и территориально–распределенных автоматизированных систем в защищенном исполнении на основе ЦОД.

Обеспечивается многопользовательский режим функционирования ЦОД и АСЗИ, а также обработка информации с уровнем конфиденциальности «Секретно», «Конфиденциальная информация».

Платформа и компоненты из её состава сертифицированы по требованиям ФСБ и ФСТЭК.

Таблица 2 - Компоненты цифровой программной платформы «СинтезМ»

39