Salta al contenuto > 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 con il loro collegamento a Docker.

Sulle problematiche generali di Docker e le soluzioni proposte è già stato scritto, oggi descriverò brevemente l'implementazione di Kata Containers. Kata Containers è un ambiente di esecuzione (runtime) sicuro per container basato su macchine virtuali leggere. La loro operatività è simile a quella di altri container, ma offre un'ulteriore isolamento più robusto attraverso la tecnologia di virtualizzazione hardware. Il progetto è iniziato nel 2017, con la comunità che ha completato la fusione delle migliori idee da Intel Clear Containers e Hyper.sh RunV, continuando poi a sviluppare il supporto per varie architetture, inclusi AMD64, ARM, IBM p- e z-series. Inoltre, si supporta l'operatività all'interno di hypervisor come QEMU, Firecracker, e c'è integrazione con containerd. Il codice è disponibile su GitHub sotto licenza MIT.

Funzionalità principali

  • Lavorando con un kernel separato, si garantisce così l'isolamento della rete, della memoria e delle operazioni di input-output, con la possibilità di forzare l'uso dell'isolamento hardware basato su estensioni di virtualizzazione.
  • Supporto degli standard industriali, inclusi OCI (formato dei container), Kubernetes CRI
  • Prestazioni stabili dei normali container Linux, maggiore isolamento senza overhead che influisce sulle prestazioni delle normali macchine virtuali
  • Eliminazione della necessità di eseguire container all'interno di macchine virtuali complete, interfacce standardizzate semplificano integrazione e avvio

Installazione

Sì molti opzioni di installazione, considererò l'installazione dai repository, basata sul sistema operativo CentOS 7.
Importante: il funzionamento di Kata Containers è supportato solo sull'hardware, il pass-through della virtualizzazione non funziona sempre, inoltre è necessaria la compatibilità con sse4.1 del processore.

L'installazione di Kata Containers è piuttosto semplice:

Installiamo gli strumenti per lavorare con i repository:

# yum -y install yum-utils

Disabilitiamo Selinux (più correttamente — 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

Impostazione

Effettuerò la configurazione per lavorare con Docker, la sua installazione è standard, non la descriverò più dettagliatamente:

# 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 il 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 container prima del riavvio di docker, si può notare che uname restituirà 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 veloce

Per valutare le perdite dalla virtualizzazione, avvio sysbench, utilizzando come principali esempi prendo questa opzione.

Avvio di sysbench utilizzando Docker+containerd

Test della CPU

sysbench 1.0: benchmark di valutazione multi-threaded del sistema

Esecuzione del test con le seguenti opzioni:
Numero di thread: 1
Inizializzando il generatore di numeri casuali dall'ora attuale

Limitazione dei numeri primi: 20000

Inizializzando i thread di lavoro...

Thread avviati!

Statistiche generali:
    tempo totale:                          36.7335s
    numero totale di eventi:              10000
    tempo totale impiegato dall'esecuzione dell'evento: 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 di sistema multi-threaded

Eseguendo il 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 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

Esecuzione di sysbench utilizzando Docker+Kata Containers

Test della CPU

sysbench 1.0: benchmark di valutazione di sistema multi-threaded

Eseguendo il test con le seguenti opzioni:
Numero di thread: 1
Inizializzazione del generatore di numeri casuali dall'orario 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 multi-threaded di sistema

Esecuzione del test con le seguenti opzioni:
Numero di thread: 1
Inizializzazione del generatore di numeri casuali dall'ora 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

La situazione è abbastanza chiara, ma è più ottimale eseguire i test più volte, escludendo le anomalie e mediando i risultati, quindi per ora non eseguo ulteriori test.

Conclusioni

Nonostante il fatto che avviare tali container richieda circa cinque-dieci volte più tempo (il tempo tipico per l'avvio di comandi simili utilizzando containerd è inferiore a un terzo di secondo) — funzionano comunque abbastanza rapidamente se consideriamo il tempo assoluto di avvio (qui sopra ci sono esempi, i comandi vengono eseguiti in media in tre secondi). Inoltre, i risultati del rapido test CPU e RAM mostrano risultati praticamente identici, il che è certamente positivo, specialmente alla luce del fatto che l'isolamento è garantito da un meccanismo ben collaudato come kvm.

Annuncio

Questo è un articolo di overview, ma offre l'opportunità di esplorare un runtime alternativo. Non sono coperte molte aree di applicazione, ad esempio sul sito è descritta l'opzione di eseguire Kubernetes sopra Kata Containers. Inoltre, è possibile condurre una serie di test mirati a scoprire problemi di sicurezza, stabilire limitazioni e altre cose interessanti.

Chiedo a tutti coloro che hanno letto o saltato a questo punto di partecipare a un sondaggio, da cui dipenderà la pubblicazione futura su questo argomento.

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

Dovremmo continuare a pubblicare articoli su Kata Containers?

  • 80,0%Sì, scrivi ancora!

  • 20,0%No, non ne vale la pena...

Hanno votato 35 utenti. Si sono astenuti 7 utenti.

Fonte: habr.com

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