Проект Kata Containers ориентирован на безопасность инфраструктуры контейнеров
Open Source-сообщество OpenStack, занимающееся IaaS-облаками, расширяет свою деятельность на безопасные контейнеры.
На конференции KubeCon в Остине (шт. Техас) организация OpenStack Foundation представила Open Source-проект Kata Containers. Этот новый проект контейнеризации объединяет Intel Clear Containers с runV компании Hyper. Какова цель? Соединить безопасность, присущую виртуальным машинам (VM), с быстродействием и управляемостью технологий контейнеров.
Изоляция контейнеров и их безопасность при этом должны обеспечиваться без издержек для производительности, возникающих, когда контейнеры запускаются в VM. Обычно контейнеры эксплуатируют в VM для безопасности, но при этом теряется ряд преимуществ использования контейнеров, связанных с малыми затратами ресурсов. Цель проекта runV была сделать так, чтобы VM работали наподобие контейнеров. В Kata этот подход комбинируется с проектом Intel Clear Containers, использующим внутрипроцессорную Intel Virtualization Technology (VT) для запуска контейнеров в облегченных виртуальных машинах. С Kata эти контейнеры должны запускаться в runV.
При этом проект Kata Containers предполагает независимость от аппаратуры. Он также рассчитан на совместимость со спецификацией Open Container Initiative (OCI) и CRI (интерфейсом исполняемой среды контейнеров) Kubernetes.
Kata Containers предлагает пользователям мощную возможность запускать инструменты управления контейнерами прямо на «голом железе» без ущерба для изоляции рабочих нагрузок. При сравнении с эксплуатацией контейнеров в виртуализованной инфраструктуре, как это обычно сегодня делают, новый подход сулит такие плюсы, как ускорение времени загрузки и эффективность по затратам.
Проект Kata Containers составлен из шести компонентов: Agent, Runtime, Proxy, Shim, Kernel и упаковки QEMU 2.9, с открытым кодом. Несмотря на присутствие QEMU и runV, проект предполагает использование разнообразных гипервизоров.
Может возникнуть естественный вопрос: «А почему группа, занимающаяся облаками по модели IaaS (инфраструктура как сервис), такая как OpenStack, вдруг занялась контейнерами?» Именно это я и спросил у Джонатана Брайса, исполнительного директора OpenStack Foundation. Он ответил следующее: «Kata Containers нацелен на операторов. Вам не надо знать, что находится внутри. Проект решает реальные проблемы максимального использования облачных ресурсов и безопасности».
Короче говоря, это поможет пользователям OpenStack. При этом Брайс добавил: «Хотя пользователи OpenStack могут извлечь преимущества новой технологии, Kata Containers является независимым проектом с собственным техническим руководством и базой контрибуторов. Помимо облаков на основе OpenStack сообщество Kata Containers ориентируется на всех популярных провайдеров инфраструктуры и все фреймворки оркестровки контейнеров, рассчитывая на сотрудничество с соответствующими организациями».
Кроме Intel и Hyper с момента запуска проекта его поддерживают следующие компании: 99cloud, AWcloud, Canonical, China Mobile, City Network, CoreOS, Dell EMC, EasyStack, Fiberhome, Google, Huawei, JD.com, Mirantis, NetApp, Red Hat, SUSE, Tencent, Ucloud, UnitedStack и ZTE. Короче говоря, он изначально заручился широкой поддержкой.
Комбинируя две Open Source-кодовые базы и ставя проект под открытое управление, сообщество Kata Containers преследует изначальную цель привлекать больше контрибуторов, поддерживать разнообразные аппаратные архитектуры и содействовать внедрению технологии. Контрибуторы смогут рассчитывать на возможности сотрудничества с различными upstream-сообществами, занимающимися инфраструктурой и оркестровкой контейнеров, включая Kubernetes, Docker, OCI, CRI, CNI, QEMU, KVM, HyperV и OpenStack.
Название Kata Containers происходит от греческого слова Καταπίστευμα (катапистевма), означающего «доверять что-то кому-либо». Оно также ассоциируется с японским словом для системы упражнений по обучению боевым искусствам. В любом смысле оно обещает сделать контейнеры более эффективными для их пользователей.
Используем Kata Containers в Kubernetes
Данная статья продолжает тему с Kata Containers, поднятую в прошлый раз. Сегодня я буду настраивать Kubernetes для работы с Kata Containers.
В этой статье я буду использовать containerd, который умеет обрабатывать RuntimeClass начиная с версии 1.2.0. Настраивать будем три сервера, используемая операционная система Centos 7.
Кратко остановлюсь на Containerd Runtime V2, который был реализован начиная с Kata Containers 1.5.0, разницу между V1 и V2 можно увидеть на изображении ниже.
Архитектура Kata Containers runtime v2 по сравнению с v1
Проводим работу со всеми тремя серверами, если не сказано иначе, имена серверов kata-node1, kata-node2, kata-node3.
Установка
Устанавливаем Kata Containers на чистый сервер с Centos 7, ставим все аналогично предыдущей статье. установку Docker проводить не нужно.
Далее устанавливаем зависимости для containerd:
Качаем и ставим containerd (можно установить чуть более старую версию из репозитория docker, надо 1.2.0+ — в принципе должно работать тоже, но я не проверял):
Ставим пакеты для k8s:
Настройка containerd
Создаем конфигурационные файлы для containerd:
Проверка containerd
Смотрим, что все верно подключили:
Настройка Kubernetes
Подключаем containerd в k8s:
Создаем кластер, команду вводим на kata-node1:
Команду kubeadm join копируем с параметрами и запускаем на остальных серверах.
Проверка kubernetes
На локальной машине должен быть установлен kubectl, дальнейшая работа будет именно с ним
Пробуем создать untrusted сервис:
Смотрим на серверах, появился ли процесс от Kata Containers:
Выводы
Kata Containers являются важнейшим этапом развития облачных технологий, предоставляя безопасность виртуальных машин вместе со скоростью контейнеров. Также можно без особых затрат перейти на использование Kata Containers в Kubernetes, поскольку обеспечивается бесшовная миграция сервисов благодаря стандартизации.
Kata containers что это
Learn more about Ant Group’s Kata Containers production use case at the OpenInfra Live Keynotes
Learn
An overview of the Kata Containers project
Kata Containers are as light and fast as containers and integrate with the container management layers—including popular orchestration tools such as Docker and Kubernetes (k8s)—while also delivering the security advantages of VMs.
#Kata Containers Project Update
#An Intro to Kata Containers
Demos
Kata Containers in the News
What’s the advantage of Kata Containers?
Kata Containers perform like containers, but provide the workload isolation and security advantages of VMs. It combines the benefits of containers and VMs.
Who uses Kata Containers?
Kata Containers is still in its formational stages, but the technical basis for the project—Clear Containers and runV—are used globally at enterprise scale by organizations like JD.com, China’s largest ecommerce company (by revenue).
Will this require a rebuild of my Docker containers? Does it work with Kubernetes?
Kata Containers is OCI (Open Container Initiative) compliant, the same standard shared by Docker containers as well as the container runtime interface (CRI) for Kubernetes.
What’s the operating system? Do I get to pick that?
Kata Containers supports Linux (host and guest) for now. On the host side, we have installation instructions for several popular distributions. We also have out-of-the-box support for Clear Linux, Fedora, and CentOS 7 rootfs images through the OSBuilder which can also be used to roll your own guest images.
What’s the license for Kata Containers?
Kata Containers is open source and licensed under the Apache 2.0 license, which means it is free to use, free to distribute, and does not require modifications to be contributed back to the project. Read more about Apache 2.0.
Where is the code?
You can find the code at github.com/kata-containers. You can find links to the original repositories from Intel and Hyper.sh on the katacontainers.io homepage.
Can I contribute to it?
Yes! Kata Containers is open source, which means it relies on contributors like you! After the initial code base merger, all areas of Kata Containers will be open for contribution. Between now and the merger completion, you can contribute:
How is Kata Containers governed?
Kata Containers is driven by an Architecture Committee. The Architecture Committee, whose members are elected by contributors, oversees architectural decisions, including standardization, and resolves technical disagreements between project maintainers. Kata Containers is managed by the Open Infrastructure Foundation, which provides event organization, code of conduct management, and other administrative support.
Are there Kata meetups?
We don’t have any scheduled yet, but you can expect to see some on the calendar soon! Want to organize a Kata Containers Meetup? Email info at katacontainers.io to get involved.
Is this an OpenStack project?
Kata Containers is managed by the Open Infrastructure Foundation, but is not a part of the OpenStack cloud infrastructure project. From a technical perspective, Kata Containers can be run on OpenStack, but can also be run on other cloud solutions like Azure and Google Cloud Platform. The Open Infrastructure Foundation brings its 8 years of open source project and community management to this new project to provide community support, technical structure, and event management.
Различия между Docker, containerd, CRI-O и runc
Появление Docker привело к взрывному росту популярности контейнеров, но с тех пор появились и другие инструменты. К сожалению, разобраться в них может быть совсем непросто. Но мы попробуем! И если вы считаете себя единственным, кто всего этого пока не понимает, не волнуйтесь. Это не так!
Что такое Docker?
Существует разница между компанией Docker, контейнерами Docker, образами Docker и инструментами Docker, к которым мы все привыкли. Важно понимать, что Docker — лишь один из инструментов для работы с контейнерами; существуют и другие инструменты, причем некоторые из них поддерживает сама компания Docker.
Как видите, вы не единственный, кто сбит с толку. Давайте разберёмся, чем отличаются Docker, containerd и CRI-O. Это особенно важно, если вы работаете с Kubernetes.
Обзор экосистемы контейнеров
Экосистема контейнеров состоит из множества технологий, специальной терминологии и компаний, конкурирующих друг с другом. К счастью, компании иногда заключают хрупкое перемирие, чтобы согласовать некоторые стандарты. Эти стандарты помогают добиться совместимости между различными инструментами и избежать зависимости от одной компании или проекта. Основные стандарты, о которых необходимо знать:
Container Runtime Interface (CRI) определяет API между Kubernetes и Container Runtime (средой выполнения контейнеров).
Open Container Initiative (OCI) определяет стандарт образов и контейнеров.
На этой иллюстрации показано, как Docker, Kubernetes, OCI, CRI, containerd и runc вписываются в эту экосистему:
Docker
Мы начнем с Docker, потому что это самый популярный инструмент для работы с контейнерами в настоящий момент. Для многих само название «Docker» является синонимом слова «контейнер».
Компания Docker создала очень удобный инструмент для работы с контейнерами. Docker можно установить на ноутбук (Docker Desktop) или сервер (Docker Engine). Он содержит набор инструментов, упрощающих труд разработчиков и DevOps—инженеров. С помощью Docker CLI можно создавать образы контейнеров, работать с репозиториями, создавать, запускать и управлять контейнерами.
Docker состоит из трех проектов:
containerd: Linux Daemon, который управляет контейнерами и запускает их. Он загружает образы из репозитория, управляет хранилищем и сетью, а также контролирует работу контейнеров.
runc: низкоуровневая среда выполнения контейнеров, которая создает и запускает контейнеры.
Dockershim: Docker в Kubernetes
Важно помнить, что Kubernetes поддерживает только Container Runtime, которые работают с Container Runtime Interface (CRI), но Docker не поддерживает этот стандарт напрямую, поэтому Kubernetes включает компонент под названием dockershim, который необходим для работы с Docker.
Компонент, который функционирует как мост между различными API, обеспечивая совместимость.
В дальнейшем Kubernetes откажется от поддержки dockershim и, соответственно, Docker и будет работать только с Container Runtime, поддерживающими Container Runtime Interface (CRI) — containerd или CRI-O.
Но это не означает, что Kubernetes не сможет запускать контейнеры из Docker—образов. И containerd, и CRI-O могут запускать образы в формате Docker (фактически в формате OCI), они просто делают это без использования команды docker и Docker Daemon.
Docker—образы
Container Runtime Interface (CRI)
CRI — это API, который Kubernetes использует для управления различными Container Runtime, создающими и управляющими контейнерами. CRI упрощает для Kubernetes использование различных Container Runtime. Вместо того, чтобы включать в Kubernetes поддержку каждой из них, используется стандарт CRI. При этом задача управления контейнерами полностью ложится на Container Runtime.
Поэтому, если вы можете использовать containerd для запуска контейнеров, вы также можете использовать CRI-O, потому что они поддерживают стандарт CRI. При этом, если вы конечный пользователь, то вам не важно, какая Container Runtime используется.
Помните, что Red Hat (проект OpenShift) использует CRI-O и отвечает за его поддержку (безопасность, исправления ошибок и т. д.). В то время как Docker поддерживает containerd.
Какая Container Runtime используется в Kubernetes
containerd
сontainerd — это Container Runtime, которая раньше была частью Docker. Реализует спецификацию CRI. Умеет скачивать образы из репозитория и управляет ими, а затем передает их Container Runtime нижнего уровня (о ней речь пойдет дальше), которая фактически создает и запускает процессы контейнера.
сontainerd был выделен из проекта Docker, чтобы сделать Docker модульным. Таким образом, Docker сам использует containerd. Когда вы устанавливаете Docker, он также устанавливает containerd. Кроме того, сontainerd использует собственный плагин для поддержки CRI в Kubernetes.
CRI-O — это еще одна Container Runtime, реализующая Container Runtime Interface (CRI). Она была специально создана с нуля при поддержке Red Hat, IBM, Intel и SUSE как Container Runtime для Kubernetes. Это альтернатива containerd, которая также позволяет загружать образы контейнеров из репозиториев, управлять ими и запускать Container Runtime нижнего уровня для запуска процессов контейнера.
Open Container Initiative (OCI)
OCI — это группа компаний, которые поддерживают спецификацию формата образа контейнера и метода запуска контейнеров. Идея OCI заключается в том, что вы можете выбирать между различными Container Runtime, которые соответствуют этой спецификации. При этом каждая из них может иметь разные реализации нижнего уровня. Например, у вас, может быть, одна OCI-совместимая Container Runtime для ваших хостов Linux и одна для ваших хостов Windows. В этом заключается преимущество стандартизации.
runc — это еще одна среда выполнения контейнера, совместимая с OCI, которая запускает процессы контейнеров. runc называют эталонной реализацией OCI.
Что такое эталонная реализация?
Эталонная реализация — это программное обеспечение, в котором реализованы все требования спецификации или стандарта. В случае с OCI runc предоставляет все функции, ожидаемые от OCI-совместимой среды выполнения.
Вот несколько альтернатив runc:
crun: среда выполнения контейнеров, написанная на C (в отличие от runc, которая написана на Go).
kata-runtime: из проекта Katacontainers, который реализует спецификацию OCI как отдельные небольшие виртуальные машины (аппаратная виртуализация).
Есть ли аналоги runc для Windows?
runc — это инструмент для запуска контейнеров в Linux. В Windows всё немного иначе. Эквивалент runc — это служба Microsoft Host Compute Service (HCS). Она содержит инструмент под названием runhcs, который является форком runc и также реализует спецификацию Open Container Initiative.
Подведем итоги
Docker — это лишь часть всей экосистемы контейнеров. Существуют открытые стандарты: CRI и OCI, и несколько Container Runtime с поддержкой CRI: containerd, runc, CRI-O и, конечно, сам Docker. Возможно, скоро мы увидим множество новых реализаций Container Runtime с поддержкой стандартов CRI и OCI.
Kata containers что это
Kata Containers Architecture
This is an architectural overview of Kata Containers, based on the 2.0 release.
The primary deliverable of the Kata Containers project is a CRI friendly shim. There is also a CRI friendly library API behind them.
The Kata Containers runtime is compatible with the OCI runtime specification and therefore works seamlessly with the Kubernetes* Container Runtime Interface (CRI) through the CRI-O* and Containerd* implementation.
Kata Containers creates a QEMU*/KVM virtual machine for pod that kubelet (Kubernetes) creates respectively.
For any given container, both the init process and all potentially executed commands within that container, together with their related I/O streams, need to go through the VSOCK interface exported by QEMU.
The container workload, that is, the actual OCI bundle rootfs, is exported from the host to the virtual machine. In the case where a block-based graph driver is configured, virtio-scsi will be used. In all other cases a virtio-fs VIRTIO mount point will be used. kata-agent uses this mount point as the root filesystem for the container processes.
How Kata Containers maps container concepts to virtual machine technologies, and how this is realized in the multiple hypervisors and VMMs that Kata supports is described within the virtualization documentation
The hypervisor will launch a virtual machine which includes a minimal guest kernel and a guest image.
The guest kernel is passed to the hypervisor and used to boot the virtual machine. The default kernel provided in Kata Containers is highly optimized for kernel boot time and minimal memory footprint, providing only those services required by a container workload. This is based on a very current upstream Linux kernel.
Kata Containers supports both an initrd and rootfs based minimal guest image.
Root filesystem image
The default packaged root filesystem image, sometimes referred to as the «mini O/S», is a highly optimized container bootstrap system based on Clear Linux. It provides an extremely minimal environment and has a highly optimized boot path.
A compressed cpio(1) archive, created from a rootfs which is loaded into memory and used as part of the Linux startup process. During startup, the kernel unpacks it into a special instance of a tmpfs that becomes the initial root filesystem.
kata-agent is a process running in the guest as a supervisor for managing containers and processes running within those containers.
For the 2.0 release, the kata-agent is rewritten in the RUST programming language so that we can minimize its memory footprint while keeping the memory safety of the original GO version of kata-agent used in Kata Container 1.x. This memory footprint reduction is pretty impressive, from tens of megabytes down to less than 100 kilobytes, enabling Kata Containers in more use cases like functional computing and edge computing.
The kata-agent execution unit is the sandbox. A kata-agent sandbox is a container sandbox defined by a set of namespaces (NS, UTS, IPC and PID). shimv2 can run several containers per VM to support container engines that require multiple containers running inside a pod.
containerd-shim-kata-v2 heavily utilizes the virtcontainers package, which provides a generic, runtime-specification agnostic, hardware-virtualized containers library.
The actual configuration file paths can be determined by running:
Most users will not need to modify the configuration file.
The file is well commented and provides a few «knobs» that can be used to modify the behavior of the runtime and your chosen hypervisor.
The configuration file is also used to enable runtime debug output.
Containers will typically live in their own, possibly shared, networking namespace. At some point in a container lifecycle, container engines will set up that namespace to add the container to a network which is isolated from the host network, but which is shared between containers
In order to do so, container engines will usually add one end of a virtual ethernet ( veth ) pair into the container networking namespace. The other end of the veth pair is added to the host networking namespace.
This is a very namespace-centric approach as many hypervisors/VMMs cannot handle veth interfaces. Typically, TAP interfaces are created for VM connectivity.
To overcome incompatibility between typical container engines expectations and virtual machines, Kata Containers networking transparently connects veth interfaces with TAP ones using Traffic Control:
Kata Containers maintains support for MACVTAP, which was an earlier implementation used in Kata. TC-filter is the default because it allows for simpler configuration, better CNI plugin compatibility, and performance on par with MACVTAP.
Kata Containers has deprecated support for bridge due to lacking performance relative to TC-filter and MACVTAP.
Kata Containers supports both CNM and CNI for networking management.
Kata Containers has developed a set of network sub-commands and APIs to add, list and remove a guest network endpoint and to manipulate the guest route table.
The following diagram illustrates the Kata Containers network hotplug workflow.
Container workloads are shared with the virtualized environment through virtio-fs.
The devicemapper snapshotter is a special case. The snapshotter uses dedicated block devices rather than formatted filesystems, and operates at the block level rather than the file level. This knowledge is used to directly use the underlying block device instead of the overlay file system for the container root file system. The block device maps to the top read-write layer for the overlay. This approach gives much better I/O performance compared to using virtio-fs to share the container file system.
Kata Containers has the ability to hotplug and remove block devices, which makes it possible to use block devices for containers started after the VM has been launched.
Kubernetes* is a popular open source container orchestration engine. In Kubernetes, a set of containers sharing resources such as networking, storage, mount, PID, etc. is called a Pod. A node can have multiple pods, but at a minimum, a node within a Kubernetes cluster only needs to run a container runtime and a container agent (called a Kubelet).
A Kubernetes cluster runs a control plane where a scheduler (typically running on a dedicated master node) calls into a compute Kubelet. This Kubelet instance is responsible for managing the lifecycle of pods within the nodes and eventually relies on a container runtime to handle execution. The Kubelet architecture decouples lifecycle management from container execution through the dedicated gRPC based Container Runtime Interface (CRI).
In other words, a Kubelet is a CRI client and expects a CRI implementation to handle the server side of the interface. CRI-O* and Containerd* are CRI implementations that rely on OCI compatible runtimes for managing container instances.
Kata Containers is an officially supported CRI-O and Containerd runtime. Refer to the following guides on how to set up Kata Containers with Kubernetes:
In order for the Kata Containers runtime (or any virtual machine based OCI compatible runtime) to be able to understand if it needs to create a full virtual machine or if it has to create a new container inside an existing pod’s virtual machine, CRI-O adds specific annotations to the OCI configuration file ( config.json ) which is passed to the OCI compatible runtime.
Mixing VM based and namespace based runtimes
Note: Since Kubernetes 1.12, the Kubernetes RuntimeClass has been supported and the user can specify runtime without the non-standardized annotations.
Kata Containers utilizes the Linux kernel DAX (Direct Access filesystem) feature to efficiently map some host-side files into the guest VM space. In particular, Kata Containers uses the QEMU NVDIMM feature to provide a memory-mapped virtual device that can be used to DAX map the virtual machine’s root filesystem into the guest memory address space.
Mapping files using DAX provides a number of benefits over more traditional VM file and device mapping mechanisms:
Kata Containers uses the following steps to set up the DAX mappings:
Information on the use of NVDIMM via QEMU is available in the QEMU source code
