ProHoster > блог > адміністраванне > Кароткі агляд і настройка 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:  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

Тэст аператыўнай памяці

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

Тэст аператыўнай памяці

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

У прынцыпе сітуацыя ўжо зразумелая, але аптымальней запускаць тэсты некалькі разоў, прыбіраючы выкіды і сярэдняя вынікі, таму больш тэстаў пакуль не раблю.

Высновы

Нягледзячы на ​​тое, што запуск такіх кантэйнераў займае прыкладна ў пяць-дзесяць разоў больш часу (тыповы час запуску аналагічных каманд пры выкарыстанні containerd - менш за траціну секунды) - яны ўсё роўна досыць хутка працуюць, калі браць абсалютны час запуску (вышэй ёсць прыклады, каманды выконваюцца ў сярэднім за тры секунды). Ну а вынікі хуткага тэсту CPU і RAM паказваюць фактычна аднолькавыя вынікі, што не можа не цешыць, асабліва ў святле таго, што ізаляцыя забяспечваецца з дапамогай такога добра абкатанага механізму, як kvm.

анонс

Артыкул аглядная, але дае магчымасць памацаць альтэрнатыўны runtime. Не ахоплены многія вобласці прымянення, напрыклад на сайце апісана магчымасць запуску Kubernetes па-над Kata Containers. Дадаткова таксама можна правесці шэраг тэстаў, арыентаваных на пошук праблем з бяспекай, усталёўку абмежаванняў і іншыя цікавыя рэчы.

Прашу ўсіх, хто дачытаў пераматаў сюды прыняць удзел у апытанні, ад якога будуць залежаць будучыя публікацыі на гэтую тэму.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці варта далей публікаваць артыкулы аб Kata Containers?

  • 80,0%Так, пішы яшчэ!

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

Прагаласавалі 35 карыстальнікаў. Устрымаліся 7 карыстальнікаў.

Крыніца: habr.com

Дадаць каментар