ProHoster > blog > amministrazione > Breve panoramica e configurazione di Kata Containers

Breve panoramica e configurazione di Kata Containers

Breve panoramica e configurazione di Kata Containers
Questo articolo discuterà come funziona Contenitori di Kata, e ci sarà anche una parte pratica con la loro connessione a Docker.

Su problemi comuni con Docker e le loro soluzioni già è stato scritto, oggi descriverò brevemente l'implementazione di Kata Containers. Kata Containers è un runtime di container sicuro basato su macchine virtuali leggere. Lavorare con loro è lo stesso che con altri contenitori, ma in più c'è un isolamento più affidabile utilizzando la tecnologia di virtualizzazione dell'hardware. Il progetto è iniziato nel 2017, quando l'omonima community ha completato la fusione delle migliori idee di Intel Clear Containers e Hyper.sh RunV, dopodiché sono proseguiti i lavori sul supporto di varie architetture, tra cui AMD64, ARM, IBM p- e z -serie. Inoltre, il lavoro è supportato all'interno degli hypervisor QEMU, Firecracker e c'è anche l'integrazione con containerd. Il codice è disponibile su GitHub con licenza MIT.

Caratteristiche principali

  • Lavorando con un core separato, fornendo così l'isolamento di rete, memoria e I/O, è possibile forzare l'uso dell'isolamento hardware basato su estensioni di virtualizzazione
  • Supporto per standard di settore tra cui OCI (formato contenitore), Kubernetes CRI
  • Prestazioni costanti dei normali container Linux, maggiore isolamento senza il sovraccarico delle prestazioni delle normali macchine virtuali
  • Elimina la necessità di eseguire container all'interno di macchine virtuali complete, le interfacce generiche semplificano l'integrazione e il lancio

Installazione

C'è molti opzioni di installazione, prenderò in considerazione l'installazione dai repository, in base al sistema operativo Centos 7.
È importante: Il lavoro di Kata Containers è supportato solo su hardware, anche l'inoltro della virtualizzazione non sempre funziona bisogno di supporto sse4.1 dal processore.

Installare Kata Containers è abbastanza semplice:

Installa le utilità per lavorare con i repository:

# yum -y install yum-utils

Disabilita Selinux (è più corretto configurare, ma per semplicità lo disabilito):

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

Colleghiamo il repository ed eseguiamo l'installazione

# 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

registrazione

Mi configurerò per lavorare con la finestra mobile, la sua installazione è tipica, non la descriverò in modo più dettagliato:

# 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

Apportiamo modifiche a daemon.json:

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

Riavvia la finestra mobile:

# service docker restart

Controllo funzionale

Se avvii il contenitore prima di riavviare la finestra mobile, puoi vedere che uname fornirà la versione del kernel in esecuzione sul sistema principale:

# 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

Dopo un riavvio, la versione del kernel si presenta così:

# 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

Più squadre!

# 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

Test di carico rapido

Per valutare le perdite dovute alla virtualizzazione, eseguo sysbench, come esempio principale prendi questa opzione.

Eseguire sysbench usando Docker+containerd

Test del processore

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

Prova 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

Esecuzione di sysbench utilizzando Docker+Kata Containers

Test del processore

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

Prova 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

In linea di principio la situazione è già chiara, ma è più ottimale eseguire i test più volte, rimuovendo i valori anomali e calcolando la media dei risultati, quindi non eseguo ancora altri test.

risultati

Nonostante il fatto che tali contenitori richiedano da cinque a dieci volte più tempo per avviarsi (il tempo di esecuzione tipico per comandi simili quando si utilizza containerd è inferiore a un terzo di secondo), funzionano comunque abbastanza rapidamente se prendiamo l'ora di inizio assoluta (lì sono esempi sopra, comandi eseguiti in media in tre secondi). Ebbene, i risultati di un rapido test di CPU e RAM mostrano quasi gli stessi risultati, il che non può che rallegrarsi, soprattutto alla luce del fatto che l'isolamento viene fornito utilizzando un meccanismo così ben gestito come kvm.

annuncio

L'articolo è una recensione, ma ti dà l'opportunità di sentire il runtime alternativo. Molte aree di applicazione non sono coperte, ad esempio, il sito descrive la possibilità di eseguire Kubernetes su Kata Containers. Inoltre, puoi anche eseguire una serie di test incentrati sulla ricerca di problemi di sicurezza, l'impostazione di restrizioni e altre cose interessanti.

Chiedo a tutti coloro che hanno letto e riavvolto qui di partecipare al sondaggio, da cui dipenderanno le future pubblicazioni su questo argomento.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Devo continuare a pubblicare articoli su Kata Containers?

  • 80,0%Sì, scrivi di più!28

  • 20,0%No, non…7

35 utenti hanno votato. 7 utenti si sono astenuti.

Fonte: habr.com

Aggiungi un commento