Kort oversigt og opsætning af Kata Containere

Kort oversigt og opsætning af Kata Containere
Denne artikel vil diskutere, hvordan det virker Kata containere, og der vil også være en praktisk del med deres forbindelse til Docker.

Om almindelige problemer med Docker og deres løsninger allerede var skrevet, i dag vil jeg kort beskrive implementeringen fra Kata Containers. Kata Containers er en sikker container-runtime baseret på lette virtuelle maskiner. Arbejdet med dem er det samme som med andre containere, men derudover er der en mere pålidelig isolering ved hjælp af hardwarevirtualiseringsteknologi. Projektet startede i 2017, hvor fællesskabet af samme navn gennemførte sammenlægningen af ​​de bedste ideer fra Intel Clear Containers og Hyper.sh RunV, hvorefter arbejdet fortsatte med support til forskellige arkitekturer, herunder AMD64, ARM, IBM p- og z -serie. Derudover understøttes arbejde inde i hypervisorerne QEMU, Firecracker, og der er også integration med containerd. Koden er tilgængelig på GitHub under MIT-licensen.

Nøglefunktioner

  • Ved at arbejde med en separat kerne, der således giver netværk, hukommelse og I/O-isolering, er det muligt at tvinge brugen af ​​hardware-isolering baseret på virtualiseringsudvidelser
  • Understøttelse af industristandarder inklusive OCI (containerformat), Kubernetes CRI
  • Konsekvent ydeevne af almindelige Linux-containere, øget isolation uden ydeevneoverhead fra almindelige VM'er
  • Eliminer behovet for at køre containere inde i fuldgyldige virtuelle maskiner, generiske grænseflader forenkler integration og lancering

Installation

Der er mange installationsmuligheder, vil jeg overveje at installere fra lagrene, baseret på Centos 7-operativsystemet.
Det er vigtigt: Kata Containers arbejde understøttes kun på hardware, virtualiseringsvideresendelse virker heller ikke altid har brug for sse4.1 support fra processoren.

Installation af Kata Containers er ret simpelt:

Installer hjælpeprogrammer til at arbejde med arkiver:

# yum -y install yum-utils

Deaktiver Selinux (det er mere korrekt at konfigurere, men for nemheds skyld deaktiverer jeg det):

# setenforce 0
# sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

Vi forbinder depotet og udfører installationen

# 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

justering

Jeg vil konfigurere til at arbejde med docker, dens installation er typisk, jeg vil ikke beskrive den mere detaljeret:

# 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

Vi foretager ændringer til daemon.json:

# cat <<EOF > /etc/docker/daemon.json
{
  "default-runtime": "kata-runtime",
  "runtimes": {
    "kata-runtime": {
      "path": "/usr/bin/kata-runtime"
    }
  }
}
EOF

Genstart docker:

# service docker restart

Sundhedstjek

Hvis du starter containeren, før du genstarter docker, kan du se, at uname vil give den version af kernen, der kører på hovedsystemet:

# 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

Efter en genstart ser kerneversionen sådan ud:

# 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

Flere hold!

# 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

Hurtig belastningstest

For at vurdere tabene fra virtualisering - kører jeg sysbench, som de vigtigste eksempler tage denne mulighed.

Kører sysbench ved hjælp af Docker+containerd

Processor test

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 test

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

Kører sysbench ved hjælp af Docker+Kata Containers

Processor test

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 test

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

I princippet er situationen allerede klar, men det er mere optimalt at køre testene flere gange, fjerne outliers og gennemsnit af resultaterne, så jeg laver ikke flere test endnu.

Fund

På trods af det faktum, at sådanne containere tager omkring fem til ti gange længere tid at starte op (typisk køretid for lignende kommandoer ved brug af containerd er mindre end en tredjedel af et sekund), fungerer de stadig ret hurtigt, hvis vi tager den absolutte starttid (der er eksempler ovenfor, kommandoer udført på et gennemsnit på tre sekunder). Nå, resultaterne af en hurtig test af CPU og RAM viser næsten de samme resultater, som ikke kan andet end at glæde sig, især i lyset af, at isolering er tilvejebragt ved hjælp af en så veldrevet mekanisme som kvm.

annoncering

Artiklen er en anmeldelse, men den giver dig mulighed for at mærke den alternative runtime. Mange anvendelsesområder er ikke dækket, for eksempel beskriver webstedet muligheden for at køre Kubernetes oven på Kata Containers. Derudover kan du også køre en række tests med fokus på at finde sikkerhedsproblemer, sætte begrænsninger og andre interessante ting.

Jeg beder alle dem, der har læst og spole tilbage her, om at deltage i undersøgelsen, som fremtidige publikationer om dette emne vil afhænge af.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Skal jeg fortsætte med at udgive artikler om Kata Containers?

  • 80,0 %Ja, skriv mere!28

  • 20,0 %Nej, lad være...7

35 brugere stemte. 7 brugere undlod at stemme.

Kilde: www.habr.com

Tilføj en kommentar