Автор оригинала: Lantao Liu, инженер программного обеспечения, Google и Mike Brown, Advocate разработчик Open Source, IBM.
Containerd 1.1 работает с Kubernetes, начиная с версии 1.10, и поддерживает все функции Kubernetes. Тестовые возможности containerd на Google Cloud Platform в инфраструктуре тестирования Kubernetes теперь эквивалентны Docker (см. тестовую панель мониторинга).
Мы рады, что containerd быстро развивается. Alibaba Cloud начал активно использовать containerd с первого дня его существования. Он же благодаря простоте и надежности стал идеальным контейнерным движком для нашего Serverless Kubernetes, который требует высокой производительности и стабильности. Несомненно, containerd станет основным механизмом эпохи контейнеров и продолжит свой инновационный марш.
— Xinwei, штатный инженер в Alibaba Cloud
Развитие архитектуры
Архитектура интеграции containerd в Kubernetes улучшилась в два раза. Каждый шаг делал стек более стабильным и эффективным.Containerd 1.0 — CRI-Containerd (более не используется)
Для containerd 1.0 требуется демон cri-containerd, чтобы оперировать между Kubelet и containerd. Cri-containerd обрабатывал заявки на сервисе Container Runtime Interface (CRI) от Kubelet и использовал containerd для управления контейнерами и образами контейнера. По сравнению с реализацией Docker CRI (dockershim), он делает в стеке на один переход меньше.
Однако cri-containerd и containerd 1.0 все же были двумя разными демонами, которые взаимодействовали через grpc. Дополнительный демон внутри цикла делает его более сложным для понимания и развертывания, и добавляет накладные расходы.
Containerd 1.1 — CRI Plugin (текущий)
В containerd 1.1 демон cri-containerd переделан в containerd CRI-плагин. CRI-плагин встроен в containerd 1.1 и включен по умолчанию. В отличие от cri-containerd, CRI-плагин взаимодействует с containerd через прямой вызов функций. Эта новая архитектура делает интеграцию более стабильной и эффективной, и устраняет еще один grpc-переход в стеке. Пользователи могут использовать Kubernetes с containerd 1.1 напрямую. Демон cri-containerd больше не нужен.
Производительность
Одной из основных задач релиза container 1.1 было повышение производительности. Она оптимизирована по задержке запуска пода и использованию ресурсов демона.Сравним containerd 1.1 и Docker 18.03 CE. Интеграция containerd 1.1 использует CRI-плагин, встроенный в containerd; интеграция Docker 18.03 CE использует dockershim.
Результаты получены эталонным тестом производительности Kubernetes, который является частью теста e2e ноды Kubernetes. Основные показатели бенчмарка выведены на панель производительности ноды containerd.
Задержка запуска пода
Результаты теста «105 pod batch startup benchmark» показывают, что интеграция containerd 1.1 имеет меньшую задержку запуска подов, чем интеграция Docker 18.03 CE с dockershim (чем меньше, тем лучше).
Процессор и память
В устойчивом состоянии с 105 подами интеграция containerd 1.1 потребляет меньше процессора и памяти, чем интеграция Docker 18.03 CE с dockershim. Показатели зависят от количества работающих подов на ноде, мы взяли 105, поскольку это по умолчанию максимальное значение пользовательских подов на ноду.Как показано на диаграммах ниже, по сравнению с интеграцией Docker 18.03 CE с dockershim, интеграция containerd 1.1 использует меньше: на 30,89% процессора kubelet, на 68,13% контейнерного процессора, на 11,30% RSS-памяти kubelet, на 12,78% контейнерной RSS-памяти.
crictl
Интерфейс командной строки контейнера (CLI) -— полезный инструмент для устранения неполадок системы и приложений. При использовании Docker для контейнеризации в Kubernetes системные администраторы иногда подключаются к ноде Kubernetes, чтобы запустить команды Docker для сбора информации о системе и/или приложении. Например, можно использовать docker ps и docker inspect для проверки состояния процесса приложения, docker images для составления списка образов на ноде и docker info для определения конфигурации среды выполнения контейнера и т. д.Для containerd и других CRI-совместимых сред выполнения контейнера, например dockershim, мы рекомендуем использовать crictl как замену CLI на Docker CLI для устранения неполадок в работе подов, контейнеров и образов контейнеров на нодах Kubernetes.
crictl — аналог Docker CLI для устранения неполадок ноды Kubernetes, crictl работает со всеми CRI-совместимыми контейнерными средами. Он есть в репозитории kubernetes-incubator/cri-tools, текущая версия — v1.0.0-beta.1. crictl похож на Docker CLI, чтобы облегчить переход на него, но это не одно и то же. Есть несколько важных отличий.
Ограниченная область примерения — crictl это инструмент траблшутинга
crictl применяется для траблшутинга, он не заменяет docker или kubectl. CLI Docker имеет больше команд, что делает его инструментом разработки. Но он не подходит для устранения неполадок на нодах Kubernetes. Некоторые команды Docker не подходят Kubernetes, такие как docker network и docker build, а некоторые даже могут сломать систему, например docker rename. crictl предлагает исключительно команды для устранения неполадок нод, что безопаснее в продакшене.Связка с Kubernetes
crictl предлагает подход к контейнерам, заточенный под Kubernetes. В Docker CLI отсутствуют основные концепции Kubernetes, например pod и namespace, поэтому он не может обеспечить четкое представление о контейнерах и подах. Например, docker ps показывает кривые длинные имена контейнеров Docker и приостановленные (pause) контейнеры и приложений в общей куче:
Однако приостановленные (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 для типичных Docker-задач, а также настроить Kubernetes так, чтобы он обращался ко встроенному containerd, с которым на той же ноде работает Docker Engine. См. рисунок архитектуры ниже, где к containerd обращаются Docker Engine и Kubelet:
Поскольку containerd используют и Kubelet, и Docker Engine, пользователи, которые выбирают интеграцию containerd, не только получат новые возможности, производительность и стабильность Kubernetes, но и смогут сохранить Docker Engine для специфических задач.
Механизм namespase containerd гарантирует, что Kubelet и Docker Engine не будут обращаться к контейнерам и образам друг друга. Как следствие:
- Команда docker ps не покажет контейнеры, созданные Kubernetes. Вместо нее используйте crictl ps. И наоборот, команда crictl ps не покажет контейнеры в Kubernetes, созданные Docker CLI. Команды crictl create и crictl runp предназначены только для траблшутинга. Не рекомендуется вручную запускать под или контейнер с crictl на продакшн нодах.
- Команда docker images не покажет скачанные образы Kubernetes. Вместо нее используйте команду crictl images. И наоборот, Kubernetes не видит образы, созданные командами docker pull, docker load или docker build. Для загрузки образов используйте команду circle pull и ctr cri load.
Итог
- Containerd 1.1 поддерживает CRI. Kubernetes может его использовать напрямую.
- Containerd 1.1 готов к продакшн.
- У Containerd 1.1 хорошая производительность по задержке запуска пода и использованию системных ресурсов.
- crictl — инструмент CLI, чтобы обмениваться информацией с containerd 1.1 и другими CRI-совместимыми контейнерными средами для траблшутинга нод.
- Следующий стабильный релиз Docker CE будет включать containerd 1.1. Пользователи могут сохранить Docker для задач, не связанных с Kubernetes, и настроить Kubernetes на использование containerd, встроенного в Docker.
- Мы благодарим всех контрибьюторов, в том числе из Google, IBM, Docker, ZTE, ZJU!
- Подробный список изменений в выпуске containerd 1.1 см. в примечаниях к релизу:
- https://github.com/containerd/containerd/releases/tag/v1.1.0
Попробуйте
Настройка кластера Kubernetes с помощью containerd:- Для кластера качества продакшн на GCE, представленном с помощью kube-up.sh смотрите здесь.
- Для мультинодового установщика кластера и создания шагов с помощью ansible и kubeadm см. здесь.
- Для создания кластера с нуля в Google Cloud см. Kubernetes the Hard Way.
- Для пользовательской установки из релиза tar-архива см. здесь.
- Для установки с помощью LinuxKit на локальную виртуальную машину см. здесь.
Контрибьюция
Плагин CRI-containerd — проект github с открытым исходным кодом внутри containerd https://github.com/containerd/cri. Приветствуем идеи, найденные проблемы и их решения. Не знаете, с чего начать — займитесь мануалом для разработчиков.Сообщество
Проект разрабатывается и поддерживается членами сообщества Kubernetes SIG-Node и сообществом containerd. Мы будем рады услышать отзывы от вас. Присоединиться к сообществам:- сайт сообщества sig-node
- Slack:
containerd channel in https://dockr.ly/community
- Список рассылки: https://groups.google.com/forum/#!forum/kubernetes-sig-node
