От переводчика : Это перевод статьи Среды выполнения контейнеров.
Часть 1. Введение в среды выполнения контейнеров.
.
Автор оригинальной публикации: Ян Льюис .
Один из терминов, который вы часто слышите при работе с контейнерами: "время выполнения контейнера" ( Дальше "время выполнения" переводится как «среда запуска» — ок.
переводчик ).
«Среда выполнения контейнера» может означать разные вещи для разных людей, поэтому неудивительно, что это такой запутанный и смутно понимаемый термин даже внутри самого сообщества пользователей и разработчиков Docker. Этот пост является первым в серии из 4 частей:
Часть 1. Введение в среду выполнения контейнеров: почему они так сбивают с толку? Часть 2. Глубокое погружение в низкоуровневые среды запуска (англ) Часть 3. Глубокое погружение в высокоуровневые среды выполнения Часть 4. Среды выполнения в Kubernetes и CRI В этом посте будет объяснено, что такое среда выполнения контейнеров и почему существует так много недоразумений.После этого я расскажу о различных типах сред выполнения контейнеров, о том, что они делают и чем отличаются друг от друга.
(На картинке изображена игра слов: Не уверен, относится ли это к среде выполнения контейнера Kubernetes, среде выполнения контейнера низкого уровня или продолжительности фильма.
- примечание переводчика) Традиционно программист может понять "время выполнения" или как фаза жизненного цикла программа, во время которой она выполняется, или как языковая среда , который поддерживает это выполнение.
Примером может служить среда выполнения Java HotSpot. Последнее значение наиболее близко к "время выполнения" контейнер.
Среда выполнения контейнера отвечает за все этапы запуска контейнера, которые не запускают непосредственно саму программу.
Как мы увидим позже в этой серии, среды запуска реализуют различные уровни функциональности, но функция "запускает контейнер" для инструмента - по сути все, что нужно для его названия среда запуска контейнера .
Если вы не слишком хорошо знакомы с контейнерами, сначала ознакомьтесь с этими ресурсами, а затем вернитесь: Что такое контейнер: пространства имен и контрольные группы
Cgroups, пространства имен и не только: из чего состоят контейнеры?
Почему время выполнения контейнеров так сбивает с толку?
Docker был выпущен в 2013 году и решил множество проблем разработчиков, запуская контейнеры в непрерывной цепочке.В него вошли: Формат образа контейнера Метод сборки образов контейнеров (Dockerfile/docker build) Возможность управления образами контейнеров (образы docker, docker rm и т.д.) Возможность управления экземплярами контейнеров (docker ps, docker rm и т. д.) Возможность делиться образами контейнеров (docker push/pull) Возможность запуска контейнеров (docker run) Все это время Docker представлял собой монолитную систему.
Однако ни одна из этих функций по-настоящему не зависела друг от друга.
Каждый из них может быть реализован в виде более мелких и специализированных инструментов, которые можно будет использовать вместе.
Каждый из инструментов может работать вместе с другими, используя общий формат — стандарт контейнера.
Из-за этого Docker, Google, CoreOS и другие вендоры создали Инициатива открытых контейнеров (OCI) .
После этого они разделили свой код для запуска контейнеров на инструмент и библиотеку под названием бежать и передал его в OCI в качестве эталонной реализации.
Спецификации среды запуска OCI .
Поначалу смущал вопрос, что именно Докер передал в OCI. То, что они передали, — это стандартный способ запуска контейнеров и ничего больше.
Они не включали формат образа или протоколы для получения/загрузки образа контейнера из/в реестр образов (хранилище образов).
Вот что на самом деле делает Docker, когда вы запускаете контейнер Docker: Загрузка изображения.
Распаковка образа в «пачку».
Это действие объединяет слои в одну файловую систему.
Запуск контейнера из пакета.
Единственное, что стандартизировал Docker, — это шаг №3. Пока это не было выяснено, все думали о среде выполнения контейнера как о системе, поддерживающей все функции, поддерживаемые Docker. Со временем ребята из Докера объяснили, что исходная спецификация утверждает, что только часть «работающего контейнера» представляет собой «работающую среду».
Это разъединение, которое продолжается даже сейчас, делает тему «время выполнения контейнеров» такой запутанной.
Я надеюсь показать, что обе стороны в некоторой степени правы, и в этом посте я буду использовать этот термин весьма свободно.
Среды запуска контейнеров низкого и высокого уровня.
Когда разработчики думают о средах выполнения контейнеров, вот список некоторых примеров, которые могут прийти на ум: runc, lxc, lmctfy, Docker (containerd), rkt, cri-o. Каждый из них предназначен для разных ситуаций и выполняет разные функции.
Некоторые, например,Containerd и Cri-O, фактически используют runc для запуска контейнера, но выполняют управление образами и имеют помимо этого API. Вы можете думать об этих функциях, включая миграцию изображений, управление изображениями, распаковку изображений и API, как о функциях высокого уровня по сравнению с реализацией низкого уровня в runc. Учитывая это, вы можете видеть, что область выполнения контейнера довольно сложна.
Каждая среда выполнения охватывает различную часть этого спектра от низкого уровня до высокого уровня.
Вот очень субъективная диаграмма: 
На практике среды выполнения контейнеров, ориентированные просто на запуск контейнеров, обычно называются «средами выполнения контейнеров низкого уровня».
Другие среды выполнения, которые поддерживают функции более высокого уровня, такие как управление изображениями и различные API-интерфейсы gRPC/Web, обычно называются «инструментами контейнеров высокого уровня», «средами выполнения контейнеров высокого уровня» или обычно просто «средами выполнения контейнеров».
Я буду называть их «средами выполнения контейнеров высокого уровня».
Важно отметить, что среды выполнения низкого и высокого уровня — это принципиально разные вещи, которые решают разные проблемы.
Контейнеры реализованы с использованием механизмов пространства имен И контрольные группы Линукс.
Пространства имен дают вам возможность виртуализировать системные ресурсы, такие как файловая система или сеть, для каждого контейнера.
Cgroups предоставляют возможность ограничить объем ресурсов, таких как ЦП и память, которые может использовать каждый контейнер.
На самом низком уровне за настройку этих пространств имен и контрольных групп отвечают среды выполнения контейнеров.
Низкоуровневая поддержка среды выполнения использует эти функции операционной системы.
Обычно разработчикам, которые хотят запускать приложения в контейнерах, требуется больше возможностей, чем предоставляют низкоуровневые среды выполнения.
Им нужны API и функции, связанные с форматами изображений, управлением изображениями и возможностью обмениваться изображениями.
Эти функции обеспечивают среду запуска высокого уровня.
Среды выполнения начального уровня просто не обладают достаточными возможностями для таких повседневных нужд. По этим причинам единственными людьми, которые будут использовать среды выполнения низкого уровня, будут разработчики сред выполнения высокого уровня и контейнерных инструментов.
Разработчики низкоуровневых сред выполнения скажут, что высокоуровневые среды выполнения, такие как контейнеры и cri-o, на самом деле не являются средами выполнения контейнеров, поскольку, с их точки зрения, они делегируют выполнение запуска контейнера программе runc. Но с точки зрения пользователя — это полноценные инструменты, предоставляющие возможность запуска контейнеров.
Одна реализация может сменяться другой, поэтому с этой точки зрения имеет смысл называть их средой запуска.
Несмотря на то, что контейнеры и cri-o используют runc, это два совершенно разных проекта с поддержкой совершенно разных функций.
В следующий раз.
Надеюсь, я помог вам лучше понять, что такое среда выполнения контейнеров и почему ее так сложно понять.
Вы можете оставлять мне комментарии к статье (на сайте автора – прим.
переводчика) или на Твиттер и дайте мне знать, что было труднее всего понять в среде выполнения контейнеров.
В моей следующей статье я углублюсь в низкоуровневую среду выполнения контейнеров.
В ней я расскажу о том, что именно делают низкоуровневые среды выполнения контейнеров.
Я буду говорить как о популярных низкоуровневых средах выполнения (например, runc и rkt), так и о непопулярных, но важных (например, lmctfy).
Я даже расскажу, как запустить простую низкоуровневую среду запуска.
Обязательно подпишитесь на мой RSS-канал или Твиттер чтобы получить уведомление о выходе следующего поста.
А пока вы можете принять участие в сообществе Kubernetes по этим каналам: Отправляя вопросы и отвечая на них Переполнение стека Следуя в Твиттере @Кубернетезио Присоединение к Кубернетесу Слабый и общение с нами.
(Я Янлевис, так что передайте привет!) Внося свой вклад в Kubernetes на GitHub Спасибо Сандип Динеш , Марк Мандель , Крейг Бокс , Майя Качоровски и Джо Бернетту за рецензирование черновиков этого поста.
От переводчика : Я в свою очередь выражаю благодарность пользователю за проверку черновиков перевода GDApsy .
Теги: #Kubernetes #docker #DevOps #контейнеры
-
Как Вычитать Текст Самостоятельно
19 Oct, 24 -
Полет Квадрокоптера На Высоте 1 Км
19 Oct, 24 -
Розетка Для Esp8266 Esp-12
19 Oct, 24 -
Хватит Крутить (Восклицательный Знак)
19 Oct, 24 -
Как Переместить Гору Фудзи
19 Oct, 24
