ProHoster > Blog > Amministrazione > Panoramica e configurazione di Kata Containers

Panoramica e configurazione di Kata Containers

Panoramica e configurazione di Kata Containers
In questo articolo verrà esaminato il principio di funzionamento Kata Containers, e ci sarà anche una parte pratica riguardante la loro integrazione con Docker.

Di problemi generali con Docker e delle varie soluzioni si è già parlato, oggi descriverò brevemente l'implementazione di Kata Containers. Kata Containers è un runtime per container sicuro basato su macchine virtuali leggere. Lavorare con essi è simile al lavoro con altri container, ma offre un'ulteriore isolamento più affidabile utilizzando la tecnologia di virtualizzazione hardware. Il progetto è iniziato nel 2017, quando la comunità omonima completò la fusione delle migliori idee da Intel Clear Containers e Hyper.sh RunV, dopodiché il lavoro è proseguito sul supporto di diverse architetture, comprese AMD64, ARM, IBM p- e z-series. È anche supportato il funzionamento all'interno di hypervisor come QEMU, Firecracker, e c'è integrazione con containerd. Il codice è disponibile su GitHub sotto licenza MIT.

Caratteristiche principali

  • Funzionamento con un kernel separato, in modo da garantire l'isolamento della rete, della memoria e delle operazioni di input/output, c'è la possibilità di utilizzare forzatamente l'isolamento hardware basato su estensioni di virtualizzazione
  • Supporto per standard industriali, tra cui OCI (formato container), Kubernetes CRI
  • Prestazioni stabili dei container Linux comuni, aumento dell'isolamento senza impatti sulle prestazioni tipici delle macchine virtuali
  • Eliminazione della necessità di eseguire container all'interno di macchine virtuali complete, interfacce standardizzate semplificano l'integrazione e l'avvio

Installazione

C'è numerose opzioni di installazione, esaminerò l'installazione dai repository su un sistema operativo Centos 7.
Importante: il funzionamento di Kata Containers è supportato solo sull'hardware, il passaggio della virtualizzazione non funziona sempre, è necessaria anche la compatibilità con sse4.1 del processore.

L'installazione di Kata Containers è abbastanza semplice:

Installiamo gli strumenti per lavorare con i repository:

# yum -y install yum-utils

Disabilitiamo Selinux (a dire il vero, sarebbe meglio configurarlo, ma per semplicità lo disabilito):

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

Colleghiamo il repository e procediamo con 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

Configurazione

Effettuerò la configurazione per lavorare con docker, la sua installazione è standard, non la descriverò in dettaglio:

# 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

Modifichiamo daemon.json:

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

Riavviamo docker:

# service docker restart

Verifica del funzionamento

Se si avvia il contenitore prima del riavvio di docker — si può vedere che uname mostrerà 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 il riavvio — la versione del kernel appare 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

Altre comandi!

# 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 dalla virtualizzazione — avvio sysbench, utilizzando come esempi principali prendo questa opzione.

Avvio di sysbench con Docker+containerd

Test della CPU

sysbench 1.0: benchmark di valutazione del sistema multi-threaded

Esecuzione del test con le seguenti opzioni:
Numero di thread: 1
Inizializzazione del generatore di numeri casuali dal tempo attuale

Limite di numeri primi: 20000

Inizializzazione dei thread di lavoro...

Thread avviati!

Statistiche generali:
    tempo totale:                          36.7335s
    numero totale di eventi:              10000
    tempo totale impiegato per l'esecuzione degli eventi: 36.7173s
    tempo di risposta:
         min:                                  3.43ms
         avg:                                  3.67ms
         max:                                  8.34ms
         circa il 95 percentile:               3.79ms

Equità dei thread:
    eventi (avg/stddev):           10000.0000/0.00
    tempo di esecuzione (avg/stddev):   36.7173/0.00

Test della memoria RAM

sysbench 1.0: benchmark di valutazione del sistema multi-threaded

Esecuzione del test con le seguenti opzioni:
Numero di thread: 1
Inizializzazione del generatore di numeri casuali dal tempo attuale

Inizializzazione dei thread di lavoro...

Thread avviati!

Operazioni eseguite: 104857600 (2172673.64 ops/sec)

102400.00 MiB trasferiti (2121.75 MiB/sec)

Statistiche generali:
    tempo totale:                          48.2620s
    numero totale di eventi:              104857600
    tempo totale impiegato per l'esecuzione degli eventi: 17.4161s
    tempo di risposta:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.17ms
         circa il 95 percentile:               0.00ms

Equità dei thread:
    eventi (avg/stddev):           104857600.0000/0.00
    tempo di esecuzione (avg/stddev):   17.4161/0.00

Avvio di sysbench con Docker+Kata Containers

Test della CPU

sysbench 1.0: benchmark di valutazione del sistema multi-threaded

Esecuzione del test con le seguenti opzioni:
Numero di thread: 1
Inizializzazione del generatore di numeri casuali dal tempo attuale

Limite di numeri primi: 20000

Inizializzazione dei thread di lavoro...

Thread avviati!

Statistiche generali:
    tempo totale:                          36.5747s
    numero totale di eventi:              10000
    tempo totale impiegato per l'esecuzione degli eventi: 36.5594s
    tempo di risposta:
         min:                                  3.43ms
         avg:                                  3.66ms
         max:                                  4.93ms
         circa il 95 percentile:               3.77ms

Equità dei thread:
    eventi (avg/stddev):           10000.0000/0.00
    tempo di esecuzione (avg/stddev):   36.5594/0.00

Test della memoria RAM

sysbench 1.0: benchmark di valutazione del sistema multi-thread

Esecuzione del test con le seguenti opzioni:
Numero di thread: 1
Inizializzazione del generatore di numeri casuali dall'orario attuale

Inizializzazione dei thread di lavoro...

Thread avviati!

Operazioni effettuate: 104857600 (2450366.94 ops/sec)

102400.00 MiB trasferiti (2392.94 MiB/sec)

Statistiche generali:
    tempo totale:                          42.7926s
    numero totale di eventi:              104857600
    tempo totale impiegato per l'esecuzione degli eventi: 16.1512s
    tempo di risposta:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.43ms
         circa il 95° percentile:               0.00ms

Equità dei thread:
    eventi (avg/stddev):           104857600.0000/0.00
    tempo di esecuzione (avg/stddev):   16.1512/0.00

In linea di massima la situazione è già chiara, ma è più ottimale eseguire i test più volte, eliminando gli scarti e mediando i risultati, quindi per ora non faccio altri test.

Conclusioni

Nonostante il fatto che l'esecuzione di tali container richieda circa cinque-dieci volte più tempo (il tempo tipico di avvio di comandi simili usando containerd è meno di un terzo di secondo) — essi funzionano comunque abbastanza rapidamente, se si considera il tempo assoluto di avvio (qui sopra ci sono esempi, i comandi vengono eseguiti in media in tre secondi). Inoltre, i risultati del test rapido della CPU e della RAM mostrano risultati praticamente identici, il che è soddisfacente, soprattutto considerando che l'isolamento è garantito attraverso un meccanismo ben collaudato come il kvm.

Annuncio

Articolo di revisione, ma offre la possibilità di testare un runtime alternativo. Non sono trattati molti ambiti di applicazione, ad esempio nel sito è descritta la possibilità di eseguire Kubernetes sopra Kata Containers. Inoltre, è possibile eseguire una serie di test focalizzati sulla ricerca di problemi di sicurezza, sull'impostazione di limiti e altre cose interessanti.

Invito tutti coloro che hanno letto o saltato qui a partecipare a un sondaggio, da cui dipenderanno le future pubblicazioni su questo argomento.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.

Vale la pena continuare a pubblicare articoli su Kata Containers?

  • 80,0%Sì, scrivi ancora!28

  • 20,0%No, non importa…7

Hanno votato 35 utenti. 7 utenti si sono astenuti.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster