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

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

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

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

На рисунке 3 показаны три контейнера, работающие на базе аппаратного обеспечения системы. Физическая система имеет свою собственную ОС хоста. Каждый контейнер содержит собственное прикладное ПО (приложение х) и запускает это ПО в одном или нескольких процессах ОС, используя такие ресурсы, как оперативная память, процессор, система хранения данных и сетевые компоненты, изолированно от других контейнеров, работающих на той же системе, но все они совместно используют ядро ОС хоста.

Ядро ОС хоста используется всеми контейнерами совместно, поэтому ОС, используемая ПО в контейнерах, должна быть совместима с ядром ОС хоста. Благодаря этому различные контейнеры смогут использовать различные варианты ОС Linux, если ОС хоста является, например, одной из версий ОС Linux, но ОС Windows невозможно будет использовать в контейнере, если ОС хоста является одной из версий ОС Linux (и наоборот).

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

Рисунок 3 — Виртуализация контейнеров

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

ОС хоста, используемая контейнерами, может работать внутри ВМ, а не на базе физического аппаратного обеспечения. ПО, работающее в контейнерах, не знает, запущена ли ОС хоста на ВМ или нет [из 7.2.1 Описание контейнеров ГОСТ Р 70860—2023]

Контейнер обеспечивает изолированную среду выполнения ПО, которая контролирует ресурсы.

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

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

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

Для доступа к блочному вводу/выводу контейнер по умолчанию имеет доступ к файловой системе, состоящей из образа контейнера, использованного для создания контейнера в режиме «только для чтения», плюс уровень контейнера для чтения/записи. Файловая система по умолчанию является временной, и уровень контейнера удаляется при удалении контейнера. Дополнительные, обычно постоянные, ресурсы для хранения данных могут стать доступны ПО внутри контейнера за счет настройки конфигурации контейнера контейнерной службой — либо в виде дополнений файловой системы внутри контейнера, внесенных из другого места вне контейнера, либо посредством предоставления одного или нескольких сервисов хранения (как правило, облачных). Такие дополнительные средства хранения необходимы, если ПО в контейнере должно иметь возможность обращаться к объектам хранения, имеющим длительный жизненный цикл. Во всех случаях видимое расположение файлов и объектов хранения внутри контейнера сопоставляется с реальным расположением за пределами контейнера.

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

Порты, открытые контейнером, можно контролировать и сопоставлять с сетевыми адресами и портами, видимыми извне. Например, контейнер может открыть порт 80 для HTTP-трафика, но он может быть сопоставлен с портом 8080 для внешнего доступа (например, Интернета). В целом можно контролировать и сопоставлять IP-адреса, порты, имена хостов, МАС-адреса, службы маршрутизации и службы DNS.

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

В ОС Linux контроль над ресурсами осуществляется с помощью функциональной возможности, называемой контрольными группами или cgroups. Она обеспечивает контроль над ресурсами, доступными наборам процессов, включая процессор, память, ввод/вывод на блочные устройства (т. е. файловые системы), доступ к устройствам, сетевое подключение.

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

В ОС Linux существуют следующие виды пространств имен (начиная с ядра Linux 4.10):

• Interprocess Communication (ipc): относится к межпроцессному взаимодействию. Только процессы в одном и том же пространстве имен могут обмениваться данными (например, выделять общую память);
• Mount (mnt): относится к точкам монтирования, т. е. местам, куда монтируются (дополнительные) файловые системы. Начальный набор для монтирования доступен при создании контейнера контейнерной службой, но после этого любые новые монтирования будут видны только внутри контейнера;
• Network (net): содержит ресурсы, связанные с сетью, такие как интерфейсы, IP-адреса, таблица маршрутизации, список сокетов, таблица отслеживания соединений и т. д.;
• Process ID (pid): содержит набор идентификаторов процессов; первый процесс в пространстве имен имеет идентификатор 1, и этот процесс имеет специальный режим, аналогичный процессу init в базовой ОС;
• User ID (user): предоставляет идентификаторы пользователей, позволяющие как идентифицировать пользователя, так и контролировать привилегии: пространство имен пользователей сопоставляет идентификаторы пользователей в пространстве имен с идентификаторами пользователей в базовой системе, что позволяет тщательно контролировать привилегии и обеспечить более высокие привилегии в пространстве имен, которые не предоставляются для каких-либо ресурсов вне этого пространства имен;
• UTS: дает возможность различным процессам иметь разные имена хостов и доменов.

Совместное использование cgroups и пространств имен обеспечивает контроль ресурсов и изоляцию, необходимую для контейнеров [из 7.2.3 Ресурсы контейнеров, изоляция и контроль ГОСТ Р 70860—2023]

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

CMS может абстрагировать базовую инфраструктуру, рассматривая набор контейнеров как единую цель развертывания и в то же время обеспечивая соблюдение политик развертывания, таких как разделение параллельных экземпляров контейнеров для целей резервирования и перехода на другой ресурс при сбое [из 7.4.1 Общие положения ГОСТ Р 70860—2023]