Как containerd сравнивается с runC
Как эти два сравниваются? Насколько я понимаю, runC - это среда выполнения для контейнеров. Это означает, что этот компонент обеспечивает необходимую среду для запуска контейнеров. Какова роль контейнера здесь тогда? Если все остальное (сеть, управление томами и т. Д.), То какова роль Docker Engine? А как насчет контейнера? По сути, я пытаюсь понять, что делает каждый из этих компонентов.
3 ответа
Я дам обзор высокого уровня, чтобы вы начали:
- http://containerd.io/ - это среда выполнения контейнера, которая может управлять полным жизненным циклом контейнера - от передачи / хранения изображений до выполнения контейнера, контроля и создания сетей.
- Container-shim обрабатывает контейнеры без заголовка, то есть, когда runc инициализирует контейнеры, он прекращает передачу контейнеров контейнеру-shim, который действует как посредник.
- runc - это легкий универсальный контейнер времени выполнения, соответствующий спецификации OCI. runc используется containerd для порождения и запуска контейнеров в соответствии со спецификацией OCI. Это также переупаковка libcontainer.
- grpc используется для связи между containerd и docker-engine.
- OCI поддерживает спецификацию OCI для среды выполнения и образов. Текущие версии докера поддерживают образ OCI и спецификации времени выполнения.
Больше ссылок:
Весь движок Docker, это был монолит, который позволял пользователям запускать контейнеры. Затем он был разбит на отдельные компоненты. Он был разбит на: - двигатель докера - containerd - runc
runC является компонентом самого низкого уровня, который реализует интерфейс OCI. Он взаимодействует с ядром и делает "запускает" контейнер
containerd делает такие вещи, как настройка сети, передача / хранение изображений и т. д. - Он заботится о полном времени выполнения контейнера (что означает, что он управляет и упрощает жизнь для runC, то есть фактического времени выполнения контейнера). В отличие от демона Docker, он имеет ограниченный набор функций; например, не поддерживается загрузка изображений.
Механизм Docker сам выполняет некоторые высокоуровневые вещи, такие как принятие пользовательских команд, загрузка изображений из реестра Docker и т. Д. Он выгружает большую их часть в контейнер.
"Демон Docker подготавливает образ как пакет Open Container Image (OCI) и выполняет API-вызов к containerd для запуска пакета OCI. containerd затем запускает контейнер с помощью runC".
Обратите внимание, что среды выполнения должны быть совместимы с OCI (как и runC), то есть они должны предоставлять фиксированный API менеджерам, таким как containerd, чтобы они (containerd) могли облегчить им жизнь (runC) (и попросить их остановка / запуск контейнеров)
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 в механизм докера.
Теперь, как 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 имеет докер для того, чтобы его можно было ДЕЙСТВИТЕЛЬНО использовать, а также для управления и облегчения жизни контейнеров, CRI -O нужен кто-то, кто позаботится об управлении изображениями - у него есть buildah, umochi и т. Д.
crun - это еще одна среда выполнения, совместимая с OCI и написанная на C. Она написана RedHat.
Мы уже обсуждали, kata-runtime - это еще одна среда выполнения, совместимая с OCI. Итак, мы можем использовать kata-runtime с CRI-O, как мы обсуждали.
Обратите внимание, что здесь, kubelet общается с CRI -O через CRI. CRI-O говорит о cc-runtime (это еще одна среда выполнения для чистых контейнеров Intel, да, OCI-совместимая), но это может быть и kata-runtime.
Не забывайте контейнер, он может управлять и облегчать жизнь для всех сред выполнения жалоб OCI - конечно, runC, но также и kata-runtime, cc-runtime
Здесь обратите внимание, что только среда выполнения перемещена из runC в kata-runtime. Для этого в конфиге containerd просто измените время выполнения на "kata".
Само собой разумеется, что он может работать в Kubernetes либо с помощью CRI-O, либо с помощью cri-containerd (он же CRI Plugin).
Это действительно круто: 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 и
У нас есть еще несколько сред выполнения:
- вагон - OCI-совместимый, написанный на ржавчине
- Чехол - модифицированный RunC от Alibaba
- nvidia runtime - форк nvidia из runC
ссылка: https://github.com/darshanime/notes/blob/master/kubernetes.org#notes
runc является одним из компонентов containerd и обрабатывает взаимодействие на уровне ядра для запуска контейнеров. В более ранних версиях containerd был по существу абстракция высокого уровня вокруг runc но теперь это намного больше, чем это. Из https://containerd.io/:
runc является компонентом containerd, исполнителем контейнеров. containerd имеет более широкую область применения, чем просто выполнение контейнеров: загрузка изображений контейнеров, управление хранилищами и сетевыми интерфейсами, вызов runc с правильными параметрами для запуска контейнеров.
Это изображение из того же источника хорошо описывает это.
Docker Engine - это продукт конечного пользователя, который использует containerd в качестве основного компонента и реализует другие функции, которые не подпадают под containerdСфера.
Обратите внимание, что Docker извлечен containerd как отдельный компонент, поэтому он может быть использован и разработан другими продуктами.