ProHoster > Blog > administración > Breve descripción y configuración de Kata Containers

Breve descripción y configuración de Kata Containers

Breve descripción y configuración de Kata Containers
Este artículo discutirá cómo funciona Contenedores de Kata, y también habrá una parte práctica con su conexión a Docker.

Sobre problemas comunes con Docker y sus soluciones ya fue escrito, hoy describiré brevemente la implementación de Kata Containers. Kata Containers es un tiempo de ejecución de contenedor seguro basado en máquinas virtuales livianas. Trabajar con ellos es igual que con otros contenedores, pero además hay un aislamiento más confiable usando tecnología de virtualización de hardware. El proyecto comenzó en 2017, cuando la comunidad del mismo nombre completó la fusión de las mejores ideas de Intel Clear Containers y Hyper.sh RunV, luego de lo cual se continuó trabajando en el soporte para varias arquitecturas, incluidas AMD64, ARM, IBM p- y z. -serie. Además, se admite el trabajo dentro de los hipervisores QEMU, Firecracker y también hay integración con containerd. El código está disponible en GitHub bajo la licencia del MIT.

Características principales

  • Al trabajar con un núcleo separado, proporcionando así aislamiento de red, memoria y E/S, es posible forzar el uso de aislamiento de hardware basado en extensiones de virtualización
  • Soporte para estándares de la industria, incluido OCI (formato de contenedor), Kubernetes CRI
  • Rendimiento uniforme de los contenedores de Linux normales, mayor aislamiento sin la sobrecarga de rendimiento de las máquinas virtuales normales
  • Elimine la necesidad de ejecutar contenedores dentro de máquinas virtuales completas, las interfaces genéricas simplifican la integración y el lanzamiento

Instalación

Hay muchos opciones de instalación, consideraré instalar desde los repositorios, basado en el sistema operativo Centos 7.
Es importante: El trabajo de Kata Containers solo se admite en hardware, el reenvío de virtualización no siempre funciona, también necesita soporte sse4.1 del procesador.

Instalar Kata Containers es bastante simple:

Instalar utilidades para trabajar con repositorios:

# yum -y install yum-utils

Deshabilitar Selinux (es más correcto configurarlo, pero por simplicidad lo deshabilito):

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

Conectamos el repositorio y realizamos la instalación

# 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

Ajuste

Estaré configurando para trabajar con docker, su instalación es típica, no lo describiré con más detalle:

# 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

Realizamos cambios en daemon.json:

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

Reiniciar ventana acoplable:

# service docker restart

Verificación funcional

Si inicia el contenedor antes de reiniciar la ventana acoplable, puede ver que uname le dará la versión del kernel que se ejecuta en el sistema 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

Después de reiniciar, la versión del kernel se ve así:

# 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

¡Más equipos!

# 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

Pruebas de carga rápida

Para evaluar las pérdidas de la virtualización, ejecuto sysbench, como ejemplos principales toma esta opción.

Ejecutando sysbench usando Docker+containerd

Prueba del procesador

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

prueba 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

Ejecutar sysbench usando Docker+Kata Containers

Prueba del procesador

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

prueba 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 principio, la situación ya está clara, pero es más óptimo ejecutar las pruebas varias veces, eliminando los valores atípicos y promediando los resultados, por lo que no hago más pruebas todavía.

Hallazgos

A pesar del hecho de que estos contenedores tardan entre cinco y diez veces más en iniciarse (el tiempo de ejecución típico para comandos similares cuando se usa containerd es menos de un tercio de segundo), todavía funcionan bastante rápido si tomamos el tiempo de inicio absoluto (hay son ejemplos anteriores, comandos ejecutados en un promedio de tres segundos). Bueno, los resultados de una prueba rápida de CPU y RAM muestran casi los mismos resultados, que no pueden sino alegrarse, especialmente a la luz del hecho de que el aislamiento se proporciona utilizando un mecanismo tan bien ejecutado como kvm.

anuncio

El artículo es una revisión, pero le brinda la oportunidad de sentir el tiempo de ejecución alternativo. Muchas áreas de aplicación no están cubiertas, por ejemplo, el sitio describe la capacidad de ejecutar Kubernetes sobre Kata Containers. Además, también puede ejecutar una serie de pruebas enfocadas en encontrar problemas de seguridad, establecer restricciones y otras cosas interesantes.

Pido a todos los que han leído y rebobinado aquí que participen en la encuesta, de la que dependerán futuras publicaciones sobre este tema.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Debo seguir publicando artículos sobre Kata Containers?

  • 80,0%¡Sí, escribe más!28

  • 20,0%No, no… 7

35 usuarios votaron. 7 usuarios se abstuvieron.

Fuente: habr.com

Añadir un comentario