lxcfs

LXCFS

Introdução

O LXCFS é um pequeno sistema de arquivos de fusíveis escrito com a intenção de fazer com que os contêineres Linux pareçam mais uma máquina virtual. Tudo começou como um projeto lateral do LXC , mas é utilizável em qualquer tempo de execução.

O LXCFS cuidará de que as informações fornecidas por arquivos cruciais em procfs como:

 /proc/cpuinfo
/proc/diskstats
/proc/meminfo
/proc/stat
/proc/swaps
/proc/uptime
/proc/slabinfo
/sys/devices/system/cpu/online

estão cientes do contêiner, de modo que os valores exibidos (por exemplo /proc/uptime ) realmente refletem quanto tempo o contêiner está em execução e não quanto tempo o host está em execução.

Antes da implementação de namespaces do CGROUP da Serge Hallyn LXCFS também forneceu uma árvore cgroupfs ciente do contêiner. Cuidou -se de que o contêiner só tinha acesso a cgroups abaixo de seus próprios cgroups e, portanto, forneceu segurança adicional. Para sistemas sem suporte para namespaces cgroup, LXCFS ainda fornecerá esse recurso, mas é considerado principalmente depreciado.

Atualizando LXCFS sem reiniciar

LXCFS é dividido em uma biblioteca compartilhada (um módulo Libtool, para ser preciso) liblxcfs e um lxcfs binário simples. Ao atualizar para uma versão mais recente do LXCFS o binário lxcfs não será reiniciado. Em vez disso, detectará que uma nova versão da biblioteca compartilhada está disponível e a recarregará usando dlclose(3) e dlopen(3) . Esse design foi escolhido para que o loop principal do fusível que LXCFS usa não precisará ser reiniciado. Se fosse, todos os recipientes que usam LXCFS precisariam ser reiniciados, pois eles seriam deixados com suportes de fusíveis quebrados.

Para forçar uma recarga da biblioteca compartilhada na próxima instância possível, basta enviar SIGUSR1 para o PID do processo LXCFS em execução. Isso pode ser tão simples quanto fazer:

 rm /usr/lib64/lxcfs/liblxcfs.so # MUST to delete the old library file first
cp liblxcfs.so /usr/lib64/lxcfs/liblxcfs.so # to place new library file
kill -s USR1 $(pidof lxcfs) # reload

Musl

Para obter atualizações suaves por meio de recarga da biblioteca compartilhada, LXCFS também se baseia no fato de que quando dlclose(3) diminui a última referência aos destruidores da biblioteca compartilhada e quando dlopen(3) é chamado de construtores. Embora isso seja verdade para glibc , não é verdade para musl (consulte a seção de descarga de bibliotecas.). Portanto, os usuários do LXCFS no musl são aconselhados a reiniciar completamente LXCFS e todos os contêineres que usam isso.

Prédio

Para criar o LXCFS, instale o fusível e os cabeçalhos de desenvolvimento de fusíveis de acordo com sua distro. O LXCFS prefere fuse3 , mas funciona com novas versões fuse2 o suficiente:

 git clone git://github.com/lxc/lxcfs
cd lxcfs
meson setup -Dinit-script=systemd --prefix=/usr build/
meson compile -C build/
sudo meson install -C build/

Para construir com os desinfetantes, você deve especificar -Db_sanitize=... opção para meson setup . Por exemplo, para ativar asan e Ubsan:

 meson setup -Dinit-script=systemd --prefix=/usr build/ -Db_sanitize=address,undefined
meson compile -C build/

Uso

O comando recomendado para executar o LXCFS é:

 sudo mkdir -p /var/lib/lxcfs
sudo lxcfs /var/lib/lxcfs

Um tempo de execução do contêiner que deseja usar LXCFS deve ligar o suporte dos arquivos apropriados aos locais corretos na inicialização do contêiner.

LXC

Para usar lxc.reboot.hook LXCFS com contêineres baseados /usr/share/lxcfs SystemD, você pode lxc.mount.hook o LXC 1.1.

 lxc.mount.auto = cgroup:mixed
lxc.autodev = 1
lxc.kmsg = 0
lxc.include = /usr/share/lxc/config/common.conf.d/00-lxcfs.conf

Usando com o Docker

 docker run -it -m 256m --memory-swap 256m 
      -v /var/lib/lxcfs/proc/cpuinfo:/proc/cpuinfo:rw 
      -v /var/lib/lxcfs/proc/diskstats:/proc/diskstats:rw 
      -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw 
      -v /var/lib/lxcfs/proc/stat:/proc/stat:rw 
      -v /var/lib/lxcfs/proc/swaps:/proc/swaps:rw 
      -v /var/lib/lxcfs/proc/uptime:/proc/uptime:rw 
      -v /var/lib/lxcfs/proc/slabinfo:/proc/slabinfo:rw 
      -v /var/lib/lxcfs/sys/devices/system/cpu:/sys/devices/system/cpu:rw 
      ubuntu:18.04 /bin/bash

Em um sistema com swap ativado, o parâmetro "-u" pode ser usado para definir todos os valores em "Meminfo" que se referem à troca para 0.

sudo lxcfs -u/var/lib/lxcfs

Manuseio de troca

Se você notou que o LXCFS não mostrava nenhuma troca no seu contêiner, apesar de ter trocado no seu sistema, leia esta seção cuidadosamente e procure instruções sobre como ativar a contabilidade de swap para sua distribuição.

O manuseio do troca de cgroup no Linux é muito confuso e simplesmente não é uma maneira perfeita para o LXCFS lidar com isso.

Terminologia usada abaixo:

• Ram refere -se a memory.usage_in_bytes e memory.limit_in_bytes
• RAM+SWAP refere -se a memory.memsw.usage_in_bytes e memory.memsw.limit_in_bytes

As principais questões são:

• A contabilidade de troca geralmente é optada e, exigindo uma opção especial de tempo de inicialização do kernel ( swapaccount=1 ) e/ou opções especiais de compilação do kernel ( CONFIG_MEMCG_SWAP ).

• Um limite de RAM e um limite de troca RAM+podem ser definidos. O Delta, no entanto, não é o espaço de troca disponível, pois o kernel ainda está livre para trocar tanto do RAM quanto parece. Isso torna impossível renderizar um tamanho de dispositivo de troca como o uso do delta entre a RAM e a troca de RAM+para isso não explicaria o kernel trocando mais páginas, levando ao uso do uso de troca excedendo.

• É impossível desativar a troca em um determinado recipiente. O mais próximo que pode ser feito é definir o swappiness para 0, o que limita severamente o risco de trocar as páginas, mas não a elimina.

Como resultado, os LXCFs tiveram que fazer algum compromisso que seguem o seguinte:

• Quando a contabilidade de troca não está ativada, nenhum espaço de troca é relatado. Isso é simplesmente porque não há como saber o consumo de troca. O contêiner pode muito estar usando alguma troca, mas não há como saber quanto disso e mostrar um dispositivo de troca exigiria algum tipo de uso de troca a ser relatado. Mostrar o valor do host estaria completamente errado, mostrar que um valor 0 seria errado.

• Como o uso de swap para um determinado contêiner pode exceder o delta entre RAM e RAM+SWAP, o tamanho da troca é sempre o menor do limite de troca de RAM+ou do próprio dispositivo de troca do host. Isso garante que, em nenhum ponto, o uso da troca poderá exceder o tamanho da troca.

• Se o swappiness for definido como 0 e não houver uso de troca, nenhuma troca será relatada. No entanto, se houver uso de troca, será relatado um dispositivo de troca do tamanho do uso (100% completo). Isso fornece relatórios adequados do consumo de memória, ao mesmo tempo em que os aplicativos assumem que mais swap estão disponíveis.

Relatórios de emissão

Dump do núcleo

No caso de falha no LXCFS, pode ser extremamente útil ter um despejo principal da memória do processo LXCFS.

1. Por favor, verifique /var/crash e coredumpctl list apenas se você já possui um arquivo de despejo lxcfs núcleo
2. Caso contrário, você pode usar a seguinte maneira para coletá -lo do seu sistema:

Na máquina onde você executa LXCFs, execute como raiz:

 # save an old core_pattern setting value:
cat /proc/sys/kernel/core_pattern > /root/core_pattern.old_value.bak

# set a new one to collect all core dumps:
echo '|/bin/sh -c $@ -- eval exec gzip --fast > /var/crash/core-%e.%p.gz' > /proc/sys/kernel/core_pattern

# wait for the next LXCFS crash and check
ls -lah /var/crash

# there should be a file with a name like "core-lxcfs.80581.gz". Please, upload it somewhere and share with us.

# restore the old "core_pattern" value:
cat /root/core_pattern.old_value.bak > /proc/sys/kernel/core_pattern