ProHoster > Blog > Administration > Kurze Übersicht und Einrichtung von Kata Containers

Kurze Übersicht und Einrichtung von Kata Containers

Kurze Übersicht und Einrichtung von Kata Containers
In diesem Artikel wird das Funktionsprinzip erläutert Kata Containers, außerdem gibt es einen praktischen Teil zur Anbindung an Docker.

Über allgemeine Probleme mit Docker und Lösungsmöglichkeiten wurde bereits geschrieben,heute werde ich die Implementierung von Kata Containers kurz beschreiben. Kata Containers sind eine sichere Ausführungsumgebung (Runtime) für Container, die auf leichtgewichtigen virtuellen Maschinen basieren. Die Arbeit mit ihnen erfolgt genauso wie mit anderen Containern, bietet jedoch eine zuverlässigere Isolierung durch den Einsatz von Hardware-Virtualisierungstechnologie. Das Projekt begann im Jahr 2017, als die gleichnamige Community das Beste aus Intel Clear Containers und Hyper.sh RunV vereinte und danach die Unterstützung verschiedener Architekturen, einschließlich AMD64, ARM, IBM p- und z-Series, weiterentwickelte. Zudem wird die Arbeit innerhalb von Hypervisoren wie QEMU, Firecracker unterstützt, und es gibt eine Integration mit containerd. Der Code ist verfügbar unter GitHub unterliegt der MIT-Lizenz.

Hauptmerkmale

  • Die Arbeit mit einem separaten Kernel gewährleistet somit die Isolierung von Netzwerk, Speicher und Ein-/Ausgabeoperationen, es ist möglich, die Hardware-Isolierung mithilfe von Virtualisierungs-Features zu erzwingen.
  • Unterstützung von Industriestandards, einschließlich OCI (Container-Format), Kubernetes CRI.
  • Stabile Leistung von regulären Linux-Containern, erhöhte Isolierung ohne Overhead, der die Leistung von herkömmlichen virtuellen Maschinen beeinträchtigt.
  • Die Notwendigkeit, Container innerhalb vollständiger virtueller Maschinen auszuführen, entfällt, standardisierte Schnittstellen vereinfachen die Integration und den Start.

Installation

Ja eine Vielzahl Für die Installation werde ich die Installation aus den Repositories auf der Basis des Betriebssystems Centos 7 betrachten.
Wichtig: Die Arbeit von Kata Containers wird nur auf Hardware unterstützt, die Virtualisierungsdurchleitung funktioniert nicht immer, außerdem wird die Unterstützung von sse4.1 vom Prozessor benötigt.

Die Installation von Kata Containers ist recht einfach:

Wir installieren die Werkzeuge zur Arbeit mit Repositories:

# yum -y install yum-utils

Wir deaktivieren Selinux (korrekter wäre es, es zu konfigurieren, aber zur Vereinfachung deaktiviere ich es):

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

Wir aktivieren 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

Einstellungen

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

# 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 in 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

Healthcheck

Wenn man einen Container vor dem Neustart von Docker startet, kann man sehen, dass uname die Kernelversion anzeigt, die auf dem Hauptsystem läuft:

# 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

Noch mehr 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

Zur Bewertung der Verluste durch Virtualisierung führe ich sysbench aus, als Hauptbeispiele Ich wähle diese Variante.

Ausführung von sysbench mit Docker+containerd

CPU-Test

sysbench 1.0: Multi-Threaded Systembewertungsbenchmark

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

Grenze der Primzahlen: 20000

Initialisierung der Arbeits-Threads...

Threads gestartet!

Allgemeine Statistiken:
    Gesamtzeit:                          36.7335s
    Gesamtanzahl der Ereignisse:         10000
    Gesamtzeit für die Ausführung der Ereignisse: 36.7173s
    Antwortzeit:
         min:                               3.43ms
         avg:                               3.67ms
         max:                               8.34ms
         ca. 95. Perzentil:                3.79ms

Gleichheit der Threads:
    Ereignisse (avg/stddev):            10000.0000/0.00
    Ausführungszeit (avg/stddev):      36.7173/0.00

Speichertest

sysbench 1.0: Multi-Threaded Systembewertungsbenchmark

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

Initialisierung der Arbeits-Threads...

Threads gestartet!

Durchgeführte Operationen: 104857600 (2172673.64 ops/sec)

102400.00 MiB übertragen (2121.75 MiB/sec)

Allgemeine Statistiken:
    Gesamtzeit:                          48.2620s
    Gesamtanzahl der Ereignisse:         104857600
    Gesamtzeit für die Ausführung der Ereignisse: 17.4161s
    Antwortzeit:
         min:                               0.00ms
         avg:                               0.00ms
         max:                               0.17ms
         ca. 95. Perzentil:                0.00ms

Gleichheit der Threads:
    Ereignisse (avg/stddev):            104857600.0000/0.00
    Ausführungszeit (avg/stddev):      17.4161/0.00

Ausführung von sysbench mit Docker+Kata Containers

CPU-Test

sysbench 1.0: Multi-Threaded Systembewertungsbenchmark

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

Grenze der Primzahlen: 20000

Initialisierung der Arbeits-Threads...

Threads gestartet!

Allgemeine Statistiken:
    Gesamtzeit:                          36.5747s
    Gesamtanzahl der Ereignisse:         10000
    Gesamtzeit für die Ausführung der Ereignisse: 36.5594s
    Antwortzeit:
         min:                               3.43ms
         avg:                               3.66ms
         max:                               4.93ms
         ca. 95. Perzentil:                3.77ms

Gleichheit der Threads:
    Ereignisse (avg/stddev):            10000.0000/0.00
    Ausführungszeit (avg/stddev):      36.5594/0.00

Speichertest

sysbench 1.0: Multi-Threaded Systembewertungsbenchmark

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

Initialisierung der Arbeits-Threads...

Threads gestartet!

Durchgeführte Operationen: 104857600 (2450366.94 ops/sec)

102400.00 MiB übertragen (2392.94 MiB/sec)

Allgemeine Statistiken:
    Gesamtzeit:                          42.7926s
    Gesamtanzahl der Ereignisse:         104857600
    Gesamtzeit für die Ausführung der Ereignisse: 16.1512s
    Antwortzeit:
         min:                               0.00ms
         avg:                               0.00ms
         max:                               0.43ms
         ca. 95. Perzentil:                0.00ms

Gleichheit der Threads:
    Ereignisse (avg/stddev):            104857600.0000/0.00
    Ausführungszeit (avg/stddev):      16.1512/0.00

Im Grunde ist die Situation bereits klar, aber es ist optimaler, die Tests mehrmals durchzuführen, um Ausreißer zu entfernen und die Ergebnisse zu mitteln. Deshalb mache ich vorerst keine weiteren Tests.

Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.

Obwohl das Starten solcher Container ungefähr fünf- bis zehnmal länger dauert (typische Startzeit ähnlicher Befehle bei Verwendung von containerd liegt unter einem Drittel Sekunde) – sie arbeiten dennoch schnell genug, 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 eigentlich identische Resultate, was besonders erfreulich ist, zumal die Isolierung mit einem so gut etablierten Mechanismus wie KVM gewährleistet wird.

Ankündigung

Der Artikel ist eine Übersicht, bietet aber die Möglichkeit, eine alternative Runtime zu testen. Viele Anwendungsbereiche sind nicht abgedeckt, z.B. wird auf der Seite die Möglichkeit beschrieben, Kubernetes über Kata Containers zu starten. Zudem können auch eine Reihe von Tests durchgeführt werden, die auf die Suche nach Sicherheitsproblemen, das Setzen von Limits und andere interessante Aspekte abzielen.

Ich bitte alle, die bis hierher gelesen oder vorgespult haben, an der Umfrage teilzunehmen, von deren Ergebnissen zukünftige Veröffentlichungen zu diesem Thema abhängen werden.

Nur registrierte Benutzer können an der Umfrage teilnehmen. Bitte einloggen.

Sollten wir weiterhin Artikel über Kata Containers veröffentlichen?

  • 80,0%Ja, schreibe mehr!28

  • 20,0%Nein, das sollte man besser nicht tun…7

35 Benutzer haben abgestimmt. 7 Benutzer haben sich enthalten.

Quelle: habr.com

60GB SSD 8Gb DDR4