Как containerd сравнивается с runC

Как эти два сравнения? Насколько я понимаю, runC - среда выполнения для контейнеров. Это означает, что этот компонент обеспечивает необходимую среду для запуска контейнеров. Какова роль контейнера здесь? Если все остальное (создание сетей, управление томами и т.д.), То в чем роль Docker Engine? А как насчет containerd-shim? В принципе, я пытаюсь понять, что делают каждый из этих компонентов.

Ответ 1

Я дам обзор высокого уровня, чтобы вы начали:

  • containerd - это время выполнения контейнера, которое может управлять полным жизненным циклом контейнера - от передачи/хранения изображений до выполнения контейнера, контроля и создания сетей.
  • Контейнеры-контейнеры для контейнеров без подгонки, означающие, что когда runc инициализирует контейнеры, он выходит из контейнера в контейнер, который действует как посредник.
  • runc - это легкий универсальный контейнер времени выполнения, который соответствует спецификации OCI. runc используется containerd для нереста и запуска контейнеров в соответствии со спецификацией OCI. Это также переупаковка libcontainer.
  • grpc, используемый для связи между контейнером и движком docker.
  • OCI поддерживает спецификацию OCI для времени выполнения и изображений. Текущие версии докеров поддерживают изображения OCI и спецификации времени выполнения.

runC, containerD

Дополнительные ссылки:

Ответ 2

Весь движок Docker, это был монолит, который позволял пользователям запускать контейнеры. Затем он был разбит на отдельные компоненты. Это было разбито на: - движок докера - containerd - runc

enter image description here

runC является компонентом самого низкого уровня, который реализует интерфейс OCI. Он взаимодействует с ядром и делает "запускает" контейнер

containerd выполняет такие вещи, как настройка сети, передача/хранение изображений и т.д. Он заботится о полном времени выполнения контейнера (что означает, что он управляет и упрощает жизнь для runC, то есть фактического времени выполнения контейнера). В отличие от демона Docker, он имеет ограниченный набор функций; например, не поддерживается загрузка изображений.

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

"Демон Docker подготавливает образ как пакет Open Container Image (OCI) и вызывает API-интерфейс containerd для запуска пакета OCI. containerd затем запускает контейнер с помощью runC".

Обратите внимание, что среды выполнения должны быть совместимы с OCI (как и runC), то есть они должны предоставлять фиксированный API менеджерам, таким как containerd, чтобы они (containerd) могли облегчить им жизнь (runC) (и попросить их остановка/запуск контейнеров)

enter image description here

rkt - это другая среда выполнения контейнера, которая пока не поддерживает OCI, но поддерживает спецификацию appc. Но это полноценное решение, оно управляет и облегчает жизнь, поэтому ему не нужен контейнер, как папа.

Итак, вот что. Теперь давайте добавим еще один компонент (и другой интерфейс) к смеси - Kubernetes

Kubernetes может запускать все, что удовлетворяет интерфейсу среды выполнения CRI-контейнера.

Вы можете запустить rkt с помощью k8s, так как rkt удовлетворяет CRI - интерфейсу среды выполнения контейнера. Kubernetes не просит ничего другого, ему просто нужен CRI, он не дает FF о том, как вы запускаете свои контейнеры, OCI или нет.

containerd не поддерживает CRI, но cri-containerd, который является оболочкой для containerd, поддерживает. Таким образом, если вы хотите запустить containerd с Kubernetes, вы должны использовать cri-containerd (это также среда выполнения по умолчанию для Kubernetes). cri-containerd недавно был переименован в CRI Plugin.

Если вы хотите включить в процесс и механизм докера, вы можете это сделать. Используйте dockershim, это добавит прокладку CRI в механизм докера.

enter image description here

