Зрелая исполняемая среда для контейнеров: containerd стал «выпускником» CNCF

За проектом containerd мы следим с самого его начала ^[1]. Посему не можем обойти вниманием значимое событие: минувшей ночью организация CNCF, стоящая за Kubernetes и другими выдающимися Open Source-решениями для мира cloud native, объявила ^[2] containerd своим «выпускником». Этот проект стал уже пятым с таким статусом, пополнив ряды K8s, Prometheus, Envoy и CoreDNS.

Критерии CNCF

В CNCF, поддерживающей на сегодняшний день десятки Open Source-проектов, приняты ^[3] три категории для их классификации:

1. Sandbox («песочница») — для самых ранних ^[4], экспериментальных, но перспективных разработок, которые (в перспективе) «добавят ценности миссии CNCF», т.е. будут способствовать развитию Open Source-экосистемы и сообщества, сформированных вокруг инфраструктуры для современных облачных (cloud native) приложений. Таких проектов сейчас 12.
2. Incubating («инкубатор») — для проектов, имеющих хотя бы трёх (документально подтверждённых и независимых) пользователей в production, в рамках которых обеспечиваются достаточные (по оценке технического комитета) уровни качества и масштабы, а также обладающих адекватным числом контрибьюторов с commit bit и стабильным развитием кодовой базы. Всего их 15.
3. Graduation («выпускники») — для проектов с коммитерами хотя бы из двух организаций, бейджем соответствия лучшим практикам CII ^[5] (Core Infrastructure Initiative), принятым CNCF Code of Conduct ^[6], ясно определённой схемой управления и принятия коммитов, публичным списком пользователей и, конечно, положительным исходом соответствующего голосования технического комитета CNCF. Теперь их 5.

В краткой же форме готовность проекта к «выпуску» в CNCF формулируют как его «бурно растущую адаптацию, своеобразность, формальный процесс управления и строгую приверженность к устойчиво развивающемуся и инклюзивному сообществу». Соответствующим таким критериям отныне признан и containerd ^[7], переданный компанией Docker в CNCF уже почти 2 года назад.

containerd: истоки и настоящее

Проект containerd берёт своё начало во времена, когда деревья Docker был большим. В 2015 году его разработчики объявили, что настало время сделать Docker Engine более компактным (быстрым, надёжным, портируемым…), а посему начали выносить его компоненты в отдельные проекты.

Всё началось ^[8] с анонса инструмента для запуска контейнеров runc (2015 год), затем появилась ^[9] исполняемая среда для контейнеров containerd (2016 год), а через год данная инициатива стала ещё более глобальной и принесла нам Moby ^[10].

Иллюстрация к релизу Docker 1.11 ^[11] (апрель 2016 года): Docker Engine и вынесенные из него компоненты

Вернёмся к containerd. Если вкратце, то его функциональная роль сводилась (и это не изменилось по сей день) к тому, что он, будучи демоном на хост-системе, управлял всем жизненным циклом контейнера: от получения и хранения образа до запуска контейнера (через уже упомянутый runc) и контролирования его работы. В марте 2017 года, через год после отделения container, компания Docker передала ^[12] его в CNCF, что произошло одновременно ^[13] с аналогичной инициативой от CoreOS под названием rkt ^[14] (к ней мы ещё вернёмся).

Дальнейшие события включают в себя появление и развитие ^[15] (под руководством Red Hat) ориентированного на Kubernetes конкурента под названием CRI-O*… и зеркальный «ответ» Docker Inc — в виде cri-containerd.

Для взаимодействия с K8s в cri-containerd использовался специальный (одноимённый) демон, а к версии 1.1 решение превратилось ^[16] в плагин к новому интерфейсу для исполняемых сред контейнеров в Kubernetes — Container Runtime Interface (CRI), — и здесь плагин общался с containerd уже напрямую (вызовом нужных функций).

В июне 2018 года было объявлено ^[17], что CRI-плагин containerd готов к production. Актуальный репозиторий проекта — containerd/cri ^[18].

* Интересно заметить, что поданная в ноябре 2018 года заявка ^[19] на включение конкурента containerd и rkt — CRI-O — в состав проектов CNCF до сих пор не нашла одобрения в организации.

На сегодняшний день containerd нескромно называет себя «исполняемой средой для контейнеров, являющейся индустриальным стандартом и фокусирующейся на простоте, надёжности и портируемости»:

Актуальная архитектура контейнерных решений, использующих containerd (в массе они, конечно, ориентированы на Kubernetes, но формально этой платформой не ограничены), представляется следующим образом:

Само решение поставляется ^[20] в виде демона для Linux (рекомендуются ^[21] ядра версий 4.x, хотя возможны и варианты с более ранними) и Windows. Исходный код написан на Go (требуется ^[22] версия 1.9.x+).

Последний релиз containerd — 1.2.4 ^[23] (от 14 февраля 2019), где исправлена уязвимость CVE-2019-5736 ^[24] в runc. Ближайший milestone — версия 1.3 ^[25], где ожидаются такие новшества, как группы контейнеров ^[26], оптимизация производительности ^[27] для операции pull'а образов, различные улучшения в работе со snapshotter и другие ^[25].

У проекта — 3500+ звёзд на GitHub, 14 коммитеров и 166 контрибьюторов из таких компаний (кроме Docker, конечно), как Alibaba ^[28], Facebook, Google, Huawei ^[29], IBM, Microsoft, NTT, Tesla. Больше статистики по кодовой базе можно увидеть на DevStats ^[30].

Среди заметных пользователей ^[31] containerd достаточно упомянуть сам Moby и связанные с ним проекты (LinuxKit, BuildKit), облачные сервисы Google (GKE), Microsoft (acs-engine в Azure, а в будущем и AKS), IBM (IKS, ICP) и Alibaba, контейнерные решения/движки (Rio от Rancher, Kata Containers, Balena), а также даже недавний Firecracker ^[32].

О конкурентах

Напоследок, стоит сказать, что темпы развития rkt — аналога containerd, включённого в CNCF примерно в то же время, — значительно уступают. Достаточно указать на то, что последний его релиз — v1.30.0 — состоялся почти год назад (в апреле 2018).

Тут напрашиваются логичные выводы с позиций бизнеса: около года назад оригинальный разработчик rkt — CoreOS — был поглощён ^[33] компанией Red Hat. А у последней (или правильнее сказать, что теперь уже ^[34] у IBM…), как упоминалось в материале, есть своё детище — cri-o, — деятельность над которым идёт куда активнее ^[35].

Однако, пока Linux-гиганту так и не удалось «завести» свой проект в CNCF, пожалуй, слова о containerd как промышленном стандарте звучат весьма правдоподобно.

P.S.

Читайте также в нашем блоге:

• «Зачем нужен containerd и почему его отделили от Docker ^[1]»;
• «В чём суть проекта Moby и почему главным репозиторием Docker вдруг стал moby/moby? ^[10]»;
• «Интеграция containerd с Kubernetes, заменяющая Docker, готова к production ^[16]»;
• «Прошлое, настоящее и будущее Docker и других исполняемых сред контейнеров в Kubernetes ^[36]»;
• «CRI-O — альтернатива Docker для запуска контейнеров в Kubernetes ^[15]».

Автор: Дмитрий Шурупов

Источник ^[37]