ProHoster > Log > administrasjon > Kort oversikt og oppsett av Kata Containers

Kort oversikt og oppsett av Kata Containers

Kort oversikt og oppsett av Kata Containers
Denne artikkelen vil diskutere hvordan det fungerer Kata containere, og det vil også være en praktisk del med deres tilknytning til Docker.

Om vanlige 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 containerkjøring basert på lette virtuelle maskiner. Å jobbe med dem er det samme som med andre containere, men i tillegg er det en mer pålitelig isolasjon ved hjelp av maskinvarevirtualiseringsteknologi. Prosjektet startet i 2017, da fellesskapet med samme navn fullførte sammenslåingen av de beste ideene fra Intel Clear Containers og Hyper.sh RunV, hvoretter arbeidet fortsatte med støtte for ulike arkitekturer, inkludert AMD64, ARM, IBM p- og z -serie. I tillegg støttes arbeid inne i hypervisorene QEMU, Firecracker, og det er også integrasjon med containerd. Koden er tilgjengelig på GitHub under MIT-lisensen.

Viktige funksjoner

  • Ved å jobbe med en separat kjerne, og dermed gi nettverks-, minne- og I/O-isolasjon, er det mulig å tvinge frem bruk av maskinvareisolasjon basert på virtualiseringsutvidelser
  • Støtte for industristandarder inkludert OCI (beholderformat), Kubernetes CRI
  • Konsekvent ytelse av vanlige Linux-beholdere, økt isolasjon uten ytelsesoverhead til vanlige VM-er
  • Eliminer behovet for å kjøre containere inne i fullverdige virtuelle maskiner, generiske grensesnitt forenkler integrasjon og lansering

Installasjon

Det er Sett med installasjonsalternativer, vil jeg vurdere å installere fra depotene, basert på Centos 7-operativsystemet.
Det er viktig: Kata Containers-arbeid støttes kun på maskinvare, virtualiseringsvideresending fungerer ikke alltid også trenger sse4.1-støtte fra prosessoren.

Å installere Kata-beholdere er ganske enkelt:

Installer verktøy for å jobbe med depoter:

# yum -y install yum-utils

Deaktiver Selinux (det er mer riktig å konfigurere, men for enkelhets skyld deaktiverer jeg det):

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

Vi kobler til depotet og utfører installasjonen

# 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 sette opp for å jobbe med docker, installasjonen er typisk, jeg vil ikke beskrive den mer detaljert:

# 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 gjør endringer i daemon.json:

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

Start docker på nytt:

# service docker restart

Funksjonell testing

Hvis du starter beholderen før du starter docker på nytt, kan du se at uname vil gi versjonen av kjernen som kjø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

Etter en omstart ser kjerneversjonen slik ut:

# 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 lag!

# 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

Rask belastningstesting

For å vurdere tapene fra virtualisering - jeg kjører sysbench, som hovedeksempler ta dette alternativet.

Kjører sysbench ved hjelp av Docker+containerd

Prosessor 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

Kjører sysbench ved hjelp av Docker+Kata Containers

Prosessor 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 prinsippet er situasjonen allerede klar, men det er mer optimalt å kjøre testene flere ganger, fjerne uteliggere og snitte resultatene, så jeg gjør ikke flere tester ennå.

Funn

Til tross for at slike containere tar omtrent fem til ti ganger lengre tid å starte opp (typisk kjøretid for lignende kommandoer ved bruk av containerd er mindre enn en tredjedel av et sekund), fungerer de fortsatt ganske raskt hvis vi tar den absolutte starttiden (der er eksempler ovenfor, kommandoer utført på gjennomsnittlig tre sekunder). Vel, resultatene av en rask test av CPU og RAM viser nesten de samme resultatene, som ikke kan annet enn å glede seg, spesielt i lys av det faktum at isolasjon er gitt ved å bruke en så veldrevet mekanisme som kvm.

Kunngjøring

Artikkelen er en anmeldelse, men den gir deg muligheten til å føle den alternative kjøretiden. Mange bruksområder er ikke dekket, for eksempel beskriver nettstedet muligheten til å kjøre Kubernetes på toppen av Kata Containers. I tillegg kan du også kjøre en serie tester med fokus på å finne sikkerhetsproblemer, sette begrensninger og andre interessante ting.

Jeg ber alle som har lest og spolet tilbake her om å delta i undersøkelsen, som fremtidige publikasjoner om dette temaet vil avhenge av.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Bør jeg fortsette å publisere artikler om Kata Containers?

  • 80,0%Ja, skriv mer!28

  • 20,0%Nei, ikke...7

35 brukere stemte. 7 brukere avsto.

Kilde: www.habr.com

Legg til en kommentar