ProHoster > Блог > Администриране > Кратък обзор и настройка на Kata Containers

Кратък обзор и настройка на Kata Containers

Кратък обзор и настройка на Kata Containers
В тази статия ще бъде разгледан принципът на работа 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: многонишков бенчмарк за оценка на системата

Стартиране на теста с следните опции:
Брой нишки: 1
Инициализиране на генератора на произволни числа от текущото време

Граница на простите числа: 20000

Инициализиране на работни нишки...

Нишките стартираха!

Общи статистики:
    общо време:                          36.7335s
    общ брой събития:                   10000
    общо време, прекарано за изпълнение на събитията: 36.7173s
    време за отговор:
         мин:                                  3.43ms
         средно:                               3.67ms
         макс:                                8.34ms
         приблизително  95 персентил:       3.79ms

Справедливост на нишките:
    събития (средно/стандартно отклонение):  10000.0000/0.00
    време за изпълнение (средно/стандартно отклонение): 36.7173/0.00

Тест на оперативната памет

sysbench 1.0: многонишков бенчмарк за оценка на системата

Стартиране на теста с следните опции:
Брой нишки: 1
Инициализиране на генератора на произволни числа от текущото време

Инициализиране на работни нишки...

Нишките стартираха!

Извършени операции: 104857600 (2172673.64 ops/sec)

102400.00 MiB прехвърлени (2121.75 MiB/sec)

Общи статистики:
    общо време:                          48.2620s
    общ брой събития:                   104857600
    общо време, прекарано за изпълнение на събитията: 17.4161s
    време за отговор:
         мин:                                  0.00ms
         средно:                               0.00ms
         макс:                                0.17ms
         приблизително  95 персентил:       0.00ms

Справедливост на нишките:
    събития (средно/стандартно отклонение):  104857600.0000/0.00
    време за изпълнение (средно/стандартно отклонение): 17.4161/0.00

Стартиране на sysbench с използване на Docker+Kata Containers

Тест на процесора

sysbench 1.0: многонишков бенчмарк за оценка на системата

Стартиране на теста с следните опции:
Брой нишки: 1
Инициализиране на генератора на произволни числа от текущото време

Граница на простите числа: 20000

Инициализиране на работни нишки...

Нишките стартираха!

Общи статистики:
    общо време:                          36.5747s
    общ брой събития:                   10000
    общо време, прекарано за изпълнение на събитията: 36.5594s
    време за отговор:
         мин:                                  3.43ms
         средно:                               3.66ms
         макс:                                4.93ms
         приблизително  95 персентил:       3.77ms

Справедливост на нишките:
    събития (средно/стандартно отклонение):  10000.0000/0.00
    време за изпълнение (средно/стандартно отклонение): 36.5594/0.00

Тест на оперативната памет

sysbench 1.0: многонишков бенчмарк за оценка на системата

Стартиране на теста с следните опции:
Брой нишки: 1
Инициализиране на генератора на произволни числа от текущото време

Инициализиране на работни нишки...

Нишките стартираха!

Извършени операции: 104857600 (2450366.94 ops/sec)

102400.00 MiB прехвърлени (2392.94 MiB/sec)

Общи статистики:
    общо време:                          42.7926s
    общ брой събития:                   104857600
    общо време, прекарано за изпълнение на събитията: 16.1512s
    време за отговор:
         мин:                                  0.00ms
         средно:                               0.00ms
         макс:                                0.43ms
         приблизително  95 персентил:       0.00ms

Справедливост на нишките:
    събития (средно/стандартно отклонение):  104857600.0000/0.00
    време за изпълнение (средно/стандартно отклонение): 16.1512/0.00

В принципе ситуация вече ясна, но оптимално е да се стартират тестове няколко пъти, за да се премахнат аномалиите и да се усреднят резултатите, затова все още не правя повече тестове.

Изводи

Въпреки че стартирането на такива контейнери отнема около пет до десет пъти повече време (типичното време за стартиране на аналогични команди при използване на containerd е по-малко от една трета от секундата) — те все пак работят доста бързо, ако се вземе предвид абсолютното време за стартиране (по-горе има примери, командите се изпълняват средно за три секунди). А резултатите от бързия тест на CPU и RAM показват фактически идентични резултати, което не може да не радва, особено на фона на факта, че изолацията се осигурява чрез така добре проучения механизъм KVM.

Анонс

Статията е обзорна, но предоставя възможност за опознаване на алтернативен runtime. Много области на приложение не са обхванати, например на сайта е описана възможността за стартиране на Kubernetes върху Kata Containers. Освен това, може да се проведат и редица тестове, ориентирани към откритие на проблеми със сигурността, установяване на ограничения и други интересни неща.

Призовавам всички, които прочетоха или преметнаха тук, да вземат участие в анкетата, от която ще зависят бъдещите публикации по тази тема.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.

Трябва ли да продължа да публикувам статии за Kata Containers?

  • 80,0%Да, пиши още!28

  • 20,0%Не, не трябва…7

Гласували 35 потребители. Въздържаха се 7 потребители.

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster