🥇Kurze Übersicht und Einrichtung von Kata Containers

In diesem Artikel wird das Funktionsprinzip behandelt Kata Containers, sowie ein praktischer Teil zur Anbindung an Docker.

Über allgemeine Probleme mit Docker und mögliche Lösungen wurde bereits geschrieben, heute werde ich kurz die Implementierung von Kata Containers beschreiben. Kata Containers bieten eine sichere Ausführungsumgebung (Runtime) für Container, die auf leichtgewichtigen virtuellen Maschinen basiert. Die Verwendung erfolgt analog zu anderen Containern, jedoch mit einer zusätzlichen, robusteren Isolierung, die auf Hardware-Virtualisierungstechnologien basiert. Das Projekt wurde 2017 initiiert, als die gleichnamige Gemeinschaft die besten Ideen von Intel Clear Containers und Hyper.sh RunV zusammenführte und anschließend die Unterstützung verschiedener Architekturen, einschließlich AMD64, ARM, sowie IBM p- und z-Serien, weiterentwickelte. Außerdem wird die Nutzung innerhalb von Hypervisoren wie QEMU und Firecracker sowie eine Integration mit containerd unterstützt. Der Code ist verfügbar unter GitHub unter der MIT-Lizenz.

Grundlegende Funktionen

Die Arbeit mit einem separaten Kernel gewährleistet somit die Isolierung von Netzwerk, Speicher und Ein-/Ausgabeoperationen, und es besteht die Möglichkeit, hardwarebasierte Isolierung über Virtualisierungs-Erweiterungen zwingend zu nutzen.
Unterstützung von Industriestandards, einschließlich OCI (Containerformat) und Kubernetes CRI
Stabile Leistung herkömmlicher Linux-Container, erhöhte Isolation ohne die Leistung regulärer virtueller Maschinen zu beeinträchtigen
Beseitigung der Notwendigkeit, Container innerhalb vollständiger virtueller Maschinen auszuführen, standardisierte Schnittstellen erleichtern die Integration und den Start

Installation von

Es gibt eine Vielzahl von Installationsoptionen; ich werde die Installation aus den Repositories auf Basis des Betriebssystems CentOS 7 betrachten.
Wichtig: Der Betrieb von Kata Containers wird nur auf Hardware unterstützt; die Virtualisierungseinspeisung funktioniert nicht immer, ebenso ist eine Unterstützung von sse4.1 vom Prozessor erforderlich.

Die Installation von Kata Containers ist recht einfach:

Wir installieren die Tools zur Arbeit mit Repositories:

# yum -y install yum-utils

Wir deaktivieren Selinux (korrekter wäre es, dies zu konfigurieren, aber der Einfachheit halber deaktiviere ich es):

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

Wir verbinden das Repository und führen die Installation durch

# 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

Konfiguration

Ich werde die Konfiguration für die Arbeit mit Docker durchführen; seine Installation ist Standard, ich werde sie nicht näher beschreiben:

# 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

Wir nehmen Änderungen an daemon.json vor:

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

Wir starten Docker neu:

# service docker restart

Überprüfung der Funktionsfähigkeit

Wenn Sie einen Container vor dem Neustart von Docker starten, können Sie sehen, dass uname die Kernelversion des auf dem Hauptsystem ausgeführten Kernels anzeigt:

# 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

Nach dem Neustart sieht die Kernelversion so aus:

# 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

Weitere Befehle!

# 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

Schnelle Lasttests

Um die Verluste durch Virtualisierung zu bewerten, führe ich sysbench mit den folgenden Beispielen aus: ich wähle diese Variante.

Start von sysbench mit Docker+containerd

CPU-Test

sysbench 1.0: Multi-Threaded System Evaluierungsbench

Der Test wird mit den folgenden Optionen ausgeführt:
Anzahl der Threads: 1
Initialisierung des Zufallszahlengenerators basierend auf der aktuellen Zeit

Limit der Primzahlen: 20000

Initialisierung der Arbeits-Threads...

Threads gestartet!

Allgemeine Statistiken:
    Gesamtdauer:                        36,7335s
    Gesamtanzahl der Ereignisse:        10000
    Gesamtzeit der Ereignisausführung:  36,7173s
    Reaktionszeit:
         min:                            3,43ms
         avg:                            3,67ms
         max:                            8,34ms
         ca. 95. Perzentil:              3,79ms

Fairness der Threads:
    Ereignisse (avg/stddev):           10000,0000/0,00
    Ausführungszeit (avg/stddev):      36,7173/0,00

