На пути к успеху: варианты контейнерных движков Kubernetes

Предприятие просто не может насытиться Kubernetes, и это привело к разного рода путанице в отношении открытого исходного кода, коммерческих дистрибутивов и сервисов, которые строятся вокруг него. Чтобы рассеять любые подозрения, что Kubernetes опирается на успех Docker, или, может быть, просто предоставить пользователям более широкий выбор в отношении сред выполнения контейнеров, новый интерфейс CRI (Container Runtime Interface) позволяет подключать любую среду выполнения контейнера, чтобы заменить Docker или rkt.. Чтобы освежить память, контейнерный движок rkt из CoreOS был включен в качестве альтернативы контейнерному движку Docker в Kubernetes версии 1.3. Интерфейс среды выполнения контейнеров был представлен в версии 1.5 на стадии альфа-тестирования и перешел в бета-версию в версии 1.6.

Контейнеры и их двигатели

Определенно возникает путаница, когда такие слова, как среда выполнения контейнера, механизм контейнера и среда выполнения используются взаимозаменяемо, но все они более или менее означают одно и то же в том или ином смысле. Среда выполнения — это фактическая реализация контейнера, которая управляет изоляцией пространства имен и распределением ресурсов на уровне операционной системы.

Просто чтобы пролить немного больше света на эту тему, отметим, что в обязанности среды выполнения входит управление жизненным циклом контейнера, выполнением, контролем, распространением образов и хранением. Все эти функции построены вокруг фрагмента кода, такого как «libcontainer» или «runC», который взаимодействует с ядром для использования таких средств, как контрольные группы и пространства имен, для создания контейнеров поверх операционной системы. Итак, если вы возьмете просто runC, у вас будет среда выполнения, которая требует много работы, но все же будет средой выполнения.

Когда вы поднимаетесь по стеку из среды выполнения, у вас есть все эти дополнительные уровни управления, которые были построены вокруг runC, и это почти то же самое, что и выше, с дополнительными функциями и службами, построенными вокруг скрипта, который помогает контейнеры для спавна.

Замена двигателя

CRI — это API, разработанный Kubernetes и для него, позволяющий любому контейнерному движку взаимодействовать с Kubelet. Kubelet — это часть Kubernetes, которая находится на каждом узле (физическом или виртуальном) и выполняет работу супервизора, чтобы убедиться, что все модули работают в соответствии со спецификацией, указанной в PodSpec или манифесте модуля, который представляет собой JSON или YAML. объект, используемый для описания модуля.

Чтобы понять, как это работает, важно знать, что в традиционном развертывании Kubernetes Kubelet является локальным агентом на каждом хосте, который общается со средой выполнения контейнера. Однако с помощью CRI Kubelet связывается с «прокладкой» CRI через gRPC (инфраструктура RPC с открытым исходным кодом), которая, в свою очередь, передает заказы в среду выполнения.

Прокладка обычно написана специально для обеспечения обратной совместимости и часто используется для поддержки нового API в старой среде или старого API в новой среде. Проще говоря, вы можете представить его как адаптер, который находится между Kubelet и средой выполнения, прозрачно перехватывая вызовы API, изменяя аргументы и перенаправляя операции по мере необходимости.

Чтобы упростить задачу, по словам Дэна Гиллеспи из CoreOS, «это [CRI] — это общий способ обращения к агенту контейнера, который позволяет вам заменять механизмы контейнера».

Поскольку суть заключается в том, что среды выполнения контейнеров можно заменять в Kubernetes, давайте посмотрим, почему кто-то может захотеть заменить механизм Docker и в чем преимущества такого решения.

ВыполнитьC

Опять же, это вариант, который должны рассмотреть люди, которые очень хорошо разбираются в использовании контейнеров, поскольку действительно требует некоторых технических ноу-хау для сборки на runC. Containerd, вероятно, является лучшим вариантом, хотя он может не иметь каких-либо значительных преимуществ, поскольку Docker является подмножеством самого Docker. runC — это низкоуровневая среда выполнения контейнера и реализация спецификации Open Container Initiative, которая предполагает, что пользователь понимает низкоуровневые детали операционной системы и конфигурации хоста. Это требует от пользователя отдельной загрузки или криптографической проверки образов контейнеров для подготовки файловой системы контейнера. runC не имеет централизованного демона и, при правильно настроенном «пакете OCI», может быть интегрирован с системами инициализации, такими как upstart и systemd.

