Como corrigir o comando top e as informações do sistema de arquivos /proc dentro de contêineres?

Em ambientes containerizados, ferramentas como top e ps frequentemente exibem informações do host em vez do contêiner, pois dependem do sistema de arquivos /proc que, por padrão, reflete os dados do host. Para resolver isso, o lxcfs pode ser empregado para virtualizar o /proc dentro do contêiner.

Procedimento para Implementação

Primeiramente, instale o lxcfs no host. A instalação pode variar conforme a distribuição; para sistemas baseados em Red Hat, use:

sudo yum install lxcfs

Em seguida, inicie o serviço e crie o ponto de montagem:

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

Ao executar um contêiner Docker, monte o diretório virtualizado no /proc do contêiner:

docker run -it -v /var/lib/lxcfs/proc:/proc:ro alpine sh

Dentro do contêiner, comandos como top agora exibirão apenas os processos e recursos do contêiner.

Como modificar o conteúdo de uma imagem no contêiner se o rootfs é montado como somente leitura?

As imagens de contêiner, como as baseadas em Ubuntu, são compostas por camadas somente leitura. Quando um contêiner é iniciado, uma camada de escrita é adicionada no topo usando um sistema de arquivos união (por exemplo, OverlayFS). Alterações dentro do contêiner ativam o mecanismo de cópia-na-escrita (Copy-on-Write): ao modificar um arquivo, ele é copiado da camada somente leitura para a camada de escrita, e as modificações ocorrem nessa nova cópia. Assim, a camada original permanece inalterada, permitindo que múltiplos contêineres compartilhem a mesma base de imagem.

Qual é o papel do namespace de Cgroup no isolamento de contêineres?

Introduzido no Linux 4.6, o namespace de Cgroup isola a visibilidade da hierarquia de Cgroups dentro de um contêiner. Sem ele, inspecionar /proc/[PID]/cgroup em um contêiner revelaria informações de Cgroups de todo o host. Com o namespace de Cgroup ativado, o contêiner só enxerga seus próprios grupos de recursos, reforçando a segurança e o isolamento. Para verificar, execute em um contêiner:

cat /proc/self/cgroup

A saída mostrará apenas os Cgroups associados ao contêiner, em contraste com a visibilidade total do host em kernels mais antigos.

Como o modo controlador do Kubernetes difere de um paradigma orientado a eventos?

O modo controlador no Kubernetes envolve monitoramento contínuo e reconciliação de estado: o controlador periodicamente verifica o estado real dos recursos (como Pods) e toma ações para alinhá-lo ao estado desejado. Em contraste, um sistema orientado a eventos reage a notificações pontuais (como criação ou atualização de um recurso), podendo perder eventos se o receptor não estiver disponível. O modo controlador garante consistência messmo com falhas intermitentes, enquanto sistemas orientados a eventos dependem da entrega confiável das notificações para manter a coerência.

Em aplicações distribuídas onde nós sincronizam dados, é necessário vincular um Pod a um Persistent Volume de forma exclusiva?

Se a aplicação suporta sincronização de dados entre nós durante a adição ou reconstrução, a vinculação um-para-um entre Pod e Persistent Volume (PV) pode não ser estritamente necessária. Isso ocorre porque a redundância de dados permite que o nó recupere informações de peers, reduzindo a dependência de armazenamento persistente específico. No entanto, fatores como desempenho de E/O, consistência de dados e requisitos de backup ainda podem justfiicar o uso de PVs dedicados, dependendo da arquitetura da aplicação.