Теперь, как containerd может управлять и упростить жизнь для runC (среды выполнения контейнера), он может управлять и упростить жизнь для других сред выполнения контейнера - фактически, для каждой среды выполнения контейнера, которая поддерживает OCI - как среда выполнения контейнера Kata (известная как ~ kata-runtime ~ - https://github.com/kata-containers/runtime.) - который запускает контейнеры kata, Clear Container runtime (от Intel).

Теперь мы знаем, что rkt удовлетворяет CRI, cri-containerd (также известный как CRI Plugin) тоже.

Обратите внимание, что containerd делает здесь. Это не среда выполнения, это менеджер runC, который является средой выполнения контейнера. Он просто управляет загрузкой, хранением и т.д. Черт, он даже не удовлетворяет CRI.

Вот почему у нас есть CRI-O. Это как контейнер, но он реализует CRI. CRI-O нужна среда выполнения контейнера для запуска образов. Он будет управлять и облегчать жизнь для этой среды выполнения, но для этого нужна среда выполнения. Это займет любую среду выполнения, совместимую с OCI. Естественно, ~ kata-runtime ~ соответствует CRI-O, runC - CRI-O.

Использовать с Kubernetes просто, укажите Kubernetes на CRI-O в качестве среды выполнения контейнера. (Да, да, CRI-O, но CRI-O и фактическое время выполнения контейнера ЕСТЬ. И Kubernetes имеет в виду эту счастливую пару, когда говорит "время выполнения контейнера").

Подобно тому, как containerd имеет докер, чтобы сделать его ДЕЙСТВИТЕЛЬНО пригодным для использования, а также управлять и упростить жизнь для containerd, CRI-O нужен кто-то, кто позаботится об управлении изображениями - у него есть buildah, umochi и т.д.

crun - это еще одна среда выполнения, совместимая с OCI и написанная на C. Она написана RedHat.

Мы уже обсуждали, kata-runtime - это другая среда выполнения, которая соответствует OCI. Итак, мы можем использовать kata-runtime с CRI-O, как мы обсуждали.

enter image description here

Обратите внимание, что здесь, kubelet общается с CRI-O через CRI. CRI-O обращается к cc-runtime (это еще одна среда выполнения для чистых контейнеров Intel, да, OCI-совместимая), но это также может быть kata-runtime.

Не забудьте о контейнере, он может управлять и облегчать жизнь для всех сред выполнения жалоб OCI - конечно, runC, но также и kata-runtime, cc-runtime

enter image description here

Здесь обратите внимание, что только среда выполнения перемещена из runC в kata-runtime. Для этого в конфиге containerd просто измените время выполнения на "kata".

Излишне говорить, что он может работать в Kubernetes либо с помощью CRI-O, либо с помощью cri-containerd (также называемый CRI Plugin).

enter image description here

Это действительно круто: top:

Kubernetes, представленный здесь его послом, г-н Kubelet управляет всем, что удовлетворяет ЧРИ. Теперь у нас есть несколько кандидатов, которые могут. - Cri-containerd заставляет containerd сделать это. - CRI-O делает это изначально. - Dockershim заставляет двигатель докера делать это.

Теперь все 3 вышеупомянутых парня могут управлять и облегчать жизнь всем совместимым с OCI средам выполнения - runC, kata-runtime, cc-runtimes.

У нас также есть frakti, который удовлетворяет CRI, как и rkt, но не удовлетворяет OCI, и поставляется в комплекте со своим собственным временем выполнения контейнера.

Здесь у нас есть CRI-O в действии, управляющий и облегчающий жизнь для OCI-совместимых kata-runtime и runC и

enter image description here

У нас есть еще несколько сред выполнения:

  • Вагон - OCI-совместимый, написанный на ржавчине
  • Чехол - Alibaba модифицированный runC
  • nvidia runtime - nvidia форк runC

ссылка: https://github.com/darshanime/notes/blob/master/kubernetes.org#notes

Ответ 3

runc является одним из компонентов containerd и обрабатывает взаимодействие на уровне ядра для запуска контейнеров. В более ранних версиях containerd представлял собой абстракцию высокого уровня вокруг runc но теперь это намного больше. Из container.io:

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

Это изображение из того же источника хорошо описывает это.

Docker Engine - это продукт для конечных пользователей, который использует containerd в качестве основного компонента и реализует другие функции, которые не попадают в область действия containerd.

Обратите внимание, что Docker извлекает containerd как отдельный компонент, поэтому его можно использовать и разрабатывать в других продуктах.

[Редактировать] Я написал больше об этой терминологии здесь