Хабрахабр

[Перевод] Интеграция containerd с Kubernetes, заменяющая Docker, готова к production

перев.: Мы уже не раз писали о containerd и других исполняемых средах для Kubernetes. Прим. Текст написан сотрудниками компаний Google и IBM, которые (конечно, вместе с Docker Inc) вносят значительный вклад в совершенствование containerd. Новая публикация — перевод недавнего анонса важной вехи в развитии containerd, опубликованного в официальном блоге проекта Kubernetes.

Очередные 6 месяцев разработки привели к тому, что интеграция стала общедоступной! Ранее в блоге — в заметке Containerd Brings More Container Runtime Options for Kubernetes — мы представляли альфа-версию интеграции containerd с Kubernetes. 1 в качестве исполняемой среды для контейнеров в Kubernetes-кластерах в production. Это означает, что теперь вы можете использовать containerd 1.

1 работает с Kubernetes версии 1. Containerd 1. В инфраструктуре тестов Kubernetes покрытие тестами интеграции с containerd на Google Cloud Platform стало таким же, что и у интеграции с Docker (см. 10 и выше, поддерживает все возможности Kubernetes. test dashboard).

В Alibaba Cloud мы начали активно использовать containerd с его первых дней и, благодаря его акценту на простоту и надёжность, сделали containerd контейнерным движком по умолчанию в своём продукте Serverless Kubernetes, предъявляющим высокие требования к производительности и стабильности. «Очень рады увидеть, что containerd быстро достиг этой значимой вехи. — Xinwei, штатный инженер из Alibaba Cloud Containerd, несомненно, будет основным двигателем эры контейнеров и приведёт к развитию инноваций».

Архитектурные улучшения

Архитектура интеграции containerd с Kubernetes дважды изменялась. Каждый её эволюционный шаг стабилизировал и улучшал эффективность стека.

Containerd 1.0 — CRI-Containerd (прекратил существование)

0 для взаимодействия между Kubelet и containerd требовался демон cri-containerd (о нём мы писали в конце этой статьи — прим. В containerd 1. Этот демон обслуживал запросы к Container Runtime Interface (CRI) от Kubelet и использовал containerd для соответствующего управления контейнерами и образами контейнеров. перев.). иллюстрацию выше. Такой подход устранял одно дополнительное звено в стеке, если сравнивать с реализацией CRI от Docker (dockershim) — см.

0 были двумя отдельными демонами, взаимодействующими по GRPC. Однако cri-containerd и containerd 1. Дополнительный демон в этой связке усложнял пользователям жизнь и в понимании устройства, и при развёртывании, а также порождал ненужные накладные расходы на взаимодействие.

Containerd 1.1 — плагин CRI (текущая версия)

1 демон cri-containerd был переделан в CRI-плагин containerd. В containerd 1. 1 и включён по умолчанию. Этот плагин встроен в containerd 1. Новая архитектура сделала интеграцию более стабильной и производительной, исключив ещё одно звено (GRPC) из стека. В отличие от cri-containerd, плагин взаимодействует с containerd прямым вызовом нужных функций. 1 можно использовать в Kubernetes напрямую, а демон cri-containerd больше не требуется. Теперь containerd 1.

Производительность

Одной из главных задач для выпуска containerd 1.1 было улучшение производительности. Оптимизации проводились в области времени запуска пода и использования ресурсов демоном.

1 и Docker 18. Представленные далее результаты — сравнение containerd 1. Интеграция containerd 1. 03 CE. 03 CE работает с dockershim. 1 использует встроенный CRI-плагин, а интеграция для Docker 18. Большая часть данных сравнения доступна публично в node performance dashboard. Результаты были сгенерированы с помощью benchmark'а производительности узлов Kubernetes, который входит в состав e2e-тестов для K8s-узлов.

Задержка при старте пода

Результаты 105 pod batch startup benchmark показывают, что у интеграции containerd 1.1 меньшая задержка при старте пода, чем у Docker 18.03 CE с dockershim (чем меньше, тем лучше).

CPU и память

В состоянии бездействия интеграция containerd 1.1 со 105 подами потребляет меньше процессора и памяти, чем интеграция Docker 18.03 CE с dockershim. Результаты могут отличаться в зависимости от числа запущенных на узле подов — количество в 105 подов выбрано, т.к. по умолчанию сейчас является максимальным значением для пользовательских подов на узле.

1 Kubelet потребляет на 30,89 % меньше CPU и на 11,30 % меньше памяти RSS (resident set size), а также на 12,78 % меньше RSS-памяти потребляет исполняемая среда для контейнеров. Как видно из графиков ниже, у интеграции containerd 1.

Дополнение от переводчика

Стоит обратить внимание, что продолжает своё развитие и другое альтернативное решение — 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.

Её можно найти в репозитории kubernetes-incubator/cri-tools; текущая версия — cri-tools v1. crictl — утилита, предлагающая схожие с Docker CLI возможности и одинаково работает для всех исполняемых сред для контейнеров, совместимых с CRI. 0 (версия исправлена на актуальный релиз 3-дневной давности вместо v1. 11. 0-beta. 0. перев.). 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 Community Edition (Docker CE) будет использовать containerd версии 1. Docker Engine собирают на основе containerd. Соответственно, у него будет встроенный и включённый по умолчанию CRI-плагин. 1. Взгляните на архитектурную схему ниже, демонстрирующую, как один и тот же containerd используется Docker Engine и Kubelet: Это означает, что у пользователей будет возможность продолжать работать с Docker Engine для иных типовых сценариев, а также возможность настроить Kubernetes на использование нижележащего containerd, который поставляется с Docker Engine и который одновременно используется самим Docker Engine на том же узле.

Поскольку 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 и индивидуальных разработчиков, которые внесли свой вклад и сделали всё это возможным!

1 смотрите в Release Notes. Подробный список изменений в релизе containerd 1.

Как попробовать

Инструкции по настройке кластера 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. от переводчика

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть