ProHoster > Blog > Administración > Breve descrición e configuración de Kata Containers

Breve descrición e configuración de Kata Containers

Breve descrición e configuración de Kata Containers
Este artigo discutirá como funciona Contenedores Kata, e tamén haberá unha parte práctica coa súa conexión con Docker.

Sobre os problemas comúns con Docker e as súas solucións xa foi escrito, hoxe describirei brevemente a implementación de Kata Containers. Kata Containers é un tempo de execución de contedores seguro baseado en máquinas virtuais lixeiras. Traballar con eles é o mesmo que con outros contedores, pero ademais hai un illamento máis fiable mediante a tecnoloxía de virtualización de hardware. O proxecto comezou en 2017, cando a comunidade do mesmo nome completou a fusión das mellores ideas de Intel Clear Containers e Hyper.sh RunV, tras o cal continuou o traballo no soporte para varias arquitecturas, incluíndo AMD64, ARM, IBM p- e z. -serie. Ademais, o traballo é compatible dentro dos hipervisores QEMU, Firecracker, e tamén hai integración con containerd. O código está dispoñible en GitHub baixo a licenza MIT.

Características clave

  • Traballando cun núcleo separado, proporcionando así rede, memoria e illamento de E/S, é posible forzar o uso de illamento de hardware baseado en extensións de virtualización
  • Soporte para estándares da industria, incluíndo OCI (formato de contedor), Kubernetes CRI
  • Rendemento consistente dos contedores Linux habituais, aumento do illamento sen a sobrecarga de rendemento das máquinas virtuales habituais
  • Elimina a necesidade de executar contedores dentro de máquinas virtuais completas, as interfaces xenéricas simplifican a integración e o lanzamento

Instalación

Ten Conxunto de opcións de instalación, considerarei instalar desde os repositorios, baseados no sistema operativo Centos 7.
É importante: o traballo de Kata Containers só é compatible con hardware, o reenvío de virtualización non sempre funciona tamén necesita soporte sse4.1 do procesador.

Instalar Kata Containers é bastante sinxelo:

Instalar utilidades para traballar con repositorios:

# yum -y install yum-utils

Desactive Selinux (é máis correcto de configurar, pero por simplicidade desactívoo):

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

Conectamos o repositorio e realizamos a 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

axuste

Estarei configurando para traballar con docker, a súa instalación é típica, non a describirei con máis 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

Facemos cambios en daemon.json:

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

Reiniciar docker:

# service docker restart

Probas Funcionais

Se inicias o contedor antes de reiniciar Docker, podes ver que uname dará a versión do núcleo que se executa no 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

Despois dun reinicio, a versión do núcleo ten o seguinte aspecto:

# 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áis 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

Proba de carga rápida

Para avaliar as perdas da virtualización, executo sysbench, como exemplos principais toma esta opción.

Execución de sysbench usando Docker+containerd

Proba do 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

Proba 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

Execución de sysbench usando Docker+Kata Containers

Proba do 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

Proba 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, a situación xa está clara, pero é máis óptimo realizar as probas varias veces, eliminando os valores atípicos e facendo a media dos resultados, polo que aínda non fago máis probas.

Descubrimentos

A pesar de que estes contedores tardan entre cinco e dez veces máis en iniciarse (o tempo de execución típico para comandos similares cando se usa containerd é inferior a un terzo de segundo), aínda funcionan bastante rápido se tomamos a hora de inicio absoluta (aí son exemplos anteriores, comandos realizados nunha media de tres segundos). Ben, os resultados dunha proba rápida de CPU e RAM mostran case os mesmos resultados, que non poden menos que alegrarse, especialmente á luz do feito de que o illamento se proporciona mediante un mecanismo tan ben executado como kvm.

Anuncio

O artigo é unha revisión, pero dáche a oportunidade de sentir o tempo de execución alternativo. Moitas áreas de aplicación non están cubertas, por exemplo, o sitio describe a capacidade de executar Kubernetes enriba de Kata Containers. Ademais, tamén pode realizar unha serie de probas centradas en atopar problemas de seguridade, establecer restricións e outras cousas interesantes.

Pídolle a todos os que leron e rebobinaron aquí que participen na enquisa, da que dependerán futuras publicacións sobre este tema.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Debo seguir publicando artigos sobre Kata Containers?

  • 80,0%Si, escribe máis!28

  • 20,0%Non, non... 7

Votaron 35 usuarios. 7 usuarios abstivéronse.

Fonte: www.habr.com

Engadir un comentario