ProHoster > Blog > administration > Bref aperçu et configuration des conteneurs Kata

Bref aperçu et configuration des conteneurs Kata

Bref aperçu et configuration des conteneurs Kata
Cet article explique comment cela fonctionne Conteneurs Kata, et il y aura aussi une partie pratique avec leur connexion à Docker.

À propos des problèmes courants avec Docker et leurs solutions déjà c'était écrit, aujourd'hui, je vais décrire brièvement l'implémentation de Kata Containers. Kata Containers est un runtime de conteneur sécurisé basé sur des machines virtuelles légères. Travailler avec eux est le même qu'avec d'autres conteneurs, mais en plus, il existe une isolation plus fiable grâce à la technologie de virtualisation matérielle. Le projet a débuté en 2017, lorsque la communauté du même nom a achevé la fusion des meilleures idées d'Intel Clear Containers et Hyper.sh RunV, après quoi les travaux se sont poursuivis sur la prise en charge de diverses architectures, notamment AMD64, ARM, IBM p- et z. -série. De plus, travaillez à l'intérieur des hyperviseurs QEMU, Firecracker est pris en charge et il existe également une intégration avec containerd. Le code est disponible sur GitHub sous licence MIT.

Caractéristiques principales

  • Travaillant avec un cœur séparé, assurant ainsi une isolation réseau, mémoire et E/S, il est possible de forcer l'utilisation de l'isolation matérielle basée sur des extensions de virtualisation
  • Prise en charge des normes de l'industrie, y compris OCI (format de conteneur), Kubernetes CRI
  • Performances constantes des conteneurs Linux classiques, isolement accru sans la surcharge de performances des machines virtuelles classiques
  • Élimine le besoin d'exécuter des conteneurs dans des machines virtuelles à part entière, les interfaces génériques simplifient l'intégration et le lancement

Installation

Il est beaucoup options d'installation, j'envisagerai d'installer à partir des référentiels, basés sur le système d'exploitation Centos 7.
Il est important: Le travail de Kata Containers n'est pris en charge que sur le matériel, le transfert de virtualisation ne fonctionne pas toujours, également besoin de support sse4.1 du processeur.

L'installation de Kata Containers est assez simple :

Installez les utilitaires pour travailler avec les dépôts :

# yum -y install yum-utils

Désactivez Selinux (c'est plus correct à configurer, mais pour plus de simplicité je le désactive) :

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

Nous connectons le référentiel et effectuons 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

réglage

Je vais me mettre en place pour travailler avec docker, son installation est typique, je ne la décrirai pas plus en détail :

# 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 à daemon.json :

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

Redémarrez le menu fixe :

# service docker restart

Bilan de santé

Si vous démarrez le conteneur avant de redémarrer docker, vous pouvez voir que uname donnera 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 un redémarrage, la version du noyau ressemble à ceci :

# 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 d'équipes !

# 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 de la virtualisation - j'exécute sysbench, comme exemples principaux prendre cette option.

Exécution de sysbench à l'aide de Docker+containerd

Test du processeur

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 20000

Initializing worker threads...

Threads started!

General statistics:
    total time:                          36.7335s
    total number of events:              10000
    total time taken by event execution: 36.7173s
    response time:
         min:                                  3.43ms
         avg:                                  3.67ms
         max:                                  8.34ms
         approx.  95 percentile:               3.79ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   36.7173/0.00

Test de RAM

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Initializing worker threads...

Threads started!

Operations performed: 104857600 (2172673.64 ops/sec)

102400.00 MiB transferred (2121.75 MiB/sec)

General statistics:
    total time:                          48.2620s
    total number of events:              104857600
    total time taken by event execution: 17.4161s
    response time:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.17ms
         approx.  95 percentile:               0.00ms

Threads fairness:
    events (avg/stddev):           104857600.0000/0.00
    execution time (avg/stddev):   17.4161/0.00

Exécution de sysbench à l'aide de conteneurs Docker + Kata

Test du processeur

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Prime numbers limit: 20000

Initializing worker threads...

Threads started!

General statistics:
    total time:                          36.5747s
    total number of events:              10000
    total time taken by event execution: 36.5594s
    response time:
         min:                                  3.43ms
         avg:                                  3.66ms
         max:                                  4.93ms
         approx.  95 percentile:               3.77ms

Threads fairness:
    events (avg/stddev):           10000.0000/0.00
    execution time (avg/stddev):   36.5594/0.00

Test de RAM

sysbench 1.0:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1
Initializing random number generator from current time

Initializing worker threads...

Threads started!

Operations performed: 104857600 (2450366.94 ops/sec)

102400.00 MiB transferred (2392.94 MiB/sec)

General statistics:
    total time:                          42.7926s
    total number of events:              104857600
    total time taken by event execution: 16.1512s
    response time:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.43ms
         approx.  95 percentile:               0.00ms

Threads fairness:
    events (avg/stddev):           104857600.0000/0.00
    execution time (avg/stddev):   16.1512/0.00

En principe, la situation est déjà claire, mais il est plus optimal d'exécuter les tests plusieurs fois, en supprimant les valeurs aberrantes et en faisant la moyenne des résultats, donc je ne fais pas encore plus de tests.

résultats

Malgré le fait que de tels conteneurs prennent environ cinq à dix fois plus de temps pour démarrer (le temps d'exécution typique pour des commandes similaires lors de l'utilisation de containerd est inférieur à un tiers de seconde), ils fonctionnent toujours assez rapidement si nous prenons le temps de démarrage absolu (il sont des exemples ci-dessus, commandes exécutées en moyenne en trois secondes). Eh bien, les résultats d'un test rapide du processeur et de la RAM montrent presque les mêmes résultats, ce qui ne peut que se réjouir, surtout à la lumière du fait que l'isolation est fournie à l'aide d'un mécanisme aussi bien géré que kvm.

annonce

L'article est une critique, mais il vous donne la possibilité de ressentir l'exécution alternative. De nombreux domaines d'application ne sont pas couverts, par exemple, le site décrit la possibilité d'exécuter Kubernetes sur des conteneurs Kata. De plus, vous pouvez également exécuter une série de tests axés sur la recherche de problèmes de sécurité, la définition de restrictions et d'autres choses intéressantes.

Je demande à tous ceux qui ont lu et rembobiné ici de participer à l'enquête, dont dépendront les futures publications sur ce sujet.

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Dois-je continuer à publier des articles sur les Kata Containers ?

  • 80,0%Oui, écrivez plus !28

  • 20,0%Non, ne…7

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

Source: habr.com

Ajouter un commentaire