ркт

Первоначально разработанный CoreOS, а теперь являющийся частью CNCF, rkt становится альтернативой № 1 использованию Docker в Kubernetes. Хотя поддержка rkt была реализована в Kubernetes 1.3, ее не подключали через CRI и не запускали в Kubelet, что дает значительные преимущества. Интегрируясь с CRI, rkt получает лучшую поддержку функций Kubernetes, которые не только упрощают разработку и обслуживание, но и помогают проверять сам CRI. Один из недостатков Docker, связанный с тем, что он использует централизованный демон для связи с контейнерами и управления ими, заключается в том, что системы инициализации не могут напрямую отслеживать жизненный цикл фактического процесса контейнера. rkt, с другой стороны, имеет уникальную архитектуру без централизованного демона «инициализации» и вместо этого запускает контейнеры непосредственно из клиентских команд.

ПЛАКАТЬ

Участники Project Atomic, работающие в Red Hat, вместе с участниками многих ведущих компаний, занимающихся Linux, открытым исходным кодом и контейнерами, начали работу над CRI-O, ранее называвшейся OCID. CRI-O — это проект-инкубатор Kubernetes, предназначенный для обеспечения пути интеграции между всеми средами выполнения OCI и Kubelet. Хотя CRI-O использует runC по умолчанию, вы не заблокированы и поддерживаете любую среду выполнения контейнера, соответствующую спецификации OCI. Конечная цель состоит в том, чтобы иметь возможность подключать любые среды выполнения OCI с небольшими изменениями к CRI-O.

Очистить контейнеры

Clear Containers недавно анонсировала версию 2.1.1, и предполагается, что Intel попытается взять лучшее из обоих миров в отношении безопасности виртуальных машин и преимуществ развертывания контейнеров. Поскольку Clear Containers совместимы с инициативой Open Container Initiative (OCI), они не являются плохим вариантом для тех, кто ищет дополнительную безопасность. Принцип его работы заключается в том, что он использует гипервизор QEMU виртуальной машины на основе ядра (KVM) в сочетании с оптимизацией системы и ядра для минимизации потребления памяти при максимальном повышении производительности. Недавние улучшения включают в себя улучшенную связь между хостом и гостем, поддержку Docker exec и Docker run, дополнительную изоляцию рабочей нагрузки с помощью пространств имен, улучшенную обработку TTY, поддержку семантики pod Kubernetes и возможность запускать Clear Containers через интерфейс Container Runtime.

Перелом

Frakti определенно является темной лошадкой, когда речь идет о контейнерных двигателях, хотя о ее включении в CRI ясно сказано. Описанная как среда выполнения контейнеров на основе гипервизора для Kubernetes, Frakti позволяет Kubernetes запускать модули и контейнеры непосредственно внутри гипервизоров через HyperContainer.

Frakti предлагает полное управление жизненным циклом pod/контейнеров/образов, потоковые интерфейсы (exec/attach/port-forward), интеграцию сетевых плагинов CNI, гибридные среды выполнения Docker и Hypercontainer для полной поддержки как обычных, так и привилегированных pod’ов.

Хотя на первый взгляд это обновление означает, что движки контейнеров можно заменять, на самом деле это означает гораздо больше, поскольку оно, по сути, меняет то, как мы смотрим на стек. До сих пор можно было с уверенностью сказать, что движок Docker был сердцем стека, и вы строили вокруг него инструменты оркестрации, мониторинга и оповещения, хранилища и т. д. Что касается CRI, Kubernetes говорит о том, что оркестрация — это сердце стека. stack, а Келси Хайтауэр, инженер Kubernetes, в интервью The New Stack сказал: «Нам на самом деле не нужно многого от любой среды выполнения контейнера — будь то Docker или rkt, им нужно делать очень мало, в основном, просто дать нам API к ядру».