RAM-Test

sysbench 1.0: Multi-Threaded-Systembewertungstest

Testausführung mit den folgenden Optionen:
Anzahl der Threads: 1
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert

Initialisierung der Arbeits-Threads...

Threads gestartet!

Durchgeführte Vorgänge: 104857600 (2172673,64 ops/sec)

102400,00 MiB übertragen (2121,75 MiB/sec)

Allgemeine Statistiken:
    Gesamtzeit:                          48,2620s
    Gesamtzahl der Ereignisse:           104857600
    Gesamtzeit für die Ereignisausführung: 17,4161s
    Antwortzeit:
         min:                                  0,00ms
         avg:                                  0,00ms
         max:                                  0,17ms
         ca. 95. Perzentil:                 0,00ms

Fairness der Threads:
    Ereignisse (avg/stddev):           104857600,0000/0,00
    Ausführungszeit (avg/stddev):   17,4161/0,00

Start von sysbench mit Docker+Kata-Containern

CPU-Test

sysbench 1.0: Multi-Threaded-Systembewertungstest

Testausführung mit den folgenden Optionen:
Anzahl der Threads: 1
Zufallszahlengenerator wird von der aktuellen Zeit initialisiert

Grenze der Primzahlen: 20000

Initialisierung der Arbeits-Threads...

Threads gestartet!

Allgemeine Statistiken:
    Gesamtzeit:                          36,5747s
    Gesamtzahl der Ereignisse:           10000
    Gesamtzeit für die Ereignisausführung: 36,5594s
    Antwortzeit:
         min:                                  3,43ms
         avg:                                  3,66ms
         max:                                  4,93ms
         ca. 95. Perzentil:                 3,77ms

Fairness der Threads:
    Ereignisse (avg/stddev):           10000,0000/0,00
    Ausführungszeit (avg/stddev):   36,5594/0,00

RAM-Test

sysbench 1.0: Mehrthread-Performance-Benchmark

Test wird mit folgenden Optionen ausgeführt:
Anzahl der Threads: 1
Initialisierung des Zufallszahlengenerators aus der aktuellen Zeit

Initialisierung der Arbeiter-Threads...

Threads gestartet!

Durchgeführte Operationen: 104857600 (2450366,94 ops/sec)

Übertragene Daten: 102400,00 MiB (2392,94 MiB/sec)

Allgemeine Statistiken:
    Gesamtzeit:                          42,7926s
    Gesamtzahl der Ereignisse:          104857600
    Gesamtzeit für die Ereignisausführung: 16,1512s
    Antwortzeit:
         min:                                  0,00ms
         avg:                                  0,00ms
         max:                                  0,43ms
         ca.  95. Perzentil:                  0,00ms

Fairness der Threads:
    Ereignisse (avg/stddev):           104857600,0000/0,00
    Ausführungszeit (avg/stddev):   16,1512/0,00

Die Situation ist im Grunde klar, aber es ist besser, die Tests mehrmals durchzuführen, um Ausreißer zu entfernen und die Ergebnisse zu mitteln. Daher führe ich vorerst keine weiteren Tests durch.

Fazit

Obwohl das Starten solcher Container etwa fünf- bis zehnmal länger dauert (die typische Startzeit vergleichbarer Befehle mit containerd liegt bei weniger als einem Drittel einer Sekunde) — arbeiten sie dennoch relativ schnell, wenn man die absolute Startzeit betrachtet (oben sind Beispiele, die Befehle werden im Durchschnitt in drei Sekunden ausgeführt). Die Ergebnisse des schnellen CPU- und RAM-Tests zeigen praktisch identische Resultate, was erfreulich ist, insbesondere im Hinblick darauf, dass die Isolation durch einen bewährten Mechanismus wie KVM gewährleistet wird.

Ankündigung

Dieser Artikel ist eine Übersicht, bietet jedoch die Möglichkeit, einen alternativen Runtime auszuprobieren. Viele Anwendungsbereiche werden nicht abgedeckt, zum Beispiel wird auf der Website die Möglichkeit beschrieben, Kubernetes über Kata Containers auszuführen. Zusätzlich können eine Reihe von Tests durchgeführt werden, die darauf abzielen, Sicherheitsprobleme zu finden, Einschränkungen zu setzen und andere interessante Aspekte zu erkunden.

Ich bitte alle, die hier angekommen sind, an der Umfrage teilzunehmen, von der zukünftige Veröffentlichungen zu diesem Thema abhängen werden.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte melden Sie sich an.Sind Sie an Contour interessiert?