ProHoster > Blog > Administração > Resumo e configuração do Kata Containers

Resumo e configuração do Kata Containers

Resumo e configuração do Kata Containers
Este artigo abordará o princípio de funcionamento Kata Containers, bem como incluirá uma parte prática com a sua conexão ao Docker.

Sobre os problemas gerais com o Docker e as opções para resolvê-los já foi escrito, hoje descreverei brevemente a implementação do Kata Containers. Kata Containers é um ambiente seguro de execução (runtime) de contêineres baseado em máquinas virtuais leves. O funcionamento com eles é semelhante ao de outros contêineres, mas há também uma isolamento mais robusto utilizando tecnologia de virtualização de hardware. O projeto começou em 2017, com a comunidade homônima finalizando a fusão das melhores ideias do Intel Clear Containers e do Hyper.sh RunV, após o qual o trabalho continuou na suporte a diferentes arquiteturas, incluindo AMD64, ARM, e séries IBM p- e z. Adicionalmente, é suportado o funcionamento dentro dos hipervisores QEMU, Firecracker, e existe integração com containerd. O código está disponível em GitHub sob a licença MIT.

Principais funcionalidades

  • O trabalho com um núcleo separado, assim assegura o isolamento de rede, memória e operações de entrada-saída, há a possibilidade de forçar o uso de isolamento de hardware baseado em extensões de virtualização
  • Suporte a padrões industriais, incluindo OCI (formato de contêineres), Kubernetes CRI
  • Desempenho estável de contêineres Linux comuns, aumentando o isolamento sem sobrecarga que afete o desempenho de máquinas virtuais convencionais
  • Eliminação da necessidade de executar contêineres dentro de máquinas virtuais completas, interfaces padronizadas simplificam a integração e o funcionamento

Instalação

Há múltiplas Para as opções de instalação, abordarei a instalação a partir dos repositórios, com base no sistema operacional CentOS 7.
Importante: o funcionamento do Kata Containers é suportado somente em hardware, a passagem de virtualização funciona nem sempre, além disso é necessário suporte a sse4.1 do processador.

A instalação do Kata Containers é bastante simples:

Instalamos utilitários para trabalhar com repositórios:

# yum -y install yum-utils

Desativamos o Selinux (o correto seria configurá-lo, mas para simplicidade estou desativando):

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

Conectamos o repositório e realizamos a instalação

# 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

Configuração

Farei a configuração para trabalhar com o docker, sua instalação é padrão, não a detalharei mais:

# 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

Fazemos as alterações no daemon.json:

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

Reiniciamos o docker:

# service docker restart

Verificação de integridade

Se você iniciar o contêiner antes de reiniciar o docker — pode-se ver que o uname exibirá a versão do núcleo em execução 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

Após o reinício — a versão do núcleo será assim:

# 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

Mais comandos!

# 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

Teste de carga rápida

Para avaliar as perdas decorrentes da virtualização — executo o sysbench, como exemplos principais escolho esta opção.

Execução do sysbench utilizando Docker+containerd

Teste de CPU

sysbench 1.0: benchmark de avaliação de sistema multi-threaded

Executando o teste com as seguintes opções:
Número de threads: 1
Inicializando gerador de números aleatórios a partir do tempo atual

Limite de números primos: 20000

Inicializando threads de trabalho...

Threads iniciadas!

Estatísticas gerais:
    tempo total:                          36.7335s
    número total de eventos:              10000
    tempo total gasto pela execução de eventos: 36.7173s
    tempo de resposta:
         min:                                  3.43ms
         avg:                                  3.67ms
         max:                                  8.34ms
         aprox.  95 percentil:               3.79ms

Justiça entre threads:
    eventos (avg/stddev):           10000.0000/0.00
    tempo de execução (avg/stddev):   36.7173/0.00

Teste de memória RAM

sysbench 1.0: benchmark de avaliação de sistema multi-threaded

Executando o teste com as seguintes opções:
Número de threads: 1
Inicializando gerador de números aleatórios a partir do tempo atual

