🥇Vue d'ensemble et configuration de Kata Containers

Cet article examinera le principe de fonctionnement Kata Containers, et il y aura également une partie pratique sur leur connexion à Docker.

Sur les problèmes généraux avec Docker et les solutions possibles, il a déjà été écrit, aujourd'hui je vais brièvement décrire la mise en œuvre de Kata Containers. Kata Containers est un environnement d'exécution (runtime) de conteneurs basé sur des machines virtuelles légères. Le travail avec eux se déroule comme avec d'autres conteneurs, mais il y a une isolation plus robuste en utilisant la technologie de virtualisation matérielle. Le projet a commencé en 2017, la communauté éponyme a alors terminé la fusion des meilleures idées d'Intel Clear Containers et de Hyper.sh RunV, après quoi le travail a continué sur le support de différentes architectures, y compris AMD64, ARM, IBM p- et z-series. De plus, le travail à l'intérieur des hyperviseurs QEMU, Firecracker est pris en charge, ainsi qu'une intégration avec containerd. Le code est disponible sur GitHub sous licence MIT.

Fonctionnalités principales

Le travail avec un noyau distinct assure ainsi l'isolation réseau, la mémoire et les opérations d'entrée-sortie, offrant la possibilité d'utiliser de manière forcée l'isolation matérielle basée sur des extensions de virtualisation.
Le support des normes industrielles, y compris OCI (format de conteneurs), Kubernetes CRI.
Performance stable des conteneurs Linux classiques, augmentation de l'isolation sans surcoût affectant la performance des machines virtuelles classiques.
Élimination de la nécessité de faire fonctionner des conteneurs à l'intérieur de machines virtuelles complètes, des interfaces standard simplifient l'intégration et le démarrage.

Installation

Oui de nombreux pour les variantes d'installation, je vais examiner l'installation à partir des dépôts, basée sur le système d'exploitation Centos 7.
Important: le fonctionnement de Kata Containers n'est pris en charge que sur du matériel, le passage de la virtualisation ne fonctionne pas toujours, de plus le processeur doit prendre en charge sse4.1. du processeur.

L'installation de Kata Containers est assez simple :

Nous installons les utilitaires pour travailler avec les dépôts :

# yum -y install yum-utils

Nous désactivons Selinux (idéalement — le configurer, mais pour la simplicité, je le désactive) :

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

Nous connectons le dépôt et procédons à l'installation

# 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

Configuration

Je vais procéder à la configuration pour travailler avec docker, son installation est standard, je ne vais pas la détailler davantage :

# 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

Nous apportons des modifications au daemon.json :

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

Nous redémarrons docker :

# service docker restart

Vérification de la fonctionnalité

Si nous lançons un conteneur avant le redémarrage de docker, nous pouvons voir que uname affiche la version du noyau en cours d'exécution sur le système principal :

# 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

Après le redémarrage — la version du noyau apparaît ainsi :

# 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

Plus de commandes !

# 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 de charge rapide

Pour évaluer les pertes dues à la virtualisation – je lance sysbench, comme exemples principaux je prends cette option.

Lancement de sysbench avec Docker+containerd

Test du processeur

sysbench 1.0 : benchmark d'évaluation système multi-threadé

Exécution du test avec les options suivantes :
Nombre de threads : 1
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Limite des nombres premiers : 20000

Initialisation des threads de travail...

Threads démarrés !

Statistiques générales :
    temps total :                          36,7335s
    nombre total d'événements :              10000
    temps total pris par l'exécution de l'événement : 36,7173s
    temps de réponse :
         min :                                  3,43ms
         moy. :                                  3,67ms
         max :                                  8,34ms
         approx. percentile 95 :               3,79ms

Équité des threads :
    événements (moy/stdev) :           10000,0000/0,00
    temps d'exécution (moy/stdev) :   36,7173/0,00

Test de la mémoire vive

sysbench 1.0 : benchmark d'évaluation système multi-threadé

Exécution du test avec les options suivantes :
Nombre de threads : 1
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Initialisation des threads de travail...

Threads démarrés !

Opérations effectuées : 104857600 (2172673,64 ops/sec)

102400,00 MiB transférés (2121,75 MiB/sec)

Statistiques générales :
    temps total :                          48,2620s
    nombre total d'événements :              104857600
    temps total pris par l'exécution de l'événement : 17,4161s
    temps de réponse :
         min :                                  0,00ms
         moy. :                                  0,00ms
         max :                                  0,17ms
         approx. percentile 95 :               0,00ms

Équité des threads :
    événements (moy/stdev) :           104857600,0000/0,00
    temps d'exécution (moy/stdev) :   17,4161/0,00

Lancement de sysbench avec Docker+Kata Containers

Test du processeur

sysbench 1.0 : benchmark d'évaluation système multi-threadé

Exécution du test avec les options suivantes :
Nombre de threads : 1
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Limite des nombres premiers : 20000

Initialisation des threads de travail...

Threads démarrés !

Statistiques générales :
    temps total :                          36,5747s
    nombre total d'événements :              10000
    temps total pris par l'exécution de l'événement : 36,5594s
    temps de réponse :
         min :                                  3,43ms
         moy. :                                  3,66ms
         max :                                  4,93ms
         approx. percentile 95 :               3,77ms

Équité des threads :
    événements (moy/stdev) :           10000,0000/0,00
    temps d'exécution (moy/stdev) :   36,5594/0,00

Test de la mémoire vive

sysbench 1.0 : benchmark d'évaluation système multi-threadé

Exécution du test avec les options suivantes :
Nombre de threads : 1
Initialisation du générateur de nombres aléatoires à partir de l'heure actuelle

Initialisation des threads de travail...

Threads démarrés !

Opérations effectuées : 104857600 (2450366,94 ops/sec)

102400,00 MiB transférés (2392,94 MiB/sec)

Statistiques générales :
    temps total :                          42,7926s
    nombre total d'événements :              104857600
    temps total pris par l'exécution de l'événement : 16,1512s
    temps de réponse :
         min :                                  0,00ms
         moy. :                                  0,00ms
         max :                                  0,43ms
         approx. percentile 95 :               0,00ms

Équité des threads :
    événements (moy/stdev) :           104857600,0000/0,00
    temps d'exécution (moy/stdev) :   16,1512/0,00

La situation est déjà claire, mais il est préférable de lancer les tests plusieurs fois, en éliminant les valeurs aberrantes et en moyenne les résultats, donc je ne fais pas encore plus de tests.

Conclusions

Bien que le lancement de tels conteneurs prenne environ cinq à dix fois plus de temps (le temps typique de lancement de commandes similaires avec containerd est inférieur à un tiers de seconde) — ils fonctionnent toujours assez rapidement en tenant compte du temps de lancement absolu (ci-dessus, des exemples montrent que les commandes s'exécutent en moyenne en trois secondes). Les résultats du test rapide du CPU et de la RAM montrent en fait des résultats identiques, ce qui est réjouissant, d'autant plus que l'isolement est assuré par un mécanisme aussi éprouvé que kvm.

Annonce

Cet article est une revue, mais il permet d'explorer un runtime alternatif. De nombreux domaines d'application ne sont pas couverts, par exemple, le site décrit la possibilité de lancer Kubernetes au-dessus de Kata Containers. De plus, il est possible de réaliser une série de tests visant à identifier des problèmes de sécurité, à appliquer des restrictions et d'autres aspects intéressants.

Je demande à tous ceux qui ont lu jusqu'ici de participer à ce sondage, dont dépendra la publication future sur ce sujet.

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Faut-il continuer à publier des articles sur Kata Containers ?

80,0%Oui, écris encore !28
20,0%Non, ce n'est pas nécessaire…7

35 utilisateurs ont voté. 7 utilisateurs se sont abstenu.

Source : habr.com

Aperçu et configuration des Kata Containers