Зрелая исполняемая среда для контейнеров: containerd стал «выпускником» CNCF
За проектом containerd мы следим с самого его начала. Посему не можем обойти вниманием значимое событие: минувшей ночью организация CNCF, стоящая за Kubernetes и другими выдающимися Open Source-решениями для мира cloud native, объявила containerd своим «выпускником». Этот проект стал уже пятым с таким статусом, пополнив ряды K8s, Prometheus, Envoy и CoreDNS.
Критерии CNCF
В CNCF, поддерживающей на сегодняшний день десятки Open Source-проектов, приняты три категории для их классификации:
- Sandbox («песочница») — для самых ранних, экспериментальных, но перспективных разработок, которые (в перспективе) «добавят ценности миссии CNCF», т.е. будут способствовать развитию Open Source-экосистемы и сообщества, сформированных вокруг инфраструктуры для современных облачных (cloud native) приложений. Таких проектов сейчас 12.
- Incubating («инкубатор») — для проектов, имеющих хотя бы трёх (документально подтверждённых и независимых) пользователей в production, в рамках которых обеспечиваются достаточные (по оценке технического комитета) уровни качества и масштабы, а также обладающих адекватным числом контрибьюторов с commit bit и стабильным развитием кодовой базы. Всего их 15.
- Graduation («выпускники») — для проектов с коммитерами хотя бы из двух организаций, бейджем соответствия лучшим практикам CII (Core Infrastructure Initiative), принятым CNCF Code of Conduct, ясно определённой схемой управления и принятия коммитов, публичным списком пользователей и, конечно, положительным исходом соответствующего голосования технического комитета CNCF. Теперь их 5.
В краткой же форме готовность проекта к «выпуску» в CNCF формулируют как его «бурно растущую адаптацию, своеобразность, формальный процесс управления и строгую приверженность к устойчиво развивающемуся и инклюзивному сообществу». Соответствующим таким критериям отныне признан и containerd, переданный компанией Docker в CNCF уже почти 2 года назад.
containerd: истоки и настоящее
Проект containerd берёт своё начало во времена, когда деревья Docker был большим. В 2015 году его разработчики объявили, что настало время сделать Docker Engine более компактным (быстрым, надёжным, портируемым…), а посему начали выносить его компоненты в отдельные проекты.
Всё началось с анонса инструмента для запуска контейнеров runc (2015 год), затем появилась исполняемая среда для контейнеров containerd (2016 год), а через год данная инициатива стала ещё более глобальной и принесла нам Moby.
Иллюстрация к релизу Docker 1.11 (апрель 2016 года): Docker Engine и вынесенные из него компоненты
Вернёмся к containerd. Если вкратце, то его функциональная роль сводилась (и это не изменилось по сей день) к тому, что он, будучи демоном на хост-системе, управлял всем жизненным циклом контейнера: от получения и хранения образа до запуска контейнера (через уже упомянутый runc) и контролирования его работы. В марте 2017 года, через год после отделения container, компания Docker передала его в CNCF, что произошло одновременно с аналогичной инициативой от CoreOS под названием rkt (к ней мы ещё вернёмся).
Дальнейшие события включают в себя появление и развитие (под руководством Red Hat) ориентированного на Kubernetes конкурента под названием CRI-O*… и зеркальный «ответ» Docker Inc — в виде cri-containerd.
Для взаимодействия с K8s в cri-containerd использовался специальный (одноимённый) демон, а к версии 1.1 решение превратилось в плагин к новому интерфейсу для исполняемых сред контейнеров в Kubernetes — Container Runtime Interface (CRI), — и здесь плагин общался с containerd уже напрямую (вызовом нужных функций).
В июне 2018 года было объявлено, что CRI-плагин containerd готов к production. Актуальный репозиторий проекта — containerd/cri.
* Интересно заметить, что поданная в ноябре 2018 года заявка на включение конкурента containerd и rkt — CRI-O — в состав проектов CNCF до сих пор не нашла одобрения в организации.
На сегодняшний день containerd нескромно называет себя «исполняемой средой для контейнеров, являющейся индустриальным стандартом и фокусирующейся на простоте, надёжности и портируемости»:
Актуальная архитектура контейнерных решений, использующих containerd (в массе они, конечно, ориентированы на Kubernetes, но формально этой платформой не ограничены), представляется следующим образом:
Само решение поставляется в виде демона для Linux (рекомендуются ядра версий 4.x, хотя возможны и варианты с более ранними) и Windows. Исходный код написан на Go (требуется версия 1.9.x+).
Последний релиз containerd — 1.2.4 (от 14 февраля 2019), где исправлена уязвимость CVE-2019–5736 в runc. Ближайший milestone — версия 1.3, где ожидаются такие новшества, как группы контейнеров, оптимизация производительности для операции pull’а образов, различные улучшения в работе со snapshotter и другие.
У проекта — 3500+ звёзд на GitHub, 14 коммитеров и 166 контрибьюторов из таких компаний (кроме Docker, конечно), как Alibaba, Facebook, Google, Huawei, IBM, Microsoft, NTT, Tesla. Больше статистики по кодовой базе можно увидеть на DevStats.
Среди заметных пользователей containerd достаточно упомянуть сам Moby и связанные с ним проекты (LinuxKit, BuildKit), облачные сервисы Google (GKE), Microsoft (acs-engine в Azure, а в будущем и AKS), IBM (IKS, ICP) и Alibaba, контейнерные решения/движки (Rio от Rancher, Kata Containers, Balena), а также даже недавний Firecracker.
О конкурентах
Напоследок, стоит сказать, что темпы развития rkt — аналога containerd, включённого в CNCF примерно в то же время, — значительно уступают. Достаточно указать на то, что последний его релиз — v1.30.0 — состоялся почти год назад (в апреле 2018).
Тут напрашиваются логичные выводы с позиций бизнеса: около года назад оригинальный разработчик rkt — CoreOS — был поглощён компанией Red Hat. А у последней (или правильнее сказать, что теперь уже у IBM…), как упоминалось в материале, есть своё детище — cri-o, — деятельность над которым идёт куда активнее.
Однако, пока Linux-гиганту так и не удалось «завести» свой проект в CNCF, пожалуй, слова о containerd как промышленном стандарте звучат весьма правдоподобно.
P.S.
Читайте также в нашем блоге:
