Прим. перев.: Мы уже не раз писали о containerd и других исполняемых средах для Kubernetes. Новая публикация — перевод недавнего анонса важной вехи в развитии containerd, опубликованного в официальном блоге проекта Kubernetes. Текст написан сотрудниками компаний Google и IBM, которые (конечно, вместе с Docker Inc) вносят значительный вклад в совершенствование containerd.
Ранее в блоге — в заметке Containerd Brings More Container Runtime Options for Kubernetes — мы представляли альфа-версию интеграции containerd с Kubernetes. Очередные 6 месяцев разработки привели к тому, что интеграция стала общедоступной! Это означает, что теперь вы можете использовать containerd 1.1 в качестве исполняемой среды для контейнеров в Kubernetes-кластерах в production.
Containerd 1.1 работает с Kubernetes версии 1.10 и выше, поддерживает все возможности Kubernetes. В инфраструктуре тестов Kubernetes покрытие тестами интеграции с containerd на Google Cloud Platform стало таким же, что и у интеграции с Docker (см. test dashboard).
«Очень рады увидеть, что containerd быстро достиг этой значимой вехи. В Alibaba Cloud мы начали активно использовать containerd с его первых дней и, благодаря его акценту на простоту и надёжность, сделали containerd контейнерным движком по умолчанию в своём продукте Serverless Kubernetes, предъявляющим высокие требования к производительности и стабильности. Containerd, несомненно, будет основным двигателем эры контейнеров и приведёт к развитию инноваций». — Xinwei, штатный инженер из Alibaba Cloud
Архитектурные улучшения
Архитектура интеграции containerd с Kubernetes дважды изменялась. Каждый её эволюционный шаг стабилизировал и улучшал эффективность стека.
Containerd 1.0 — CRI-Containerd (прекратил существование)
В containerd 1.0 для взаимодействия между Kubelet и containerd требовался демон cri-containerd (о нём мы писали в конце этой статьи — прим. перев.). Этот демон обслуживал запросы к Container Runtime Interface (CRI) от Kubelet и использовал containerd для соответствующего управления контейнерами и образами контейнеров. Такой подход устранял одно дополнительное звено в стеке, если сравнивать с реализацией CRI от Docker (dockershim) — см. иллюстрацию выше.
Однако cri-containerd и containerd 1.0 были двумя отдельными демонами, взаимодействующими по GRPC. Дополнительный демон в этой связке усложнял пользователям жизнь и в понимании устройства, и при развёртывании, а также порождал ненужные накладные расходы на взаимодействие.
Containerd 1.1 — плагин CRI (текущая версия)
В containerd 1.1 демон cri-containerd был переделан в CRI-плагин containerd. Этот плагин встроен в containerd 1.1 и включён по умолчанию. В отличие от cri-containerd, плагин взаимодействует с containerd прямым вызовом нужных функций. Новая архитектура сделала интеграцию более стабильной и производительной, исключив ещё одно звено (GRPC) из стека. Теперь containerd 1.1 можно использовать в Kubernetes напрямую, а демон cri-containerd больше не требуется.
Производительность
Одной из главных задач для выпуска containerd 1.1 было улучшение производительности. Оптимизации проводились в области времени запуска пода и использования ресурсов демоном.
Представленные далее результаты — сравнение containerd 1.1 и Docker 18.03 CE. Интеграция containerd 1.1 использует встроенный CRI-плагин, а интеграция для Docker 18.03 CE работает с dockershim. Результаты были сгенерированы с помощью benchmark'а производительности узлов Kubernetes, который входит в состав e2e-тестов для K8s-узлов. Большая часть данных сравнения доступна публично в node performance dashboard.
Задержка при старте пода
Результаты 105 pod batch startup benchmark показывают, что у интеграции containerd 1.1 меньшая задержка при старте пода, чем у Docker 18.03 CE с dockershim (чем меньше, тем лучше).
CPU и память
В состоянии бездействия интеграция containerd 1.1 со 105 подами потребляет меньше процессора и памяти, чем интеграция Docker 18.03 CE с dockershim. Результаты могут отличаться в зависимости от числа запущенных на узле подов — количество в 105 подов выбрано, т.к. по умолчанию сейчас является максимальным значением для пользовательских подов на узле.
Как видно из графиков ниже, у интеграции containerd 1.1 Kubelet потребляет на 30,89 % меньше CPU и на 11,30 % меньше памяти RSS (resident set size), а также на 12,78 % меньше RSS-памяти потребляет исполняемая среда для контейнеров.
Дополнение от переводчика
Стоит обратить внимание, что продолжает своё развитие и другое альтернативное решение — CRI-O. В частности, на проходящем в эти дни Open Source Summit Japan 2018 сотрудник компании NTT представил доклад с развёрнутым сравнением имеющихся исполняемых сред для контейнеров. И вот как выглядит один из его слайдов, сравнивающих их производительность:
crictl
Консольный интерфейс (CLI) исполняемой среды для контейнеров — полезный инструмент для выявления проблем в системе и приложении. При использовании Docker в качестве контейнерной среды в Kubernetes системные администраторы иногда заходят на узел Kubernetes, чтобы выполнить команды Docker, собрать информацию о системе и/или приложении. Например, они могут воспользоваться docker ps и docker inspect для проверки состояния процесса, docker images для получения списка образов на узле, docker info для получения конфигурации исполняемой среды для контейнеров и т.п.
Для containerd и всех других совместимых с CRI сред, таких как dockershim, мы рекомендуем использовать crictl в качестве CLI-альтернативы консольным командам Docker для анализа проблем на подах, контейнерах и в образах контейнеров, размещённых на узлах Kubernetes.
crictl — утилита, предлагающая схожие с Docker CLI возможности и одинаково работает для всех исполняемых сред для контейнеров, совместимых с CRI. Её можно найти в репозитории kubernetes-incubator/cri-tools; текущая версия — cri-tools v1.11.0 (версия исправлена на актуальный релиз 3-дневной давности вместо v1.0.0-beta.1, указанной в оригинальной статье, — прим. перев.). Хоть утилита crictl и создана быть похожей на Docker CLI, предлагая простой переход для пользователей, полной его копией она не является. О нескольких важных различиях рассказано ниже.
Ограниченность применения: crictl — инструмент для troubleshooting'а
crictl не является заменой команд docker или kubectl — её применение ограничено областью выявления, анализа проблем. Консольный интерфейс Docker предлагает богатый набор команд, что делает его очень полезным инструментом для разработки. Однако это не самый оптимальный вариант для troubleshooting'а на узлах Kubernetes. Некоторые команды Docker (например, docker network и docker build) бесполезны для Kubernetes, а некоторые (например, docker rename) и вовсе могут всё сломать. Цель crictl — предоставить достаточное количество команд для выявления проблем на узлах, которые безопасно использовать в production-окружениии.
Ориентированность на Kubernetes
crictl предлагает более понятное в мире Kubernetes представление контейнеров. Консольный интерфейс Docker не оперирует базовыми концепциями Kubernetes, такими как под (pod) и пространство имён (namespace), что препятствует наглядному представлению контейнеров и подов (о важности этой проблемы — правда, уже в контексте мониторинга — мы недавно рассказывали в этом докладе — прим. перев.). Один из таких примеров — docker ps показывает малопонятные, длинные имена Docker-контейнеров и список pause-контейнеров вместе с контейнерами приложений:
Однако pause-контейнеры — это часть реализации пода, где по одному такому контейнеру используется для каждого пода; они не должны отображаться при выводе контейнеров, входящих в состав пода.
crictl же, напротив, был создан для Kubernetes. В утилите предусмотрены разные наборы команд для подов и контейнеров. Например, crictl pods выводит информацию о подах, а crictl ps — только информацию о контейнерах приложения. Все данные отформатированы в табличное представление:
Другой пример — в crictl pods есть аргумент --namespace, позволяющий фильтровать поды по пространствам имён, определённым в Kubernetes:
Больше информации о том, как использовать crictl с containerd, смотрите здесь:
А как же Docker Engine?
Мы часто слышим такой вопрос: «Означает ли переход на containerd, что я больше не смогу использовать Docker Engine?», — и короткий ответ на него: «НЕТ».
Docker Engine собирают на основе containerd. Следующий релиз Docker Community Edition (Docker CE) будет использовать containerd версии 1.1. Соответственно, у него будет встроенный и включённый по умолчанию CRI-плагин. Это означает, что у пользователей будет возможность продолжать работать с Docker Engine для иных типовых сценариев, а также возможность настроить Kubernetes на использование нижележащего containerd, который поставляется с Docker Engine и который одновременно используется самим Docker Engine на том же узле. Взгляните на архитектурную схему ниже, демонстрирующую, как один и тот же containerd используется Docker Engine и Kubelet:
Поскольку containerd используется и Kubelet, и Docker Engine, пользователи, которые выберут интеграцию с containerd, не только получат все новые возможности для Kubernetes, улучшения в производительности и стабильности, но и опцию использования Docker Engine, как и прежде, для других потребностей.
Механизм пространств имён в containerd гарантирует, что Kubelet и Docker Engine не будут иметь доступ к контейнерам и образам, созданным не ими. Это означает, что они не будут мешать друг другу, а также:
- Пользователи, вводя команду
docker ps, не увидят созданные в Kubernetes контейнеры. Для этого используйтеcrictl ps. И наоборот, пользователи не увидят в Kubernetes или по командеcrictl psконтейнеры, созданные в Docker CLI. Командыcrictl createиcrictl runпредназначены только для troubleshooting'а. Ручной запуск подов или контейнеров с помощьюcrictlна production-узлах не рекомендуется. - Пользователи, вводя команду
docker images, не увидят образы из Kubernetes. Для этого используйте командуcrictl images. И наоборот, Kubernetes не увидит образы, созданные командамиdocker pull,docker loadиdocker build. Для этого используйте командуcrictl pull, а такжеctr cri load, если необходимо загрузить образ.
Резюме
- Containerd 1.1 обладает родной поддержкой CRI. Он может напрямую использоваться Kubernetes.
- Containerd 1.1 готов для production.
- У containerd 1.1 хорошая производительность в смысле времени запуска пода и утилизации системных ресурсов.
- crictl — консольная (CLI) утилита для общения с containerd 1.1 и другими исполняемыми средами для контейнеров, соответствующими CRI, с целью выявления проблем на узле.
- Containerd 1.1 войдёт в следующий стабильный релиз Docker CE. Пользователям будет оставлена возможность продолжать работать с Docker в случаях, не относящихся к Kubernetes, и настраивать Kubernetes на использование нижележащего containerd, входящего в состав Docker.
Хотим поблагодарить всех из Google, IBM, Docker, ZTE, ZJU и индивидуальных разработчиков, которые внесли свой вклад и сделали всё это возможным!
Подробный список изменений в релизе containerd 1.1 смотрите в Release Notes.
Как попробовать
Инструкции по настройке кластера Kubernetes на использование containerd в качестве исполняемой среды по умолчанию:
- для кластера на GCE, поднимаемого с помощью
kube-up.sh, — здесь; - для установки кластера из многих узлов с использованием Ansible и kubeadm — здесь;
- для создания кластера с нуля в Google Cloud — см. «Kubernetes the Hard Way»;
- для инсталляции вручную из tarball-архива — здесь;
- для установки с помощью LinuxKit на локальной виртуальной машине — здесь.
Как внести вклад
CRI-плагин containerd — Open Source-проект на GitHub, входящий в состав containerd: https://github.com/containerd/cri. Все предлагаемые изменения приветствуются в виде идей, тикетов, исправлений. Это руководство по началу работы для разработчиков — хорошая отправная точка для внесения изменений.
P.S. от переводчика
Читайте также в нашем блоге:
- «CRI-O — альтернатива Docker для запуска контейнеров в Kubernetes»;
- «Что и зачем Docker делает в Moby для интеграции с Kubernetes?»;
- «Четыре релиза 1.0 от CNCF и главные анонсы про Kubernetes с KubeCon 2017»;
- «Зачем нужен containerd и почему его отделили от Docker»;
- «В чём суть проекта Moby и почему главным репозиторием Docker вдруг стал moby/moby?»
Автор: shurup
