Что такое containerd и как он связан с Docker и Kubernetes?

Контейнеры по-прежнему означают «Докер» для многих людей. Docker популяризировал современное использование контейнеров в разработке и развертывании программного обеспечения. В наши дни существуют и другие технологии. Вот как Containerd, Docker и Kubernetes связаны друг с другом.

Начало

На момент своего выпуска в 2013 году Docker был автономным проектом со всем необходимым для создания и запуска контейнеров. Чего ему не хватало, так это простого способа организовать развертывание контейнеров в облаке.

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

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

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

Восстание Containerd

По мере роста Kubernetes и появления новых сторонних инструментов вокруг Docker стали очевидны ограничения его архитектуры. В то же время Open Container Initiative (OCI) начала стандартизировать форматы контейнеров и среды выполнения. Это привело к спецификации OCI, определяющей контейнер, который может использоваться несколькими средами выполнения, примером которых является Docker.

Затем Docker извлек свою среду выполнения контейнера в новый проект containerd. Это включает в себя функциональность Docker для выполнения контейнеров, обработки низкоуровневого хранилища и управления передачей образов. Containerd был передан в дар Cloud Native Computing Foundation (CNCF), чтобы предоставить сообществу контейнеров основу для создания новых контейнерных решений.

Появление containerd облегчает таким проектам, как Kubernetes, доступ к необходимым низкоуровневым элементам «Docker». Вместо того, чтобы фактически использовать Docker, теперь у них есть более доступный интерфейс для среды выполнения контейнера. Стандартизация контейнерных технологий OCI означает, что можно использовать и другие среды выполнения.

Понимание роли Containerd

Чтобы полностью понять containerd, необходимо взглянуть на природу контейнеров. Контейнеры на самом деле являются абстракцией различных функций ядра Linux. Чтобы запустить контейнер, вам нужно использовать системные вызовы для настройки контейнерной среды. Шаги зависят от платформы и дистрибутива.

Containerd вмешивается, чтобы абстрагировать эту низкоуровневую проводку. Он задуман как «клиентский уровень», над которым затем строится контейнерное программное обеспечение. Это может быть программное обеспечение, ориентированное на разработчиков, такое как Docker, или облачные инструменты разработки, такие как Kubernetes.

Раньше при разработке Kubernetes оставалось два плохих варианта: продолжать писать прокладки вокруг здоровенного интерфейса Docker или начать напрямую взаимодействовать с функциями ядра Linux. После отделения containerd от Docker стала доступной третья альтернатива: использовать containerd в качестве уровня системной абстракции без участия Docker.

Вот краткое описание того, как сочетаются эти три технологии:

• Docker – ориентированное на разработчиков программное обеспечение с высокоуровневым интерфейсом, которое позволяет легко создавать и запускать контейнеры с вашего терминала. Теперь в качестве среды выполнения контейнера используется containerd.
• Containerd — абстракция функций ядра, обеспечивающая относительно высокоуровневый интерфейс контейнера. Другие программные проекты могут использовать это для запуска контейнеров и управления образами контейнеров.
• Kubernetes — оркестратор контейнеров, который работает с несколькими средами выполнения контейнеров, включая containerd. Kubernetes ориентирован на развертывание контейнеров в совокупности на одном или нескольких физических «узлах». Исторически Kubernetes был привязан к Docker.

Containerd — это только один контейнерный бэкэнд. Другие контейнеры, реализующие спецификацию Open Containers Runtime, включают runC и CRI-O. Эти среды выполнения также можно использовать с Docker и Kubernetes; каждый имеет свои отличия.

ОКИ

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

Спецификация образа OCI определяет, как должен выглядеть контейнер. Спецификация среды выполнения устанавливает интерфейс для запуска контейнеров. Затем такие проекты, как containerd, реализуют эти спецификации.

Важно отметить, что одним из приоритетов OCI является поддержка опыта использования контейнеров, популяризированного Docker. Его образы должны исполняться на целевой платформе без каких-либо пользовательских аргументов (например, docker run hello-world:latest). Поэтому изображения OCI должны содержать достаточно метаданных, чтобы включить эту автоматическую настройку.

Вы также можете увидеть ссылки на интерфейс времени выполнения контейнера (CRI). Это специфичная для Kubernetes абстракция спецификации OCI. CRI основывается на спецификациях OCI, чтобы обеспечить поддержку взаимозаменяемых сред выполнения контейнеров в Kubernetes.

Как насчет моих образов Docker?

Образы, которые вы создаете с помощью Docker, на самом деле вовсе не являются «образами Docker». Поскольку Docker теперь использует среду выполнения containerd, ваши образы создаются в стандартизированном формате Open Container Initiative (OCI).

Вам не нужно беспокоиться о несовместимости между вашими образами Docker и средой, в которой они используются. Образы, которые вы создаете с помощью Docker, по-прежнему можно развернуть с помощью Kubernetes. Это связано с тем, что Kubernetes также поддерживает образы OCI благодаря использованию containerd (и других сред выполнения, соответствующих стандартам). Загружать и запускать образы должна среда выполнения, а не высокоуровневый интерфейс, который предоставляют такие инструменты, как Docker и Kubernetes.

Кубернетес и Докер

Kubernetes прекратил поддержку среды выполнения Docker в конце 2020 года. Она будет удалена в будущем выпуске, который в настоящее время запланирован на конец 2021 года. После этого Kubernetes больше не будет предлагать поддержку среды выполнения Docker. Вместо этого необходимо использовать альтернативную среду выполнения, совместимую со спецификациями OCI, например containerd.

Это объявление вызвало обеспокоенность по поводу последствий для разработчиков. Изменение не должно повлиять на большинство существующих рабочих процессов. Как мы уже видели, Docker создает образы, совместимые с OCI, которые могут запускаться в средах выполнения, совместимых с OCI. Любые образы, которые вы создаете с помощью docker build, по-прежнему будут работать в Kubernetes даже после удаления среды выполнения Docker.

Рассматриваются две разные технологии: интерфейс командной строки Docker, используемый для создания и запуска контейнеров, и среда выполнения Docker, в которую встроен интерфейс командной строки.

Все слишком запутанно!

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

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

Каждый высокоуровневый пользовательский интерфейс (например, Docker и Kubernetes) теперь выигрывает от выбора взаимозаменяемых низкоуровневых сред выполнения контейнеров (например, containerd и runC). Это обеспечивает большую степень гибкости и позволяет новым контейнерным технологиям внедряться в соответствии со стандартами.