В этой статье будет рассмотрен принцип работы Kata Containers, а также будет практическая часть с их подключением к Docker.
Про общие проблемы с Docker и вариантами их решения уже было написано, сегодня я кратко опишу реализацию от Kata Containers. Kata Containers — безопасная среда выполнения (runtime) контейнеров на основе облегченных виртуальных машин. Работа с ними происходит так же как и с другими контейнерами, но дополнительно имеется более надежная изоляция с использованием технологии виртуализации оборудования. Проект начался в 2017 году, одноименное сообщество тогда завершило слияние лучших идей от Intel Clear Containers и Hyper.sh RunV, после чего работа продолжилась над поддержкой различных архитектур, включая AMD64, ARM, IBM p- и z-series. Дополнительно поддерживается работа внутри гипервизоров QEMU, Firecracker, а также есть интеграция с containerd. Код доступен на GitHub под лицензией MIT.
Основные возможности
- Работа с отдельным ядром, таким образом обеспечивается изоляция сети, памяти и операций ввода-вывода, есть возможность принудительного использования аппаратной изоляции на основе расширений виртуализации
- Поддержка промышленных стандартов, включая OCI (формат контейнеров), Kubernetes CRI
- Стабильная производительность обычных контейнеров Linux, повышение изоляции без накладных расходов, влияющих на производительность обычных виртуальных машин
- Устранение необходимости запуска контейнеров внутри полноценных виртуальных машин, типовые интерфейсы упрощают интеграцию и запуск
Установка
Есть множество вариантов установки, я рассмотрю установку из репозиториев, на основе операционной системы Centos 7.
Важно: работа Kata Containers поддерживается только на железе, проброс виртуализации работает не всегда, также нужна поддержка sse4.1 от процессора.
Установка Kata Containers достаточно простая:
Устанавливаем утилиты для работы с репозиториями:
# yum -y install yum-utilsОтключаем Selinux (правильнее — настроить, но для простоты я его отключаю):
# setenforce 0
# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/configПодключаем репозиторий и производим установку
# source /etc/os-release
# ARCH=$(arch)
# BRANCH="${BRANCH:-stable-1.10}"
# yum-config-manager --add-repo "http://download.opensuse.org/repositories/home:/katacontainers:/releases:/${ARCH}:/${BRANCH}/CentOS_${VERSION_ID}/home:katacontainers:releases:${ARCH}:${BRANCH}.repo"
# yum -y install kata-runtime kata-proxy kata-shimНастройка
Я буду проводить настройку для работы с docker, его установка типовая, я ее не буду расписывать подробнее:
# rpm -qa | grep docker
docker-ce-cli-19.03.6-3.el7.x86_64
docker-ce-19.03.6-3.el7.x86_64
# docker -v
Docker version 19.03.6, build 369ce74a3cВносим правки в daemon.json:
# cat <<EOF > /etc/docker/daemon.json
{
"default-runtime": "kata-runtime",
"runtimes": {
"kata-runtime": {
"path": "/usr/bin/kata-runtime"
}
}
}
EOFПерезапускаем docker:
# service docker restartПроверка работоспособности
Если запустить контейнер до перезапуска docker — можно увидеть, что uname выдаст версию ядра, запущенного на основной системе:
# docker run busybox uname -a
Linux 19efd7188d06 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 GNU/LinuxПосле перезапуска — версия ядра выглядит так:
# docker run busybox uname -a
Linux 9dd1f30fe9d4 4.19.86-5.container #1 SMP Sat Feb 22 01:53:14 UTC 2020 x86_64 GNU/Linux# time docker run busybox mount
kataShared on / type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666)
sysfs on /sys type sysfs (ro,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (ro,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
kataShared on /etc/resolv.conf type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
kataShared on /etc/hostname type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
kataShared on /etc/hosts type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
proc on /proc/bus type proc (ro,relatime)
proc on /proc/fs type proc (ro,relatime)
proc on /proc/irq type proc (ro,relatime)
proc on /proc/sys type proc (ro,relatime)
tmpfs on /proc/acpi type tmpfs (ro,relatime)
tmpfs on /proc/timer_list type tmpfs (rw,nosuid,size=65536k,mode=755)
tmpfs on /sys/firmware type tmpfs (ro,relatime)
real 0m2.381s
user 0m0.066s
sys 0m0.039s# time docker run busybox free -m
total used free shared buff/cache available
Mem: 1993 30 1962 0 1 1946
Swap: 0 0 0
real 0m3.297s
user 0m0.086s
sys 0m0.050sБыстрое нагрузочное тестирование
Для оценки потерь от виртуализации — запускаю sysbench, в качестве основных примеров беру этот вариант.
Запуск sysbench с использованием Docker+containerd
sysbench 1.0: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
General statistics:
total time: 36.7335s
total number of events: 10000
total time taken by event execution: 36.7173s
response time:
min: 3.43ms
avg: 3.67ms
max: 8.34ms
approx. 95 percentile: 3.79ms
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 36.7173/0.00sysbench 1.0: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Initializing worker threads...
Threads started!
Operations performed: 104857600 (2172673.64 ops/sec)
102400.00 MiB transferred (2121.75 MiB/sec)
General statistics:
total time: 48.2620s
total number of events: 104857600
total time taken by event execution: 17.4161s
response time:
min: 0.00ms
avg: 0.00ms
max: 0.17ms
approx. 95 percentile: 0.00ms
Threads fairness:
events (avg/stddev): 104857600.0000/0.00
execution time (avg/stddev): 17.4161/0.00Запуск sysbench с использованием Docker+Kata Containers
sysbench 1.0: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
General statistics:
total time: 36.5747s
total number of events: 10000
total time taken by event execution: 36.5594s
response time:
min: 3.43ms
avg: 3.66ms
max: 4.93ms
approx. 95 percentile: 3.77ms
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 36.5594/0.00sysbench 1.0: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Initializing worker threads...
Threads started!
Operations performed: 104857600 (2450366.94 ops/sec)
102400.00 MiB transferred (2392.94 MiB/sec)
General statistics:
total time: 42.7926s
total number of events: 104857600
total time taken by event execution: 16.1512s
response time:
min: 0.00ms
avg: 0.00ms
max: 0.43ms
approx. 95 percentile: 0.00ms
Threads fairness:
events (avg/stddev): 104857600.0000/0.00
execution time (avg/stddev): 16.1512/0.00В принципе ситуация уже понятная, но оптимальнее запускать тесты несколько раз, убирая выбросы и усредняя результаты, поэтому больше тестов пока не делаю.
Выводы
Несмотря на то, что запуск таких контейнеров занимает примерно в пять-десять раз больше времени (типичное время запуска аналогичных команд при использовании containerd — меньше трети секунды) — они все равно достаточно быстро работают, если брать абсолютное время запуска (выше есть примеры, команды выполняются в среднем за три секунды). Ну а результаты быстрого теста CPU и RAM показывают фактически одинаковые результаты, что не может не радовать, особенно в свете того, что изоляция обеспечивается с помощью такого хорошо обкатанного механизма, как kvm.
Анонс
Статья обзорная, но дает возможность пощупать альтернативный runtime. Не охвачены многие области применения, например на сайте описана возможность запуска Kubernetes поверх Kata Containers. Дополнительно также можно провести ряд тестов, ориентированных на поиск проблем с безопасностью, установку ограничений и прочие интересные вещи.
Прошу всех дочитавших\перемотавших сюда принять участие в опросе, от которого будут зависеть будущие публикации на эту тему.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Стоит ли дальше публиковать статьи о Kata Containers?
-
70,0%Да, пиши еще!14
-
30,0%Нет, не стоит…6
