Кратък преглед и настройка на Kata Containers

Кратък преглед и настройка на Kata Containers
Тази статия ще обсъди как работи Ката контейнери, като ще има и практическа част със свързването им с Docker.

Вече относно често срещаните проблеми с Docker и техните решения беше написано, днес ще опиша накратко изпълнението от Kata Containers. Kata Containers е защитено време за изпълнение на контейнери, базирано на леки виртуални машини. Работата с тях е същата като с други контейнери, но освен това има по-надеждна изолация с помощта на технология за хардуерна виртуализация. Проектът започна през 2017 г., когато общността със същото име завърши сливането на най-добрите идеи от Intel Clear Containers и Hyper.sh RunV, след което продължи работата по поддръжката на различни архитектури, включително AMD64, ARM, IBM p- и z -серия. Освен това се поддържа работа в хипервайзорите QEMU, Firecracker и има интеграция с контейнер. Кодът е достъпен на GitHub под лиценза на MIT.

Основни характеристики

  • Работейки с отделно ядро, като по този начин осигурявате мрежа, памет и I / O изолация, е възможно да се принуди използването на хардуерна изолация, базирана на разширения за виртуализация
  • Поддръжка за индустриални стандарти, включително 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

регулиране

Ще се настройвам за работа с докер, инсталацията му е типична, няма да го описвам по-подробно:

# 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

Рестартирайте докера:

# service docker restart

Функционално тестване

Ако стартирате контейнера преди да рестартирате докера, можете да видите, че 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+container

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

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.00

RAM тест

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

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 контейнери

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

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.00

RAM тест

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

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

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

Данни

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

Съобщение

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

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

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

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

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

  • 20,0%Не, недей...7

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

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

Добавяне на нов коментар