Inicializando threads de trabalho...

Threads iniciadas!

Operações realizadas: 104857600 (2172673.64 ops/seg)

102400.00 MiB transferidos (2121.75 MiB/seg)

Estatísticas gerais:
    tempo total:                          48.2620s
    número total de eventos:              104857600
    tempo total gasto pela execução de eventos: 17.4161s
    tempo de resposta:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.17ms
         aprox.  95 percentil:               0.00ms

Justiça entre threads:
    eventos (avg/stddev):           104857600.0000/0.00
    tempo de execução (avg/stddev):   17.4161/0.00

Execução do sysbench utilizando Docker+Kata Containers

Teste de CPU

sysbench 1.0: benchmark de avaliação de sistema multi-threaded

Executando o teste com as seguintes opções:
Número de threads: 1
Inicializando gerador de números aleatórios a partir do tempo atual

Limite de números primos: 20000

Inicializando threads de trabalho...

Threads iniciadas!

Estatísticas gerais:
    tempo total:                          36.5747s
    número total de eventos:              10000
    tempo total gasto pela execução de eventos: 36.5594s
    tempo de resposta:
         min:                                  3.43ms
         avg:                                  3.66ms
         max:                                  4.93ms
         aprox.  95 percentil:               3.77ms

Justiça entre threads:
    eventos (avg/stddev):           10000.0000/0.00
    tempo de execução (avg/stddev):   36.5594/0.00

Teste de memória RAM

sysbench 1.0: benchmark de avaliação de sistema multi-threaded

Executando o teste com as seguintes opções:
Número de threads: 1
Inicializando gerador de números aleatórios a partir do tempo atual

Inicializando threads de trabalho...

Threads iniciadas!

Operações realizadas: 104857600 (2450366.94 ops/seg)

102400.00 MiB transferidos (2392.94 MiB/seg)

Estatísticas gerais:
    tempo total:                          42.7926s
    número total de eventos:              104857600
    tempo total gasto pela execução de eventos: 16.1512s
    tempo de resposta:
         min:                                  0.00ms
         avg:                                  0.00ms
         max:                                  0.43ms
         aprox.  95 percentil:               0.00ms

Justiça entre threads:
    eventos (avg/stddev):           104857600.0000/0.00
    tempo de execução (avg/stddev):   16.1512/0.00

A situação já está clara, mas é mais eficiente rodar os testes várias vezes, eliminando os outliers e calculando a média dos resultados. Portanto, por enquanto não farei mais testes.

Como resultado, obtemos um serviço de "monitoramento como serviço", automatizado na linha de produção de integração contínua. O desenvolvedor ou testador precisa apenas definir a lista de métricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lançamentos: todas as notificações sobre desempenho, consumo de recursos ou regressões arquitetônicas.

Apesar de que iniciar esses contêineres leva aproximadamente cinco a dez vezes mais tempo (o tempo típico para iniciar comandos semelhantes com containerd é menos de um terço de segundo) – eles ainda funcionam de maneira bastante rápida, se considerarmos o tempo absoluto de inicialização (acima há exemplos, e os comandos são executados em média em três segundos). Os resultados do teste rápido de CPU e RAM mostram resultados praticamente idênticos, o que é encorajador, especialmente considerando que a isolação é garantida por um mecanismo tão bem testado como o kvm.

Anúncio

O artigo é um panorama, mas permite explorar uma runtime alternativa. Muitas áreas de aplicação não são cobertas, como a possibilidade de executar Kubernetes sobre Kata Containers, descrita no site. Além disso, uma série de testes focados em identificar problemas de segurança, imposição de limites e outras questões interessantes também pode ser realizada.

Peço a todos que leram ou avançaram até aqui que participem da pesquisa, da qual dependerão as futuras publicações sobre este assunto.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.

Devo continuar publicando artigos sobre Kata Containers?

  • 80,0%Sim, escreva mais!28

  • 20,0%Não, não vale a pena…7

35 usuários votaram. 7 usuários se abstiveram.

Fonte: habr.com

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster